Hi Nico, Thanks for your reply. Actually, I need 1.4 *inside* the Oracle database, which has its own internal JVM -- but I'm sure this detail doesn't really matter (does it?) -- your suggestions still appear to be relevant. I'll have a look at both of the options you've suggested. Thanks for your help!
Regards, Eric Adamson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nicolas de loof Sent: Friday, January 18, 2008 1:22 PM To: Maven Users List Subject: Re: Multiple Artifacts, Same Source Please correct me : what you need is a java 1.4 version of your java 1.5classes used on client / app server ? Option 1 : compile with target = 1.4, so that same jar can be used on all runtimes Option 2 : use retrotranslator to backport your j5 classes to 1.4. This can be auto-configured in maven to produce two jars (yourcode.jar and yourcode-backport.jar) As your code needs to be 1.4 compliant (no java5 construct), option1 seems simpliest. Nico 2008/1/18, Adamson, Eric (DIT) <[EMAIL PROTECTED]>: > > I'm relatively new to Maven 2, and am seeking advice regarding the > following problem: I have written a data transfer object > (MailMergeRequest) that will be passed (serialized to XML using > Xstream) between web client, app server and database. The client and > app server are running JDK5, the database (Oracle 10g) has an internal > JVM, version 1.4.2_06. I'll be creating a JAR file for each tier. > > I understand re: "one POM, one artifact", and hence expect to break > this into three separate projects. Since all JARs must contain this > data transfer object, I'm trying to decide the best way (or at least a > very good one) of keeping the three projects in sync. > > So far, I've considered: > > 1. using the scm plugin to checkout from SVN > prior to building/packaging > > 2. copying the duplicate source files from one project to the > others using some other method (e.g. ant > task) > > Option #1 seems the safest to me, #2 seems like a hack. Are both of > these bad options, and/or is there a more appropriate mechanism/plugin > that I should be looking at? > > TIA, > > Eric Adamson > > --------------------------------------------------------------------- > 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]
