You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Saloucious <sa...@gmail.com> on 2007/10/12 00:49:44 UTC
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-tf4610394s177.html#a13166191
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Harlan Iverson <h....@gmail.com>.
To build on this and give a concrete upgrade path that I've used:
When a company I was with first tried Maven2, we had several projects with a
common dependency. Each project and the dependency were built with Ant.
* First, we wrote a pom for the common project that included all of its
dependencies, and pulled them into a local lib directory using Maven Antlib.
* Next we made it install the jar to the local repo using
install:install-file.
* Then we did the same for the dependent projects, write a POM and make it
pull dependencies local with Antlib.
* Then the shared library went fully Maven,
* Followed by the dependent projects several months later.
Antlib was really the key to a successful, gradual migration.
Harlan
On 10/12/07, Graham Leggett <mi...@sharp.fm> wrote:
>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Harlan Iverson
http://blog.devspan.com
Re: Maven good Design
Posted by Saloucious <sa...@gmail.com>.
Ok, know i'm refactoring project to have something like :
project1-ejb
project1-sar
project2-jar
...
In actual Ant build process, some properties files are not embed in jar and
are copied in a conf dir (conf directory is in server'sclasspath).
Which is the best pratice ? create a new project with only properties file
or create a classifier artifact attached to main jar artifact ?
Thanks
Graham Leggett wrote:
>
> On Tue, October 16, 2007 3:44 pm, Saloucious wrote:
>
>> Ok refactoring projects has been validated !!!
>>
>> Thanks for your reply
>>
>> So, it will be easy now to follow conventions ;-)
>
> Yay!
>
>> Is it a good solution to split project with a dedicated one for each
>> artifacts produced by ANT ?
>>
>> eg: a project for EJB , another for SAR ...
>
> Where it makes sense, yes.
>
> Maven can be configured to produce multiple artifacts per project, but
> generally you need to have a deep understanding of the maven lifecycle and
> what gets built when and in what order, leading to headaches. It is way
> simpler just to follow the one-artifact-per-project convention.
>
> An example of where it may not be necessary is where maven produces two
> artifacts from the same code, such as an EJB client side interface
> alongside the EJB implementation. Here maven cannot help but create two
> artifacts from one project, because the same source code can be used for
> both.
>
> What you'll find is that some of the projects will be very simple. In our
> case, our ear projects just contain a pom.xml, and nothing else.
>
> Regards,
> Graham
> --
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Maven-good-Design-tf4610394s177.html#a13290674
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Graham Leggett <mi...@sharp.fm>.
On Tue, October 16, 2007 3:44 pm, Saloucious wrote:
> Ok refactoring projects has been validated !!!
>
> Thanks for your reply
>
> So, it will be easy now to follow conventions ;-)
Yay!
> Is it a good solution to split project with a dedicated one for each
> artifacts produced by ANT ?
>
> eg: a project for EJB , another for SAR ...
Where it makes sense, yes.
Maven can be configured to produce multiple artifacts per project, but
generally you need to have a deep understanding of the maven lifecycle and
what gets built when and in what order, leading to headaches. It is way
simpler just to follow the one-artifact-per-project convention.
An example of where it may not be necessary is where maven produces two
artifacts from the same code, such as an EJB client side interface
alongside the EJB implementation. Here maven cannot help but create two
artifacts from one project, because the same source code can be used for
both.
What you'll find is that some of the projects will be very simple. In our
case, our ear projects just contain a pom.xml, and nothing else.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Maven good Design
Posted by Jeff Jensen <je...@upstairstechnology.com>.
Yes, that is correct...one artifact per build.
As you already hinted, you may find the "project count" daunting at first.
I believe after awhile you will appreciate the precision of the
organization/separation. This helps focus on modules/components
organization.
> -----Original Message-----
> From: Saloucious [mailto:saloucious@gmail.com]
> Sent: Tuesday, October 16, 2007 8:44 AM
> To: users@maven.apache.org
> Subject: Re: Maven good Design
>
>
> Ok refactoring projects has been validated !!!
>
> Thanks for your reply
>
> So, it will be easy now to follow conventions ;-)
>
> Is it a good solution to split project with a dedicated one for each
> artifacts produced by ANT ?
>
> eg: a project for EJB , another for SAR ...
>
> We have a lot of projects with 2 or 3 artifacts each, i'm afraid to have
> finally : projects number * artifacts number.
>
> project1-ejb
> project1-sar
> project2-jar
> project3-ear
> project3-war
> ...
>
> But if it is conventions, so we will follow it .
>
>
>
> Wayne Fay wrote:
> >
> > 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 <sa...@gmail.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 <mi...@sharp.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-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: users-help@maven.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: users-help@maven.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Maven-good-Design-tf4610394s177.html#a13219789
> >> Sent from the Maven - Users mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Maven-good-Design-
> tf4610394s177.html#a13233906
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Saloucious <sa...@gmail.com>.
Ok refactoring projects has been validated !!!
Thanks for your reply
So, it will be easy now to follow conventions ;-)
Is it a good solution to split project with a dedicated one for each
artifacts produced by ANT ?
eg: a project for EJB , another for SAR ...
We have a lot of projects with 2 or 3 artifacts each, i'm afraid to have
finally : projects number * artifacts number.
project1-ejb
project1-sar
project2-jar
project3-ear
project3-war
...
But if it is conventions, so we will follow it .
Wayne Fay wrote:
>
> 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 <sa...@gmail.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 <mi...@sharp.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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Maven-good-Design-tf4610394s177.html#a13219789
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Maven-good-Design-tf4610394s177.html#a13233906
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Wayne Fay <wa...@gmail.com>.
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 <sa...@gmail.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 <mi...@sharp.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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Maven-good-Design-tf4610394s177.html#a13219789
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Saloucious <sa...@gmail.com>.
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 <mi...@sharp.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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Maven-good-Design-tf4610394s177.html#a13219789
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Wendy Smoak <ws...@gmail.com>.
On 10/12/07, Graham Leggett <mi...@sharp.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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Graham Leggett <mi...@sharp.fm>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Wayne Fay <wa...@gmail.com>.
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 <sa...@gmail.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-tf4610394s177.html#a13166299
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Saloucious <sa...@gmail.com>.
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-tf4610394s177.html#a13166299
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Saloucious <sa...@gmail.com>.
This is just an example (many projects)
Here, ejb is embed in sar and jar a separated artifact
Graham Leggett wrote:
>
> 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
> --
>
>
>
--
View this message in context: http://www.nabble.com/Maven-good-Design-tf4610394s177.html#a13221027
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Graham Leggett <mi...@sharp.fm>.
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
--
Re: Maven good Design
Posted by Saloucious <sa...@gmail.com>.
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 <ws...@gmail.com> wrote:
>> On 10/11/07, Saloucious <sa...@gmail.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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Maven-good-Design-tf4610394s177.html#a13219501
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Dan Tran <da...@gmail.com>.
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 <ws...@gmail.com> wrote:
> On 10/11/07, Saloucious <sa...@gmail.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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven good Design
Posted by Wendy Smoak <ws...@gmail.com>.
On 10/11/07, Saloucious <sa...@gmail.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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org