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
How to execute Java task within a Archetype
Hi all AFAIK when execute archetype:create command , the archetype copy the folder structure with resources according to the archetype's archetype.xml file . I want to execute a custom Java method in addition to above default behaviour along with archetype:create command . Is there any way to achieve this ? if so please update me with some references . Thanks , Sagara Gunathunga Blog - http://ssagara.blogspot.com Web - http://sagaras.awardspace.com/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Big slowdown on Linux when upgrading assembly plugin from 2.2-beta-1 to 2.2-beta-3
Hi On behalf of Peter Nilsson which works in the same project as me a JIRA case was entered in Codehaus JIRA. JIRA case id: MASSEMBLY-392. Regards Fredrik brettporter wrote: Would you mind posting this, along with some characteristics of your build so we can see where the slowdown is? On 20/02/2009, at 12:04 AM, PeterNilsson wrote: No, it has neither been resolved nor reported. Our current workaround is not to use the assembly plugin in as many places to keep down total build times. /Peter brettporter wrote: Did you report or resolve this problem eventually? On 21/01/2009, at 9:27 PM, PeterNilsson wrote: ... -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://www.nabble.com/Big-slowdown-on-Linux-when-upgrading-assembly-plugin-from-2.2-beta-1-to-2.2-beta-3-tp21580492p22099914.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 -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://www.nabble.com/Big-slowdown-on-Linux-when-upgrading-assembly-plugin-from-2.2-beta-1-to-2.2-beta-3-tp21580492p22179102.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Repo release final
Justin, Thank you for the response, the solution looks pretty complex and not really what I want as the deployer username and password are set in a settings.xml that is deployed with our dev tools to many developers. Is there no way to do look deployments via pom properties or other settings in Nexus? Cheers Paul Edelson, Justin wrote: https://docs.sonatype.com/display/NX/Nexus+FAQ#NexusFAQ-Q.HowdoIdisablea rtifactredeployment. -- View this message in context: http://n2.nabble.com/Repo-release-final-tp2374974p2377447.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Integration for Eclipse - does it support modules?
On 24/02/2009, Brett Randall javabr...@gmail.com wrote: Try Maven-Update Project Configuration after setting maven-compiler-plugin configuration. Does not seem to help, even after amending POM as suggested below. And I think you want: This is a Maven project plugin, so I would expect the POM to be correct ... plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target /configuration /plugin Best Brett On Tue, Feb 24, 2009 at 4:53 AM, sebb seb...@gmail.com wrote: On 18/02/2009, Jason van Zyl jvan...@sonatype.com wrote: It is always better to import Maven projects as Maven projects, not normal projects and then enabling dependency management. We should probably just remove that option as it seems to confuse many people and can also corrupt your eclipse projects. The version of Java used is determined by the JDT integration which obeys anything you have setup in the compiler plugin. If nothing is set then the default of 1.4 is chosen. This is the configuration framework in action and the POM is the source of truth if you are using m2e. Java version selection does not seem to work, even when the project is checked out as a Maven project. E.g. I checked out maven/surefire/trunk as a Maven project (using current version 0.9.7) This created several projects - looks to be one for each module. However, all of the projects have been set to use Java 1.3, even though some of the POMs specify 1.4. For example, the surefire-junit4 and surefire-testng POMs have: artifactIdmaven-compiler-plugin/artifactId configuration forkfalse/fork compilerVersion1.4/compilerVersion /configuration yet Eclipse is configured for Java 1.3. Likewise maven-surefire-plugin, maven-surefire-report-plugin. [Surefire-booter and surefire-integration-tests seem to require 1.4, but fail to specify it in the POM] On 18-Feb-09, at 8:30 AM, sebb wrote: Thanks, that's fixed it. Unfortunately it does not seem to deal with multiple Java versions well - I would expect it to set the Java version to the highest version it finds - or at least warn the user that there are multiple requirements. On 18/02/2009, Stefan Seidel ssei...@vub.de wrote: You have to do: right click on project - Maven - Enable nested modules HTH, Stefan On Wed, 18 Feb 2009 00:45:11 + sebb seb...@gmail.com wrote: I tried enabling Maven Dependency Management on a project with modules (Surefire 2.4.3) and the dependencies from the top-level project were added OK, but none of the dependencies for any of the modules were added. Is this the expected behaviour? Or is it a bug? If if is expected, how can one use the plugin with modules? [Using version 0.0.12.20071107-2300 in Eclipse 3.4.1] - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- best regards Stefan Seidel Software Developer VUB Printmedia GmbH Chopinstraße 4, D-04103 Leipzig tel.+49 (341) 9 60 50 93 fax.+49 (341) 9 60 50 92 mail. ssei...@vub.de web.www.vub.de HRB Köln 24015 UStID DE 122 649 251 GF Dr. Achim Preuss Neudorf, Dr. Christian Preuss Neudorf - 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 jason at sonatype dot com http://twitter.com/jvanzyl -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands,
[m2] release-plugin skips parent build plugins configuration
I've got a parent pom which defines several project-wide build-plugins in pluginManagement and the build section. The normal build clean install works fine (compilation of code is for version 1.5) but in release-plugin the pluginManagement and build section is completely missing in pom-release.xml or in reactor build (and compilation of code is version 1.3, causes an error on Enumeration objects). It makes no difference if generateReleasePoms of release-plugin is set or not. (windows xp, maven-2.0.9, release-plugin 2.0-beta-8) Sample: Parent.pom ... groupId.../groupId artifactIdbasis_maven_pom/artifactId version1/version packagingpom/packaging build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version inheritedtrue/inherited configuration source1.5/source target1.5/target /configuration /plugin /plugins /pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId inheritedtrue/inherited configuration source1.5/source target1.5/target /configuration /plugin ... MyModule.pom ... parent groupId.../groupId artifactIdbasis_maven_pom/artifactId version1/version /parent groupIdch.visana.rin.ieu.web/groupId artifactIdmyModule/artifactId version1.2.2-SNAPSHOT/version packagingjar/packaging build NOTHING DEFINED HERE, ALL COMES FROM BASIS_MAVEN_POM /build ... Is this a bug or what I'm doing wrong - mvn clean install (works) - mvn release:prepare (compiler error) -- View this message in context: http://www.nabble.com/-m2--release-plugin-skips-parent-build-plugins-configuration-tp22180870p22180870.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project 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: How to execute Java task within a Archetype
First, the create goal has been deprecated, you can better use the generate goal. Second, the documentation[1] says that it runs the generate-sources before executing, so maybe it is possible to add your own plugin there. Unfortunately, I don't know how it can be done and I can't find any documentation or examples. Can someone more knowledgeable share his insights? [1] http://maven.apache.org/plugins/maven-archetype-plugin/generate-mojo.html Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Tue, Feb 24, 2009 at 10:47 AM, Sagara Gunathunga sagar...@gmail.com wrote: Hi all AFAIK when execute archetype:create command , the archetype copy the folder structure with resources according to the archetype's archetype.xml file . I want to execute a custom Java method in addition to above default behaviour along with archetype:create command . Is there any way to achieve this ? if so please update me with some references . Thanks , Sagara Gunathunga Blog - http://ssagara.blogspot.com Web - http://sagaras.awardspace.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 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 in
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
mvn prepare-package invalid task?
Hi, according to the documentation, there is a prepare-package task since maven 2.1. I'm running Maven version: 2.1.0-M1 but when I want to call the prepare-package task, it fails with the following error message: [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'prepare-package': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVer sion:goal [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Feb 24 15:53:45 CET 2009 [INFO] Final Memory: 1M/4M [INFO] any ideas? -- View this message in context: http://www.nabble.com/mvn-prepare-package-invalid-task--tp22181075p22181075.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project 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: Using the filtered option within an assembly descriptor
Any feed back on this issue - anyone?
I see conflicting things in the source code - things like how the
files lists ARE expanded with things from the mavenProject object, not
just a filters file.
-Original Message-
From: EJ Ciramella [mailto:ecirame...@upromise.com]
Sent: Friday, February 20, 2009 3:21 PM
To: Maven Users List
Subject: RE: Using the filtered option within an assembly descriptor
I think I've discovered what's tripping me up a bit here.
Does this filtering take into consideration properties defined within
the mavenProject object or ONLY stuff pass in via the filtering file.
I'm referencing this page in particular:
http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/fi
ltering-some-distribution-files.html
All the above files are in the root directory of the project but only
the README and the NOTICE files should be filtered. The property file
used to filter these are files is found in
src/assemble/filter.properties.
However, there is some conflicting documatation up there - in one place,
it suggests filters only exist for files but it's clearly there in
fileSets.
Mick - I just saw your reply, and no, I've not set up filters in my
pom.
I've been under the impression (until right now) that the filtering that
the assembly plugin did factored in any of the mavenProject properties -
which apparently it doesn't.
Am I correct?
-Original Message-
From: EJ Ciramella [mailto:ecirame...@upromise.com]
Sent: Friday, February 20, 2009 3:06 PM
To: users@maven.apache.org
Subject: Using the filtered option within an assembly descriptor
Hello again list, I'm struggling to get this thing working.
I'm trying my hardest to not process files (for a war project) once to
the target directory then AGAIN into the final assembly location.
So I'm using mvn assembly:directory but I don't see any of the tokens
expanded for the files when inside the descriptor, I have something like
this:
fileSet
directorysrc/main/resources/java-properties/directory
outputDirectorysomedir/outputDirectory
useStrictFilteringtrue/useStrictFiltering
lineEndingunix/lineEnding
filteredtrue/filtered
includes
includehibernate.properties/include
/includes
/fileSet
The resulting hibernate.properties file still has ${stuff} type
properties left in there.
Any suggestions?
-
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: mvn prepare-package invalid task?
I think you mean issue MNG-3566 [1]. The last comment by Brett says: Brett Porter added a comment - 17/Dec/08 07:20 PM with milestones of 2.1 already coming out, and this slated for 2.1.0-M2, we will settle for that. I guess you will have to upgrade to at least M2. Hth, [1] http://jira.codehaus.org/browse/MNG-3566 Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Tue, Feb 24, 2009 at 4:05 PM, nkr1pt kristof.vanhae...@gmail.com wrote: prepare-package - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Wow. That's different advice from what others are saying, BUT, you're the maven so I do appreciate your warning and take it seriously! Was there a missing not in your first sentence? It seems to make more sense that way. I am prepared to fail the first few times, start with the simplest projects, etc. I'm not a newbie, I have a lot of experience in reengineering builds and I don't imagine immediate success the first time around. Also, I'm a team of, for all practical purposes, one. There are no other users I can burn with my failed efforts. And I'm a bulldog when I want to be. It seems to me that my experiences, if carefully logged and ultimately successful, could be helpful to other potential users who might be in my position. Frankly, I think would be good for Maven to lower the bar to conversion. It seems higher to me than it ought to be. Steve Jason van Zyl wrote: Do make your first Maven project a conversion. You will likely fail or be extremely unhappy. I have seen this a hundred times now and trying to wedge Maven into what you currently have is categorically not a good idea. Find a new, preferably small, project where you can try out Maven and understand fully what it does before you attempt to convert a project. On 23-Feb-09, at 4:53 PM, Steve Cohen wrote: OK, after extensive discussion in earlier thread about the best way to go about Mavenizing Existing Project(s) in my, shall we say, unusual environment (see that thread for details, don't want to recapitulate them here) I have decided to try to move forward. First I have to learn this tool. I have used maven before, but mainly in the way of building from someone else's POM. Just type maven install or some such and bingo, the world is built. Now my goal is to have pre-existing non-Maven projects be mavenized. I am prepared to throw the first one away. I also want to take this opportunity to start from a m2eclipse platform, so I have now installed that, even to the point of installing Ganymede because I couldn't get it to install in Europa. Although I know there is benefit to the command line tools, I'd like to start from eclipse, understanding that I can take the POM I produce and install it with command line tools. So my first question is this: How do I convert a non-Maven project into a Maven project? 1) Is there some way to change natures? 2) Create a new Maven project, place in SVN, then move stuff to the right places? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Mavenizing Existing Project Part Deux
Jason, This blogpost, http://tech.puredanger.com/2009/01/28/maven-adoption-curve/ , sparked quite a debate in my company. We have been quite the early adopters with maven, and have seen the benefits etc. etc., but it seem like this Ant/script to Maven, what do we get, we only got trouble fight has to be fought all the time with clients and new co workers. In your experience who adopt and embrace maven? Is it always the I have seen the need-people? Or do you have to have a maven Maven guy preaching? It seems, to me, that if none of the two is present, Maven is often considered a hassel and pain. Often, if used, Maven also becomes a specialist skill. One or two persons know it, the rest just use it, and can't fix it if something is broken. I have often heard that the reason for this is that Ant is very transparent in what it does. Maven is not. Does this raise the bar for adoption? Project size/complexity and skills matter? Jon -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: 24. februar 2009 16:32 To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux Do make your first Maven project a conversion. You will likely fail or be extremely unhappy. I have seen this a hundred times now and trying to wedge Maven into what you currently have is categorically not a good idea. Find a new, preferably small, project where you can try out Maven and understand fully what it does before you attempt to convert a project. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
On Mon, Feb 23, 2009 at 3:51 PM, Steve Cohen sco...@javactivity.org wrote: You should also look at continuous build systems like Hudson or CruiseControl. We're probably too small for those sorts of systems. No one is too small for Hudson! Hudson installs in five minutes. All you need is JDK 1.5 or higher. If you're running Eclipse or Maven, you've already satisfied that requirement. Hudson contains its own server using winestone. It is a self contained JAR. You simply run a single Java command, and it's up and running. Setting up a build project in Hudson is completely intuitive. Its graphical with a complete help system. It integrates with CVS, Subversion, Ant, Maven, and even Jira and Bugzilla. The only thing I suggest is that you have enough diskspace to store builds. Or, you can tell Hudson to delete builds older than a certain age or if there only save the X most recent builds. Try Hudson: https://hudson.dev.java.net/. You'll find it is an absolutely wonderful tool. And, I think it is one of the best run open source projects I have ever seen. They support is wonderful, and the developers behind it are very responsive to suggestions. -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mvn release:perform, upload fails
Hi all Executing release:perform fails. I'm using the latest ASF TLP pom [1] and saw that the repositoryidapache.releases.https/idurl has changed from scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository (apache-4.pom) to https://repository.apache.org/service/local/staging/deploy/maven2 (apache-5.pom). - Does any hints or documentation on how to migrate it exist? - Do I need a special user for this? Maven version: 10 maven-release-plugin version: 2.0-beta-8 java version 1.6.0_12 Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode) Thanks and regards Felix [1] http://repo2.maven.org/maven2/org/apache/apache/5/apache-5.pom - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:perform, upload fails
Felix Knecht schrieb: Hi all Executing release:perform fails. I'm using the latest ASF TLP pom [1] and saw that the repositoryidapache.releases.https/idurl has changed from scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository (apache-4.pom) to https://repository.apache.org/service/local/staging/deploy/maven2 (apache-5.pom). - Does any hints or documentation on how to migrate it exist? - Do I need a special user for this? Maven version: 2.0.10 of course maven-release-plugin version: 2.0-beta-8 java version 1.6.0_12 Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode) Thanks and regards Felix [1] http://repo2.maven.org/maven2/org/apache/apache/5/apache-5.pom - 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: How to execute Java task within a Archetype
There are a number of ways to do this. A shell script is one option that
springs to mind.
For a simple 'pure' Maven approach that doesnt require you to write much
code you could try something like this
A pom (make sure you rename it to bootstrap.xml or some such) -
project
modelVersion4.0.0/modelVersion
groupIdcom.acme/groupId
artifactIdproject-gen/artifactId
packagingpom/packaging
version1.0-SNAPSHOT/version
build
directory${genArtifactId}/directory
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phaseprocess-resources/phase
goals
goalrun/goal
/goals
configuration
tasks
echo message=processing generated project
${genArtifactId} .../
/tasks
/configuration
/execution
/executions
/plugin
plugin
artifactIdmaven-archetype-plugin/artifactId
executions
execution
phasegenerate-resources/phase
goals
goalcreate/goal
/goals
configuration
groupId${genGroupId}/groupId
artifactId${genArtifactId}/artifactId
/configuration
/execution
/executions
/plugin
/plugins
/build
/project
Combined with the following command line:
mvn clean process-resources -DgenArtifactId=test-project
-DgenGroupId=com.acme -f bootstrap.xml
Should create you a basic quickstart project in a relative folder named
[genArtifactId]
You will need to invoke your Java 'method' via the antrun plugin.
On Tue, 2009-02-24 at 14:49 +0100, Nick Stolwijk wrote:
First, the create goal has been deprecated, you can better use the
generate goal.
Second, the documentation[1] says that it runs the generate-sources
before executing, so maybe it is possible to add your own plugin
there. Unfortunately, I don't know how it can be done and I can't find
any documentation or examples. Can someone more knowledgeable share
his insights?
[1] http://maven.apache.org/plugins/maven-archetype-plugin/generate-mojo.html
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Tue, Feb 24, 2009 at 10:47 AM, Sagara Gunathunga sagar...@gmail.com
wrote:
Hi all
AFAIK when execute archetype:create command , the archetype copy the
folder structure with resources according to the archetype's
archetype.xml file . I want to execute a custom Java method in
addition to above default behaviour along with archetype:create
command . Is there any way to achieve this ? if so please update
me with some references .
Thanks ,
Sagara Gunathunga
Blog - http://ssagara.blogspot.com
Web - http://sagaras.awardspace.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
--
Adam Leggett
BuildFactory Principal Architect
UPCO
Office: 0113 20 10 600
Direct Line: 0113 20 10 631
Mobile: 07801 269056
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:perform, upload fails
It may depend on exactly what the failure is. We have seen some Out of Memory errors during uploads of large artifacts. We simply increased the size of the Java Heap. Out specific issue was taking place inside a Hudson build system. So, we added -Xms256m -Xmx512m to the CATALINA_OPTS variable before Tomcat starts. Dave Felix Knecht wrote: Hi all Executing release:perform fails. I'm using the latest ASF TLP pom [1] and saw that the repositoryidapache.releases.https/idurl has changed from scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository (apache-4.pom) to https://repository.apache.org/service/local/staging/deploy/maven2 (apache-5.pom). - Does any hints or documentation on how to migrate it exist? - Do I need a special user for this? Maven version: 10 maven-release-plugin version: 2.0-beta-8 java version 1.6.0_12 Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode) Thanks and regards Felix [1] http://repo2.maven.org/maven2/org/apache/apache/5/apache-5.pom - 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: [mojo-user] [ANNOUNCEMENT] - UNIX Maven Plugin 1.0-alpha-2 released
I think that that was the problem; they couldn't imagine what it might do. The word UNIX doesn't bring to mind doing anything specific. Trygve Laugstøl wrote: What did they expect it to do? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:perform, upload fails
Thanks for help, I finally I got it :-) I was a permission denied error. What solved my problem was to add the executables in the server section of my settings.xml server idapache.release/id usernamefelixk/username !-- This solved my permission problems !?? - configuration sshExecutablessh/sshExecutable scpExecutablescp/scpExecutable /configuration /server Thanks Felix David C. Hicks schrieb: It may depend on exactly what the failure is. We have seen some Out of Memory errors during uploads of large artifacts. We simply increased the size of the Java Heap. Out specific issue was taking place inside a Hudson build system. So, we added -Xms256m -Xmx512m to the CATALINA_OPTS variable before Tomcat starts. Dave Felix Knecht wrote: Hi all Executing release:perform fails. I'm using the latest ASF TLP pom [1] and saw that the repositoryidapache.releases.https/idurl has changed from scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository (apache-4.pom) to https://repository.apache.org/service/local/staging/deploy/maven2 (apache-5.pom). - Does any hints or documentation on how to migrate it exist? - Do I need a special user for this? Maven version: 10 maven-release-plugin version: 2.0-beta-8 java version 1.6.0_12 Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode) Thanks and regards Felix [1] http://repo2.maven.org/maven2/org/apache/apache/5/apache-5.pom - 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: Repo release final
Is there no way to do look deployments via pom properties or other settings in Nexus? This is a great question for the Nexus Users list. Unfortunately, you're asking the Maven Users list. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Repo release final
Hi Wayne I will post on nexus but was wondering if there was something you could set in the pol and then the install/deploy plugin would then stop you deploying if the same version existed in the repository? That's not to much to ask for? Cheers Paul Wayne Fay wrote: Is there no way to do look deployments via pom properties or other settings in Nexus? This is a great question for the Nexus Users list. Unfortunately, you're asking the Maven Users list. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://n2.nabble.com/Repo-release-final-tp2374974p2379612.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Repo release final
I will post on nexus but was wondering if there was something you could set in the pol and then the install/deploy plugin would then stop you deploying if the same version existed in the repository? That's not to much to ask for? Its not too much to ask. But quite simply, the answer is no, or else the Nexus FAQ post that was rather complex would have been much simpler, right? You can't do this in plain old Maven at this point in time, unless something has changed and I'm simply unaware of it. Some people manage this by creating a cron job to run every hour on their repo server that runs through the artifacts and sets read-only mode on all the deployed files. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to configure resources plugin to copy extra files
I had the same issue... and I didn't want to set the extra resources in the
build section of the pom, because i didn't want to include them in my jar.
I think this has to do with the version of the maven-resources-plugin that
you have installed. If you run maven -U to update to the latest version
of all dependencies, it should solve the problem. Or you can explicitly set
the version to 2.3:
plugin
artifactIdmaven-resources-plugin/artifactId
version2.3/version
executions
execution.../execution
/executions
/plugin
zorro2b wrote:
I am converting a project to use Maven. I have got it to compile but the
tests are failing because there are xml files in with the java source that
need to be copied over with the classes. I don't want to move these into
the resources dir, so I followed the example here:
http://maven.apache.org/plugins/maven-resources-plugin/examples/copy-resources.html
but I get the error 'copy-resources' was specified in an execution, but
not found in the plugin
so I have tried changing the goal to resources as well as removing the
goals section completely. Both get rid of the error, but no files are
copied.
Does anyone have a working config they could share?
Here is my current config:
plugin
artifactIdmaven-resources-plugin/artifactId
executions
execution
idcopy-resources/id
phaseprocess-resources/phase
goals
goalresources/goal
/goals
configuration
outputDirectory${basedir}/target/classes/outputDirectory
resources
resource
directorysrc/main/java/directory
includes
include**/*.xml/include
/includes
/resource
/resources
/configuration
/execution
/executions
/plugin
--
View this message in context:
http://www.nabble.com/How-to-configure-resources-plugin-to-copy-extra-files-tp21067611p22189863.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
Probable bug with maven-war-plugin-2.1-alpha-2
I recently upgraded Maven 2.0.10 and noticed that this version of Maven has changed the default version of the maven-war-plugin to 2.1-alpha-2. When using this version of the plugin I get the following error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappS tructure.java:109) at org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(Web appStructure.java:288) at org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask. performPackaging(DependenciesAnalysisPackagingTask.java:46) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo. java:439) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(Abstract WarMojo.java:375) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:500) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:479) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) I have reverted back to alpha-1 of the plugin and everythings works fine. I checkedout the source and compared it with alpha 1 and it looks like there were a lot of changes to file WebappStructure.java:109, the file throwing the NullPointerException. My best guess is that the new version of the file does not correctly handling the situation where no dependencies are found. Has anyone else seen this? I have not see this issue raised on the Jira page yet. --- Todd Thiessen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Probable bug with maven-war-plugin-2.1-alpha-2
I checkedout the source and compared it with alpha 1 and it looks like there were a lot of changes to file WebappStructure.java:109, the file throwing the NullPointerException. My best guess is that the new version of the file does not correctly handling the situation where no dependencies are found. Has anyone else seen this? I have not see this issue raised on the Jira page yet. Sounds like a bug -- please file it, with a sample project if you have one to share. You're probably one of very few people using Maven 2.0.10 and working on a WAR project with zero dependencies. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Probable bug with maven-war-plugin-2.1-alpha-2
Reported and fixed in the next version. See http://jira.codehaus.org/browse/MWAR-170 Todd Thiessen wrote: I recently upgraded Maven 2.0.10 and noticed that this version of Maven has changed the default version of the maven-war-plugin to 2.1-alpha-2. When using this version of the plugin I get the following error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappS tructure.java:109) at org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(Web appStructure.java:288) at org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask. performPackaging(DependenciesAnalysisPackagingTask.java:46) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo. java:439) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(Abstract WarMojo.java:375) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:500) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:479) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) I have reverted back to alpha-1 of the plugin and everythings works fine. I checkedout the source and compared it with alpha 1 and it looks like there were a lot of changes to file WebappStructure.java:109, the file throwing the NullPointerException. My best guess is that the new version of the file does not correctly handling the situation where no dependencies are found. Has anyone else seen this? I have not see this issue raised on the Jira page yet. --- Todd Thiessen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven-Eclipse-Hibernate: Missing indirectly referenced artifact
I'm getting the following error when I attempt to specify Hibernate Annotations as a dependency (I get a similar error with Hibernate itself). Missing indirectly referenced artifact javax.persistence:ejb:jar:3.0- public_review:compile This is using the m2eclipse plugin in Eclipse. Here is my pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIddhosek/groupId artifactIdlibrary-catalog/artifactId packagingwar/packaging version0.0.1-SNAPSHOT/version namelibrary-catalog Maven Webapp/name urlhttp://maven.apache.org/url dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdhibernate/groupId artifactIdhibernate-annotations/artifactId version3.1beta4/version /dependency /dependencies build finalNamelibrary-catalog/finalName /build /project Any thoughts on what I can do to let Maven manage my dependencies? -dh - 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
Does maven deploy have maximum size limit?
I run mvn deploy command to package and deploy a jar which is more than 50m size. Maven will throw an out-of memory exception. I wander whether maven has a size limit. thanks. -- View this message in context: http://www.nabble.com/Does-maven-deploy-have-maximum-size-limit--tp22194751p22194751.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
On 24-Feb-09, at 8:12 AM, Jon Georg Berentsen wrote: Jason, This blogpost, http://tech.puredanger.com/2009/01/28/maven-adoption-curve/ , sparked quite a debate in my company. We have been quite the early adopters with maven, and have seen the benefits etc. etc., but it seem like this Ant/script to Maven, what do we get, we only got trouble fight has to be fought all the time with clients and new co workers. In your experience who adopt and embrace maven? People who try it and have something that works. If it doesn't work for you then don't use it. I'm not very preachy about Maven and I've never tried to convert people to use it. I don't think that would generally work anyway. If Ant or scripting languages work for you then use them. Is it always the I have seen the need-people? Or do you have to have a maven Maven guy preaching? I don't think you'll get very far if the team doesn't buy into it. Any organization who listens to one preachy guy and then adopts Maven is not going to get very far. It seems, to me, that if none of the two is present, Maven is often considered a hassel and pain. Often people don't read any documentation, think a build is just something that requires no maintenance and is just going to work, or are just completely accustom to Ant that anything different seems like a hassle. We get lots of people telling us all the time that they think Maven is great and works well for them. Often, if used, Maven also becomes a specialist skill. One or two persons know it, the rest just use it, and can't fix it if something is broken. I honestly have not found that to be the case when developers are prepared. If you took two people who don't know either Ant or Maven you would probably have an equal amount of difficulty. You get used to what you use. Project who think that they can get away without investing something in the infrastructure and training about it are going to have problems. Many people think build and release management is just some appendage to their project. Your project is not going to work if the infrastructure doesn't work. I have often heard that the reason for this is that Ant is very transparent in what it does. Maven is not. I really don't think that's the case. I think people have just used Ant for a long time and they are used to it. Does this raise the bar for adoption? I don't think so. Traffic on Maven central has grown incredibly over the last year (on the order of 200M hits/month) and it continues to grow. So Maven is still being adopted all the time because the number of unique IPs keeps growing. So empirically we're seeing an increase in adoption as time passes. Project size/complexity and skills matter? Nope. I know lots people who use Maven on small projects and we have clients who build project that are 6M lines of code. Some are build and release engineers, most of them are just developers. Jon -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: 24. februar 2009 16:32 To: Maven Users List Subject: Re: Mavenizing Existing Project Part Deux Do make your first Maven project a conversion. You will likely fail or be extremely unhappy. I have seen this a hundred times now and trying to wedge Maven into what you currently have is categorically not a good idea. Find a new, preferably small, project where you can try out Maven and understand fully what it does before you attempt to convert a project. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- Three may keep a secret if two of them are dead. -- Benjamin Franklin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
The one big concern I have is your plan of starting with eclipse and the m2eclipse plugin. It's not that I'm old school and prefer the command line but I find that the m2eclipse plugin does a lot of automagic stuff and you may not realize when things are changing under you because of what the plugin is doing. Once you have your project working from the command line, then commit it to svn, then in eclipse check it out from svn as a maven project. The other thing is, and this may be an urban legend, that I think it's better to not have the sub modules nested in the parent module's directory. Make them parallel; siblings. This means using ../ with relativePath when referring to the parent's pom: parent artifactIdproject_parent/artifactId groupIdmy.company.group.id/groupId version1.1-SNAPSHOT/version relativePath../project_parent/pom.xml/relativePath /parent artifactIdproject_module1/artifactId packagingjar/packaging etc. I think eclipse doesn't like or support nested projects. If you use the nested directories layout, when you import it into eclipse I think the m2eclipse does some voodoo behind your back, rearranging things to make eclipse happy. For me it was a bit more transparent having the modules as parallel projects in eclipse. Steve Cohen wrote: OK, after extensive discussion in earlier thread about the best way to go about Mavenizing Existing Project(s) in my, shall we say, unusual environment (see that thread for details, don't want to recapitulate them here) I have decided to try to move forward. First I have to learn this tool. I have used maven before, but mainly in the way of building from someone else's POM. Just type maven install or some such and bingo, the world is built. Now my goal is to have pre-existing non-Maven projects be mavenized. I am prepared to throw the first one away. I also want to take this opportunity to start from a m2eclipse platform, so I have now installed that, even to the point of installing Ganymede because I couldn't get it to install in Europa. Although I know there is benefit to the command line tools, I'd like to start from eclipse, understanding that I can take the POM I produce and install it with command line tools. So my first question is this: How do I convert a non-Maven project into a Maven project? 1) Is there some way to change natures? 2) Create a new Maven project, place in SVN, then move stuff to the right places? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Does maven deploy have maximum size limit?
Unfortunately, it doesn't stream it properly - I'd suggest you file an issue under http://jira.codehaus.org/browse/MDEPLOY There is no size limit other than it gets loaded into memory - you can increase the memory you give to Maven with MAVEN_OPTS=-Xmx256m for example. On 25/02/2009, at 1:06 PM, youhaodeyi wrote: I run mvn deploy command to package and deploy a jar which is more than 50m size. Maven will throw an out-of memory exception. I wander whether maven has a size limit. thanks. -- View this message in context: http://www.nabble.com/Does-maven-deploy-have-maximum-size-limit--tp22194751p22194751.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 -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Wagon 1.0 beta 5 Released
The Maven team is pleased to announce the release of Wagon 1.0-beta-5. This release includes 17 fixes. You can take a look at the release notes here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335styleName=Htmlversion=14467 * [WAGON-111] - UNC paths don't work when properly URL encoded. * [WAGON-221] - removeCheckoutDirectory throws NPE * [WAGON-223] - HTTP Wagon getFileList() returns empty list for connected base URL * [WAGON-231] - PathUtils.toRelative() throws SIOOBE if supplied arguments specify the same directory * [WAGON-232] - Lightweight HTTP wagon doesn't reset proxy settings correctly if they were not previously set * [WAGON-237] - keyboard-interactive method is used even when password is supplied * [WAGON-239] - remove password workaround hack in TraditionalKeyboardInteractive * [WAGON-242] - FtpWagon class needs to handle possible null returned from ftpFiles[0].getTimestamp() * [WAGON-243] - wagon-ssh-external does not always detect usage of PSCP (as opposed to SSH) * [WAGON-244] - Deploying to WebDAV repository fails in IAE * [WAGON-245] - Wagon providers throw the wrong exception in getFilelist for resource not found * [WAGON-246] - Wagon.getFilelist does not work for WebDav * [WAGON-248] - wagon-file's FileWagon.resourceExists should check for directory when resouce indicate it is a directory * [WAGON-250] - SftpWagon.getFileList gets String index out of range: 0 * [WAGON-253] - known_hosts file recreated for each ssh connection. * [WAGON-254] - wagon-ftp :: error uploading site:: too many open files * [WAGON-255] - Upgrade wagon-webdav to use jackrabbit-1.5.0 IMPORTANT NOTE: This release will only work as an extension in Maven 2.1.0-M1 and above. -The Maven team -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/
Setup for multiple products
I was examining the Example in the Book Better Builds With Maven and find that it focuses on a product Proficio. In our case we have several products and a suite of modules. Would the following be a reasonable structure for us? /areteq /pom.xml - super pom - contains site information, etc.? /modules /foundation /pom.xml - to create the foundation jar (common to all products) /src .. in all of these /engine /pom.xml - to create the engine jar ( common to all products ) /pre-processors /pom.xml - to create all pre-processor jars /pre-processor1 /pom.xml - to create pre-processor1 jar /pre-processor2 / etc. /post-processors /renderers /products /pom.xml - to create all products and test? /product1 /pom.xml - to create product1 and test? Contains list of child modules it depends upon? /src - not clear there is much here except for resources, data, configurations. /product2 etc. Now, if we want to put our documentation on our site, I could run at the top level to generate the site? Since each product uses different combinations of processors, configurations, etc., do the product poms use the children modules, and the children don't have anything about their parents since they might be different? It's clear that engine's pom has to have foundation pom as a dependency, and so forth in some of the others. Does this make sense? It will take a while and I want to be sure I'm approaching a multi-product maven setup in the correct manner. (I won't try to do this all at once, but rather product1 and get that working 8-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Setup for multiple products
You seem to be on the right track. One statement was a bit confusing: On 25/02/2009, at 8:47 AM, John Wooten wrote: Since each product uses different combinations of processors, configurations, etc., do the product poms use the children modules, and the children don't have anything about their parents since they might be different? It's clear that engine's pom has to have foundation pom as a dependency, and so forth in some of the others. All the children should have parents consistent with the structure of the layout. There should be a 1:1 relationship with the parent and the modules. Consider your release patterns as well - you want to make sure a releasable unit is buildable together from a common root. Products should have dependencies on stuff from /modules in your case, which I think you have correct. Hope this helps. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-Eclipse-Hibernate: Missing indirectly referenced artifact
I'm getting the following error when I attempt to specify Hibernate Annotations as a dependency (I get a similar error with Hibernate itself). Missing indirectly referenced artifact javax.persistence:ejb:jar:3.0-public_review:compile That artifact does not exist in Central: http://repo2.maven.org/maven2/javax/persistence/ You either need to: 1) Manually install this artifact into your local repo cache 2) Add an excludes and a corresponding dependency so you get a proper artifact 3) Stop depending on outdated Hibernate artifacts, I'd suggest upgrading to this one: http://repo2.maven.org/maven2/org/hibernate/hibernate-annotations/3.4.0.GA/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
