Caveat: "I'm fairly certain that...(X)...but I'm sure someone else would tell me that I'm not following 'The Maven Way'." (see below)
--- Adrian Brock <[EMAIL PROTECTED]> wrote: > On Sun, 2006-02-12 at 04:36, Adrian Brock wrote: > > I still don't know how to make this compile within Eclipse? > > i.e. > > Without a standard location for thirdparty how do we share the > > Eclipse project descriptors? > > Although, I believe Maven has a task to generate them locally > > rather than sharing them, I don't currently know how to do this. > > This is relatively trivial, you just use > mvn eclipse:eclipse > to generate the files, as long as you have a compiler property set > M2_REPO=~/.m2/repository > > But the project structure is broken for this. > e.g. the pom.xml says the common project is called "jboss-common" > so it cannot find. It is a directory called just plain "common". > > I have no idea why eclipse:eclipse requires a full build? > i.e. download and compile. The information it needs is in the pom.xml > When you run eclipse:eclipse on a single project the eclipse plug-in doesn't run in the context of a multiproject build, and instead of relating two projects together as projects, you end up depending on another project's artifact from your local repository. So, if you run eclipse:eclipse from the jboss-core directory and it depends on jboss-common, you'll end up with an annoying situation in eclipse where jboss-core doesn't rely on jboss-common's project, it depends on the artifact in M2_REPO. If you want workable eclipse projects with Maven2, you should always run "eclipse:eclipse" from the topmost level of your multiproject build. The Maven purist would argue that you *never* check in a Eclipse/IntelliJ/whatever project file into your repository. But, in my own projects of late I've found myself checking them in so that a large team of developers doesn't need to constantly run a multiproject build. Yes, this is a compromise, but you'l find that the eclipse .project and .classpath files only contain a reference to M2_REPO as Adrian previously mentioned. > I can see this being tortous, especially when people > like the webservices project change their project structure/dependencies > at a rate of 600 MHz. :-) > > On the Maven/Eclipse plugins from Codehaus. > > * The main ide plugins only seem to support Maven 1.x > You should be looking at the new one: http://maven.apache.org/eclipse-plugin.html > * I have no idea what the new plugin does, the one referenced from the > Maven site. The only docs are in flash demos! > The only option that seems to do anything is the "update sources" > which just has the affect of munging your .classpath :-) Flash demonstrations.....the Maven 2 documentation sucks badly. :-) That's unfair, I know, but it's true. It isn't that it sucks so much as it isn't aggregated into a single source. You've got a bunch of tutorials, and plug-in documentation is something of a crap-shoot. This is getting better over time. There is a good book coming out in short order that should fill a lot of these gaps. I'm not sure if the authors have finished it just yet. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
