qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: build system
Date Wed, 09 Jan 2008 16:35:56 GMT
On 09/01/2008, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> 1) maven seems to suffer from unrepeatable builds, specifically:
>
> We do manage to use it repeatedly by preserving all dependencies when doing
> a release build. Do an on-line build to suck in all dependencies, then an
> off-line against the dependencies. All dependencies get preserved in an
> internal repository.
>
>  2) maven is unsuitable for OS distro builds, specifically:
>    - no true off-line build capability
>
> Yup, this seems to be a problem for Linux users. True off-line does work
> though, I build maven projects on my laptop when there is no net connection
> and it works just fine.
>
>    - can't pick up dependencies from standard filesystem locations.
>
> Can, but not if you want to release into central repo, as your file system
> is only visible locally. To participate in the maven Java OS ecosystem you
> need to only include dependencies that are also available in the central
> repo.
>
>  3) mvn clean doesn't clean up everything
>
> Does if you put all generated artefacts under /target (the maven way...).
>
>  4) javadoc doesn't work
>
> Mysterious, but I'm sure it can be made to. Certainly I have it working on
> other M2 projects.
>
>  5) there is no easy way to run the broker/examples/etc directly out
>     of a source build
>
> Not sure what you mean by this? Can't exec an external process? Can do that
> by injecting a little bit of ant into the maven build script.
>
>  6) we need to manually create poms for client.jar
>
> Also a bit ridiculous. Maven project ought to be able to correctly generate
> its poms, we are clearly using it in an unusual fashion if not. Again, I
> have this sort of thing working perfectly on other maven projects.
>
> I think only 2a is a genuine issue for linux users, and those wanting to
> build Java packages for linux distributions.
>
> I think the answer as to why we want to use Ant and not Maven or Buildr, is
> one of familiarity. There is a general consensus that those contributing to
> the Java are more familiar and comfortable with Ant and would see adoption
> of Ant as enabling them to get on with writing the software than wrestling
> with Maven. Which is fine, I have absolutely no problems with that. The real
> issue is that maven has a learning curve that most of us are not willing to
> climb (and some mysterious behaviours too).
>
> This would also be the reason for not attempting to use Buildr. It might be
> the latest thing, but its one more thing to learn, and none of us can
> guarantee that the end result will be any better.
>
> We should make a list of things that the current build system does that its
> replacement should also do. Here are the ones I can think of (aside from the
> obvious ones of building the .jars and .zips and .tar.gzs):
>
> Build a retro translated Java 1.4 version of the client.
> Create poms for all broker and client build artefacts, and suitably named
> and version stamped build artefacts, for inclusion in a maven 2 repository
> (a template pom and a little XSLT should do the trick from Ant).
> Perform builds that depend an all tests passing.
> Generate test scripts for performance tests, and package these tests as a
> distribution.
> Run checkstyle against the code.
> Run clover (or equivalent) against the tests.
> Include local properties for default log4j.configurations (so that each
> developer can use a local custom set up for it).
> Inject subversion revision numbers, project and module names into each .jar
> on every build, so that the source version for 'lost' jars can always be
> identified.
> Be able to start/stop an external broker to run tests against.
> Run the python tests against an external broker.
>
> Can anyone think of anything else?

We shouldn't also forget we created a bunch of Jiras relating to
features that the ant system had that maven didn't do when we started
using maven. AFAIR they were not all implemented so we should ensure
we include that functionality in any future build system

> Rupert
>
>
> On 09/01/2008, Robert Greig <robert.j.greig@gmail.com> wrote:
> >
> > On 09/01/2008, Rafael Schloming <rafaels@redhat.com> wrote:
> >
> > > We did briefly discuss this option. I believe the primary objection to
> > > buildr was from windows users who wished to avoid introducing a ruby
> > > dependency to the Java build.
> >
> > OK, that makes sense.
> >
> > RG
> >
>


-- 
Martin Ritchie

Mime
View raw message