RE: Multiple Artifacts, Same Source

2008-01-18 Thread Adamson, Eric (DIT)
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]



Re: Multiple Artifacts, Same Source

2008-01-18 Thread nicolas de loof
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]
>
>


Re: Multiple Artifacts, Same Source

2008-01-18 Thread Michael Meyer

> 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.
Maybe I misunderstand your question but this sounds like an ordinary 
maven multi module build. Are your sure that "all JARs must contain this 
data transfer object"? Dont you mean that all jars need to have access 
to the MailMergeRequest.class at compile and runtime?


If so, I would create 4 jars.
- mycommon.jar contains your MailMergeRequest class (and other common 
classes) and is compiled with java 1.4
- the web client, app server and database jars all have mycommon.jar as 
dependency (@see dependency section in the pom.xml file)


michael

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Multiple Artifacts, Same Source

2008-01-21 Thread Guillaume Lederrey
On 18/01/2008, Adamson, Eric  (DIT) <[EMAIL PROTECTED]> wrote:
> 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.

We are in the process of migrating quite a few Ant based projects to
Maven. Those projects had the requirement to have the same class in 2
jars (for bad technical reasons that I wont explain here). Before we
can actually spend the time needed to clean that up, we did as follow
:

  Have all sources for all modules in the parent src folder. Create a
subfolder with a pom.xml for each module. Configure those modules to
fetch their sources from the parent src folder. Configure the
maven-compiler-plugin to include the needed sources in the jar. So
more or less :

project
  |-- module1
  | \-- pom.xml
  |-- module2
  | \-- pom.xml
  |-- module3
  | \-- pom.xml
  |-- src
  | \-- main
  |   \-- java
  \-- pom.xml


with the module1 pom having some thing like :


  maven-compiler-plugin
  

  **/package/to/include/**

  



This is definitely a dirty hack, but it can be quite flexible ...


-- 
Jabber : [EMAIL PROTECTED]
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Multiple Artifacts, Same Source

2008-01-21 Thread Nicole Lacoste
Hi,

Does this (Have all sources for all modules in the parent src folder) work
with the release plugin?  I would be very surprised if it did...  Since the
release plugin checks out a tagged version of everything to a different
folder anything relative is lost.

Another option would be to have an artifact that zips the source, then
depend on this and dezip it for the other multiple artifacts.

Nicole


On 21/01/2008, Guillaume Lederrey <[EMAIL PROTECTED]> wrote:
>
> On 18/01/2008, Adamson, Eric  (DIT) <[EMAIL PROTECTED]> wrote:
> > 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.
>
> We are in the process of migrating quite a few Ant based projects to
> Maven. Those projects had the requirement to have the same class in 2
> jars (for bad technical reasons that I wont explain here). Before we
> can actually spend the time needed to clean that up, we did as follow
> :
>
> Have all sources for all modules in the parent src folder. Create a
> subfolder with a pom.xml for each module. Configure those modules to
> fetch their sources from the parent src folder. Configure the
> maven-compiler-plugin to include the needed sources in the jar. So
> more or less :
>
> project
> |-- module1
> | \-- pom.xml
> |-- module2
> | \-- pom.xml
> |-- module3
> | \-- pom.xml
> |-- src
> | \-- main
> |   \-- java
> \-- pom.xml
>
>
> with the module1 pom having some thing like :
>
> 
> maven-compiler-plugin
> 
>
>  **/package/to/include/**
>
> 
> 
>
>
> This is definitely a dirty hack, but it can be quite flexible ...
>
>
> --
> Jabber : [EMAIL PROTECTED]
> Skype : Guillaume.Lederrey
> Projects :
> * http://rwanda.wordpress.com/
> * http://rwandatech.wordpress.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


Re: Multiple Artifacts, Same Source

2008-01-21 Thread Guillaume Lederrey
On 21/01/2008, Nicole Lacoste <[EMAIL PROTECTED]> wrote:
> Does this (Have all sources for all modules in the parent src folder) work
> with the release plugin?  I would be very surprised if it did...  Since the
> release plugin checks out a tagged version of everything to a different
> folder anything relative is lost.

Actually, yes, it does. I thought I would have problems with the
release plugin (among others). As I didnt really understand how it
worked, I just tried, and it worked. The only problem I've had with
the release plugin sofar has been tagging a project for release when
the project is on a CVS branch.

But with your remark, I will double and triple check !

Thanks for the hint !


> Another option would be to have an artifact that zips the source, then
> depend on this and dezip it for the other multiple artifacts.
>
> Nicole
>
>
> On 21/01/2008, Guillaume Lederrey <[EMAIL PROTECTED]> wrote:
> >
> > On 18/01/2008, Adamson, Eric  (DIT) <[EMAIL PROTECTED]> wrote:
> > > 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.
> >
> > We are in the process of migrating quite a few Ant based projects to
> > Maven. Those projects had the requirement to have the same class in 2
> > jars (for bad technical reasons that I wont explain here). Before we
> > can actually spend the time needed to clean that up, we did as follow
> > :
> >
> > Have all sources for all modules in the parent src folder. Create a
> > subfolder with a pom.xml for each module. Configure those modules to
> > fetch their sources from the parent src folder. Configure the
> > maven-compiler-plugin to include the needed sources in the jar. So
> > more or less :
> >
> > project
> > |-- module1
> > | \-- pom.xml
> > |-- module2
> > | \-- pom.xml
> > |-- module3
> > | \-- pom.xml
> > |-- src
> > | \-- main
> > |   \-- java
> > \-- pom.xml
> >
> >
> > with the module1 pom having some thing like :
> >
> > 
> > maven-compiler-plugin
> > 
> >
> >  **/package/to/include/**
> >
> > 
> > 
> >
> >
> > This is definitely a dirty hack, but it can be quite flexible ...
> >
> >
> > --
> > Jabber : [EMAIL PROTECTED]
> > Skype : Guillaume.Lederrey
> > Projects :
> > * http://rwanda.wordpress.com/
> > * http://rwandatech.wordpress.com/
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>


-- 
Jabber : [EMAIL PROTECTED]
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]