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]
