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]
