RE: Compilation problem with maven
That's not a maven error. It's the java compiler telling you there is a compilation error in your code. Jon -Original Message- From: amar.sann...@gmail.com [mailto:amar.sann...@gmail.com] Sent: 3. mars 2009 09:36 To: users@maven.apache.org Subject: Compilation problem with maven Hi there, I get a error while compilation with maven, I am using maven version 2.0.10 here is the maven compiler config I have plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin during compile error I get it is [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure d:/foodlab_feb09/mealbox/meijer/trunk/src/main/java/com/meijer/foodlab/r emote/ikan/shoppingcart/package-info.java:[1,49] package annotations should be in file package-info.java d:/foodlab_feb09/mealbox/meijer/trunk/src/main/java/com/meijer/webservic es/foodlab/client/package-info.java:[1,49] package annotations should be in file package-info.java I dint get much of help browsing internet, can someone help me fix this. thanks in advance -- Amar Sannaik | Senior Engineer - 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
-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
+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
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
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: gathering jar files
Could you elaborate a bit more? Are these three artifact dependencies to your project or something you build? Jon I'd like to distribute a desktop utility utility.jar lib/lib1.jar lib/lib2.jar lib/... where the MANIFEST.MF contains the line classpath = lib/lib1.jar lib/lib2.jar ... included libs are listed as dependencies or transient dependencies as specified in pom.xml. Is such a thing possible? With or without writing a plugin? Please be patient, I'm new to maven. I read a lot. Maybe at the wrong place. I included addClasspathtrue/addClasspath to maven-jar-plugin configuration, without luck to change manifest.mf Any help welcome. Rolf - 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: project internal dependencies in a multi-module project
-Original Message-
From: Florian Rampp [mailto:florian.ra...@web.de]
Sent: 23. februar 2009 11:58
To: users@maven.apache.org
Subject: project internal dependencies in a multi-module project
Hello everybody,
I'm working on a quite big project using a maven multimodule project
layout. I learned quite a lot about Maven the last month and I'm happy
to use this tool.
Currently, I'm wondering about a issue, I couldn't find a guide or a
hint for best practice for.
I'm using a dependency management section at the root pom for managing
project external dependencies like mysql connector, or spring framework
version.
It is perfectly clear to me, to use dependency management here.
But what about project-internal dependencies? Should I also include each
leaf of my project tree (i.e. each module with packaging type jar) in
the dependency management section, with the project.version as its
version?
Like this?
dependency
groupIdourGroup/groupId
artifactIdrootmodule.submodule1.subsubmodule1/artifactId
version${project.version}/version
/dependency
What is the best practice here?
I think you nailed it.
That's the practice I use.
Furthermore, if I run a compile on the root pom, I get the feeling,
that maven does not try to find project-internal dependencies by
traversing the multi-module-project, but looking up the local
repository. Can this behaviour be changed? Otherwise, I always have to
redeploy the modules, other modules depend on, to the local repository
before I can compile the module itself...
I hope you get the problem!
Nonetheless, thanks a lot for this great tool, that really helps me
developing and following good development practice!
Maven builds up the compile order based on the modules pom's.
It will try to compile your active code aka. your modules.
So no, it will not look in the repo for the artifact if it's a module in
your project.
Removing it as a module, but keeping it as a dependency will make it
look in the repo.
Regards,
Flo
Jon
-
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
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
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
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
-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:
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
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
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
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: Can't get maven to compile with java 1.5
+1 BUT this link should give you some hints: http://maven.apache.org/plugins/maven-checkstyle-plugin/plugin-info.html AFTER you learn the basics ;) Jon -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: 22. februar 2009 01:35 To: Maven Users List Subject: Re: Can't get maven to compile with java 1.5 Added that and here is pom.xml (inherited by Foundation/pom.xml) snip Note it still says same thing. Is the configuration in the right place? 1. Don't send the full output like that to this list again. If you can identify the relevant ~10 lines or so of the output, that's ok to send here. Otherwise, paste the text at a site like pastebin.com and send a link to it instead. 2. The same goes for posting full poms. Its ok to send snippets, but full poms is too much. 3. You need to take the advice you've already been given by other people about reading the free PDF ebooks provided by Sonatype and exist. You have missed some basics related to versions that are causing you problems now. Go back and learn the basics before proceeding! Hint: Things with a non-SNAPSHOT version should never, ever change, or you will have big problems in Maven. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
