JFrog: To Build or Not to Be
JFrog’s “To Build or Not to Be” seminar was an exceptional one. Usually, there are very few events fully devoted to the subject of builds and build tools. Lucky us we had this one with so many key people of today’s build arena:
- Hans Dockter: Gradle, @Gradleware, Gradle Inc.
- Frederic Simon and Yoav Landman: Artifactory, @artifrog, JFrog Ltd.
- Kohsuke Kawaguchi: Hudson, @hudsonci, InfraDNA, Inc.
- Sergey Anchipolevsky and Max Feldman: TeamCity, @teamcity, JetBrains
I allowed myself to ask participants some questions.
Sergey Anchipolevsky, Max Feldman – TeamCity:
“What does "Git (JetBrains)" Git integration of TeamCity mean?”
It’s just a version of Git plugin developed by JetBrains, to differentiate it from previous Git plugins.
“Is it possible to "tag" a YouTrack issue?”
That’s a YouTrack question but yes, you can tag an issue.
“Is it possible to backup YouTrack issues?”
Sure, you can schedule YouTrack database backups with a cron expression or run it manually.
“Is it possible to re-order YouTrack issues by drag-n-dropping them, similarly to how it is done in Nozbe?”
No, it can’t be done. YouTrack isn’t really a task management tool, like Nozbe. It is an issue tracker which is something different. The order between issues is specified by a "sort by" criteria so they can’t be arbitrarily re-ordered with drag-n-drop. But you should probably take a look at checkvist.com, a simpler task management tool developed by JetBrains developers.
“Ok, TeamCity question. What do you think of cloud-based TeamCity version, similar to Artifactory Online. Can it be done?”
Oh, that’s a good one. First of all, let’s get something clear. You can’t provide a SaaS solution for a build server. Normally, SaaS solutions, like Artifactory Online that you have mentioned, are based on a shared resources, hosted by provider. But something like a build server is too resource-hungry and can’t be shared with other users.
My comment: I agree. Experience shows how unshareable build servers are. You really want a dedicated machine for each one of them, trying to run too many builds on the same machine may quickly bring the server to its knees and overall response time drops dramatically.
But something else can be done. First of all, you can run build agents on EC2 today. Second, we can provide TeamCity images ready to be run on EC2 as well. But it’s always better if you run main TeamCity server inside your organization, on your own IT infrastructures. We haven’s seen too many customers willing to out-source the build server completely: networking issues, server configurations, additional setups, security .. it’s too much of a pain and, again, can hardly be shared between different users.
“I see, thank you. Is it possible to develop plugins for TeamCity?”
Sure!
Yoav Landman – Artifactory:
“After hearing your session about module development options in Java – what do you think of JPF? Is it somehow a player in today’s Java module-space?”
I looked at JPF several times before as an application level module system, but I don’t think it amounts to a Java language module system. You can incorporate it into an application but you can’t build or run a full application based strictly on JPF modules (last time I checked).
“You mentioned Java moduling system is not united and fragmented, we have lot’s of approaches and various repos available. Can “repo1″ be *the one*?”
It kind of is at the moment and there are no much alternatives available. I wish it would be more developer friendly, though.
“As people are running more and more Artifactory Online instances, does it contribute to overall module-space fragmentation? Don’t get me wrong, I love it and had a great success in providing a Maven support for the Groovy++ project with a help of groovypp.artifactoryonline.com. I have my own repo set up at evgeny-goldin.org/artifactory that I’m about to use for my personal projects. So it’s cool, by all means. Still, the fragmentation issue you have just mentioned during the session just made me wonder .. “
Having a central repository and a central URL to get things from is a great thing. However, Maven central brings some long-lasting issues with it: the existence of module developers is not obvious and artifacts cannot be linked back to them; publishing is not straightforward – rather than getting an account and a simple Web UI/REST deploy, you need to set up rsync or learn a commercial tool to do that – in both cases the final published artifact looses relation to its creator account; repositories provide no REST API, there’s no access to statistics, and mostly – no searches: rather than sending a query to Central you have to download index file and search on the client side. I think these are the main concerns that keep people managing their public repositories on apache/sf/google-code/svn/artifactory/nexus etc.
Hans Dockter – Gradle:
“Gradle is a truly awesome build tool. Are you planning to provide a way to invoke Maven plugins from Gradle?”
Yes, it is of very high priority, we will provide a way to “import” and run an existing "pom.xml"
“In fact, I was thinking more of invoking a plugin directly, given its <groupid>, <artifactid>, and <version>. Similarly to how it is done by Mojo Executor .. “
Ah, right, right, this one. Sure, it should be done as well, although it is not simple, you know. To invoke a Maven plugin you need to “bind” it with a Maven container but we may probably trick into thinking there’s a Maven container while it will be talking to a Gradle run-time environment. Anyway, it’s definitely on our TODO list.
“The reason I ask is to ease Maven to Gradle migration or simply re-use an existing Maven plugins, some of which are really good! Now, I believe Gradle is a great tool but it requires a serious understanding of what you’re doing. In some aspects, it reminds me of Git where some people consider it to be too complex sometimes”
Yes, there’s a need to provide a really simple guidance for a people to switch between the tools or adopt a new one, like Gradle. But you need to understand your tool, there’s no doubt about it.
…
It was time to say good bye. But I hope to see you all again!
A big thanks to Guy Nir and Shlomi Ben Haim for generously allowing me to use some of the photos they have made.
Spring: Ant-like files pattern matching Say “No” to ServletResponse.setContentLength()
