What problems do you have with Eclipse? I do exactly this across a project with many components which are re-used in various combinations of .ear and .war files using the Maven dependency mechanism and have no problems at all using Eclipse as my IDE.
Matt. > -----Original Message----- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: 29 June 2004 13:38 > To: Maven Users List > Subject: Re: RFE for the war plugin > > Yes, I thought of doing that very thing :) however I then > have problems with Eclipse as it doesn't understand > multi-project builds, and you really want all the parts of an > application in the same place. > > Still doable, but less than optimum. > > - Brill > > Charles Daniels wrote: > > >If you really want to create a jar file instead of deploying your > >classes in WEB-INF/classes, just split your project into 2 > subprojects. > >One subproject will create your jar file. The other subproject will > >build your war file and will include the jar file as a > dependency, with > >the <war.bundle> property set to true (just like any other > dependency > >that you bundle into your war file). > > > > > > > >>-----Original Message----- > >>From: Brill Pappin [mailto:[EMAIL PROTECTED] > >>Sent: Monday, June 28, 2004 2:21 PM > >>To: Maven Users List > >>Subject: Re: RFE for the war plugin > >> > >> > >>To clarify; I'm not asking that the classes dir go away, I'm just > >>asking for the ability to use a jar instead. Which should > be a fairly > >>simple addition to the war goal. > >> > >>Doing this allows me to use the manifest versioning, labeling and > >>dependency parts of the manifest. For example, my code > currently logs > >>not only the file and line number that an exception > happened in, but > >>also the package and version of the jar, because in my > situation it's > >>possible that I have different servers running different > revisions of > >>the code. > >> > >>Your class-load order comment is a good point, but I > actually see this > >>as a bonus for the JAR argument, in that I can quickly > patch a library > >>or over-ride a log4j properties file without > re-deploying... not that > >>I would tend to do this if I could help it, but I've seen > the need for > >>it recently (in an emergency). > >> > >>- Brill Pappin > >> > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]