Maven good Design

Hi,

i'm newbie with Maven and i'm in charge to convert
application projects from
Ant to Maven

Each Ant scripts creates one or more artifacts : jar , ejb,
aar, sar (with
embeded artifacts) ...
As i can see in Maven : one pom.xml = one artifact
(recommanded).

I search a good design solution to convert these Ant's
processes to Maven
(without changes).

What i've proposed to my manager is to create in each root
project dir a m2
dir

In root project direct, a parent pom.xml with reference to
module in m2 dir.

We can easily see which artifacts are produced by project,
and we can create
artifacts with embded artifacts (eg: ejb go into sar ...)

my-app
|-- pom.xml
|-- build.xml
|-- src
|    |- App.java
|
|--m2
      |--jar
      |    |--pom.xml
      |
      |--ejb
      |    |--pom.xml
      |
      |--sar
          |--pom.xml


Is a good design  ? Have you any better ideas  ?

Thanks
-- 
View this message in context: http://www.nabble.com/Maven-good-Design-tf46
10394s177.html#a13166191
Sent from the Maven - Users mailing list archive at
Nabble.com.


------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribemaven.apache.org
For additional commands, e-mail: users-helpmaven.apache.org

Sorry for the really poor subject title, Ant to Maven : Best
Practises would
be better ...



Saloucious wrote:
> 
> Hi,
> 
> i'm newbie with Maven and i'm in charge to convert
application projects
> from Ant to Maven
> 
> Each Ant scripts creates one or more artifacts : jar ,
ejb, aar, sar (with
> embeded artifacts) ...
> As i can see in Maven : one pom.xml = one artifact
(recommanded).
> 
> I search a good design solution to convert these Ant's
processes to Maven
> (without changes).
> 
> What i've proposed to my manager is to create in each
root project dir a
> m2 dir
> 
> In root project direct, a parent pom.xml with reference
to module in m2
> dir.
> 
> We can easily see which artifacts are produced by
project, and we can
> create artifacts with embded artifacts (eg: ejb go into
sar ...)
> 
> my-app
> |-- pom.xml
> |-- build.xml
> |-- src
> |    |- App.java
> |
> |--m2
>       |--jar
>       |    |--pom.xml
>       |
>       |--ejb
>       |    |--pom.xml
>       |
>       |--sar
>           |--pom.xml
> 
> 
> Is a good design  ? Have you any better ideas  ?
> 
> Thanks
> 

-- 
View this message in context: http://www.nabble.com/Maven-good-Design-tf46
10394s177.html#a13166299
Sent from the Maven - Users mailing list archive at
Nabble.com.


------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribemaven.apache.org
For additional commands, e-mail: users-helpmaven.apache.org

If you are truly "converting" from Ant to Maven,
the correct approach
would be to "convert" the application structure
into the suggested
Maven layout.

You should be able to do this in a branch in your SCM so as
to not
disturb the rest of your team until you are ready to
finalize your
changes.

Wayne

On 10/11/07, Saloucious <salouciousgmail.com> wrote:
>
> Sorry for the really poor subject title, Ant to Maven :
Best Practises would
> be better ...
>
>
>
> Saloucious wrote:
> >
> > Hi,
> >
> > i'm newbie with Maven and i'm in charge to convert
application projects
> > from Ant to Maven
> >
> > Each Ant scripts creates one or more artifacts :
jar , ejb, aar, sar (with
> > embeded artifacts) ...
> > As i can see in Maven : one pom.xml = one artifact
(recommanded).
> >
> > I search a good design solution to convert these
Ant's processes to Maven
> > (without changes).
> >
> > What i've proposed to my manager is to create in
each root project dir a
> > m2 dir
> >
> > In root project direct, a parent pom.xml with
reference to module in m2
> > dir.
> >
> > We can easily see which artifacts are produced by
project, and we can
> > create artifacts with embded artifacts (eg: ejb go
into sar ...)
> >
> > my-app
> > |-- pom.xml
> > |-- build.xml
> > |-- src
> > |    |- App.java
> > |
> > |--m2
> >       |--jar
> >       |    |--pom.xml
> >       |
> >       |--ejb
> >       |    |--pom.xml
> >       |
> >       |--sar
> >           |--pom.xml
> >
> >
> > Is a good design  ? Have you any better ideas  ?
> >
> > Thanks
> >
>
> --
> View this message in context: http://www.nabble.com/Maven-good-Design-tf46
10394s177.html#a13166299
> Sent from the Maven - Users mailing list archive at
Nabble.com.
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: users-unsubscribemaven.apache.org
> For additional commands, e-mail: users-helpmaven.apache.org
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribemaven.apache.org
For additional commands, e-mail: users-helpmaven.apache.org

On 10/11/07, Saloucious <salouciousgmail.com> wrote:

> Each Ant scripts creates one or more artifacts : jar ,
ejb, aar, sar (with
> embeded artifacts) ...
> As i can see in Maven : one pom.xml = one artifact
(recommanded).
>
> I search a good design solution to convert these Ant's
processes to Maven
> (without changes).
>
> What i've proposed to my manager is to create in each
root project dir a m2
> dir

Been there, done that.  I will *never* do it again without
hazard pay.

It can work *briefly* as a way to get your (or Maven's) foot
in the
door and maybe generate the project website, but it is not a
solution.
 It's not a fair test for Maven, and no one will be happy,
least of
all the person working on the m2 build.

Much better is Wayne's suggestion to branch, do a proper
conversion,
and then show them.

-- 
Wendy

------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribemaven.apache.org
For additional commands, e-mail: users-helpmaven.apache.org

On Fri, October 12, 2007 3:31 am, Wayne Fay wrote:

> If you are truly "converting" from Ant to
Maven, the correct approach
> would be to "convert" the application
structure into the suggested
> Maven layout.
>
> You should be able to do this in a branch in your SCM
so as to not
> disturb the rest of your team until you are ready to
finalize your
> changes.

Having done this conversion on a large project in the past
year, in
practise the full conversion to maven took a very long time,
so this
strategy may not work.

If you are not experienced in maven already, the best thing
to do is to
take baby steps.

Get the most simplest part of your project (the jars)
building cleanly
with maven, and use this as a testing ground to get you
familiar with the
maven build process. Do this on the existing sources if you
can, by
dropping in pom.xml into the root of each jar as necessary.
It will
probably become apparent as you go on that some of your code
needs to be
restructured. Do this as necessary, updating your ant build
as you go
along to keep everything working.

Sometimes, you may find that an ant build produces more than
one artifact,
such as an EJB, and then an EAR file. What we did was to
create new
projects alongside the EJB project, which only built the EAR
file (This
project contained a pom.xml file and nothing else).

Eventually we were ready to wean people off the ant build
and get things
going with maven only, and the conversion has worked very
well.

The prize at the end of all this work is worth it: All our
code is built
and tested using continuous integration, with no platform or
machine
specific build setups (we had hard coded paths
*everywhere*).

A release is tested, tagged, and built from the pristine tag
(no more
releases from working copies) start to finish within 30
minutes ("Help! We
need to get this bugfix into UAT as soon as possible!",
"No problem".),
and we now have the *exact* source code used to create a
production
release ("Help! We need to replicate this production
problem in a
development environment!", "No problem").

The docs are all auto-built and auto-deployed ("Help!
We need to cook up a
plan to make javadocs available, which will be very
difficult!", "Already
done, here is the URL").

Regards,
Graham
--



------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribemaven.apache.org
For additional commands, e-mail: users-helpmaven.apache.org

Sure, a new branch (with Maven convention) should be the
better solution.

Unfortunately, this is not planned ...

So is this stucture is fine : 
my-app
|-- pom.xml
|-- build.xml
|-- src
|    |- App.java
|
|--m2
      |--jar
      |    |--pom.xml
      |
      |--ejb
      |    |--pom.xml
      |
      |--sar
          |--pom.xml 


Or is better to put everything in one pom.xml, with many
classifier attached
artifacts ?

Thanks


Dan Tran wrote:
> 
> Wendy puts it right on the spot.  "hazard
pay"
> 
> I also want to add:  pay premium for extra health
insurance b/c you
> will go insane.
> 
> 
> 
> like Wayne has suggested, do it on the branch and show
your boss prototype
> before your proposal shows up on his desk.
> 
> -D
> 
> 
> 
> On 10/11/07, Wendy Smoak <wsmoakgmail.com> wrote:
>> On 10/11/07, Saloucious <salouciousgmail.com> wrote:
>>
>> > Each Ant scripts creates one or more artifacts
: jar , ejb, aar, sar
>> (with
>> > embeded artifacts) ...
>> > As i can see in Maven : one pom.xml = one
artifact (recommanded).
>> >
>> > I search a good design solution to convert
these Ant's processes to
>> Maven
>> > (without changes).
>> >
>> > What i've proposed to my manager is to create
in each root project dir
>> a m2
>> > dir
>>
>> Been there, done that.  I will *never* do it again
without hazard pay.
>>
>> It can work *briefly* as a way to get your (or
Maven's) foot in the
>> door and maybe generate the project website, but it
is not a solution.
>>  It's not a fair test for Maven, and no one will be
happy, least of
>> all the person working on the m2 build.
>>
>> Much better is Wayne's suggestion to branch, do a
proper conversion,
>> and then show them.
>>
>> --
>> Wendy
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: users-unsubscribemaven.apache.org
>> For additional commands, e-mail: users-helpmaven.apache.org
>>
>>
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: users-unsubscribemaven.apache.org
> For additional commands, e-mail: users-helpmaven.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Maven-good-Design-tf46
10394s177.html#a13219501
Sent from the Maven - Users mailing list archive at
Nabble.com.


------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribemaven.apache.org
For additional commands, e-mail: users-helpmaven.apache.org

On 10/12/07, Graham Leggett <minfrinsharp.fm> wrote:

> Get the most simplest part of your project (the jars)
building cleanly
> with maven, and use this as a testing ground to get you
familiar with the
> maven build process. Do this on the existing sources if
you can, by
> dropping in pom.xml into the root of each jar as
necessary. It will
> probably become apparent as you go on that some of your
code needs to be
> restructured. Do this as necessary, updating your ant
build as you go
> along to keep everything working.

I agree, but the original message specifically said
"without changes".
 That's a huge red flag to me that things are about to get
very
painful for everyone involved.

-- 
Wendy

>
> Sometimes, you may find that an ant build produces more
than one artifact,
> such as an EJB, and then an EAR file. What we did was
to create new
> projects alongside the EJB project, which only built
the EAR file (This
> project contained a pom.xml file and nothing else).
>
> Eventually we were ready to wean people off the ant
build and get things
> going with maven only, and the conversion has worked
very well.
>
> The prize at the end of all this work is worth it: All
our code is built
> and tested using continuous integration, with no
platform or machine
> specific build setups (we had hard coded paths
*everywhere*).
>
> A release is tested, tagged, and built from the
pristine tag (no more
> releases from working copies) start to finish within 30
minutes ("Help! We
> need to get this bugfix into UAT as soon as
possible!", "No problem".),
> and we now have the *exact* source code used to create
a production
> release ("Help! We need to replicate this
production problem in a
> development environment!", "No
problem").
>
> The docs are all auto-built and auto-deployed
("Help! We need to cook up a
> plan to make javadocs available, which will be very
difficult!", "Already
> done, here is the URL").
>
> Regards,
> Graham
> --
>
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: users-unsubscribemaven.apache.org
> For additional commands, e-mail: users-helpmaven.apache.org
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribemaven.apache.org
For additional commands, e-mail: users-helpmaven.apache.org

Sure this is painful.

The only solution I have found is : 

my-app
|-- pom.xml
|-- build.xml
|-- src
|    |- App.java
|
|--m2
      |--jar
      |    |--pom.xml
      |
      |--ejb
      |    |--pom.xml
      |
      |--sar
          |--pom.xml


Is better to put everything in one pom.xml, with many
classifier attached
artifacts ? 



Wendy Smoak-3 wrote:
> 
> On 10/12/07, Graham Leggett <minfrinsharp.fm> wrote:
> 
>> Get the most simplest part of your project (the
jars) building cleanly
>> with maven, and use this as a testing ground to get
you familiar with the
>> maven build process. Do this on the existing
sources if you can, by
>> dropping in pom.xml into the root of each jar as
necessary. It will
>> probably become apparent as you go on that some of
your code needs to be
>> restructured. Do this as necessary, updating your
ant build as you go
>> along to keep everything working.
> 
> I agree, but the original message specifically said
"without changes".
>  That's a huge red flag to me that things are about to
get very
> painful for everyone involved.
> 
> -- 
> Wendy
> 
>>
>> Sometimes, you may find that an ant build produces
more than one
>> artifact,
>> such as an EJB, and then an EAR file. What we did
was to create new
>> projects alongside the EJB project, which only
built the EAR file (This
>> project contained a pom.xml file and nothing
else).
>>
>> Eventually we were ready to wean people off the ant
build and get things
>> going with maven only, and the conversion has
worked very well.
>>
>> The prize at the end of all this work is worth it:
All our code is built
>> and tested using continuous integration, with no
platform or machine
>> specific build setups (we had hard coded paths
*everywhere*).
>>
>> A release is tested, tagged, and built from the
pristine tag (no more
>> releases from working copies) start to finish
within 30 minutes ("Help!
>> We
>> need to get this bugfix into UAT as soon as
possible!", "No problem".),
>> and we now have the *exact* source code used to
create a production
>> release ("Help! We need to replicate this
production problem in a
>> development environment!", "No
problem").
>>
>> The docs are all auto-built and auto-deployed
("Help! We need to cook up
>> a
>> plan to make javadocs available, which will be very
difficult!", "Already
>> done, here is the URL").
>>
>> Regards,
>> Graham
>> --
>>
>>
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: users-unsubscribemaven.apache.org
>> For additional commands, e-mail: users-helpmaven.apache.org
>>
>>
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: users-unsubscribemaven.apache.org
> For additional commands, e-mail: users-helpmaven.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Maven-good-Design-tf46
10394s177.html#a13219789
Sent from the Maven - Users mailing list archive at
Nabble.com.


------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribemaven.apache.org
For additional commands, e-mail: users-helpmaven.apache.org

I'm not aware of any published "best practices for
people who want to
use Maven but can't follow the conventions".

Perhaps someone else will reply with something more useful.
My general
response is "do what works best for you".

Wayne

On 10/15/07, Saloucious <salouciousgmail.com> wrote:
>
> Sure this is painful.
>
> The only solution I have found is :
>
> my-app
> |-- pom.xml
> |-- build.xml
> |-- src
> |    |- App.java
> |
> |--m2
>      |--jar
>      |    |--pom.xml
>      |
>      |--ejb
>      |    |--pom.xml
>      |
>      |--sar
>          |--pom.xml
>
>
> Is better to put everything in one pom.xml, with many
classifier attached
> artifacts ?
>
>
>
> Wendy Smoak-3 wrote:
> >
> > On 10/12/07, Graham Leggett <minfrinsharp.fm> wrote:
> >
> >> Get the most simplest part of your project
(the jars) building cleanly
> >> with maven, and use this as a testing ground
to get you familiar with the
> >> maven build process. Do this on the existing
sources if you can, by
> >> dropping in pom.xml into the root of each jar
as necessary. It will
> >> probably become apparent as you go on that
some of your code needs to be
> >> restructured. Do this as necessary, updating
your ant build as you go
> >> along to keep everything working.
> >
> > I agree, but the original message specifically
said "without changes".
> >  That's a huge red flag to me that things are
about to get very
> > painful for everyone involved.
> >
> > --
> > Wendy
> >
> >>
> >> Sometimes, you may find that an ant build
produces more than one
> >> artifact,
> >> such as an EJB, and then an EAR file. What we
did was to create new
> >> projects alongside the EJB project, which only
built the EAR file (This
> >> project contained a pom.xml file and nothing
else).
> >>
> >> Eventually we were ready to wean people off
the ant build and get things
> >> going with maven only, and the conversion has
worked very well.
> >>
> >> The prize at the end of all this work is worth
it: All our code is built
> >> and tested using continuous integration, with
no platform or machine
> >> specific build setups (we had hard coded paths
*everywhere*).
> >>
> >> A release is tested, tagged, and built from
the pristine tag (no more
> >> releases from working copies) start to finish
within 30 minutes ("Help!
> >> We
> >> need to get this bugfix into UAT as soon as
possible!", "No problem".),
> >> and we now have the *exact* source code used
to create a production
> >> release ("Help! We need to replicate this
production problem in a
> >> development environment!", "No
problem").
> >>
> >> The docs are all auto-built and auto-deployed
("Help! We need to cook up
> >> a
> >> plan to make javadocs available, which will be
very difficult!", "Already
> >> done, here is the URL").
> >>
> >> Regards,
> >> Graham
> >> --
> >>
> >>
> >>
> >>
------------------------------------------------------------
---------
> >> To unsubscribe, e-mail: users-unsubscribemaven.apache.org
> >> For additional commands, e-mail:
users-helpmaven.apache.org
> >>
> >>
> >
> >
------------------------------------------------------------
---------
> > To unsubscribe, e-mail: users-unsubscribemaven.apache.org
> > For additional commands, e-mail: users-helpmaven.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Maven-good-Design-tf46
10394s177.html#a13219789
> Sent from the Maven - Users mailing list archive at
Nabble.com.
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: users-unsubscribemaven.apache.org
> For additional commands, e-mail: users-helpmaven.apache.org
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribemaven.apache.org
For additional commands, e-mail: users-helpmaven.apache.org

Saloucious wrote:

>       |--jar
>       |    |--pom.xml
>       |
>       |--ejb
>       |    |--pom.xml
>       |
>       |--sar
>           |--pom.xml 

Can you explain what is in the jar and the ejb? Is the jar
the client 
side interface for the ejb, or is it something else?

Is the code in the sar also in the jar, or is it on its
own?

Regards,
Graham
--