Hi All, This discussion is something worthy of its own thread with a meaningful subject name on dev.
There are quite a few opinions out there on the subject and likely requires a vote to make major changes. We've been through so many build system re-writes that I don't have much appetite for more. But I'm definitely not the voice of build - so a full discussion would be best. Regards, Marnie On Sat, Dec 18, 2010 at 3:19 PM, Andrew Kennedy < [email protected]> wrote: > On 13 Dec 2010, at 02:32, Martin Ritchie wrote: > >> If we are looking to technologies to track dependencies and module >> interdependencies then there are technologies out there that do all >> that for us. I know we experimented with maven back in the early days >> of their 2.0 release when the world was not quite ready for it but >> this really is its area of expertise. >> >> The biggest two issues we had were: >> 1) Problems with repeatable builds. >> 2) Unsuitability in downstream OS builds. >> >> Problem 1 was widely criticised in the Maven community and was down to >> core plugins not adhering to the offline status and updating behind >> the scenes. This has been addressed since 2.0 and the latest 2.2 >> release is very capable of performing repeatable builds. >> Problem 2 has also been addressed by the community. Specifically >> JPackage which addresses the problems of maven downloading 'random' >> binaries as long as a few simple rules are followed in the project >> setup. >> > > Agreed, Maven 2.x stream is very good, and 2.2 is very dependable, with an > excellent plugin ecosystem. It seems to be the build-system of choice for > most business Java applications, now that people realise it is much improved > over the 1.x releases... > > As for repeatable builds, this is very important for releases. But, > shouldn't we also be able to take advantage of things like depending on the > most recent 10.6.x release of Derby for bug-fixes automatically, and > similar, at least for our development versions like 0.9? > > > Using maven to define our project structure would drastically simplify >> our IDE setups, Intelij for example understand pom files directly so >> removes the old need to run the 'mvn intelij:intelij' command. This >> sounds like it would be of immediate benefit to Andrew. >> > > <plug><pulled /></plug> >> > > I like Eclipse. It has a 'vi' plugin for the editor. And good Maven > support, too... > > > The biggest benefit to the project and the community would be so that >> we can actually release our java modules to the maven repos. Something >> which despite the addition of scripting to generate pom files has yet >> to done for any Qpid release. Searching the Apache Nexus and official >> maven repos only finds a 0.6 Snapshot that has been released via >> ServiceMix. If we want to drive adoption of Qpid Java as an messaging >> solution then we should be making this a priority to address. Apache >> even provides guidance on to do it: >> http://www.apache.org/dev/publishing-maven-artifacts.html >> > > That's pretty bad. If your project libraries aren't easily integratable by > adding a dependency to a Maven POM file, your project might as well not > exist for many, many people. I should be able to go to 'jarvana.com' and > search for 'org.apache.qpid', and get the latest release, source and javadoc > Jar files. > > I think this hurts a lot of projects more than they realise. I know it has > prompted me to recommend switching libraries when I saw either out of date > or badly packaged POM files for various Java projects. Many times these were > as a result of the project maintainers not providing the POM files, and > therefore community-provided files were used, which had these problems. > > > For those concerned about our ant heritage we wouldn't have to give up >> our existing build system as the two would quite happily live >> together, integrating the ant build so that binaries can be generated >> for release would be trivial. >> > > True. > > But we don't just want to duplicate functionality, we should be using Maven > features to the full. For example, automated 'mvn site' and 'mvn report' > builds should be linked to from our main website. This shows people the > project dependency structure, APIs and so on. The 'mvn release' command > should also greatly simplify generating RCs in future as well, and the IDE > setup commands have been mentioned many times already... > > The other thing that appeals to me about this is that once we have split > the Java modules and defined the inter-module dependencies properly, we can > then start defining stricter interfaces between them and it becomes much > easier to build and deploy those modules as, say, part of an OSGi > application or framework. > > On 12 December 2010 22:13, Andrew Kennedy <[email protected]> >> wrote: >> >>> Anyway, I am willing to try and configure 'ant-eclipse' and see if we can >>> get something useful out of it? I'm still philosophically opposed to >>> putting >>> files under revision control that can be generated automatically, and are >>> not actually required for the project build, which is why this appeals to >>> me. >>> >> > > In fact, moving to Maven instead seems like a very good idea. Particularly, > as Martin points out, we can keep our existing Ant build files initially, > which would remain callable as AntRun plugin tasks. This simplifies getting > our artifacts out to repositories, and would really help in integrating with > other projects, which should drive both visibility and adoption. > > Anyway, that's now something to do over the holidays when I get bored ;) > > > Andrew. > -- > -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ; > -- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ; > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
