Re: Mavenizing a project
My advice is to fit your needs into Maven's standard directory layout (project structure). http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html Your main source and junit source will fit well there. Unsure how your helper classes fit in but it seems to me that the case can probably be made for that to be packaged within the test source branch as well. SF On Fri, May 28, 2010 at 1:26 PM, Greg Akins angryg...@gmail.com wrote: I'm working on Mavenizing a small project. In the current project, there are three source directories. The Main source, the JUnit test source and a dir called test_informal that contains some helper classes for doing interactive testing... In a maven project, where would one put that type of source? -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing a project
On Fri, May 28, 2010 at 1:43 PM, Steve Francolla sfranco...@gmail.com wrote: My advice is to fit your needs into Maven's standard directory layout (project structure). http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html Your main source and junit source will fit well there. Unsure how your helper classes fit in but it seems to me that the case can probably be made for that to be packaged within the test source branch as well. That seems like it might work better for my team. I think I'll have a bit more of a fight if I have to create a separate project. And truth is, I don't even think these tests get executed anymore. I just need to keep them intact until I can replace them with something better. -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing a project
My experience has consistently been that if I adapt my projects to Maven instead of vice-versa, life is just peachy. Have yet to come across a circumstance in Maven that hasn't already been solved for. Just go with it. On Fri, May 28, 2010 at 2:04 PM, Greg Akins angryg...@gmail.com wrote: On Fri, May 28, 2010 at 1:43 PM, Steve Francolla sfranco...@gmail.com wrote: My advice is to fit your needs into Maven's standard directory layout (project structure). http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html Your main source and junit source will fit well there. Unsure how your helper classes fit in but it seems to me that the case can probably be made for that to be packaged within the test source branch as well. That seems like it might work better for my team. I think I'll have a bit more of a fight if I have to create a separate project. And truth is, I don't even think these tests get executed anymore. I just need to keep them intact until I can replace them with something better. -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre
RE: Mavenizing a project
one is re-factoring your ANT taskdef class into a Mojo path of least resistance is to stick with antrun http://maven.apache.org/plugins/maven-antrun-plugin/ Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Fri, 28 May 2010 14:56:37 -0400 Subject: Re: Mavenizing a project From: sfranco...@gmail.com To: angryg...@gmail.com CC: users@maven.apache.org My experience has consistently been that if I adapt my projects to Maven instead of vice-versa, life is just peachy. Have yet to come across a circumstance in Maven that hasn't already been solved for. Just go with it. On Fri, May 28, 2010 at 2:04 PM, Greg Akins angryg...@gmail.com wrote: On Fri, May 28, 2010 at 1:43 PM, Steve Francolla sfranco...@gmail.com wrote: My advice is to fit your needs into Maven's standard directory layout (project structure). http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html Your main source and junit source will fit well there. Unsure how your helper classes fit in but it seems to me that the case can probably be made for that to be packaged within the test source branch as well. That seems like it might work better for my team. I think I'll have a bit more of a fight if I have to create a separate project. And truth is, I don't even think these tests get executed anymore. I just need to keep them intact until I can replace them with something better. -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
Re: Mavenizing a project
Put your tests in src/test/java as normal. If your helper classes are to be used by multiple projects, create a new project just for the helper classes, call it foo-test or something. Put the helper classes in src/main/java in the foo-test project, not src/test/main. Then you can create a dependency with test scope on foo-test from the projects that need the test helper classes. If you don't use that little trick, project B cannot depend on project A for it's test classes because the final artifacts never contain test classes. Brian On May 28, 2010, at 1:26 PM, Greg Akins wrote: I'm working on Mavenizing a small project. In the current project, there are three source directories. The Main source, the JUnit test source and a dir called test_informal that contains some helper classes for doing interactive testing... In a maven project, where would one put that type of source? -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing a project
If you don't use that little trick, project B cannot depend on project A for it's test classes because the final artifacts never contain test classes. That is one way to do it... but I'd suggest the test-jar approach: http://maven.apache.org/guides/mini/guide-attached-tests.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
On 25 Feb 2009, at 14:40, Steve Cohen wrote: I am thinking about this very carefully, and the option of not using Maven at all is still in play. So is the option of using Maven ONLY to grab third-party dependencies into a local repository. I did this the other day, using the maven-ant-tasks to manage dependencies of an ant based project. I've written a POM and a minimal ant script, which collaborate to download all dependencies from our internal repo. It works like a charm, given that this project can't be converted to maven wholesale yet (it's cocoon 2.1, and would need to be migrated to 2.2). -Dom
Re: Mavenizing Existing Project Part Deux
Based on this discussion, I have a question here regarding uncommon requirement. Once my build is finished I need to copy all the generated artifacts as well as portal components and some shell scripts/batch files from resources. Copying is done to custom directory which acts as TestBed of the application. i.e. it can start jetty..with portal and all application jars. I couldnt do that using maven-assembly plugin. Only otions I had 1) jar with dependencies - doesnt work as I need it in directory format or rather I can first gather all things and then build executable jarbut it takes longer too considering frequent change install cycle 2) assembly descriptor --- How can I copy generated artifacts i.e. jars modulesets? ..but then with unpack=false option it also copies all dependencies too which I don't need Can anybody suggest me better solution? TIA Ketan On Thu, Feb 26, 2009 at 4:03 PM, Dominic Mitchell d...@semantico.com wrote: On 25 Feb 2009, at 14:40, Steve Cohen wrote: I am thinking about this very carefully, and the option of not using Maven at all is still in play. So is the option of using Maven ONLY to grab third-party dependencies into a local repository. I did this the other day, using the maven-ant-tasks to manage dependencies of an ant based project. I've written a POM and a minimal ant script, which collaborate to download all dependencies from our internal repo. It works like a charm, given that this project can't be converted to maven wholesale yet (it's cocoon 2.1, and would need to be migrated to 2.2). -Dom
RE: Mavenizing Existing Project Part Deux
The other thing is, and this may be an urban legend, that I think it's better to not have the sub modules nested in the parent module's directory. Make them parallel; siblings. This means using ../ with relativePath when referring to the parent's pom: This is due to the old eclipses not supporting nested modules. With M2e this is no longer a problem, so you should maintain a traditional tree structure instead. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Thanks, that's very good to know. Brian E. Fox wrote: The other thing is, and this may be an urban legend, that I think it's better to not have the sub modules nested in the parent module's directory. Make them parallel; siblings. This means using ../ with relativePath when referring to the parent's pom: This is due to the old eclipses not supporting nested modules. With M2e this is no longer a problem, so you should maintain a traditional tree structure instead. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Dependency:copy and/or dependency:copy-dependencies -Original Message- From: Ketan Khairnar [mailto:ketan.khair...@gmail.com] Sent: Thursday, February 26, 2009 5:42 AM To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux Based on this discussion, I have a question here regarding uncommon requirement. Once my build is finished I need to copy all the generated artifacts as well as portal components and some shell scripts/batch files from resources. Copying is done to custom directory which acts as TestBed of the application. i.e. it can start jetty..with portal and all application jars. I couldnt do that using maven-assembly plugin. Only otions I had 1) jar with dependencies - doesnt work as I need it in directory format or rather I can first gather all things and then build executable jarbut it takes longer too considering frequent change install cycle 2) assembly descriptor --- How can I copy generated artifacts i.e. jars modulesets? ..but then with unpack=false option it also copies all dependencies too which I don't need Can anybody suggest me better solution? TIA Ketan On Thu, Feb 26, 2009 at 4:03 PM, Dominic Mitchell d...@semantico.com wrote: On 25 Feb 2009, at 14:40, Steve Cohen wrote: I am thinking about this very carefully, and the option of not using Maven at all is still in play. So is the option of using Maven ONLY to grab third-party dependencies into a local repository. I did this the other day, using the maven-ant-tasks to manage dependencies of an ant based project. I've written a POM and a minimal ant script, which collaborate to download all dependencies from our internal repo. It works like a charm, given that this project can't be converted to maven wholesale yet (it's cocoon 2.1, and would need to be migrated to 2.2). -Dom
Re: Mavenizing Existing Project Part Deux
Sorry to get late into this conversation, but I am wondering if there might be a way to do a gentler migration path. For example, let's say you modify the current directory structure bit-by-bit into the standard Maven directory structure, then once you have setup in a way Maven likes it, convert the build over to Maven. Of course, the whole thing depends on how standard are your current projects. Our main project is a mess of enterprise beans, various frameworks, and an infrastructure that was hacked together into a mish-mosh of one of the biggest messes you've ever seen. The software was developed about a decade ago by a bunch of developers who worry about such things as planning or architecture. To move over to Maven is almost impossible because it may require massive structural changes in our project. However, other projects we had were quite easy. They produced a standard JAR file or WAR file and the whole process was pretty straight forward. And, unlike the previous monstrous project I described, these were actually buildable in Eclipse, so there may be hope for you. If I remember, you're talking about a rather small shop of three developers and about 10 projects. It may simply be a matter of moving your source to emulate Maven's structure, then moving resources to where they're suppose to go. Once that is done, you can generate a POM via the mvn: archetype:generate and put it into your Eclipse project. Once you're able to get your project to build with Maven, simply remove the jarfiles you have in your revision control system. This is a similar path we took with our smaller projects. We moved the source files around while still doing our Ant builds, then created the POM. Once we got things working, we simply moved Hudson from using Ant to Maven, and removed the jarfiles from Subversion. Each project took a couple of days. No branching or merging. On Mon, Feb 23, 2009 at 7:53 PM, Steve Cohen stevec...@comcast.net wrote: OK, after extensive discussion in earlier thread about the best way to go about Mavenizing Existing Project(s) in my, shall we say, unusual environment (see that thread for details, don't want to recapitulate them here) I have decided to try to move forward. First I have to learn this tool. I have used maven before, but mainly in the way of building from someone else's POM. Just type maven install or some such and bingo, the world is built. Now my goal is to have pre-existing non-Maven projects be mavenized. I am prepared to throw the first one away. I also want to take this opportunity to start from a m2eclipse platform, so I have now installed that, even to the point of installing Ganymede because I couldn't get it to install in Europa. Although I know there is benefit to the command line tools, I'd like to start from eclipse, understanding that I can take the POM I produce and install it with command line tools. So my first question is this: How do I convert a non-Maven project into a Maven project? 1) Is there some way to change natures? 2) Create a new Maven project, place in SVN, then move stuff to the right places? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Thanks, Rusty. I am thinking about this very carefully, and the option of not using Maven at all is still in play. So is the option of using Maven ONLY to grab third-party dependencies into a local repository. Another option is to use Eclipse's build functionality headlessly, from the command line, without Maven. This capabilty exists in Eclipse, although it's not well publicized. A key goal of mine is to keep local developer builds in Eclipse working pretty much as they have. Directories may have to move to accomodate Maven standards, but I still want to be able to compile and run my Mavenized projects as well as pieces thereof inside Eclipse. In other words, the Java Build Path, natures, etc. in Eclipse will still be operative and the capabilities of running java apps from the command line, and web apps through WTP will still exist. This is the reason for my perhaps misguided intention of working through m2eclipse. What's keeping me undecided is the lack of an assertion from anyone that when I am done, my Mavenized projects will be able to be used this way. Can someone tell me definitively that that's possible? If not, I may be wasting my time. Once you have your project working from the command line, then commit it to svn, then in eclipse check it out from svn as a maven project. Can you tell me what checking out as a maven project actually entails? I tried this on a non-maven project, thinking that it might generate all the maven framework for me, a skeleton POM or something, that I would have to complete. This did not work. It sounds like the right path is to command-line-mavenize, check-in, and then check out as a maven project. I guess I need to understand what a Maven project in Eclipse is. I suppose I should generate one from scratch and compare to an existing project. I think eclipse doesn't like or support nested projects. If you use the nested directories layout, when you import it into eclipse I think the m2eclipse does some voodoo behind your back, rearranging things to make eclipse happy. For me it was a bit more transparent having the modules as parallel projects in eclipse. I already work this way in Eclipse. No nested projects. So this shouldn't be a problem - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
I'm pretty sure you'll be able to continue doing all of the usual eclipse stuff everyone is used to doing. I also use WTP and have a tomcat server running under/in eclipse that I fire up to test my jsps and whatnot. What bothers me about the m2eclipse plugin is that it's not obvious, to me at least, who's doing what and when. For example, you'll have maven menu items for doing the usual maven things; compile, package, test, etc. But what happens when I click on the eclipse build button? Is that doing a maven build or just an eclipse build? Likewise with a clean? I have my rituals when using the tomcat under eclipse; for example, I try to remember to always stop it before I click on the build button; at some time in the past it didn't always see the changes. And I'm not sure if doing a maven build in eclipse (from the maven menu) will update the files tomcat uses. So the reason I think it's better to start with the command line is so that you'll have a better understanding of what you're doing and why. Checking out a maven project into eclipse from svn simply means that the project was set up as a maven project before you committed to svn; it has a pom.xml, the correct directory structure, etc. If you want to start a mavenized eclipse project from scratch, use the archetype thing. That's quite nice for hitting the ground running. Steve Cohen wrote: Thanks, Rusty. I am thinking about this very carefully, and the option of not using Maven at all is still in play. So is the option of using Maven ONLY to grab third-party dependencies into a local repository. Another option is to use Eclipse's build functionality headlessly, from the command line, without Maven. This capabilty exists in Eclipse, although it's not well publicized. A key goal of mine is to keep local developer builds in Eclipse working pretty much as they have. Directories may have to move to accomodate Maven standards, but I still want to be able to compile and run my Mavenized projects as well as pieces thereof inside Eclipse. In other words, the Java Build Path, natures, etc. in Eclipse will still be operative and the capabilities of running java apps from the command line, and web apps through WTP will still exist. This is the reason for my perhaps misguided intention of working through m2eclipse. What's keeping me undecided is the lack of an assertion from anyone that when I am done, my Mavenized projects will be able to be used this way. Can someone tell me definitively that that's possible? If not, I may be wasting my time. Once you have your project working from the command line, then commit it to svn, then in eclipse check it out from svn as a maven project. Can you tell me what checking out as a maven project actually entails? I tried this on a non-maven project, thinking that it might generate all the maven framework for me, a skeleton POM or something, that I would have to complete. This did not work. It sounds like the right path is to command-line-mavenize, check-in, and then check out as a maven project. I guess I need to understand what a Maven project in Eclipse is. I suppose I should generate one from scratch and compare to an existing project. I think eclipse doesn't like or support nested projects. If you use the nested directories layout, when you import it into eclipse I think the m2eclipse does some voodoo behind your back, rearranging things to make eclipse happy. For me it was a bit more transparent having the modules as parallel projects in eclipse. I already work this way in Eclipse. No nested projects. So this shouldn't be a problem - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Also remember that in eclipse you'll need to right click on the project and select Properties; there are some important maven things in there. Steve Cohen wrote: Thanks, Rusty. I am thinking about this very carefully, and the option of not using Maven at all is still in play. So is the option of using Maven ONLY to grab third-party dependencies into a local repository. Another option is to use Eclipse's build functionality headlessly, from the command line, without Maven. This capabilty exists in Eclipse, although it's not well publicized. A key goal of mine is to keep local developer builds in Eclipse working pretty much as they have. Directories may have to move to accomodate Maven standards, but I still want to be able to compile and run my Mavenized projects as well as pieces thereof inside Eclipse. In other words, the Java Build Path, natures, etc. in Eclipse will still be operative and the capabilities of running java apps from the command line, and web apps through WTP will still exist. This is the reason for my perhaps misguided intention of working through m2eclipse. What's keeping me undecided is the lack of an assertion from anyone that when I am done, my Mavenized projects will be able to be used this way. Can someone tell me definitively that that's possible? If not, I may be wasting my time. Once you have your project working from the command line, then commit it to svn, then in eclipse check it out from svn as a maven project. Can you tell me what checking out as a maven project actually entails? I tried this on a non-maven project, thinking that it might generate all the maven framework for me, a skeleton POM or something, that I would have to complete. This did not work. It sounds like the right path is to command-line-mavenize, check-in, and then check out as a maven project. I guess I need to understand what a Maven project in Eclipse is. I suppose I should generate one from scratch and compare to an existing project. I think eclipse doesn't like or support nested projects. If you use the nested directories layout, when you import it into eclipse I think the m2eclipse does some voodoo behind your back, rearranging things to make eclipse happy. For me it was a bit more transparent having the modules as parallel projects in eclipse. I already work this way in Eclipse. No nested projects. So this shouldn't be a problem - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Hmm, I don't usually click the build button. I typically live with build automatically turned on. I live with the fact that this will bomb out the WTP Tomcat if I'm not careful. But that's another can of worms no? If we're not sure what build does, it's even scarier for automatic build. Does anyone know? Or should I take this over to the m2eclipse list? Rusty Wright wrote: I'm pretty sure you'll be able to continue doing all of the usual eclipse stuff everyone is used to doing. I also use WTP and have a tomcat server running under/in eclipse that I fire up to test my jsps and whatnot. What bothers me about the m2eclipse plugin is that it's not obvious, to me at least, who's doing what and when. For example, you'll have maven menu items for doing the usual maven things; compile, package, test, etc. But what happens when I click on the eclipse build button? Is that doing a maven build or just an eclipse build? Likewise with a clean? I have my rituals when using the tomcat under eclipse; for example, I try to remember to always stop it before I click on the build button; at some time in the past it didn't always see the changes. And I'm not sure if doing a maven build in eclipse (from the maven menu) will update the files tomcat uses. So the reason I think it's better to start with the command line is so that you'll have a better understanding of what you're doing and why. Checking out a maven project into eclipse from svn simply means that the project was set up as a maven project before you committed to svn; it has a pom.xml, the correct directory structure, etc. If you want to start a mavenized eclipse project from scratch, use the archetype thing. That's quite nice for hitting the ground running. Steve Cohen wrote: Thanks, Rusty. I am thinking about this very carefully, and the option of not using Maven at all is still in play. So is the option of using Maven ONLY to grab third-party dependencies into a local repository. Another option is to use Eclipse's build functionality headlessly, from the command line, without Maven. This capabilty exists in Eclipse, although it's not well publicized. A key goal of mine is to keep local developer builds in Eclipse working pretty much as they have. Directories may have to move to accomodate Maven standards, but I still want to be able to compile and run my Mavenized projects as well as pieces thereof inside Eclipse. In other words, the Java Build Path, natures, etc. in Eclipse will still be operative and the capabilities of running java apps from the command line, and web apps through WTP will still exist. This is the reason for my perhaps misguided intention of working through m2eclipse. What's keeping me undecided is the lack of an assertion from anyone that when I am done, my Mavenized projects will be able to be used this way. Can someone tell me definitively that that's possible? If not, I may be wasting my time. Once you have your project working from the command line, then commit it to svn, then in eclipse check it out from svn as a maven project. Can you tell me what checking out as a maven project actually entails? I tried this on a non-maven project, thinking that it might generate all the maven framework for me, a skeleton POM or something, that I would have to complete. This did not work. It sounds like the right path is to command-line-mavenize, check-in, and then check out as a maven project. I guess I need to understand what a Maven project in Eclipse is. I suppose I should generate one from scratch and compare to an existing project. I think eclipse doesn't like or support nested projects. If you use the nested directories layout, when you import it into eclipse I think the m2eclipse does some voodoo behind your back, rearranging things to make eclipse happy. For me it was a bit more transparent having the modules as parallel projects in eclipse. I already work this way in Eclipse. No nested projects. So this shouldn't be a problem - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Hey! Great! Since mavnen config is pretty new to you, this is a great way to learn. 1) Is there some way to change natures? No. With Ant and scripts you can get a very specific build process, usually with som quircks and/or workarounds. I find using the Ant scripts and other scripts as inspiration and documentation for building up the pom, the best way to use them. But there are a bunch of tricks and tips in doing so. I think we went thru a few previously in this tread. 2) Create a new Maven project, place in SVN, then move stuff to the right places? I always presume people have a branch, a tag and a trunk folder, but if not have a look at some apache project and see how it's done. I usually do a poc in a branch to see if it all works out. (A copy or externals of the working trunk) You do not want to mess up your code, fail, get a new order for business/management, and desperatly revert trunk. You also want to tag a stable last version of your Ant built project. -Original Message- From: Steve Cohen [mailto:stevec...@comcast.net] Sent: 24. februar 2009 01:53 To: Maven Users List Subject: Mavenizing Existing Project Part Deux OK, after extensive discussion in earlier thread about the best way to go about Mavenizing Existing Project(s) in my, shall we say, unusual environment (see that thread for details, don't want to recapitulate them here) I have decided to try to move forward. First I have to learn this tool. I have used maven before, but mainly in the way of building from someone else's POM. Just type maven install or some such and bingo, the world is built. Now my goal is to have pre-existing non-Maven projects be mavenized. I am prepared to throw the first one away. I also want to take this opportunity to start from a m2eclipse platform, so I have now installed that, even to the point of installing Ganymede because I couldn't get it to install in Europa. Although I know there is benefit to the command line tools, I'd like to start from eclipse, understanding that I can take the POM I produce and install it with command line tools. So my first question is this: How do I convert a non-Maven project into a Maven project? 1) Is there some way to change natures? 2) Create a new Maven project, place in SVN, then move stuff to the right places? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
OK. Since we're skipping the ant phase on this project, never having used it here, I'll go with your suggestions in #2. I'll start by making a branch, using the least dependent project (which depends on no others) for my first guinea pig. (I DO follow the trunk-branch-tag pattern). However, one question remains - in my present mode I always check everything into SVN, including all those .* files (.project etc.) which, by default, eclipse filters out. I do that to make checkout easier for the next guy, no configuration, etc. But it creates a problem here - it means that the nature of the project is predetermined at the time of the checkout. That's what I wanted, but I don't want it here. So I suppose the plan would be: 1. make a tag of current state and cut a branch at the same point. 2. delete from the branch all the .* files that determine configuration, IN THE REPOSITORY, not on a local copy, where Eclipse would immediately recreate these files. 3. delete the local copy of the project. 4. check it out again from the repository as a new project and specify maven in the wizards? I assume this is possible. Is it what you had in mind? Or is there a better way. Steve Jon Georg Berentsen wrote: Hey! Great! Since mavnen config is pretty new to you, this is a great way to learn. 1) Is there some way to change natures? No. With Ant and scripts you can get a very specific build process, usually with som quircks and/or workarounds. I find using the Ant scripts and other scripts as inspiration and documentation for building up the pom, the best way to use them. But there are a bunch of tricks and tips in doing so. I think we went thru a few previously in this tread. 2) Create a new Maven project, place in SVN, then move stuff to the right places? I always presume people have a branch, a tag and a trunk folder, but if not have a look at some apache project and see how it's done. I usually do a poc in a branch to see if it all works out. (A copy or externals of the working trunk) You do not want to mess up your code, fail, get a new order for business/management, and desperatly revert trunk. You also want to tag a stable last version of your Ant built project. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing Existing Project Part Deux
-Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 24. februar 2009 14:34 To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux OK. Since we're skipping the ant phase on this project, never having used it here, I'll go with your suggestions in #2. I'll start by making a branch, using the least dependent project (which depends on no others) for my first guinea pig. (I DO follow the trunk-branch-tag pattern). However, one question remains - in my present mode I always check everything into SVN, including all those .* files (.project etc.) which, by default, eclipse filters out. I do that to make checkout easier for the next guy, no configuration, etc. But it creates a problem here - it means that the nature of the project is predetermined at the time of the checkout. That's what I wanted, but I don't want it here. So I suppose the plan would be: 1. make a tag of current state and cut a branch at the same point. Yes 2. delete from the branch all the .* files that determine configuration, IN THE REPOSITORY, not on a local copy, where Eclipse would immediately recreate these files. Yes, and use svn ignore so they will not come back. 3. delete the local copy of the project. Well not yet. Mavenize the branch first and make sure it works. Tha' POC. Then go to 3. 4. check it out again from the repository as a new project and specify maven in the wizards? Haven't used m2eclipse, but I'll say yes :) I would urge you to also learn to use maven with the commandline. I assume this is possible. Is it what you had in mind? Or is there a better way. Steve Jon Georg Berentsen wrote: Hey! Great! Since mavnen config is pretty new to you, this is a great way to learn. 1) Is there some way to change natures? No. With Ant and scripts you can get a very specific build process, usually with som quircks and/or workarounds. I find using the Ant scripts and other scripts as inspiration and documentation for building up the pom, the best way to use them. But there are a bunch of tricks and tips in doing so. I think we went thru a few previously in this tread. 2) Create a new Maven project, place in SVN, then move stuff to the right places? I always presume people have a branch, a tag and a trunk folder, but if not have a look at some apache project and see how it's done. I usually do a poc in a branch to see if it all works out. (A copy or externals of the working trunk) You do not want to mess up your code, fail, get a new order for business/management, and desperatly revert trunk. You also want to tag a stable last version of your Ant built project. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Wow. There are 101 ways (perhaps 11) to do what you want. No one specific way is best and there is no wizard that automatically converts an ant build.xml into a Maven project. I can share some of the things that I found important to learn during my transition to Maven. 1. Become familiar with Maven's philosophy: http://maven.apache.org/background/philosophy-of-maven.html 2. Get to know your settings.xml file and what it is for. I found it somewhat confusing to understand at first. Understand the difference between the global and local settings.xml file. 3. Understand that the m2e plugin still has some bugs. Particularly if you use the Embedded installation. It is a GREAT tool still to use even when considering these bugs but you will still want to have the command line available. One thing that helps with m2e is pointing to a local install instead of the Embedded install. 4. Understand how multi-module projects are structured and how they work. I made a dummy project for this before I even considered porting over the actual production code. 5. Understand what a SNAPSHOT version is and how this is different from a regular released version. I found this confusing at first. 6. Get to know the release plugin; its benefits and its limitations. 7. Understand the build lifecycle and how to bind goals to phases. 8. Understand that Maven encourges, as a rule of thumb, one built artifact per project. This could be a challenge when moving from ant if your ant build builds many artifacts. I found that when we moved to Maven, we had a larger number of projects than with ant but this in the end was a very good thing. 9. Using a repo manager has proved to be extremely useful. Builds are faster and it provides a great way to share artifacts with your team. 10. Understand what aggregation means and that Maven does not yet support aggregation well. Some things that you had available in ant, like an aggregated checkstyle report, are not yet available in Maven. And above all, enjoy ;-). --- Todd Thiessen -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: Tuesday, February 24, 2009 8:34 AM To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux OK. Since we're skipping the ant phase on this project, never having used it here, I'll go with your suggestions in #2. I'll start by making a branch, using the least dependent project (which depends on no others) for my first guinea pig. (I DO follow the trunk-branch-tag pattern). However, one question remains - in my present mode I always check everything into SVN, including all those .* files (.project etc.) which, by default, eclipse filters out. I do that to make checkout easier for the next guy, no configuration, etc. But it creates a problem here - it means that the nature of the project is predetermined at the time of the checkout. That's what I wanted, but I don't want it here. So I suppose the plan would be: 1. make a tag of current state and cut a branch at the same point. 2. delete from the branch all the .* files that determine configuration, IN THE REPOSITORY, not on a local copy, where Eclipse would immediately recreate these files. 3. delete the local copy of the project. 4. check it out again from the repository as a new project and specify maven in the wizards? I assume this is possible. Is it what you had in mind? Or is there a better way. Steve Jon Georg Berentsen wrote: Hey! Great! Since mavnen config is pretty new to you, this is a great way to learn. 1) Is there some way to change natures? No. With Ant and scripts you can get a very specific build process, usually with som quircks and/or workarounds. I find using the Ant scripts and other scripts as inspiration and documentation for building up the pom, the best way to use them. But there are a bunch of tricks and tips in doing so. I think we went thru a few previously in this tread. 2) Create a new Maven project, place in SVN, then move stuff to the right places? I always presume people have a branch, a tag and a trunk folder, but if not have a look at some apache project and see how it's done. I usually do a poc in a branch to see if it all works out. (A copy or externals of the working trunk) You do not want to mess up your code, fail, get a new order for business/management, and desperatly revert trunk. You also want to tag a stable last version of your Ant built project. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing Existing Project Part Deux
+1 -Original Message- From: Todd Thiessen [mailto:thies...@nortel.com] Sent: 24. februar 2009 15:16 To: Maven Users List Subject: RE: Mavenizing Existing Project Part Deux Wow. There are 101 ways (perhaps 11) to do what you want. No one specific way is best and there is no wizard that automatically converts an ant build.xml into a Maven project. I can share some of the things that I found important to learn during my transition to Maven. 1. Become familiar with Maven's philosophy: http://maven.apache.org/background/philosophy-of-maven.html 2. Get to know your settings.xml file and what it is for. I found it somewhat confusing to understand at first. Understand the difference between the global and local settings.xml file. 3. Understand that the m2e plugin still has some bugs. Particularly if you use the Embedded installation. It is a GREAT tool still to use even when considering these bugs but you will still want to have the command line available. One thing that helps with m2e is pointing to a local install instead of the Embedded install. 4. Understand how multi-module projects are structured and how they work. I made a dummy project for this before I even considered porting over the actual production code. 5. Understand what a SNAPSHOT version is and how this is different from a regular released version. I found this confusing at first. 6. Get to know the release plugin; its benefits and its limitations. 7. Understand the build lifecycle and how to bind goals to phases. 8. Understand that Maven encourges, as a rule of thumb, one built artifact per project. This could be a challenge when moving from ant if your ant build builds many artifacts. I found that when we moved to Maven, we had a larger number of projects than with ant but this in the end was a very good thing. 9. Using a repo manager has proved to be extremely useful. Builds are faster and it provides a great way to share artifacts with your team. 10. Understand what aggregation means and that Maven does not yet support aggregation well. Some things that you had available in ant, like an aggregated checkstyle report, are not yet available in Maven. And above all, enjoy ;-). --- Todd Thiessen -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: Tuesday, February 24, 2009 8:34 AM To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux OK. Since we're skipping the ant phase on this project, never having used it here, I'll go with your suggestions in #2. I'll start by making a branch, using the least dependent project (which depends on no others) for my first guinea pig. (I DO follow the trunk-branch-tag pattern). However, one question remains - in my present mode I always check everything into SVN, including all those .* files (.project etc.) which, by default, eclipse filters out. I do that to make checkout easier for the next guy, no configuration, etc. But it creates a problem here - it means that the nature of the project is predetermined at the time of the checkout. That's what I wanted, but I don't want it here. So I suppose the plan would be: 1. make a tag of current state and cut a branch at the same point. 2. delete from the branch all the .* files that determine configuration, IN THE REPOSITORY, not on a local copy, where Eclipse would immediately recreate these files. 3. delete the local copy of the project. 4. check it out again from the repository as a new project and specify maven in the wizards? I assume this is possible. Is it what you had in mind? Or is there a better way. Steve Jon Georg Berentsen wrote: Hey! Great! Since mavnen config is pretty new to you, this is a great way to learn. 1) Is there some way to change natures? No. With Ant and scripts you can get a very specific build process, usually with som quircks and/or workarounds. I find using the Ant scripts and other scripts as inspiration and documentation for building up the pom, the best way to use them. But there are a bunch of tricks and tips in doing so. I think we went thru a few previously in this tread. 2) Create a new Maven project, place in SVN, then move stuff to the right places? I always presume people have a branch, a tag and a trunk folder, but if not have a look at some apache project and see how it's done. I usually do a poc in a branch to see if it all works out. (A copy or externals of the working trunk) You do not want to mess up your code, fail, get a new order for business/management, and desperatly revert trunk. You also want to tag a stable last version of your Ant built project. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Hey, I know. In the Beginning was the Command Line. I'm a believer. BUT, if I can't make this look seamless in Eclipse, I'll never win. Re pts 3 and 4 delete the local copy of the project meant delete the local copy of the project on the branch. I can always get back to what I had from the trunk. Mavenization comes in and after step 4. Jon Georg Berentsen wrote: -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 24. februar 2009 14:34 To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux OK. Since we're skipping the ant phase on this project, never having used it here, I'll go with your suggestions in #2. I'll start by making a branch, using the least dependent project (which depends on no others) for my first guinea pig. (I DO follow the trunk-branch-tag pattern). However, one question remains - in my present mode I always check everything into SVN, including all those .* files (.project etc.) which, by default, eclipse filters out. I do that to make checkout easier for the next guy, no configuration, etc. But it creates a problem here - it means that the nature of the project is predetermined at the time of the checkout. That's what I wanted, but I don't want it here. So I suppose the plan would be: 1. make a tag of current state and cut a branch at the same point. Yes 2. delete from the branch all the .* files that determine configuration, IN THE REPOSITORY, not on a local copy, where Eclipse would immediately recreate these files. Yes, and use svn ignore so they will not come back. 3. delete the local copy of the project. Well not yet. Mavenize the branch first and make sure it works. Tha' POC. Then go to 3. 4. check it out again from the repository as a new project and specify maven in the wizards? Haven't used m2eclipse, but I'll say yes :) I would urge you to also learn to use maven with the commandline. I assume this is possible. Is it what you had in mind? Or is there a better way. Steve Jon Georg Berentsen wrote: Hey! Great! Since mavnen config is pretty new to you, this is a great way to learn. 1) Is there some way to change natures? No. With Ant and scripts you can get a very specific build process, usually with som quircks and/or workarounds. I find using the Ant scripts and other scripts as inspiration and documentation for building up the pom, the best way to use them. But there are a bunch of tricks and tips in doing so. I think we went thru a few previously in this tread. 2) Create a new Maven project, place in SVN, then move stuff to the right places? I always presume people have a branch, a tag and a trunk folder, but if not have a look at some apache project and see how it's done. I usually do a poc in a branch to see if it all works out. (A copy or externals of the working trunk) You do not want to mess up your code, fail, get a new order for business/management, and desperatly revert trunk. You also want to tag a stable last version of your Ant built project. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Thanks Todd. But note, I don't have any Ant stuff to convert. I'm starting from a more rudimentary base - Eclipse Export has been my build system. In some ways this makes things easier. I hope so, anyway. Todd Thiessen wrote: Wow. There are 101 ways (perhaps 11) to do what you want. No one specific way is best and there is no wizard that automatically converts an ant build.xml into a Maven project. I can share some of the things that I found important to learn during my transition to Maven. 1. Become familiar with Maven's philosophy: http://maven.apache.org/background/philosophy-of-maven.html Been there. Wouldn't be here if not. 2. Get to know your settings.xml file and what it is for. I found it somewhat confusing to understand at first. Understand the difference between the global and local settings.xml file. good point, I will. 3. Understand that the m2e plugin still has some bugs. Particularly if you use the Embedded installation. It is a GREAT tool still to use even when considering these bugs but you will still want to have the command line available. One thing that helps with m2e is pointing to a local install instead of the Embedded install. Will have to learn what you're talking about here. 4. Understand how multi-module projects are structured and how they work. I made a dummy project for this before I even considered porting over the actual production code. Yup, this is where I want to wind up. I am supposing that the right thing is to get the individual projects buildable this way, then build a multi-module architecture around it. If that is wrong, please let me know now before I get too far into this. 5. Understand what a SNAPSHOT version is and how this is different from a regular released version. I found this confusing at first. Will do. 6. Get to know the release plugin; its benefits and its limitations. ditto 7. Understand the build lifecycle and how to bind goals to phases. ditto 8. Understand that Maven encourges, as a rule of thumb, one built artifact per project. This could be a challenge when moving from ant if your ant build builds many artifacts. I found that when we moved to Maven, we had a larger number of projects than with ant but this in the end was a very good thing. This mirrors present structure, except for one manual step where I exported (Eclipse Export) a bunch of projects to a jar, then manually zipped it up with its dependencies. This is the hump I want Maven to get me over. 9. Using a repo manager has proved to be extremely useful. Builds are faster and it provides a great way to share artifacts with your team. See previous thread. Ain't gonna happen unless I get team using with individual repos first. 10. Understand what aggregation means and that Maven does not yet support aggregation well. Some things that you had available in ant, like an aggregated checkstyle report, are not yet available in Maven. Checkstyle? Oh Lord. Can't miss what you never had. And above all, enjoy ;-). Yup. --- Todd Thiessen -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: Tuesday, February 24, 2009 8:34 AM To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux OK. Since we're skipping the ant phase on this project, never having used it here, I'll go with your suggestions in #2. I'll start by making a branch, using the least dependent project (which depends on no others) for my first guinea pig. (I DO follow the trunk-branch-tag pattern). However, one question remains - in my present mode I always check everything into SVN, including all those .* files (.project etc.) which, by default, eclipse filters out. I do that to make checkout easier for the next guy, no configuration, etc. But it creates a problem here - it means that the nature of the project is predetermined at the time of the checkout. That's what I wanted, but I don't want it here. So I suppose the plan would be: 1. make a tag of current state and cut a branch at the same point. 2. delete from the branch all the .* files that determine configuration, IN THE REPOSITORY, not on a local copy, where Eclipse would immediately recreate these files. 3. delete the local copy of the project. 4. check it out again from the repository as a new project and specify maven in the wizards? I assume this is possible. Is it what you had in mind? Or is there a better way. Steve Jon Georg Berentsen wrote: Hey! Great! Since mavnen config is pretty new to you, this is a great way to learn. 1) Is there some way to change natures? No. With Ant and scripts you can get a very specific build process, usually with som quircks and/or workarounds. I find using the Ant scripts and other scripts as inspiration and documentation for building up the pom, the best way to use them. But there are a bunch of tricks and tips in doing so. I think we went thru a few previously
RE: Mavenizing Existing Project Part Deux
4. Understand how multi-module projects are structured and how they work. I made a dummy project for this before I even considered porting over the actual production code. Yup, this is where I want to wind up. I am supposing that the right thing is to get the individual projects buildable this way, then build a multi-module architecture around it. If that is wrong, please let me know now before I get too far into this. If the project can be built individually, then yes that makes sense. But if you have any depencencies between projects then of course the picture is a bit more complex. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Todd Thiessen wrote: 4. Understand how multi-module projects are structured and how they work. I made a dummy project for this before I even considered porting over the actual production code. Yup, this is where I want to wind up. I am supposing that the right thing is to get the individual projects buildable this way, then build a multi-module architecture around it. If that is wrong, please let me know now before I get too far into this. If the project can be built individually, then yes that makes sense. But if you have any depencencies between projects then of course the picture is a bit more complex. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Okay, so this is going to be the rub, it looks like. I have multiple projects and they DO depend on one another, but in a well defined fashion, not cyclically. I guess my question is, what, in Maven, takes the place of (or supplements) the Eclipse action of putting one project on the build path of another? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
you need: - a top folder (parent pom) - sub-folders with the modules (each refering the top pom and the other modules dependencies - if any) then in the top folder you type: mvn install eclipse:eclipse it will do the job On Tue, Feb 24, 2009 at 4:29 PM, Steve Cohen sco...@javactivity.org wrote: Todd Thiessen wrote: 4. Understand how multi-module projects are structured and how they work. I made a dummy project for this before I even considered porting over the actual production code. Yup, this is where I want to wind up. I am supposing that the right thing is to get the individual projects buildable this way, then build a multi-module architecture around it. If that is wrong, please let me know now before I get too far into this. If the project can be built individually, then yes that makes sense. But if you have any depencencies between projects then of course the picture is a bit more complex. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Okay, so this is going to be the rub, it looks like. I have multiple projects and they DO depend on one another, but in a well defined fashion, not cyclically. I guess my question is, what, in Maven, takes the place of (or supplements) the Eclipse action of putting one project on the build path of another? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Please help to test this application: http://fgaucho.dyndns.org:8080/cejug-classifieds-richfaces - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Do make your first Maven project a conversion. You will likely fail or be extremely unhappy. I have seen this a hundred times now and trying to wedge Maven into what you currently have is categorically not a good idea. Find a new, preferably small, project where you can try out Maven and understand fully what it does before you attempt to convert a project. On 23-Feb-09, at 4:53 PM, Steve Cohen wrote: OK, after extensive discussion in earlier thread about the best way to go about Mavenizing Existing Project(s) in my, shall we say, unusual environment (see that thread for details, don't want to recapitulate them here) I have decided to try to move forward. First I have to learn this tool. I have used maven before, but mainly in the way of building from someone else's POM. Just type maven install or some such and bingo, the world is built. Now my goal is to have pre-existing non-Maven projects be mavenized. I am prepared to throw the first one away. I also want to take this opportunity to start from a m2eclipse platform, so I have now installed that, even to the point of installing Ganymede because I couldn't get it to install in Europa. Although I know there is benefit to the command line tools, I'd like to start from eclipse, understanding that I can take the POM I produce and install it with command line tools. So my first question is this: How do I convert a non-Maven project into a Maven project? 1) Is there some way to change natures? 2) Create a new Maven project, place in SVN, then move stuff to the right places? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Wow. That's different advice from what others are saying, BUT, you're the maven so I do appreciate your warning and take it seriously! Was there a missing not in your first sentence? It seems to make more sense that way. I am prepared to fail the first few times, start with the simplest projects, etc. I'm not a newbie, I have a lot of experience in reengineering builds and I don't imagine immediate success the first time around. Also, I'm a team of, for all practical purposes, one. There are no other users I can burn with my failed efforts. And I'm a bulldog when I want to be. It seems to me that my experiences, if carefully logged and ultimately successful, could be helpful to other potential users who might be in my position. Frankly, I think would be good for Maven to lower the bar to conversion. It seems higher to me than it ought to be. Steve Jason van Zyl wrote: Do make your first Maven project a conversion. You will likely fail or be extremely unhappy. I have seen this a hundred times now and trying to wedge Maven into what you currently have is categorically not a good idea. Find a new, preferably small, project where you can try out Maven and understand fully what it does before you attempt to convert a project. On 23-Feb-09, at 4:53 PM, Steve Cohen wrote: OK, after extensive discussion in earlier thread about the best way to go about Mavenizing Existing Project(s) in my, shall we say, unusual environment (see that thread for details, don't want to recapitulate them here) I have decided to try to move forward. First I have to learn this tool. I have used maven before, but mainly in the way of building from someone else's POM. Just type maven install or some such and bingo, the world is built. Now my goal is to have pre-existing non-Maven projects be mavenized. I am prepared to throw the first one away. I also want to take this opportunity to start from a m2eclipse platform, so I have now installed that, even to the point of installing Ganymede because I couldn't get it to install in Europa. Although I know there is benefit to the command line tools, I'd like to start from eclipse, understanding that I can take the POM I produce and install it with command line tools. So my first question is this: How do I convert a non-Maven project into a Maven project? 1) Is there some way to change natures? 2) Create a new Maven project, place in SVN, then move stuff to the right places? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Jason, This blogpost, http://tech.puredanger.com/2009/01/28/maven-adoption-curve/ , sparked quite a debate in my company. We have been quite the early adopters with maven, and have seen the benefits etc. etc., but it seem like this Ant/script to Maven, what do we get, we only got trouble fight has to be fought all the time with clients and new co workers. In your experience who adopt and embrace maven? Is it always the I have seen the need-people? Or do you have to have a maven Maven guy preaching? It seems, to me, that if none of the two is present, Maven is often considered a hassel and pain. Often, if used, Maven also becomes a specialist skill. One or two persons know it, the rest just use it, and can't fix it if something is broken. I have often heard that the reason for this is that Ant is very transparent in what it does. Maven is not. Does this raise the bar for adoption? Project size/complexity and skills matter? Jon -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: 24. februar 2009 16:32 To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux Do make your first Maven project a conversion. You will likely fail or be extremely unhappy. I have seen this a hundred times now and trying to wedge Maven into what you currently have is categorically not a good idea. Find a new, preferably small, project where you can try out Maven and understand fully what it does before you attempt to convert a project. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
On Mon, Feb 23, 2009 at 3:51 PM, Steve Cohen sco...@javactivity.org wrote: You should also look at continuous build systems like Hudson or CruiseControl. We're probably too small for those sorts of systems. No one is too small for Hudson! Hudson installs in five minutes. All you need is JDK 1.5 or higher. If you're running Eclipse or Maven, you've already satisfied that requirement. Hudson contains its own server using winestone. It is a self contained JAR. You simply run a single Java command, and it's up and running. Setting up a build project in Hudson is completely intuitive. Its graphical with a complete help system. It integrates with CVS, Subversion, Ant, Maven, and even Jira and Bugzilla. The only thing I suggest is that you have enough diskspace to store builds. Or, you can tell Hudson to delete builds older than a certain age or if there only save the X most recent builds. Try Hudson: https://hudson.dev.java.net/. You'll find it is an absolutely wonderful tool. And, I think it is one of the best run open source projects I have ever seen. They support is wonderful, and the developers behind it are very responsive to suggestions. -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
On 24-Feb-09, at 8:12 AM, Steve Cohen wrote: Wow. That's different advice from what others are saying, BUT, you're the maven so I do appreciate your warning and take it seriously! Was there a missing not in your first sentence? It seems to make more sense that way. Yes, a typo. Try a small Maven project first and learn what it does on a small scale before attempting a large project. Maven is very different then ad-hoc scripting and you'll get frustrated pretty fast. There's usually a way in Maven to do everything you need. Also a good idea to read: http://www.sonatype.com/products/maven/documentation/book-defguide I am prepared to fail the first few times, start with the simplest projects, etc. I'm not a newbie, I have a lot of experience in reengineering builds and I don't imagine immediate success the first time around. Also, I'm a team of, for all practical purposes, one. There are no other users I can burn with my failed efforts. And I'm a bulldog when I want to be. It seems to me that my experiences, if carefully logged and ultimately successful, could be helpful to other potential users who might be in my position. Frankly, I think would be good for Maven to lower the bar to conversion. It seems higher to me than it ought to be. You're talking about conversion from something usually arbitrary relative to Maven. We do have some tools around to help with conversions but it's primarily mapping out dependencies and creating repositories that's enough to get people started. Steve Jason van Zyl wrote: Do make your first Maven project a conversion. You will likely fail or be extremely unhappy. I have seen this a hundred times now and trying to wedge Maven into what you currently have is categorically not a good idea. Find a new, preferably small, project where you can try out Maven and understand fully what it does before you attempt to convert a project. On 23-Feb-09, at 4:53 PM, Steve Cohen wrote: OK, after extensive discussion in earlier thread about the best way to go about Mavenizing Existing Project(s) in my, shall we say, unusual environment (see that thread for details, don't want to recapitulate them here) I have decided to try to move forward. First I have to learn this tool. I have used maven before, but mainly in the way of building from someone else's POM. Just type maven install or some such and bingo, the world is built. Now my goal is to have pre-existing non-Maven projects be mavenized. I am prepared to throw the first one away. I also want to take this opportunity to start from a m2eclipse platform, so I have now installed that, even to the point of installing Ganymede because I couldn't get it to install in Europa. Although I know there is benefit to the command line tools, I'd like to start from eclipse, understanding that I can take the POM I produce and install it with command line tools. So my first question is this: How do I convert a non-Maven project into a Maven project? 1) Is there some way to change natures? 2) Create a new Maven project, place in SVN, then move stuff to the right places? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
On 24-Feb-09, at 8:12 AM, Jon Georg Berentsen wrote: Jason, This blogpost, http://tech.puredanger.com/2009/01/28/maven-adoption-curve/ , sparked quite a debate in my company. We have been quite the early adopters with maven, and have seen the benefits etc. etc., but it seem like this Ant/script to Maven, what do we get, we only got trouble fight has to be fought all the time with clients and new co workers. In your experience who adopt and embrace maven? People who try it and have something that works. If it doesn't work for you then don't use it. I'm not very preachy about Maven and I've never tried to convert people to use it. I don't think that would generally work anyway. If Ant or scripting languages work for you then use them. Is it always the I have seen the need-people? Or do you have to have a maven Maven guy preaching? I don't think you'll get very far if the team doesn't buy into it. Any organization who listens to one preachy guy and then adopts Maven is not going to get very far. It seems, to me, that if none of the two is present, Maven is often considered a hassel and pain. Often people don't read any documentation, think a build is just something that requires no maintenance and is just going to work, or are just completely accustom to Ant that anything different seems like a hassle. We get lots of people telling us all the time that they think Maven is great and works well for them. Often, if used, Maven also becomes a specialist skill. One or two persons know it, the rest just use it, and can't fix it if something is broken. I honestly have not found that to be the case when developers are prepared. If you took two people who don't know either Ant or Maven you would probably have an equal amount of difficulty. You get used to what you use. Project who think that they can get away without investing something in the infrastructure and training about it are going to have problems. Many people think build and release management is just some appendage to their project. Your project is not going to work if the infrastructure doesn't work. I have often heard that the reason for this is that Ant is very transparent in what it does. Maven is not. I really don't think that's the case. I think people have just used Ant for a long time and they are used to it. Does this raise the bar for adoption? I don't think so. Traffic on Maven central has grown incredibly over the last year (on the order of 200M hits/month) and it continues to grow. So Maven is still being adopted all the time because the number of unique IPs keeps growing. So empirically we're seeing an increase in adoption as time passes. Project size/complexity and skills matter? Nope. I know lots people who use Maven on small projects and we have clients who build project that are 6M lines of code. Some are build and release engineers, most of them are just developers. Jon -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: 24. februar 2009 16:32 To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux Do make your first Maven project a conversion. You will likely fail or be extremely unhappy. I have seen this a hundred times now and trying to wedge Maven into what you currently have is categorically not a good idea. Find a new, preferably small, project where you can try out Maven and understand fully what it does before you attempt to convert a project. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- Three may keep a secret if two of them are dead. -- Benjamin Franklin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
The one big concern I have is your plan of starting with eclipse and the m2eclipse plugin. It's not that I'm old school and prefer the command line but I find that the m2eclipse plugin does a lot of automagic stuff and you may not realize when things are changing under you because of what the plugin is doing. Once you have your project working from the command line, then commit it to svn, then in eclipse check it out from svn as a maven project. The other thing is, and this may be an urban legend, that I think it's better to not have the sub modules nested in the parent module's directory. Make them parallel; siblings. This means using ../ with relativePath when referring to the parent's pom: parent artifactIdproject_parent/artifactId groupIdmy.company.group.id/groupId version1.1-SNAPSHOT/version relativePath../project_parent/pom.xml/relativePath /parent artifactIdproject_module1/artifactId packagingjar/packaging etc. I think eclipse doesn't like or support nested projects. If you use the nested directories layout, when you import it into eclipse I think the m2eclipse does some voodoo behind your back, rearranging things to make eclipse happy. For me it was a bit more transparent having the modules as parallel projects in eclipse. Steve Cohen wrote: OK, after extensive discussion in earlier thread about the best way to go about Mavenizing Existing Project(s) in my, shall we say, unusual environment (see that thread for details, don't want to recapitulate them here) I have decided to try to move forward. First I have to learn this tool. I have used maven before, but mainly in the way of building from someone else's POM. Just type maven install or some such and bingo, the world is built. Now my goal is to have pre-existing non-Maven projects be mavenized. I am prepared to throw the first one away. I also want to take this opportunity to start from a m2eclipse platform, so I have now installed that, even to the point of installing Ganymede because I couldn't get it to install in Europa. Although I know there is benefit to the command line tools, I'd like to start from eclipse, understanding that I can take the POM I produce and install it with command line tools. So my first question is this: How do I convert a non-Maven project into a Maven project? 1) Is there some way to change natures? 2) Create a new Maven project, place in SVN, then move stuff to the right places? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Same setup as the project I been mavenizing for the last few weeks. The first thing you want to do is set up a local company Nexus and release all those proprietary jars. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Should not be a problem. Plenty of plugins for any given container. Whould recommend jetty, if you have no servers lockins. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Same as we had. Expect to use some time trimming the pom's. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. Every brown field mavneization is different. My strategi was: 1.Depending on the setting and controll over the source, consider using subversion externals in a POC. 2. Setup and/or release 3 party jars in the company repo. 3.Put it all in one project and make it compile. 4. Get in running on the container of your choise, using a maven plugin. 5. Import all tests and make'em run green (might have to be done earlyer, dep on your project) 6. Divide the project into multimodule projects. Recommend Domain Driven Design :) And yes it can take some time. Took me 3 weeks, doing a enterprise 250++ external jars, 3 years of code, lockins to container, bad tests next to production code. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. Again consider using Subversion externals in a poc first. 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. With a good repo you'll have both :) Thanks. Steve Cohen No p'! Good luck! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
2009/2/23 Jon Georg Berentsen jon.georg.berent...@objectware.no I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Same setup as the project I been mavenizing for the last few weeks. The first thing you want to do is set up a local company Nexus and release all those proprietary jars. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Should not be a problem. Plenty of plugins for any given container. Whould recommend jetty, if you have no servers lockins. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Same as we had. Expect to use some time trimming the pom's. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. Every brown field mavneization is different. My strategi was: 1.Depending on the setting and controll over the source, consider using subversion externals in a POC. Why not just do it on a branch it'll make merging the changes back easier. Doing it via externals will actually make your life harder IMHO 2. Setup and/or release 3 party jars in the company repo. +1000 3.Put it all in one project and make it compile. I'm less keen on this option. I would take each artifact one step at a time, the Big Feck Off Project (BFOP) technique tends to lead to bad pom design... easier to refactor jars as jars, wars as wars, and if you want at the end string them all together with an aggregator pom... but getting your release process working with the release plugin will require much more effort on a brown-field project if you go BFOP than if you go lots of small projects and an aggregator if you need to join them together. 4. Get in running on the container of your choise, using a maven plugin. 5. Import all tests and make'em run green (might have to be done earlyer, dep on your project) 6. Divide the project into multimodule projects. Recommend Domain Driven Design :) And yes it can take some time. Took me 3 weeks, doing a enterprise 250++ external jars, 3 years of code, lockins to container, bad tests next to production code. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. Again consider using Subversion externals in a poc first. 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. With a good repo you'll have both :) Thanks. Steve Cohen No p'! Good luck! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
-Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 23. februar 2009 10:21 To: Maven Users List Subject: Re: Mavenizing existing project 2009/2/23 Jon Georg Berentsen jon.georg.berent...@objectware.no I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Same setup as the project I been mavenizing for the last few weeks. The first thing you want to do is set up a local company Nexus and release all those proprietary jars. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Should not be a problem. Plenty of plugins for any given container. Whould recommend jetty, if you have no servers lockins. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Same as we had. Expect to use some time trimming the pom's. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. Every brown field mavneization is different. My strategi was: 1.Depending on the setting and controll over the source, consider using subversion externals in a POC. Why not just do it on a branch it'll make merging the changes back easier. Doing it via externals will actually make your life harder IMHO YES! Sorry! Branch out. Even if you use subversion externals. Using svn externals depends on the setting. In my case I was doing a maven POC and could'nt touch the trunk, but needed the changes. Branching depends on the changes you expect in the trunk. In my case a big no, no since we where doing heavy refactoring at the same time. 2. Setup and/or release 3 party jars in the company repo. +1000 3.Put it all in one project and make it compile. I'm less keen on this option. I would take each artifact one step at a time, the Big Feck Off Project (BFOP) technique tends to lead to bad pom design... easier to refactor jars as jars, wars as wars, and if you want at the end string them all together with an aggregator pom... but getting your release process working with the release plugin will require much more effort on a brown-field project if you go BFOP than if you go lots of small projects and an aggregator if you need to join them together. Yes. Avoiding the BFOP is a good thing, but it depends how well you know the code. I would rather have a BFOP that runs in week one. After all that's what I have now! And then start to refactor nice and steady, dealing with the spagetti code. Nothing more frightening than not haveing a running project for weeks! 4. Get in running on the container of your choise, using a maven plugin. 5. Import all tests and make'em run green (might have to be done earlyer, dep on your project) 6. Divide the project into multimodule projects. Recommend Domain Driven Design :) And yes it can take some time. Took me 3 weeks, doing a enterprise 250++ external jars, 3 years of code, lockins to container, bad tests next to production code. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. Again consider using Subversion externals in a poc first. 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. With a good repo you'll have both :) Thanks. Steve Cohen No p'! Good luck! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail
Re: Mavenizing existing project
Interested in this thread as I am in the same situation with large set of projects in Eclipse that I mung into a final application with a combination of Ant tasks and shell scripts. Also need to handle two sets of developers, one set uses Mac OS X, the other Vista. Want to be able to check into and out of our subversion the exact same project, but allow in pom for differences in platform locations. Good advice appreciated here. Have read first 1/2 of the new Maven2 book. Thanks for advice and protocol. On Feb 22, 2009, at 9:04 AM, Steve Cohen wrote: I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. Thanks. Steve Cohen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
Thanks, Jon and Stephen Can you please define some terms in what you wrote that are unfamiliar to me? subversion externals POC thanks. Steve Cohen Jon Georg Berentsen wrote: -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 23. februar 2009 10:21 To: Maven Users List Subject: Re: Mavenizing existing project 2009/2/23 Jon Georg Berentsen jon.georg.berent...@objectware.no I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Same setup as the project I been mavenizing for the last few weeks. The first thing you want to do is set up a local company Nexus and release all those proprietary jars. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Should not be a problem. Plenty of plugins for any given container. Whould recommend jetty, if you have no servers lockins. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Same as we had. Expect to use some time trimming the pom's. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. Every brown field mavneization is different. My strategi was: 1.Depending on the setting and controll over the source, consider using subversion externals in a POC. Why not just do it on a branch it'll make merging the changes back easier. Doing it via externals will actually make your life harder IMHO YES! Sorry! Branch out. Even if you use subversion externals. Using svn externals depends on the setting. In my case I was doing a maven POC and could'nt touch the trunk, but needed the changes. Branching depends on the changes you expect in the trunk. In my case a big no, no since we where doing heavy refactoring at the same time. 2. Setup and/or release 3 party jars in the company repo. +1000 3.Put it all in one project and make it compile. I'm less keen on this option. I would take each artifact one step at a time, the Big Feck Off Project (BFOP) technique tends to lead to bad pom design... easier to refactor jars as jars, wars as wars, and if you want at the end string them all together with an aggregator pom... but getting your release process working with the release plugin will require much more effort on a brown-field project if you go BFOP than if you go lots of small projects and an aggregator if you need to join them together. Yes. Avoiding the BFOP is a good thing, but it depends how well you know the code. I would rather have a BFOP that runs in week one. After all that's what I have now! And then start to refactor nice and steady, dealing with the spagetti code. Nothing more frightening than not haveing a running project for weeks! 4. Get in running on the container of your choise, using a maven plugin. 5. Import all tests and make'em run green (might have to be done earlyer, dep on your project) 6. Divide the project into multimodule projects. Recommend Domain Driven Design :) And yes it can take some time. Took me 3 weeks, doing a enterprise 250++ external jars, 3 years of code, lockins to container, bad tests next to production code. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. Again consider using Subversion externals in a poc first. 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. With a good repo you'll have both :) Thanks. Steve Cohen No p'! Good luck! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
Hm. Google it.. But, here y' go! POC - http://en.wikipedia.org/wiki/Proof_of_concept Subversion externals - http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 14:22 To: Maven Users List Subject: Re: Mavenizing existing project Thanks, Jon and Stephen Can you please define some terms in what you wrote that are unfamiliar to me? subversion externals POC thanks. Steve Cohen Jon Georg Berentsen wrote: -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 23. februar 2009 10:21 To: Maven Users List Subject: Re: Mavenizing existing project 2009/2/23 Jon Georg Berentsen jon.georg.berent...@objectware.no I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Same setup as the project I been mavenizing for the last few weeks. The first thing you want to do is set up a local company Nexus and release all those proprietary jars. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Should not be a problem. Plenty of plugins for any given container. Whould recommend jetty, if you have no servers lockins. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Same as we had. Expect to use some time trimming the pom's. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. Every brown field mavneization is different. My strategi was: 1.Depending on the setting and controll over the source, consider using subversion externals in a POC. Why not just do it on a branch it'll make merging the changes back easier. Doing it via externals will actually make your life harder IMHO YES! Sorry! Branch out. Even if you use subversion externals. Using svn externals depends on the setting. In my case I was doing a maven POC and could'nt touch the trunk, but needed the changes. Branching depends on the changes you expect in the trunk. In my case a big no, no since we where doing heavy refactoring at the same time. 2. Setup and/or release 3 party jars in the company repo. +1000 3.Put it all in one project and make it compile. I'm less keen on this option. I would take each artifact one step at a time, the Big Feck Off Project (BFOP) technique tends to lead to bad pom design... easier to refactor jars as jars, wars as wars, and if you want at the end string them all together with an aggregator pom... but getting your release process working with the release plugin will require much more effort on a brown-field project if you go BFOP than if you go lots of small projects and an aggregator if you need to join them together. Yes. Avoiding the BFOP is a good thing, but it depends how well you know the code. I would rather have a BFOP that runs in week one. After all that's what I have now! And then start to refactor nice and steady, dealing with the spagetti code. Nothing more frightening than not haveing a running project for weeks! 4. Get in running on the container of your choise, using a maven plugin. 5. Import all tests and make'em run green (might have to be done earlyer, dep on your project) 6. Divide the project into multimodule projects. Recommend Domain Driven Design :) And yes it can take some time. Took me 3 weeks, doing a enterprise 250++ external jars, 3 years of code, lockins to container, bad tests next to production code. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. Again consider using Subversion externals in a poc first. 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only
Re: Mavenizing existing project
As I begin, I've made a copy of the Chapter 3 code package for proficio. I've started to slowly move my eclipse code into these packages, but have some questions. 1) The group id is actually the base of all of the package names. Is that right. So if I'm com.areteq, then my groupId should be com.areteq. 2) In one eclipse project(Foundation), I have several packages such as com.areteq.foundation, com.areteq.foundation.impl, com.areteq.util, etc. I need to have my directory structure under java match that, I believe. 3) Now, in the poms, the foundation (mapping to proficio-api) all the groupIds need to be changed to com.areteq. Correct? 4) For each of the poms, the same changes need to be made. Correct? 5) One other question. I want ALL compilations, reports, plugins that require it to use java 1.5. Is there one place I can put this, or do reports and builds have to have their own? Thanks, On Feb 23, 2009, at 8:46 AM, Jon Georg Berentsen wrote: Hm. Google it.. But, here y' go! POC - http://en.wikipedia.org/wiki/Proof_of_concept Subversion externals - http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 14:22 To: Maven Users List Subject: Re: Mavenizing existing project Thanks, Jon and Stephen Can you please define some terms in what you wrote that are unfamiliar to me? subversion externals POC thanks. Steve Cohen Jon Georg Berentsen wrote: -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 23. februar 2009 10:21 To: Maven Users List Subject: Re: Mavenizing existing project 2009/2/23 Jon Georg Berentsen jon.georg.berent...@objectware.no I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Same setup as the project I been mavenizing for the last few weeks. The first thing you want to do is set up a local company Nexus and release all those proprietary jars. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Should not be a problem. Plenty of plugins for any given container. Whould recommend jetty, if you have no servers lockins. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Same as we had. Expect to use some time trimming the pom's. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. Every brown field mavneization is different. My strategi was: 1.Depending on the setting and controll over the source, consider using subversion externals in a POC. Why not just do it on a branch it'll make merging the changes back easier. Doing it via externals will actually make your life harder IMHO YES! Sorry! Branch out. Even if you use subversion externals. Using svn externals depends on the setting. In my case I was doing a maven POC and could'nt touch the trunk, but needed the changes. Branching depends on the changes you expect in the trunk. In my case a big no, no since we where doing heavy refactoring at the same time. 2. Setup and/or release 3 party jars in the company repo. +1000 3.Put it all in one project and make it compile. I'm less keen on this option. I would take each artifact one step at a time, the Big Feck Off Project (BFOP) technique tends to lead to bad pom design... easier to refactor jars as jars, wars as wars, and if you want at the end string them all together with an aggregator pom... but getting your release process working with the release plugin will require much more effort on a brown-field project if you go BFOP than if you go lots of small projects and an aggregator if you need to join them together. Yes. Avoiding the BFOP is a good thing, but it depends how well you know the code. I would rather have a BFOP that runs in week one. After all that's what I have now! And then start to refactor nice and steady, dealing with the spagetti code. Nothing more frightening than not haveing a running project for weeks! 4. Get in running
Re: Mavenizing existing project
I realize now that I have an additional problem in doing this - an internal sales job within the development team appears to be necessary. Maven is not SELF-EVIDENTLY a GOOD THING. I know this because I too have been a Maven skeptic. I suppose somewhere there must be an introductory article that explains the basic reasons why Maven is to be preferred over the alternatives. Can someone point me at some good ones. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
Thanks. I now grok your meaning - use svn externals as a proof of concept (when I saw POC I imagined some variation on POM) way station between what we are doing now and setting up a true maven repository. That may be the only way to do it in my situation. I am in the worst of both worlds, a small organization (with few resources) inside a mega-corporation (with large security bureaucracy to appease). Perhaps then use Maven as the build tool and skip the local repository for now? Is that what you are suggesting? I hadn't heard of subversion externals before. Could be what I'm looking for. BUT - if I'm understanding correctly, svn externals references Subversion repositories, not Maven repositories. Does this not require knowing the subversion repository location of every third party project you want to use? Or is there some central Subversion (not Maven) repository somewhere that contains these jars? Or can svn externals reference Maven repos? Jon Georg Berentsen wrote: Hm. Google it.. But, here y' go! POC - http://en.wikipedia.org/wiki/Proof_of_concept Subversion externals - http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 14:22 To: Maven Users List Subject: Re: Mavenizing existing project Thanks, Jon and Stephen Can you please define some terms in what you wrote that are unfamiliar to me? subversion externals POC thanks. Steve Cohen Jon Georg Berentsen wrote: -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 23. februar 2009 10:21 To: Maven Users List Subject: Re: Mavenizing existing project 2009/2/23 Jon Georg Berentsen jon.georg.berent...@objectware.no I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Same setup as the project I been mavenizing for the last few weeks. The first thing you want to do is set up a local company Nexus and release all those proprietary jars. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Should not be a problem. Plenty of plugins for any given container. Whould recommend jetty, if you have no servers lockins. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Same as we had. Expect to use some time trimming the pom's. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. Every brown field mavneization is different. My strategi was: 1.Depending on the setting and controll over the source, consider using subversion externals in a POC. Why not just do it on a branch it'll make merging the changes back easier. Doing it via externals will actually make your life harder IMHO YES! Sorry! Branch out. Even if you use subversion externals. Using svn externals depends on the setting. In my case I was doing a maven POC and could'nt touch the trunk, but needed the changes. Branching depends on the changes you expect in the trunk. In my case a big no, no since we where doing heavy refactoring at the same time. 2. Setup and/or release 3 party jars in the company repo. +1000 3.Put it all in one project and make it compile. I'm less keen on this option. I would take each artifact one step at a time, the Big Feck Off Project (BFOP) technique tends to lead to bad pom design... easier to refactor jars as jars, wars as wars, and if you want at the end string them all together with an aggregator pom... but getting your release process working with the release plugin will require much more effort on a brown-field project if you go BFOP than if you go lots of small projects and an aggregator if you need to join them together. Yes. Avoiding the BFOP is a good thing, but it depends how well you know the code. I would rather
Re: Mavenizing existing project
2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I agree you should follow the Maven happy path. I migrated a big several-million-LOC project from Ant to Maven, and I chose a 3rd way, somewhat in-between. The trick is to keep the trunk as it is, so that people can still work with Ant as they are used to, and to perform the migration in a branch. In the branch, you commit only your pom.xml files and an empty folder structure. Every time you need some files from the trunk, you use svn:externals to make a kind of 'dynamic link' inside your SVN repository. Typically, your svn:external will look like this: module/submodule/src/main/java http://repo/trunk/module/submodule/src This way, you can quietly migrate without bothering anyone. When the migration is ready, you also need to make a shell script that will copy the pom.xml from the branch to the trunk and move all source folders in the right place. Similarly, you can prepare and test this script quietly on your side without impacting developers. The migration itself is then just a matter of minutes, while the script is run and you commit everything. That was a little more work for me, but not having 40 stuck developers on my back while I was performing the migration was priceless :-) Hope this will help you Samuel -- View this message in context: http://www.nabble.com/Mavenizing-existing-project-tp22147061p22163304.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
http://wiki.community.objectware.no/display/smidigtonull/Maven+FAQ Enjoy :) -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 15:45 To: Maven Users List Subject: Re: Mavenizing existing project I realize now that I have an additional problem in doing this - an internal sales job within the development team appears to be necessary. Maven is not SELF-EVIDENTLY a GOOD THING. I know this because I too have been a Maven skeptic. I suppose somewhere there must be an introductory article that explains the basic reasons why Maven is to be preferred over the alternatives. Can someone point me at some good ones. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
Bonjour Sam Which tool do you recommend to convert an build.xml to maven? I was thinking of using eclipse-maven plugin but havent found one that works with Eclipse 4.0? it doesnt seem that tough to handcraft settings.xml and pom.xml but I would assume there has to be a build.xml-pom.xml or .project-pom.xml converter tool available..? Merci! Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Mon, 23 Feb 2009 07:11:19 -0800 From: slangl...@ilog.fr To: users@maven.apache.org Subject: Re: Mavenizing existing project 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I agree you should follow the Maven happy path. I migrated a big several-million-LOC project from Ant to Maven, and I chose a 3rd way, somewhat in-between. The trick is to keep the trunk as it is, so that people can still work with Ant as they are used to, and to perform the migration in a branch. In the branch, you commit only your pom.xml files and an empty folder structure. Every time you need some files from the trunk, you use svn:externals to make a kind of 'dynamic link' inside your SVN repository. Typically, your svn:external will look like this: module/submodule/src/main/java http://repo/trunk/module/submodule/src This way, you can quietly migrate without bothering anyone. When the migration is ready, you also need to make a shell script that will copy the pom.xml from the branch to the trunk and move all source folders in the right place. Similarly, you can prepare and test this script quietly on your side without impacting developers. The migration itself is then just a matter of minutes, while the script is run and you commit everything. That was a little more work for me, but not having 40 stuck developers on my back while I was performing the migration was priceless :-) Hope this will help you Samuel -- View this message in context: http://www.nabble.com/Mavenizing-existing-project-tp22147061p22163304.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org _ Windows Live™: Discover 10 secrets about the new Windows Live. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!7540.entry?ocid=TXT_TAGLM_WL_t2_ugc_post_022009
RE: Mavenizing existing project
Answers -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 16:09 To: Maven Users List Subject: Re: Mavenizing existing project Thanks. I now grok your meaning - use svn externals as a proof of concept (when I saw POC I imagined some variation on POM) way station between what we are doing now and setting up a true maven repository. That may be the only way to do it in my situation. I am in the worst of both worlds, a small organization (with few resources) inside a mega-corporation (with large security bureaucracy to appease). Perhaps then use Maven as the build tool and skip the local repository for now? Is that what you are suggesting? POM, POC - I can see that one :) Maven is not a build tool. It's a collection of best practies from an entire worldwide community. The build tool is just a consequence of following best practies. It seems that you (like we had 3 years ago) need to sell this idea to your organization. And trust me, it's worth fighting for a company maven repo. Your salespitch is that this saves development time. If all fails you could (hurts to say it) build it with maven and drop it back in subversion. But if you can get subversion in there, you can get a repo. I hadn't heard of subversion externals before. Could be what I'm looking for. BUT - if I'm understanding correctly, svn externals references Subversion repositories, not Maven repositories. Does this not require knowing the subversion repository location of every third party project you want to use? Or is there some central Subversion (not Maven) repository somewhere that contains these jars? Or can svn externals reference Maven repos? Svn externals is a way to hook in to code. That is: your own code. So no, there is no central Subversion repo. But subversion look at files, and you have a lot of jar files in your subversion repo. So yes, you can hook in to get those files. But that's what you want to get away from when using Maven. 3 party jars should be refed in dependecy management. Jon Jon Georg Berentsen wrote: Hm. Google it.. But, here y' go! POC - http://en.wikipedia.org/wiki/Proof_of_concept Subversion externals - http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 14:22 To: Maven Users List Subject: Re: Mavenizing existing project Thanks, Jon and Stephen Can you please define some terms in what you wrote that are unfamiliar to me? subversion externals POC thanks. Steve Cohen Jon Georg Berentsen wrote: -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 23. februar 2009 10:21 To: Maven Users List Subject: Re: Mavenizing existing project 2009/2/23 Jon Georg Berentsen jon.georg.berent...@objectware.no I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Same setup as the project I been mavenizing for the last few weeks. The first thing you want to do is set up a local company Nexus and release all those proprietary jars. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Should not be a problem. Plenty of plugins for any given container. Whould recommend jetty, if you have no servers lockins. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Same as we had. Expect to use some time trimming the pom's. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. Every brown field mavneization is different. My strategi was: 1.Depending on the setting and controll over the source, consider using subversion externals in a POC. Why not just do it on a branch it'll make merging the changes back easier. Doing it via externals
RE: Mavenizing existing project
+1 -Original Message- From: Samuel Langlois [mailto:slangl...@ilog.fr] Sent: 23. februar 2009 16:11 To: users@maven.apache.org Subject: Re: Mavenizing existing project 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I agree you should follow the Maven happy path. I migrated a big several-million-LOC project from Ant to Maven, and I chose a 3rd way, somewhat in-between. The trick is to keep the trunk as it is, so that people can still work with Ant as they are used to, and to perform the migration in a branch. In the branch, you commit only your pom.xml files and an empty folder structure. Every time you need some files from the trunk, you use svn:externals to make a kind of 'dynamic link' inside your SVN repository. Typically, your svn:external will look like this: module/submodule/src/main/java http://repo/trunk/module/submodule/src This way, you can quietly migrate without bothering anyone. When the migration is ready, you also need to make a shell script that will copy the pom.xml from the branch to the trunk and move all source folders in the right place. Similarly, you can prepare and test this script quietly on your side without impacting developers. The migration itself is then just a matter of minutes, while the script is run and you commit everything. That was a little more work for me, but not having 40 stuck developers on my back while I was performing the migration was priceless :-) Hope this will help you Samuel -- View this message in context: http://www.nabble.com/Mavenizing-existing-project-tp22147061p22163304.ht ml Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
Votre esprit et votre meilleur éditeur. Your brain and your favourite IDE. Yes, it will take time, but it's no clean path around it. Jon -Original Message- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: 23. februar 2009 16:41 To: users@maven.apache.org Subject: RE: Mavenizing existing project Bonjour Sam Which tool do you recommend to convert an build.xml to maven? I was thinking of using eclipse-maven plugin but havent found one that works with Eclipse 4.0? it doesnt seem that tough to handcraft settings.xml and pom.xml but I would assume there has to be a build.xml-pom.xml or .project-pom.xml converter tool available..? Merci! Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Mon, 23 Feb 2009 07:11:19 -0800 From: slangl...@ilog.fr To: users@maven.apache.org Subject: Re: Mavenizing existing project 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I agree you should follow the Maven happy path. I migrated a big several-million-LOC project from Ant to Maven, and I chose a 3rd way, somewhat in-between. The trick is to keep the trunk as it is, so that people can still work with Ant as they are used to, and to perform the migration in a branch. In the branch, you commit only your pom.xml files and an empty folder structure. Every time you need some files from the trunk, you use svn:externals to make a kind of 'dynamic link' inside your SVN repository. Typically, your svn:external will look like this: module/submodule/src/main/java http://repo/trunk/module/submodule/src This way, you can quietly migrate without bothering anyone. When the migration is ready, you also need to make a shell script that will copy the pom.xml from the branch to the trunk and move all source folders in the right place. Similarly, you can prepare and test this script quietly on your side without impacting developers. The migration itself is then just a matter of minutes, while the script is run and you commit everything. That was a little more work for me, but not having 40 stuck developers on my back while I was performing the migration was priceless :-) Hope this will help you Samuel -- View this message in context: http://www.nabble.com/Mavenizing-existing-project-tp22147061p22163304.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org _ Windows Live(tm): Discover 10 secrets about the new Windows Live. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!7540.entry?ocid=TXT_TAGLM_WL_t2_ugc_post_022009 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
I am fairly new to Maven, so maybe there are things that I simply don't know the correct way of doing things. However, we did Mavenize one project, and we simply found that it wasn't worth the effort. We had a strong Ant build process and things were working very well there. The idea to Mavenize came from above. We rearranged our directory structure, but then realized that we were doing a few things that weren't quite standard. Getting these to work took a lot of time and effort. It involved modifying some code and changing the way we deployed. We had times when we were sure everything was okay with our Maven build, but then testing found holes that we didn't realize were there. After three weeks, we finally got the Maven build working.In the end, we have angry developers, a steep learning curve to learn how to work on a project that developers knew in and out, and a build process that isn't much better than what we had. As a result, we have decided not to Mavenize all of our projects. All new projects will use Maven. Some of the simpler projects may be mavenized, but we'll carefully evaluate them. That doesn't mean we didn't learn some neat tricks in the process. The biggest concerns having project A build a jarfile that project B requires. In the pre-Maven days, that meant checking in that built JAR into Subversion, then using svn:export to pick up that jar from the other project. Checking in JARs several times a day into our Subversion repository proved difficult in both process and room. Now that we have a Maven repository, we now use the deploy:deploy-file mojo to deploy that Jar to our Maven repository. If the receiving project is a Maven project, we can now pick it up using the standard dependencies methods in the pom.xml, and we are converting many of these dependent projects into Maven because here's a real advantage Maven does have for us. And for the few dependent projects that we cannot easily Mavenize, I now use Ant's get task to download the jars from the Maven repository. It isn't as clean as the way Maven does it, but it has proven easier to do than to Mavenize these difficult projects. So Mavenizing old projects isn't just a blanket thing to do. You have to evaluate what you have now, and what you expect to gain with Maven. Some projects are pretty straight forward, but if you have an older project with a complex build process, and a build process that fairly rigorous, moving to Maven simply doesn't buy you all that much. On Sun, Feb 22, 2009 at 9:04 AM, Steve Cohen sco...@javactivity.org wrote: I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. Thanks. Steve Cohen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
Some projects are pretty straight forward, but if you have an older project with a complex build process, and a build process that fairly rigorous, moving to Maven simply doesn't buy you all that much. I completely disagree here. I have looked at very complex projects (70+ modules) with extremely complex builds. There was absolutely no doubt about the move. Sure, the initial hit was frustrating but it pays off big time down the road. This is just my opinion and experience of course. Everyone's will vary. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
Unfortunately, you guys may be talking me out of mavenizing rather than into it. :-( My situation is a bit different than what is described. There are only two or three real developers in my project and they work on separate applications with very little sharing between them - and I am one of them, the one most involved in coding, in fact. I'm not an SCM guy per se, though automated builds have always been an interest of mine. Nonetheless I recognize the third-party-jars-in-svn thing as an anti-pattern, and would like to move toward a truly automated build. (As I indicated in my original post, we don't even use Ant here - we use Eclipse's built-in Export to build - and even THAT was a big step forward for this team). But a local, networked M2 repo is going to run up against all sorts of security minefields. So I would like to explore a somewhat different path: 1) abandon any thought of a local repository for now. Too many political/bureaucratic issues. Each developer could download maven and the m2eclipse plugin himself and build a local repository of things needed. 2) create a POM in an SVN branch and develop automated maven-based builds using developer-local repos. If builds break, devs can update their repo. 3) as this becomes general, down the road, if and when the need for a local repo is perceived, only then take that step. Does this kind of plan make any sense to you guys? Jon Georg Berentsen wrote: +1 -Original Message- From: Samuel Langlois [mailto:slangl...@ilog.fr] Sent: 23. februar 2009 16:11 To: users@maven.apache.org Subject: Re: Mavenizing existing project 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I agree you should follow the Maven happy path. I migrated a big several-million-LOC project from Ant to Maven, and I chose a 3rd way, somewhat in-between. The trick is to keep the trunk as it is, so that people can still work with Ant as they are used to, and to perform the migration in a branch. In the branch, you commit only your pom.xml files and an empty folder structure. Every time you need some files from the trunk, you use svn:externals to make a kind of 'dynamic link' inside your SVN repository. Typically, your svn:external will look like this: module/submodule/src/main/java http://repo/trunk/module/submodule/src This way, you can quietly migrate without bothering anyone. When the migration is ready, you also need to make a shell script that will copy the pom.xml from the branch to the trunk and move all source folders in the right place. Similarly, you can prepare and test this script quietly on your side without impacting developers. The migration itself is then just a matter of minutes, while the script is run and you commit everything. That was a little more work for me, but not having 40 stuck developers on my back while I was performing the migration was priceless :-) Hope this will help you Samuel - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
-Original Message- From: David Weintraub [mailto:qazw...@gmail.com] Sent: 23. februar 2009 16:58 To: Maven Users List Subject: Re: Mavenizing existing project I am fairly new to Maven, so maybe there are things that I simply don't know the correct way of doing things. However, we did Mavenize one project, and we simply found that it wasn't worth the effort. We had a strong Ant build process and things were working very well there. The idea to Mavenize came from above. We rearranged our directory structure, but then realized that we were doing a few things that weren't quite standard. Why was this a bad thing? Getting these to work took a lot of time and effort. It involved modifying some code and changing the way we deployed. We had times when we were sure everything was okay with our Maven build, but then testing found holes that we didn't realize were there. Again, why was this bad? After three weeks, we finally got the Maven build working.In the end, we have angry developers, a steep learning curve to learn how to work on a project that developers knew in and out, and a build process that isn't much better than what we had. Not good. But the time spent will pay off. And 3 weeks is normal for å enterprise project. As a result, we have decided not to Mavenize all of our projects. All new projects will use Maven. Some of the simpler projects may be mavenized, but we'll carefully evaluate them. That doesn't mean we didn't learn some neat tricks in the process. The biggest concerns having project A build a jarfile that project B requires. In the pre-Maven days, that meant checking in that built JAR into Subversion, then using svn:export to pick up that jar from the other project. Checking in JARs several times a day into our Subversion repository proved difficult in both process and room. Now that we have a Maven repository, we now use the deploy:deploy-file mojo to deploy that Jar to our Maven repository. If the receiving project is a Maven project, we can now pick it up using the standard dependencies methods in the pom.xml, and we are converting many of these dependent projects into Maven because here's a real advantage Maven does have for us. And for the few dependent projects that we cannot easily Mavenize, I now use Ant's get task to download the jars from the Maven repository. It isn't as clean as the way Maven does it, but it has proven easier to do than to Mavenize these difficult projects. So Mavenizing old projects isn't just a blanket thing to do. You have to evaluate what you have now, and what you expect to gain with Maven. Some projects are pretty straight forward, but if you have an older project with a complex build process, and a build process that fairly rigorous, moving to Maven simply doesn't buy you all that much. Yes. Maven is a complex thing to learn, but it is better than anything I have seen. On Sun, Feb 22, 2009 at 9:04 AM, Steve Cohen sco...@javactivity.org wrote: I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. Thanks. Steve Cohen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr
RE: Mavenizing existing project
-Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 17:12 To: Maven Users List Subject: Re: Mavenizing existing project Unfortunately, you guys may be talking me out of mavenizing rather than into it. :-( My situation is a bit different than what is described. There are only two or three real developers in my project and they work on separate applications with very little sharing between them - and I am one of them, the one most involved in coding, in fact. I'm not an SCM guy per se, though automated builds have always been an interest of mine. Nonetheless I recognize the third-party-jars-in-svn thing as an anti-pattern, and would like to move toward a truly automated build. (As I indicated in my original post, we don't even use Ant here - we use Eclipse's built-in Export to build - and even THAT was a big step forward for this team). But a local, networked M2 repo is going to run up against all sorts of security minefields. So I would like to explore a somewhat different path: 1) abandon any thought of a local repository for now. Too many political/bureaucratic issues. Each developer could download maven and the m2eclipse plugin himself and build a local repository of things needed. Thats a work around. 2) create a POM in an SVN branch and develop automated maven-based builds using developer-local repos. If builds break, devs can update their repo. Seems okay. 3) as this becomes general, down the road, if and when the need for a local repo is perceived, only then take that step. Can you create a new user, and have all this done on a separate laptop? Does this kind of plan make any sense to you guys? Jon Georg Berentsen wrote: +1 -Original Message- From: Samuel Langlois [mailto:slangl...@ilog.fr] Sent: 23. februar 2009 16:11 To: users@maven.apache.org Subject: Re: Mavenizing existing project 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I agree you should follow the Maven happy path. I migrated a big several-million-LOC project from Ant to Maven, and I chose a 3rd way, somewhat in-between. The trick is to keep the trunk as it is, so that people can still work with Ant as they are used to, and to perform the migration in a branch. In the branch, you commit only your pom.xml files and an empty folder structure. Every time you need some files from the trunk, you use svn:externals to make a kind of 'dynamic link' inside your SVN repository. Typically, your svn:external will look like this: module/submodule/src/main/java http://repo/trunk/module/submodule/src This way, you can quietly migrate without bothering anyone. When the migration is ready, you also need to make a shell script that will copy the pom.xml from the branch to the trunk and move all source folders in the right place. Similarly, you can prepare and test this script quietly on your side without impacting developers. The migration itself is then just a matter of minutes, while the script is run and you commit everything. That was a little more work for me, but not having 40 stuck developers on my back while I was performing the migration was priceless :-) Hope this will help you Samuel - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
1) abandon any thought of a local repository for now. Too many political/bureaucratic issues. I am not sure if you are aware, but even the OSS version of Nexus (Maven repo manager) has an abundance of security options. You can configure it so that only very specific developers have access to it. Very flexible. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
Jon Georg Berentsen wrote: -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 17:12 To: Maven Users List Subject: Re: Mavenizing existing project Unfortunately, you guys may be talking me out of mavenizing rather than into it. :-( My situation is a bit different than what is described. There are only two or three real developers in my project and they work on separate applications with very little sharing between them - and I am one of them, the one most involved in coding, in fact. I'm not an SCM guy per se, though automated builds have always been an interest of mine. Nonetheless I recognize the third-party-jars-in-svn thing as an anti-pattern, and would like to move toward a truly automated build. (As I indicated in my original post, we don't even use Ant here - we use Eclipse's built-in Export to build - and even THAT was a big step forward for this team). But a local, networked M2 repo is going to run up against all sorts of security minefields. So I would like to explore a somewhat different path: 1) abandon any thought of a local repository for now. Too many political/bureaucratic issues. Each developer could download maven and the m2eclipse plugin himself and build a local repository of things needed. Thats a work around. Sure, but is it a bad one in my situation? The third party dependencies our projects depend on are not rapidly changing. The most typical change is an add and that is rare. If a POM change breaks someone's local build, that's not that hard to overcome. Balancing this against the bureaucratic fight I would have to win to get a local repository, it seems to be a no-brainer. Having experience pointing to the need for it would help me win that fight. Otherwise it's biting off too big a piece. My goal here is to improve process over time. I want to avoid continuing down a path that over time make improving the process later harder. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
Todd Thiessen wrote: 1) abandon any thought of a local repository for now. Too many political/bureaucratic issues. I am not sure if you are aware, but even the OSS version of Nexus (Maven repo manager) has an abundance of security options. You can configure it so that only very specific developers have access to it. Very flexible. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org You don't know my security police. They are all-powerful and no one in management dares oppose them. And they couldn't care less about improving the development process. Any new server-type application would be scrutinized to death. Think Dilbert: Network Security = Productivity Prevention Department :-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
If you have any 3 party dep that resides in any global Maven repos., hook that up first. I belive your workaround will not come in conflict with the repo idea, given your restrictions. It's what maven does anyway, except for the manual installation for modules. But keep pushing for a company repo. Better to get it in 09 than oh'never. Jon -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 17:52 To: Maven Users List Subject: Re: Mavenizing existing project Jon Georg Berentsen wrote: -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 17:12 To: Maven Users List Subject: Re: Mavenizing existing project Unfortunately, you guys may be talking me out of mavenizing rather than into it. :-( My situation is a bit different than what is described. There are only two or three real developers in my project and they work on separate applications with very little sharing between them - and I am one of them, the one most involved in coding, in fact. I'm not an SCM guy per se, though automated builds have always been an interest of mine. Nonetheless I recognize the third-party-jars-in-svn thing as an anti-pattern, and would like to move toward a truly automated build. (As I indicated in my original post, we don't even use Ant here - we use Eclipse's built-in Export to build - and even THAT was a big step forward for this team). But a local, networked M2 repo is going to run up against all sorts of security minefields. So I would like to explore a somewhat different path: 1) abandon any thought of a local repository for now. Too many political/bureaucratic issues. Each developer could download maven and the m2eclipse plugin himself and build a local repository of things needed. Thats a work around. Sure, but is it a bad one in my situation? The third party dependencies our projects depend on are not rapidly changing. The most typical change is an add and that is rare. If a POM change breaks someone's local build, that's not that hard to overcome. Balancing this against the bureaucratic fight I would have to win to get a local repository, it seems to be a no-brainer. Having experience pointing to the need for it would help me win that fight. Otherwise it's biting off too big a piece. My goal here is to improve process over time. I want to avoid continuing down a path that over time make improving the process later harder. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
You don't know my security police. They are all-powerful and no one in management dares oppose them. hehe true. I wasn't suggesting you go against them. Just that there are Maven tools available to satisfy their security needs. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing existing project
Haha :) Where the h*** do you work? Tell Mr. M. Hayden hello... ;) Jon -Original Message- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: 23. februar 2009 17:56 To: Maven Users List Subject: Re: Mavenizing existing project Todd Thiessen wrote: 1) abandon any thought of a local repository for now. Too many political/bureaucratic issues. I am not sure if you are aware, but even the OSS version of Nexus (Maven repo manager) has an abundance of security options. You can configure it so that only very specific developers have access to it. Very flexible. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org You don't know my security police. They are all-powerful and no one in management dares oppose them. And they couldn't care less about improving the development process. Any new server-type application would be scrutinized to death. Think Dilbert: Network Security = Productivity Prevention Department :-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
The issue to us was fairly simple: We had a working build process. The developers knew the project. Everything was fine and dandy. We moved to Maven and lost three weeks of work. Developers don't understand the new process as well as the old process, we've fallen behind schedule. We had a strong build process. Granted, we spent a long time working with Ant to make the process strong and stable, but moving to Maven wouldn't give me back the time we spent. Maven gave us a standard way we setup a project, so developers will be familiar with it, but we already had that. Yes, new developers will have to learn the quirks, but now the current developers are stuck learning the new Maven way in a project they knew backwards and forwards. So, where did moving to Maven in this particular project benefit us? Was it worth the bad will generated? Was it worth the time we took which could have been spent doing actual coding? In our evaluation, the costs outweighed the benefits. We didn't get a better build process out of it. It didn't make our project easier to work with. And, it ended up costing us a lot of time and effort. We aren't abandoning Maven. We are still using it for new projects. We are still moving some older projects off of our old system and onto Maven. Sooner or later, those older projects we decided not to move to Maven will be rearchitected. At that time, we'll probably insist they convert over to Maven. On Mon, Feb 23, 2009 at 11:19 AM, Jon Georg Berentsen jon.georg.berent...@objectware.no wrote: -Original Message- From: David Weintraub [mailto:qazw...@gmail.com] Sent: 23. februar 2009 16:58 To: Maven Users List Subject: Re: Mavenizing existing project I am fairly new to Maven, so maybe there are things that I simply don't know the correct way of doing things. However, we did Mavenize one project, and we simply found that it wasn't worth the effort. We had a strong Ant build process and things were working very well there. The idea to Mavenize came from above. We rearranged our directory structure, but then realized that we were doing a few things that weren't quite standard. Why was this a bad thing? Getting these to work took a lot of time and effort. It involved modifying some code and changing the way we deployed. We had times when we were sure everything was okay with our Maven build, but then testing found holes that we didn't realize were there. Again, why was this bad? After three weeks, we finally got the Maven build working.In the end, we have angry developers, a steep learning curve to learn how to work on a project that developers knew in and out, and a build process that isn't much better than what we had. Not good. But the time spent will pay off. And 3 weeks is normal for å enterprise project. As a result, we have decided not to Mavenize all of our projects. All new projects will use Maven. Some of the simpler projects may be mavenized, but we'll carefully evaluate them. That doesn't mean we didn't learn some neat tricks in the process. The biggest concerns having project A build a jarfile that project B requires. In the pre-Maven days, that meant checking in that built JAR into Subversion, then using svn:export to pick up that jar from the other project. Checking in JARs several times a day into our Subversion repository proved difficult in both process and room. Now that we have a Maven repository, we now use the deploy:deploy-file mojo to deploy that Jar to our Maven repository. If the receiving project is a Maven project, we can now pick it up using the standard dependencies methods in the pom.xml, and we are converting many of these dependent projects into Maven because here's a real advantage Maven does have for us. And for the few dependent projects that we cannot easily Mavenize, I now use Ant's get task to download the jars from the Maven repository. It isn't as clean as the way Maven does it, but it has proven easier to do than to Mavenize these difficult projects. So Mavenizing old projects isn't just a blanket thing to do. You have to evaluate what you have now, and what you expect to gain with Maven. Some projects are pretty straight forward, but if you have an older project with a complex build process, and a build process that fairly rigorous, moving to Maven simply doesn't buy you all that much. Yes. Maven is a complex thing to learn, but it is better than anything I have seen. On Sun, Feb 22, 2009 at 9:04 AM, Steve Cohen sco...@javactivity.org wrote: I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming
RE: Mavenizing existing project
The issue to us was fairly simple: We had a working build process. The developers knew the project. Everything was fine and dandy. We moved to Maven and lost three weeks of work. Developers don't understand the new process as well as the old process, we've fallen behind schedule. I am sorry it didn't work for you. All I can offer is what we did in our environment that worked well. We assigned one individual to research Maven and worked towards Mavenizing our project. Everyone else continued working on features using the ant process. So very little work was lost. Once a stable Maven environment was acheived, the rest of the team was cut over. There of course is a learning curve here but the rest of the team didn't need to get it working, but rather they had to learn how the new environment works. This saved a lot of frustion between developers. Maven is now starting to spread like wildfire ;-). At any rate, I don't think anyone should be trying to shove Maven down your throat. It is good to share experiences and I am glad you have shared yours. I hope it works out better for you in the future. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
Yes, haveing something pushed down on the developers is not very agile. The fact that you didnt know this tool, should have pushed the estmations thru the roof. Haveing one or two guys doing the research and poc, is better than haveing the whole team craming in. Look at what Maven has to offer thru all it's plugins. I bet you will something of good use. Sendt fra min iPhone Den 23. feb.. 2009 kl. 18.40 skrev Todd Thiessen thies...@nortel.com: The issue to us was fairly simple: We had a working build process. The developers knew the project. Everything was fine and dandy. We moved to Maven and lost three weeks of work. Developers don't understand the new process as well as the old process, we've fallen behind schedule. I am sorry it didn't work for you. All I can offer is what we did in our environment that worked well. We assigned one individual to research Maven and worked towards Mavenizing our project. Everyone else continued working on features using the ant process. So very little work was lost. Once a stable Maven environment was acheived, the rest of the team was cut over. There of course is a learning curve here but the rest of the team didn't need to get it working, but rather they had to learn how the new environment works. This saved a lot of frustion between developers. Maven is now starting to spread like wildfire ;-). At any rate, I don't think anyone should be trying to shove Maven down your throat. It is good to share experiences and I am glad you have shared yours. I hope it works out better for you in the future. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
Actually, if you don't have a strong build process, you need one -- Maven or no Maven. Builds should be automatic and repeatable. If I gave you the same source code, you should produce the same build. It's bad enough keeping track of actual coding errors, but when you might introduce bugs simply because of a manual build process, you're in trouble. We use Hudson for continuous build integrations. Every time someone checks in new code, we automatically build and test. It doesn't matter if a developer is simply fixing a spelling error in a readme document, or restructuring the entire foundation of the project: We build. And, our official build process is available for the developers to use. When an official build fails, the It worked on my machine excuse doesn't cut it. The developer not only has to build it in his Eclipse environment, but also has to run our build scripts to prove to me that it actually works. Since you don't have a build process, creating one using other tools like Ant or simply moving to Maven really doesn't make too much difference now. As you said, you don't need third party jars in Subversion if you use Maven. It might be worth moving to Maven just to have a solid build process. You should also look at continuous build systems like Hudson or CruiseControl. On Mon, Feb 23, 2009 at 11:11 AM, Steve Cohen sco...@javactivity.org wrote: Unfortunately, you guys may be talking me out of mavenizing rather than into it. :-( My situation is a bit different than what is described. There are only two or three real developers in my project and they work on separate applications with very little sharing between them - and I am one of them, the one most involved in coding, in fact. I'm not an SCM guy per se, though automated builds have always been an interest of mine. Nonetheless I recognize the third-party-jars-in-svn thing as an anti-pattern, and would like to move toward a truly automated build. (As I indicated in my original post, we don't even use Ant here - we use Eclipse's built-in Export to build - and even THAT was a big step forward for this team). But a local, networked M2 repo is going to run up against all sorts of security minefields. So I would like to explore a somewhat different path: 1) abandon any thought of a local repository for now. Too many political/bureaucratic issues. Each developer could download maven and the m2eclipse plugin himself and build a local repository of things needed. 2) create a POM in an SVN branch and develop automated maven-based builds using developer-local repos. If builds break, devs can update their repo. 3) as this becomes general, down the road, if and when the need for a local repo is perceived, only then take that step. Does this kind of plan make any sense to you guys? Jon Georg Berentsen wrote: +1 -Original Message- From: Samuel Langlois [mailto:slangl...@ilog.fr] Sent: 23. februar 2009 16:11 To: users@maven.apache.org Subject: Re: Mavenizing existing project 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I agree you should follow the Maven happy path. I migrated a big several-million-LOC project from Ant to Maven, and I chose a 3rd way, somewhat in-between. The trick is to keep the trunk as it is, so that people can still work with Ant as they are used to, and to perform the migration in a branch. In the branch, you commit only your pom.xml files and an empty folder structure. Every time you need some files from the trunk, you use svn:externals to make a kind of 'dynamic link' inside your SVN repository. Typically, your svn:external will look like this: module/submodule/src/main/java http://repo/trunk/module/submodule/src This way, you can quietly migrate without bothering anyone. When the migration is ready, you also need to make a shell script that will copy the pom.xml from the branch to the trunk and move all source folders in the right place. Similarly, you can prepare and test this script quietly on your side without impacting developers. The migration itself is then just a matter of minutes, while the script is run and you commit everything. That was a little more work for me, but not having 40 stuck developers on my back while I was performing the migration was priceless :-) Hope this will help you Samuel - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e
Re: Mavenizing existing project
David Weintraub wrote: Actually, if you don't have a strong build process, you need one -- Maven or no Maven. Builds should be automatic and repeatable. Thanks. You are preaching to the choir, friend. I'm usually the one preaching automated builds (and I'm in fact an Ant committer) but I've never been on a team this small before and I'm the junior member of the team in terms of seniority, but not in terms of experience. I could easily stay with what we've got because our developers basically don't work together (on what I do, I'm a team of one as far as coding is concerned), but it isn't good practice and too much rests in my own head. This is my motivation for making a switch. Since I'm most likely NOT going to get to build a team-wide (much less enterprise-wide) repo, this is in fact my main reason for wanting to introduce Maven at this point. If I gave you the same source code, you should produce the same build. It's bad enough keeping track of actual coding errors, but when you might introduce bugs simply because of a manual build process, you're in trouble. Yup - fortunately, a small team lets you get away with such sloppiness but I know it's bad practice. We use Hudson for continuous build integrations. Every time someone checks in new code, we automatically build and test. It doesn't matter if a developer is simply fixing a spelling error in a readme document, or restructuring the entire foundation of the project: We build. And, our official build process is available for the developers to use. When an official build fails, the It worked on my machine excuse doesn't cut it. The developer not only has to build it in his Eclipse environment, but also has to run our build scripts to prove to me that it actually works. Since you don't have a build process, creating one using other tools like Ant or simply moving to Maven really doesn't make too much difference now. As you said, you don't need third party jars in Subversion if you use Maven. It might be worth moving to Maven just to have a solid build process. Yes. That's my point. Thanks. You should also look at continuous build systems like Hudson or CruiseControl. We're probably too small for those sorts of systems. On Mon, Feb 23, 2009 at 11:11 AM, Steve Cohen sco...@javactivity.org wrote: Unfortunately, you guys may be talking me out of mavenizing rather than into it. :-( My situation is a bit different than what is described. There are only two or three real developers in my project and they work on separate applications with very little sharing between them - and I am one of them, the one most involved in coding, in fact. I'm not an SCM guy per se, though automated builds have always been an interest of mine. Nonetheless I recognize the third-party-jars-in-svn thing as an anti-pattern, and would like to move toward a truly automated build. (As I indicated in my original post, we don't even use Ant here - we use Eclipse's built-in Export to build - and even THAT was a big step forward for this team). But a local, networked M2 repo is going to run up against all sorts of security minefields. So I would like to explore a somewhat different path: 1) abandon any thought of a local repository for now. Too many political/bureaucratic issues. Each developer could download maven and the m2eclipse plugin himself and build a local repository of things needed. 2) create a POM in an SVN branch and develop automated maven-based builds using developer-local repos. If builds break, devs can update their repo. 3) as this becomes general, down the road, if and when the need for a local repo is perceived, only then take that step. Does this kind of plan make any sense to you guys? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
Sent from my [rhymes with myPod] ;-) On 23 Feb 2009, at 20:51, Steve Cohen sco...@javactivity.org wrote: David Weintraub wrote: Actually, if you don't have a strong build process, you need one -- Maven or no Maven. Builds should be automatic and repeatable. Thanks. You are preaching to the choir, friend. I'm usually the one preaching automated builds (and I'm in fact an Ant committer) but I've never been on a team this small before and I'm the junior member of the team in terms of seniority, but not in terms of experience. I could easily stay with what we've got because our developers basically don't work together (on what I do, I'm a team of one as far as coding is concerned), but it isn't good practice and too much rests in my own head. This is my motivation for making a switch. Since I'm most likely NOT going to get to build a team- wide (much less enterprise-wide) repo, this is in fact my main reason for wanting to introduce Maven at this point. If I gave you the same source code, you should produce the same build. It's bad enough keeping track of actual coding errors, but when you might introduce bugs simply because of a manual build process, you're in trouble. Yup - fortunately, a small team lets you get away with such sloppiness but I know it's bad practice. We use Hudson for continuous build integrations. Every time someone checks in new code, we automatically build and test. It doesn't matter if a developer is simply fixing a spelling error in a readme document, or restructuring the entire foundation of the project: We build. And, our official build process is available for the developers to use. When an official build fails, the It worked on my machine excuse doesn't cut it. The developer not only has to build it in his Eclipse environment, but also has to run our build scripts to prove to me that it actually works. Since you don't have a build process, creating one using other tools like Ant or simply moving to Maven really doesn't make too much difference now. As you said, you don't need third party jars in Subversion if you use Maven. It might be worth moving to Maven just to have a solid build process. Yes. That's my point. Thanks. You should also look at continuous build systems like Hudson or CruiseControl. We're probably too small for those sorts of systems. I run Hudson on my home computer. seriously, if you have either a good ant build or a good maven build, setting up Hudson is a 5min no brainer On Mon, Feb 23, 2009 at 11:11 AM, Steve Cohen sco...@javactivity.org wrote: Unfortunately, you guys may be talking me out of mavenizing rather than into it. :-( My situation is a bit different than what is described. There are only two or three real developers in my project and they work on separate applications with very little sharing between them - and I am one of them, the one most involved in coding, in fact. I'm not an SCM guy per se, though automated builds have always been an interest of mine. Nonetheless I recognize the third-party-jars-in-svn thing as an anti-pattern, and would like to move toward a truly automated build. (As I indicated in my original post, we don't even use Ant here - we use Eclipse's built-in Export to build - and even THAT was a big step forward for this team). But a local, networked M2 repo is going to run up against all sorts of security minefields. So I would like to explore a somewhat different path: 1) abandon any thought of a local repository for now. Too many political/bureaucratic issues. Each developer could download maven and the m2eclipse plugin himself and build a local repository of things needed. 2) create a POM in an SVN branch and develop automated maven-based builds using developer-local repos. If builds break, devs can update their repo. 3) as this becomes general, down the road, if and when the need for a local repo is perceived, only then take that step. Does this kind of plan make any sense to you guys? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
2009/2/22 Steve Cohen sco...@javactivity.org I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are FYI, maven's lifecycle says *nothing* about deploying post release. When maven talks about deploying, this is deploying the released artifacts to a Maven repository. There are maven plugins to deploy your war to tomcat, jetty, etc... but they are not part of the lifecycle... I think you will always end up with a manual deployment step (even if that is running a maven mojo in tomcat-maven-plugin, cargo-maven-plugin, jetty-maven-plugin, etc) And your customers will have the same... On the other hand, if deployment is for integration testing, then maven can do even better, with the ability to start and stop the app server before and after the integration tests (as part of the lifecycle). Some aspects of the maven support for this are poorer than they could be though. some annoying manual post-export tasks that must be run. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. I have done several conversions, and providing you rename and move the files in subversion, you can keep your history without issue. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I'd want to be on subversion 1.5.5 before trying that of course if you are using subversion 1.5.x and have repository access via http or https you will have a bit of fun when releasing using the release plugin. svn: does not have these issues. (A bug the mod_dav_svn prevents tagging from a working copy that is not based off of the head revision) 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. You would be best served using nexus to host your artifacts and cache all the remote ones. There are alternatives, but Nexus is, IMHO, the easiest to set up and get running, and also has the lowest cost of switching to the others (i.e. all the data is on the disk) (Note I have no affiliation with either Nexus or Sonatype ) Thanks. Steve Cohen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
Thanks Stephen: I figured there would always be one manual deployment step but I would like to at least get rid of the post-eclipse export, pre-deploy manual steps. I have one more question I meant to ask earlier but forgot. I do make use of the Eclipse WTP environment and a local Tomcat server and immediate compilation to create a rapid-turnaround development environment apart from the server. This dovetails pretty nicely with the regular Eclipse export. Is it possible to still do this when Maven is running the show? Stephen Connolly wrote: 2009/2/22 Steve Cohen sco...@javactivity.org I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are FYI, maven's lifecycle says *nothing* about deploying post release. When maven talks about deploying, this is deploying the released artifacts to a Maven repository. There are maven plugins to deploy your war to tomcat, jetty, etc... but they are not part of the lifecycle... I think you will always end up with a manual deployment step (even if that is running a maven mojo in tomcat-maven-plugin, cargo-maven-plugin, jetty-maven-plugin, etc) And your customers will have the same... On the other hand, if deployment is for integration testing, then maven can do even better, with the ability to start and stop the app server before and after the integration tests (as part of the lifecycle). Some aspects of the maven support for this are poorer than they could be though. some annoying manual post-export tasks that must be run. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. I have done several conversions, and providing you rename and move the files in subversion, you can keep your history without issue. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I'd want to be on subversion 1.5.5 before trying that of course if you are using subversion 1.5.x and have repository access via http or https you will have a bit of fun when releasing using the release plugin. svn: does not have these issues. (A bug the mod_dav_svn prevents tagging from a working copy that is not based off of the head revision) 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. You would be best served using nexus to host your artifacts and cache all the remote ones. There are alternatives, but Nexus is, IMHO, the easiest to set up and get running, and also has the lowest cost of switching to the others (i.e. all the data is on the disk) (Note I have no affiliation with either Nexus or Sonatype ) Thanks. Steve Cohen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
Hi Steve, I use Maven for building my projects and the eclipse WTP plugin as well. JSP re-compilation while running and hot swap code replacement while debugging has always worked for me. On Sun, Feb 22, 2009 at 5:21 PM, Steve Cohen sco...@javactivity.org wrote: Thanks Stephen: I figured there would always be one manual deployment step but I would like to at least get rid of the post-eclipse export, pre-deploy manual steps. I have one more question I meant to ask earlier but forgot. I do make use of the Eclipse WTP environment and a local Tomcat server and immediate compilation to create a rapid-turnaround development environment apart from the server. This dovetails pretty nicely with the regular Eclipse export. Is it possible to still do this when Maven is running the show? Stephen Connolly wrote: 2009/2/22 Steve Cohen sco...@javactivity.org I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are FYI, maven's lifecycle says *nothing* about deploying post release. When maven talks about deploying, this is deploying the released artifacts to a Maven repository. There are maven plugins to deploy your war to tomcat, jetty, etc... but they are not part of the lifecycle... I think you will always end up with a manual deployment step (even if that is running a maven mojo in tomcat-maven-plugin, cargo-maven-plugin, jetty-maven-plugin, etc) And your customers will have the same... On the other hand, if deployment is for integration testing, then maven can do even better, with the ability to start and stop the app server before and after the integration tests (as part of the lifecycle). Some aspects of the maven support for this are poorer than they could be though. some annoying manual post-export tasks that must be run. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. I have done several conversions, and providing you rename and move the files in subversion, you can keep your history without issue. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? Yes. This is the way I recommend myself. There are two ways you can do this... 1. Make the changes in trunk, and keep the existing build process functional while you change everything... this allows you to ignore maven until you get everything perfect. 2. Make the changes in a branch and merge them back when you're ready... I'd want to be on subversion 1.5.5 before trying that of course if you are using subversion 1.5.x and have repository access via http or https you will have a bit of fun when releasing using the release plugin. svn: does not have these issues. (A bug the mod_dav_svn prevents tagging from a working copy that is not based off of the head revision) 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. You would be best served using nexus to host your artifacts and cache all the remote ones. There are alternatives, but Nexus is, IMHO, the easiest to set up and get running, and also has the lowest cost of switching to the others (i.e. all the data is on the disk) (Note I have no affiliation with either Nexus or Sonatype ) Thanks. Steve Cohen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
