Hey Martin, Nice to hear back from you && fully agree with you there. We should have at minimum a presence in the main maven repositories (like most of the java based apache projects) so qpid can be easily used in maven bases projects without manual installs in local repos.
Cheers, Sorin On Mon, Dec 13, 2010 at 2:32 AM, Martin Ritchie <[email protected]> wrote: > On 12 December 2010 22:13, Andrew Kennedy <[email protected]> > wrote: > > On 11 Dec 2010, at 18:59, Marnie McCormack wrote: > >> > >> Much as I hate to raise the subject - isn't this primarily a debate > about > >> dependency management ? > >> > >> I have the same problems using IntelliJ. It was pretty much the onlt > thing > >> I > >> liked about the maven build -> generated project files ! > >> How about using the ant-eclipse generator, has anyone been using it ? > >> http://ant-eclipse.sourceforge.net/ > > > > Interesting, thanks. If it works like the Maven 'mvn eclipse:eclipse' > (or, > > of course, something like 'mvn intellij:intellij' which I believe does > the > > same thing Marnie mentioned, from the command line) then great. I have > had a > > brief look, and it seems useful. The problem is then how we cater for the > > two choices for project setup in an IDE, namely: > > > > a.) Load all modules (most directories under 'qpid/java') as separate > > projects, and manage inter-project dependencies, as well as the external > > ones, in the CLASSPATH. > > b.) Create a single project with all module source directories loaded, > and > > only reference external library dependencies (from 'qpid/java/lib') in > the > > CLASSPATH. > > > > I use method b. (as does Robbie, see previous discussion) however we > should > > probably support both, using e.g. 'ant eclipse' for a. which would > recurse > > through modules doing the same, which would be quite simple with the Ant > > 'module.xml' build file, and then 'ant eclipse-single' for b. which can > go > > in the main 'build.xml' file? > > I use method a) with intelij and I agree the time take to setup such a > project is quite annoying. Getting the right libraries for each module > and module interdependency set up takes a bit of 'local knowledge'. I > even went as far as having a script to copy Intelij files between > checkouts. > > 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. > > 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>The new > version 10 of Intelij is fantastic, orders of magnitude better than > eclipse and better still open source devs can apply for a free license > for the Ultimate edition.</plug> > > 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 > > 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. > > Cheers, > Martin > > > > On 11 Dec 2010, at 02:39, Robbie Gemmell wrote: > >> > >> You can use the existing build.xml files to run the build etc within > >> Eclipse, I don't think there is anything specific needing done there. > >> Running individual tests etc using the built in JUnit plugin is another > >> matter, and needs quite a lot of configuration. Again though, I tend to > >> use > >> the cmd line for all these tasks. > > > > You're right, this is what I was thinking of. Running the JUnit tests > easily > > inside an IDE would be a useful goal, and would make things easier for a > lot > > of people, certainly. Not sure that any of the proposed mechanisms would > > solve this problem? > > > >> I'm not sure compatibility would be a problem, the files are pretty > simple > >> and don't seem to have changed for as long as I've ever looked inside > >> them. > >> Differences between developer preference is what will cause issues most > I > >> think. > > > > I *have* had issues when upgrading Eclipse and have had to re-import > broken > > projects, of course, this could always have been user-error ;) Developer > > preference is probably the thing to keep in mind here. > > > >> Example project files could always be checked in to a directory in the > >> tree, > >> rather than into a location Eclipse would actually pick them up directly > >> and > >> use them. Of course, then they will simply become out date if no one > kept > >> them fresh, defeating the point. > > > > > > True, but shouldn't this go into the developer documentation, with links > or > > attachments for examples for various IDEs? Someone still has to keep the > > documentation up to date, obviously. This would still give developers the > > freedom to choose their workflow, without worrying about 'svn update' or > > whatever doing something bad to their IDE. > > > > 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. > > > > Cheers, > > 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] > > > > > > > > -- > Martin Ritchie > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Sorin S
