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 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
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