Re: Maven good Design
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven good Design
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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >> >> developmen
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> >> -- >> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Harlan Iverson http://blog.devspan.com
Re: Maven good Design
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
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 -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Maven good Design
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
On 10/12/07, Graham Leggett <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
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 <[EMAIL PROTECTED]> wrote: >> On 10/11/07, Saloucious <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
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 <[EMAIL PROTECTED]> wrote: > On 10/11/07, Saloucious <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
On 10/11/07, Saloucious <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven good Design
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]