gerrit builds and future directions
Shawn Pearce
I just submitted a pile of changes to master to make sure Maven does
the right thing by default. If you want the build to go faster you
need to add the magic flags necessary to skip the slow parts. If you
don't have AsciiDoc installed on your system, its your responsibility
to figure out how to make Maven not package the documentation.
I tried offering a better solution but our contributors love
themselves their Maven, so I'm pushing the problem back to them and
doing nothing.
Some fallout from keeping Maven:
- We are not going to eject any more functionality from the core
server. If its in gerrit master, its there to stay.
- There will be no new core plugins.
- The existing core plugins will be versioned the same as the core server.
- I was going to break OpenID and LDAP authentication support into
plugins. This refactoring will not happen. OpenID and LDAP support is
going to (basically) remain as-is in the core server.
- The core server will not move to an OSGi based container. Our
existing plugin infrastructure is staying. Refactoring the classpath
is not going to be easy and I have no desire to fix it in Maven.
- The UI is staying in GWT. I am not going to bring anything else into
this build mess. Using CodeMirror for the diff view is an exception I
am willing to consider making because of the high value it provides.
Shawn Pearce
> Some fallout from keeping Maven:
finding dependencies that we publish to
gerrit-maven.commondatastorage.googleapis.com. Maven works perfectly
fine and there is user support on other mailing lists.
Alex Blewitt
I just submitted a pile of changes to master to make sure Maven does
the right thing by default. If you want the build to go faster you
need to add the magic flags necessary to skip the slow parts. If you
don't have AsciiDoc installed on your system, its your responsibility
to figure out how to make Maven not package the documentation.
Shawn Pearce
unless you always use `mvn clean package`. I can't trust `mvn package`
to do the right thing. For example a few minutes ago it just packaged
two competing versions of JGit into the same WAR file. But this is OK
because Maven works correctly. So always use `mvn clean package`.
Shawn Pearce
laptop did. Apparently there is a bug in Maven where sometimes you
can't depend on the output of one module in the same Reactor build as
input to another module. Good thing I wasn't expecting a dependency
analysis or something from a build system. :-)
[1] http://jira.codehaus.org/browse/MDEP-187
Luca Milanesio
Everybody agrees that Maven is really painful, and m2e is even worse :-O ... so why don't we try to use the new build system and, if we have problems (o course we'll have plenty of them) just do as Saša and the others did: get everybody's help to sort it out collectively !!!
I would vote to stay on the innovation track for Gerrit 2.8 (shall we call it 3.0 then ?) with a new Build system.
Luca
---------
Sent from my iPhone
Luca Milanesio
Skype: lucamilanesio
> --
> 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.
>
>
Matthias Sohn
Moving away from Maven is hard, but innovation is based on experiments - trial and error - and is necessary to make things better, even if that means getting some new scars on our face.
Everybody agrees that Maven is really painful, and m2e is even worse :-O ... so why don't we try to use the new build system and, if we have problems (o course we'll have plenty of them) just do as Saša and the others did: get everybody's help to sort it out collectively !!!
I would vote to stay on the innovation track for Gerrit 2.8 (shall we call it 3.0 then ?) with a new Build system.
Saša Živkov
Moving away from Maven is hard, but innovation is based on experiments - trial and error - and is necessary to make things better, even if that means getting some new scars on our face.
Everybody agrees that Maven is really painful, and m2e is even worse :-O
... so why don't we try to use the new build system and, if we have problems (o course we'll have plenty of them) just do as Saša and the others did: get everybody's help to sort it out collectively !!!
I would vote to stay on the innovation track for Gerrit 2.8 (shall we call it 3.0 then ?) with a new Build system.
Blewitt, Alex [Tech]
There are three key problems with Buck as a build tool that aren’t going to be solved soon.
1. It doesn’t work on Windows. This may not be an issue if you do all your builds on OSX, but cross-platform compatibility has always been an important part of Java based open-source projects, and cutting off Windows users will alienate some from contributing.
2. There’s no direct integration with Eclipse or other IDEs. Yes, Maven has been around a long time, and is very regimented in the way that it works – but almost all IDEs support Maven out of the box for inter-project references and ability to resolve assets. Given that the average developer spends >90% of their time in their IDE and <10% of their time executing a build, the trade-off should be to focus on making the IDE experience better.
3. There isn’t a standard build which is widely available and has been used by the community for some time. ‘Build it yourself so you can build Gerrit’ is not a great trade-off, and only discourages contributions. Not only that, but not everyone has an open choice about which build tools to use; integration points with build systems (e.g. Jenkins) and artefact repositories (e.g. Nexus) are widely understood and used, and have subtle restrictions that may not be present for developers that have unfettered access to the internet.
In short, whilst Buck may have some advantages (and a build time of ‘about twice as fast’ may be one of them) it also brings a significant number of disadvantages to some. If the disadvantages can be overcome then it may be a worthwhile trade-off in the end, but it would be much better if time were spent building Gerrit than building a build system for Gerrit.
BTW the problems of having to refresh Eclipse periodically – especially when switching branches – would be dramatically reduced if the .project and .classpath files were checked into the repository as well. The fact that they aren’t is one of the key problems in projects disappearing and/or causing conflicts when switching between branches where one project exists and the other doesn’t.
Alex
Edwin Kempin
There are three key problems with Buck as a build tool that aren’t going to be solved soon.
1. It doesn’t work on Windows. This may not be an issue if you do all your builds on OSX, but cross-platform compatibility has always been an important part of Java based open-source projects, and cutting off Windows users will alienate some from contributing.
2. There’s no direct integration with Eclipse or other IDEs. Yes, Maven has been around a long time, and is very regimented in the way that it works – but almost all IDEs support Maven out of the box for inter-project references and ability to resolve assets. Given that the average developer spends >90% of their time in their IDE and <10% of their time executing a build, the trade-off should be to focus on making the IDE experience better.
3. There isn’t a standard build which is widely available and has been used by the community for some time. ‘Build it yourself so you can build Gerrit’ is not a great trade-off, and only discourages contributions. Not only that, but not everyone has an open choice about which build tools to use; integration points with build systems (e.g. Jenkins) and artefact repositories (e.g. Nexus) are widely understood and used, and have subtle restrictions that may not be present for developers that have unfettered access to the internet.
In short, whilst Buck may have some advantages (and a build time of ‘about twice as fast’ may be one of them) it also brings a significant number of disadvantages to some. If the disadvantages can be overcome then it may be a worthwhile trade-off in the end, but it would be much better if time were spent building Gerrit than building a build system for Gerrit.
BTW the problems of having to refresh Eclipse periodically – especially when switching branches – would be dramatically reduced if the .project and .classpath files were checked into the repository as well. The fact that they aren’t is one of the key problems in projects disappearing and/or causing conflicts when switching between branches where one project exists and the other doesn’t.
Alex
From: repo-d...@googlegroups.com [mailto:repo-d...@googlegroups.com] On Behalf Of Saša Živkov
Sent: 07 May 2013 09:33
To: Luca Milanesio
Cc: Shawn Pearce; repo-discuss
Subject: Re: gerrit builds and future directions
On Tue, May 7, 2013 at 8:30 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:
Moving away from Maven is hard, but innovation is based on experiments - trial and error - and is necessary to make things better, even if that means getting some new scars on our face.
Everybody agrees that Maven is really painful, and m2e is even worse :-O
Yes, I cannot count how many times I had to:
1. refresh projects in eclipse (because errors were reported where they don't exist)
2. after the 1. doesn't help: select-all-projects > right-click > Maven > Update Project ...
3. sometimes, remove and (re)import everything when 1 and 2 don't help
Werner Beroux
Dariusz Luksza
>
> Everybody agrees that Maven is really painful, and m2e is even worse :-O ... so why don't we try to use the new build system and, if we have problems (o course we'll have plenty of them) just do as Saša and the others did: get everybody's help to sort it out collectively !!!
>
> I would vote to stay on the innovation track for Gerrit 2.8 (shall we call it 3.0 then ?) with a new Build system.
plugins and OSGi. This would be a playground for next generation
Gerrit. I'm willing to help with all of those topics!
--
Best regards
GSM: +49 017 445 41235
Blog: http://luksza.org
LinkedIn: http://www.linkedin.com/in/dariuszluksza
Dariusz Luksza
<Alex.B...@gs.com> wrote:
> There are three key problems with Buck as a build tool that aren’t going to
> be solved soon.
>
> 1. It doesn’t work on Windows. This may not be an issue if you do all
> your builds on OSX, but cross-platform compatibility has always been an
> important part of Java based open-source projects, and cutting off Windows
> users will alienate some from contributing.
>
> 2. There’s no direct integration with Eclipse or other IDEs. Yes,
> Maven has been around a long time, and is very regimented in the way that it
> works – but almost all IDEs support Maven out of the box for inter-project
> references and ability to resolve assets. Given that the average developer
> spends >90% of their time in their IDE and <10% of their time executing a
> build, the trade-off should be to focus on making the IDE experience better.
>
> 3. There isn’t a standard build which is widely available and has been
> used by the community for some time. ‘Build it yourself so you can build
> Gerrit’ is not a great trade-off, and only discourages contributions. Not
> only that, but not everyone has an open choice about which build tools to
> use; integration points with build systems (e.g. Jenkins) and artefact
> repositories (e.g. Nexus) are widely understood and used, and have subtle
> restrictions that may not be present for developers that have unfettered
> access to the internet.
Eclipse should not be so popular because you cannot build on your own,
same goes for open/libre office, firefox, even jenkins.
The main problem here is that gerrit is not so expendable like
Eclipse, Firefox or Jenkins and therefore most adopters fork it to
achieve theirs goals. When I was contributing to EGit I didn't need to
ran full Eclipse build... We as gerrit contributors are use to run
builds on ours machines but maybe this is a problem, or rather mental
switch we need to make.
I'm getting into conclusion that build system should *only* fetch all
dependencies and make my IDE configuration easier (possibly generate
proper files) and I'm as a *developer* shouldn't bother about anything
else. Unfortunately most of persons that participate in this
discussion are developers and releaser's. I'm wondering what is the
perception of a person that do only gerrit development end don't
bother about release.
Yes, having one or two persons in a team that can release (or run a
full build) of your software is not comfortable... but lets make it
clear, eclipse release was build by *one* person for most of the days!
Only recently eclipse build is moving to maven+tycho...
Richard Bywater
Matthias Sohn
Just as a side question (and apologies if this has been covered in a thread which I missed), was Buck chosen for any particular reason to try over another build tool? For instance we use Gradle for our builds of our application - would that be suitable for the build process for instance?