Paul's description is more or less how I handle it. The problem about components being independent, yet, the desire to have their presence in Eclipse override this is not new of course. When I was still working at SAP, we had a proprietary build system that could do this and behaved exactly as you'd expect, i.e. if the component is loaded in eclipse, it takes precedence over the downloaded built artifacts. The build system we use at IBM (jazz.net) manages this by using eclipse target platforms, but that only works because everything we do here sits in a plugin.
AFAIK, there is no proper solution to Jena's setup in Maven other than manually fixing the classpaths Simon From: Paul Gearon <[email protected]> To: [email protected] Date: 06/14/2012 02:06 PM Subject: Re: Building Jena in Eclipse Repeating stuff I said offline to Alex.... On Thu, Jun 14, 2012 at 10:20 AM, Alex Hall <[email protected]> wrote: > I did a check-out of the Jena source from SVN, and now I'm having a little > bit of trouble getting it set up in Eclipse. > > I'm using Eclipse 3.7 (Indigo) on Windows, Jave EE distribution, with the > m2e Maven plugin. > > When I import the Jena projects as Maven projects, they build (albeit with > Maven warnings) but m2e generates a lot of cruft that gets SVN confused, > which tells me that this isn't the way folks normally develop in Eclipse > (else the :svn-ignore properties would have been set up to ignore this > stuff). > > When I import the Jena projects as a regular Java project, I get unresolved > build dependencies because (for example) jena-core is looking for the > latest jena-iri snapshot in my Maven repository. I think this will work if > I do a 'mvn clean install' from the Jena root directory, but it also seems > that if I do this, changes will not propagate from one project to another > without doing a mvn build/install cycle. > > Any guidance on how the best way to set this up is? When I first checked Jena out of SVN I was having difficulties with SVN in Eclipse (since fixed), so I took a hybrid approach between the command line and the GUI. I'm pretty happy with how it's working for me now. After checking everything out, I used mvn on the command line to build everything. This brought in all the required dependencies. Back in Eclipse, I had errors due to M2_REPO not being set. So I set this variable to point to my .m2 directory (where everything had already been installed) and immediately my build came together. However, this didn't create an integrated environment, since all the projects were dependent on the binary artifacts of the other projects in the Maven repo. This meant that a change in (say) jena-arq wasn't visible when running code in jena-fuseki. Fixing this was a small matter of going to the build path for each project, removing all of the jena-* jar files from "Libraries", and replacing them with the equivalent projects in the "Projects" tab. This lets each project look at the live sources from the projects it depends on instead of the pre-built binaries. Ideally, these cross-project dependencies would be in the .classpath files checked into SVN, but that would break the independence that allows these projects to be worked on individually (i.e. without downloading the others). However, I would have thought that this would be a common enough development requirement that alternative .classpath files would be available, or at least a description of how to set them up. (A better description than the one I've provided here, particularly due to my CLI/GUI muddle) :-) Regards, Paul
