>> Doing the same thing in Maven requires us to setup a new top levelI want to increase the modularity of the server, but doing the source
>> directory with a bunch of new configuration files (.gitignore,
>> .settings/, pom.xml) and adds several seconds to the build while Maven
>> figures out how to parse that XML, start the necessary plugins, build
>> the JAR. It also further clutters the source tree. We can't just
>> partition on the Java package names.
> Good point, I agree with this.
code tree refactorings to please Maven scares me. So I just keep not
doing it. Maven is actively keeping me from making changes that are
probably valuable to the long-term health of the source tree. Yay--.
>> I say eventually here because step 1 is to replace Maven. Step 2 is toYes, based on the recent plugin work.. I am reconsidering the idea of
>> refactor the source tree into a more clean format. At least with Buck
>> there is no need to do these two steps as one big bang. Its not quite
>> like Maven where it ties your hands and (roughly) demands you follow
>> its rules... or else.
> I'm with you here... would even add third step 'convert modules to
> OSGi bundles' ;)
bundling an OSGi container and having Gerrit plugins managed by an
>>> In case of build performance, as far as I see we spent most of timeFor GWT yes. But it also depends on how may cores you have. If you
>>> compiling GWT code and replacing build system will not solve this problem.
>> Sure. But we run two copies of the GWT compiler now. And Maven doesn't
>> do anything in parallel. At least Buck will run steps in parallel
>> where it can.
> AFAIK GWT compiler since version 1.6 have option 'localWorkers' which
> allows you utilize all cpu's/core's so running two compilers in
> parallel doesn't really make sense.
have say 16 CPUs, we only use 6 during the GWT step, because we only
build 6 permutations of the web UI. On a 16-way system you could build
both GWT steps in parallel, if your build system knew what threads
The new acceptance-tests package makes it easier to run some sanity
checking under Maven, but its still not sufficient in my mind before
pushing a release.
See above about making the server more modular. The Maven way to do
> One thing that I learned during few
> years of using maven is that it works really great when you do
> everything 'the maven way' any customization in the process will hit
> you sooner or later...
this is to move my source files all over the tree and make lots of
more pom.xml files. I guess I could start doing this rather than
complaining about it, but its always been painful, e.g. the move to
create -openid or -cache-h2.
>> For me, I am only willing to keep Maven if someone can fix the release
>> build process so that I can't botch another rc. I'm not convinced this
>> is doable in Maven, and have no desire to spend a week of my own time
>> poking pom.xml trying to make it work.
Try that with Maven sometime.
You will go screaming for the hills, I just don't think its possible.
I say eventually here because step 1 is to replace Maven. Step 2 is to
refactor the source tree into a more clean format. At least with Buck
there is no need to do these two steps as one big bang. Its not quite
like Maven where it ties your hands and (roughly) demands you follow
its rules... or else.
> In case of build performance, as far as I see we spent most of time
> compiling GWT code and replacing build system will not solve this problem.
Sure. But we run two copies of the GWT compiler now. And Maven doesn't
do anything in parallel. At least Buck will run steps in parallel
where it can.
On Sun, Apr 28, 2013 at 2:19 AM, Alex Blewitt <alex.b...@gmail.com> wrote:
> On 28 Apr 2013, at 02:18, Shawn Pearce wrote:
>> https://gerrit-review.googlesource.com/45110 is still incomplete but
>> shows what a Buck based build format would look like and manages to
>> compile some sections of Gerrit's tree.
> As -1'd on the review:If you want to keep Maven, step up and fix the Maven build:
> Building on Windows is essential for developers that still use Windows as their primary development platform.
> Being able to use a standard IDE's tool support for performing compilation and project dependencies is far more important than the build tool itself. All major IDEs can deal with Maven builds and allow cross-platform builds.
Issue 1) Maven needs to build a correct release WAR with one command.
The fact that it can't do this is why I have dragged my feet on 2.6,
and why the rc1 was not built correctly. Its no longer fun to make a
release WAR of Gerrit. But at least make it work right so I can't do
Issue 2) Prolog predicates are broken in Eclipse.
I expect to be able to launch a debug server from Eclipse anytime.
Periodically Eclipse loses predicates from gerrit_common.pl and a
server startup crashes. Fix this.
Issue 3) Publishing API JARs is a disaster.
Everyone is complaining about this from their own plugin builds.
The API JARs aren't easy to make, aren't easy to get picked up,
etc. What we have isn't working.
As for me, I am done messing around with Maven pom.xml files. I might
look at buildr and try to prototype a build in that to compare against
the Buck prototype I have now, but Maven is dead to me.
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
From a first look, BUCK files seem much more readable than pom.xml files.
Can one also add python code to BUCK file(s) if a specific control logic needsto be programmed? This is usually quite difficult and ugly to do in maven.Take the following example from the gerrit-plugin-archetype/src/main/resources/archetype-resources/pom.xml<repositories><repository><id>gerrit-api-repository</id>#if ($gerritApiVersion.endsWith("SNAPSHOT"))#else#end</repository></repositories>Here we use velocity macros in order to generate proper url depending on the $gerritApiVersion.But this helps only for the initial plugin generation.Once a plugin skeleton is generated, we must make sure that the URL is correctevery time the gerritApiVersion changes.
If you use Buck for your plugin, assuming you copy Shawn's script and maven_jar macro, you'll likely specify the repo for your dependency, switching the constant when you change the dep version (or possibly using a new specific macro that does the if/else branching)