POM element orders
Hello, I'm having a bit of a problem here ! I have a project that while not very big, does span a dependency tree a few level deep and has many leaves of final deployed packages. I use maven not only to build and all but to generate zip files that contain everything (doc, runtime environment, libraries, config files etc). This makes the job of people that have to deploy the modules a lot easier. So.. Parent POM contains all that is necessary to build the base package, most of which are set to not be inherited by the children as they will simply use the parent Zip file package as a baseline and will complete or override the necessary files to create the final packages. My problem is this, in the parent I define some build tasks that will be inherited by the children, namely : build plugins plugin artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration inheritedtrue/inherited /plugin ... snip ... plugin inheritedtrue/inherited artifactIdmaven-assembly-plugin/artifactId executions execution idmake-assembly/id phasepackage/phase goals goalattached/goal /goals /execution /executions configuration descriptors descriptorsrc/main/assembly/package.xml /descriptor /descriptors /configuration /plugin /plugins /build I clipped out the extra fluff leaving the interesting bits. In the child project I have this build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin /artifactId executions execution idunpackProcessor/id phasepackage/phase goals goalunpack/goal /goals configuration artifactItems artifactItem groupIdcom.purkinje/groupId artifactIdProcessorService/artifactId classifierpackage/classifier typezip/type overWritetrue/overWrite outputDirectorytarget/processorPack /outputDirectory /artifactItem /artifactItems overWriteReleasesfalse/overWriteReleases overWriteSnapshotstrue/overWriteSnapshots /configuration /execution /executions /plugin /plugins The goal is to be able to use the definition of the parent to create a package based on the assembly rules (package.xml) that all child must have. My problem is that the assembly is executed BEFORE the unpacking and thus will not include the parent`s file as intended. The only workaround I found to this is to redefine the assembly section in each children thereby nullifying the inheritance benefit... Questions : 1 - can I control the order in which the build tasks are executed ? 2 - can I create dependencies amongst them so that the order of execution, while not controlled in absolute, would still be respected and do the intended work. 3 - is there a better way to achieve this knowing the children may very well have some code inside along with documentation and configuration ? Many thanks in advance Éric
RE: POM element orders
AFAIK, the execution of plugin goals within a phase is not configurable, at least in Maven 2.0.x. In order to make dependency:unpack happen before assembly:attached, just execute dependency:unpack in an earlier lifecycle phase. HTH, Justin From: Éric Daigneault [mailto:dai...@gmail.com] Sent: Sun 2/1/2009 12:08 PM To: users@maven.apache.org Subject: POM element orders Hello, I'm having a bit of a problem here ! I have a project that while not very big, does span a dependency tree a few level deep and has many leaves of final deployed packages. I use maven not only to build and all but to generate zip files that contain everything (doc, runtime environment, libraries, config files etc). This makes the job of people that have to deploy the modules a lot easier. So.. Parent POM contains all that is necessary to build the base package, most of which are set to not be inherited by the children as they will simply use the parent Zip file package as a baseline and will complete or override the necessary files to create the final packages. My problem is this, in the parent I define some build tasks that will be inherited by the children, namely : build plugins plugin artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration inheritedtrue/inherited /plugin ... snip ... plugin inheritedtrue/inherited artifactIdmaven-assembly-plugin/artifactId executions execution idmake-assembly/id phasepackage/phase goals goalattached/goal /goals /execution /executions configuration descriptors descriptorsrc/main/assembly/package.xml /descriptor /descriptors /configuration /plugin /plugins /build I clipped out the extra fluff leaving the interesting bits. In the child project I have this build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin /artifactId executions execution idunpackProcessor/id phasepackage/phase goals goalunpack/goal /goals configuration artifactItems artifactItem groupIdcom.purkinje/groupId artifactIdProcessorService/artifactId classifierpackage/classifier typezip/type overWritetrue/overWrite outputDirectorytarget/processorPack /outputDirectory /artifactItem /artifactItems overWriteReleasesfalse/overWriteReleases overWriteSnapshotstrue/overWriteSnapshots /configuration /execution /executions /plugin /plugins The goal is to be able to use the definition of the parent to create a package based on the assembly rules (package.xml) that all child must have. My problem is that the assembly is executed BEFORE the unpacking and thus will not include the parent`s file as intended. The only workaround I found to this is to redefine the assembly section in each children thereby nullifying the inheritance benefit... Questions : 1 - can I control the order in which the build tasks are executed ? 2 - can I create dependencies amongst them so that the order of execution, while not controlled in absolute, would still be respected and do the intended work. 3 - is there a better way to achieve this knowing the children may very well have some code inside along with documentation and configuration ? Many thanks in advance Éric
Re: Maven for the internet afraid
I need to clarify my question. The security people at my company certainly want the finest-grained control possible over artifacts, that is, an ask-first model where they approve each individually. I don't question that we can force Maven into this mindset, but whether we can do so without significantly hindering its usefulness. For us, a reactive approach like what Nexus's procurement mechanism assists with will inevitably turn artifact approval into an agonizing bureaucratic process at exactly the wrong times for developers. To ensure that relatively arcane corners of dependency resolution do not hamstring them in the midst of coding frenzies, I need a big-bang approach to front-load the repository. Basically, how can I minimize the pain when someone tries to use an already approved artifact in an unanticipated configuration? Incidentally, I have been happily experimenting with Nexus for a little while now. Good work. In short, two handy URLs: http://books.sonatype.com/nexus-book/reference/procure.html http://blogs.sonatype.com/people/2009/01/nexus-professional-what-is-procurement/ Hope helps, ~t~ On Sat, Jan 31, 2009 at 9:36 PM, Merv Green paradeofh...@gmail.com wrote: So, in my quest to take Maven completely internal, I'm still grappling with a couple of use cases: 1. Gathering plugin dependencies We have some list of approved plugins we somehow decide we need. For each, we want to populate our repo with any artifacts those plugins might require in use. During the approval process we create dummy projects to exercise each plugin, then we build those projects against a proxy repo and declare whatever landed in the proxy kosher. That step rubs me wrong because I feel like Maven is resolving plugin dependencies based on the plugin's configuration for a particular project, and we'll easily miss some use cases, ending up with an incomplete repository. Wendy, apparently has a better way that uses the assembly plugin, but I don't quite understand it. Could you illustrate? 2. Different dependency configurations Say we like artifact A, so we create a project, P that depends on A. Declared dependencies are like so: P -- A A -- B, C B -- D-v1 C -- D-v2 So we bundle P's dependencies in remote repo configuration and upload to the approved repository, which now includes A, B, C and D-v1. Some time later, a developer depends on only C, and the project refuses to build. How do you all handle this? In any case, thank you all for the encouragement that we might not be as crazy as I think. - 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: Maven for the internet afraid
I don't see how you can have both an ask-first approach and not some business process to handle it. The recommended setup we like to see is to let developers have access to the repos, but keep the official builds behind the Nexus Procurement repo so that you are sure what is officially built. It's the best of both worlds. If they really insist on being 100% offline, then you are stuck with a completely manual process that will be bureaucratic regardless of the existence of a tool or not. It simply isn't practical to try and pull down all 80gb of central and every other repo you might ever want and then hide in a corner hoping you never need something more. It has to be a balanced approach. -Original Message- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Sunday, February 01, 2009 2:14 PM To: Maven Users List Subject: Re: Maven for the internet afraid I need to clarify my question. The security people at my company certainly want the finest-grained control possible over artifacts, that is, an ask-first model where they approve each individually. I don't question that we can force Maven into this mindset, but whether we can do so without significantly hindering its usefulness. For us, a reactive approach like what Nexus's procurement mechanism assists with will inevitably turn artifact approval into an agonizing bureaucratic process at exactly the wrong times for developers. To ensure that relatively arcane corners of dependency resolution do not hamstring them in the midst of coding frenzies, I need a big-bang approach to front-load the repository. Basically, how can I minimize the pain when someone tries to use an already approved artifact in an unanticipated configuration? Incidentally, I have been happily experimenting with Nexus for a little while now. Good work. In short, two handy URLs: http://books.sonatype.com/nexus-book/reference/procure.html http://blogs.sonatype.com/people/2009/01/nexus-professional-what-is-procurement/ Hope helps, ~t~ On Sat, Jan 31, 2009 at 9:36 PM, Merv Green paradeofh...@gmail.com wrote: So, in my quest to take Maven completely internal, I'm still grappling with a couple of use cases: 1. Gathering plugin dependencies We have some list of approved plugins we somehow decide we need. For each, we want to populate our repo with any artifacts those plugins might require in use. During the approval process we create dummy projects to exercise each plugin, then we build those projects against a proxy repo and declare whatever landed in the proxy kosher. That step rubs me wrong because I feel like Maven is resolving plugin dependencies based on the plugin's configuration for a particular project, and we'll easily miss some use cases, ending up with an incomplete repository. Wendy, apparently has a better way that uses the assembly plugin, but I don't quite understand it. Could you illustrate? 2. Different dependency configurations Say we like artifact A, so we create a project, P that depends on A. Declared dependencies are like so: P -- A A -- B, C B -- D-v1 C -- D-v2 So we bundle P's dependencies in remote repo configuration and upload to the approved repository, which now includes A, B, C and D-v1. Some time later, a developer depends on only C, and the project refuses to build. How do you all handle this? In any case, thank you all for the encouragement that we might not be as crazy as I think. - 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: POM element orders
The order should follow the pom, with children always coming before the parent definitions. User bound executions always come after the default ones for any given phase. -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Sunday, February 01, 2009 12:12 PM To: Maven Users List Subject: RE: POM element orders AFAIK, the execution of plugin goals within a phase is not configurable, at least in Maven 2.0.x. In order to make dependency:unpack happen before assembly:attached, just execute dependency:unpack in an earlier lifecycle phase. HTH, Justin From: Éric Daigneault [mailto:dai...@gmail.com] Sent: Sun 2/1/2009 12:08 PM To: users@maven.apache.org Subject: POM element orders Hello, I'm having a bit of a problem here ! I have a project that while not very big, does span a dependency tree a few level deep and has many leaves of final deployed packages. I use maven not only to build and all but to generate zip files that contain everything (doc, runtime environment, libraries, config files etc). This makes the job of people that have to deploy the modules a lot easier. So.. Parent POM contains all that is necessary to build the base package, most of which are set to not be inherited by the children as they will simply use the parent Zip file package as a baseline and will complete or override the necessary files to create the final packages. My problem is this, in the parent I define some build tasks that will be inherited by the children, namely : build plugins plugin artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration inheritedtrue/inherited /plugin ... snip ... plugin inheritedtrue/inherited artifactIdmaven-assembly-plugin/artifactId executions execution idmake-assembly/id phasepackage/phase goals goalattached/goal /goals /execution /executions configuration descriptors descriptorsrc/main/assembly/package.xml /descriptor /descriptors /configuration /plugin /plugins /build I clipped out the extra fluff leaving the interesting bits. In the child project I have this build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin /artifactId executions execution idunpackProcessor/id phasepackage/phase goals goalunpack/goal /goals configuration artifactItems artifactItem groupIdcom.purkinje/groupId artifactIdProcessorService/artifactId classifierpackage/classifier typezip/type overWritetrue/overWrite outputDirectorytarget/processorPack /outputDirectory /artifactItem /artifactItems overWriteReleasesfalse/overWriteReleases overWriteSnapshotstrue/overWriteSnapshots /configuration /execution /executions /plugin /plugins The goal is to be able to use the definition of the parent to create a package based on the assembly rules (package.xml) that all child must have. My problem is that the assembly is executed BEFORE the unpacking and thus will not include the parent`s file as intended. The only workaround I found to this is to redefine the assembly section in each children thereby nullifying the inheritance benefit... Questions : 1 - can I control the order in which the build tasks are executed ? 2 - can I create dependencies amongst them so that the order of execution, while not controlled in absolute, would still be respected and do the intended work. 3 - is there a better way to achieve this knowing the children may very well have some code inside along with documentation and configuration ? Many thanks in advance Éric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for the internet afraid
I have to agree with Brian: letting developers use the proxy repo, but CI/Releases the procured repo (which pulls its content from same proxy repo that devs uses, but bureaucratic rules are applied). This IS a supported scenario. But, as with many things in our lives, you can play Unnatural Acts (sic!) with Nexus too... You could even procure a procured repository (waterfall procurement? ;) Set up central repo as proxy for central. Set up a procured-light repo, as procured for devs (with light rule management applied) using central as target. Set up a devs group and put procured-devs repo into it (and possibly any other secure reposes) Set up a procured-strong repo, as procured for CI/Release (with bureaucratic rule management applied) using devs group as target. ...and so on. That's it. But it would require a lot of beers to explain me why would you do it :) Thanks for appreciating Nexus! ~t~ [1] fav TV series, followed by cultic Mighty Boosh On Sun, Feb 1, 2009 at 8:19 PM, Brian E. Fox bri...@reply.infinity.nu wrote: I don't see how you can have both an ask-first approach and not some business process to handle it. The recommended setup we like to see is to let developers have access to the repos, but keep the official builds behind the Nexus Procurement repo so that you are sure what is officially built. It's the best of both worlds. If they really insist on being 100% offline, then you are stuck with a completely manual process that will be bureaucratic regardless of the existence of a tool or not. It simply isn't practical to try and pull down all 80gb of central and every other repo you might ever want and then hide in a corner hoping you never need something more. It has to be a balanced approach. -Original Message- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Sunday, February 01, 2009 2:14 PM To: Maven Users List Subject: Re: Maven for the internet afraid I need to clarify my question. The security people at my company certainly want the finest-grained control possible over artifacts, that is, an ask-first model where they approve each individually. I don't question that we can force Maven into this mindset, but whether we can do so without significantly hindering its usefulness. For us, a reactive approach like what Nexus's procurement mechanism assists with will inevitably turn artifact approval into an agonizing bureaucratic process at exactly the wrong times for developers. To ensure that relatively arcane corners of dependency resolution do not hamstring them in the midst of coding frenzies, I need a big-bang approach to front-load the repository. Basically, how can I minimize the pain when someone tries to use an already approved artifact in an unanticipated configuration? Incidentally, I have been happily experimenting with Nexus for a little while now. Good work. In short, two handy URLs: http://books.sonatype.com/nexus-book/reference/procure.html http://blogs.sonatype.com/people/2009/01/nexus-professional-what-is-procurement/ Hope helps, ~t~ On Sat, Jan 31, 2009 at 9:36 PM, Merv Green paradeofh...@gmail.com wrote: So, in my quest to take Maven completely internal, I'm still grappling with a couple of use cases: 1. Gathering plugin dependencies We have some list of approved plugins we somehow decide we need. For each, we want to populate our repo with any artifacts those plugins might require in use. During the approval process we create dummy projects to exercise each plugin, then we build those projects against a proxy repo and declare whatever landed in the proxy kosher. That step rubs me wrong because I feel like Maven is resolving plugin dependencies based on the plugin's configuration for a particular project, and we'll easily miss some use cases, ending up with an incomplete repository. Wendy, apparently has a better way that uses the assembly plugin, but I don't quite understand it. Could you illustrate? 2. Different dependency configurations Say we like artifact A, so we create a project, P that depends on A. Declared dependencies are like so: P -- A A -- B, C B -- D-v1 C -- D-v2 So we bundle P's dependencies in remote repo configuration and upload to the approved repository, which now includes A, B, C and D-v1. Some time later, a developer depends on only C, and the project refuses to build. How do you all handle this? In any case, thank you all for the encouragement that we might not be as crazy as I think. - 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: Maven for the internet afraid
We envision a process where we periodically reevaluate our needs, gathering all artifacts we'll use until the next assessment. In summary, that is simply impractical; we need a different approach. Saying that at work lately, I've felt like Cassandra, but I'll be glad to admit if I'm wrong... Tamás Cservenák wrote: I have to agree with Brian: letting developers use the proxy repo, but CI/Releases the procured repo (which pulls its content from same proxy repo that devs uses, but bureaucratic rules are applied). This IS a supported scenario. But, as with many things in our lives, you can play Unnatural Acts (sic!) with Nexus too... You could even procure a procured repository (waterfall procurement? ;) Set up central repo as proxy for central. Set up a procured-light repo, as procured for devs (with light rule management applied) using central as target. Set up a devs group and put procured-devs repo into it (and possibly any other secure reposes) Set up a procured-strong repo, as procured for CI/Release (with bureaucratic rule management applied) using devs group as target. ...and so on. That's it. But it would require a lot of beers to explain me why would you do it :) Thanks for appreciating Nexus! ~t~ [1] fav TV series, followed by cultic Mighty Boosh On Sun, Feb 1, 2009 at 8:19 PM, Brian E. Fox bri...@reply.infinity.nu wrote: I don't see how you can have both an ask-first approach and not some business process to handle it. The recommended setup we like to see is to let developers have access to the repos, but keep the official builds behind the Nexus Procurement repo so that you are sure what is officially built. It's the best of both worlds. If they really insist on being 100% offline, then you are stuck with a completely manual process that will be bureaucratic regardless of the existence of a tool or not. It simply isn't practical to try and pull down all 80gb of central and every other repo you might ever want and then hide in a corner hoping you never need something more. It has to be a balanced approach. -Original Message- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Sunday, February 01, 2009 2:14 PM To: Maven Users List Subject: Re: Maven for the internet afraid I need to clarify my question. The security people at my company certainly want the finest-grained control possible over artifacts, that is, an ask-first model where they approve each individually. I don't question that we can force Maven into this mindset, but whether we can do so without significantly hindering its usefulness. For us, a reactive approach like what Nexus's procurement mechanism assists with will inevitably turn artifact approval into an agonizing bureaucratic process at exactly the wrong times for developers. To ensure that relatively arcane corners of dependency resolution do not hamstring them in the midst of coding frenzies, I need a big-bang approach to front-load the repository. Basically, how can I minimize the pain when someone tries to use an already approved artifact in an unanticipated configuration? Incidentally, I have been happily experimenting with Nexus for a little while now. Good work. In short, two handy URLs: http://books.sonatype.com/nexus-book/reference/procure.html http://blogs.sonatype.com/people/2009/01/nexus-professional-what-is-procurement/ Hope helps, ~t~ On Sat, Jan 31, 2009 at 9:36 PM, Merv Green paradeofh...@gmail.com wrote: So, in my quest to take Maven completely internal, I'm still grappling with a couple of use cases: 1. Gathering plugin dependencies We have some list of approved plugins we somehow decide we need. For each, we want to populate our repo with any artifacts those plugins might require in use. During the approval process we create dummy projects to exercise each plugin, then we build those projects against a proxy repo and declare whatever landed in the proxy kosher. That step rubs me wrong because I feel like Maven is resolving plugin dependencies based on the plugin's configuration for a particular project, and we'll easily miss some use cases, ending up with an incomplete repository. Wendy, apparently has a better way that uses the assembly plugin, but I don't quite understand it. Could you illustrate? 2. Different dependency configurations Say we like artifact A, so we create a project, P that depends on A. Declared dependencies are like so: P -- A A -- B, C B -- D-v1 C -- D-v2 So we bundle P's dependencies in remote repo configuration and upload to the approved repository, which now includes A, B, C and D-v1. Some time later, a developer depends on only C, and the project refuses to build. How do you all handle this? In any case, thank you all for the encouragement that we might not be as crazy as I think. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail:
RE: Maven for the internet afraid
you can stage the process online hours Server1 pulls any/all necessary poms/jars/wars/ears/properties 8am server1 run every AntiVirus on the planet against downloaded files 9am server1 becomes accessible locally Now you can set your localRepository to server1 e.g. settings localRepository/server1/localRepository /settings !-- if no basic authentication is required setup server1 to be a non-proxied hosts -- proxies proxy activetrue/active protocolhttp/protocol hostproxy.somewhere.com/host port8080/port usernameproxyuser/username passwordsomepassword/password nonProxyHostswww.google.com|server1/nonProxyHosts /proxy /proxies advice? Martin Gainty __ 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: Sun, 1 Feb 2009 17:17:56 -0500 From: paradeofh...@gmail.com To: users@maven.apache.org Subject: Re: Maven for the internet afraid We envision a process where we periodically reevaluate our needs, gathering all artifacts we'll use until the next assessment. In summary, that is simply impractical; we need a different approach. Saying that at work lately, I've felt like Cassandra, but I'll be glad to admit if I'm wrong... Tamás Cservenák wrote: I have to agree with Brian: letting developers use the proxy repo, but CI/Releases the procured repo (which pulls its content from same proxy repo that devs uses, but bureaucratic rules are applied). This IS a supported scenario. But, as with many things in our lives, you can play Unnatural Acts (sic!) with Nexus too... You could even procure a procured repository (waterfall procurement? ;) Set up central repo as proxy for central. Set up a procured-light repo, as procured for devs (with light rule management applied) using central as target. Set up a devs group and put procured-devs repo into it (and possibly any other secure reposes) Set up a procured-strong repo, as procured for CI/Release (with bureaucratic rule management applied) using devs group as target. ...and so on. That's it. But it would require a lot of beers to explain me why would you do it :) Thanks for appreciating Nexus! ~t~ [1] fav TV series, followed by cultic Mighty Boosh On Sun, Feb 1, 2009 at 8:19 PM, Brian E. Fox bri...@reply.infinity.nu wrote: I don't see how you can have both an ask-first approach and not some business process to handle it. The recommended setup we like to see is to let developers have access to the repos, but keep the official builds behind the Nexus Procurement repo so that you are sure what is officially built. It's the best of both worlds. If they really insist on being 100% offline, then you are stuck with a completely manual process that will be bureaucratic regardless of the existence of a tool or not. It simply isn't practical to try and pull down all 80gb of central and every other repo you might ever want and then hide in a corner hoping you never need something more. It has to be a balanced approach. -Original Message- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Sunday, February 01, 2009 2:14 PM To: Maven Users List Subject: Re: Maven for the internet afraid I need to clarify my question. The security people at my company certainly want the finest-grained control possible over artifacts, that is, an ask-first model where they approve each individually. I don't question that we can force Maven into this mindset, but whether we can do so without significantly hindering its usefulness. For us, a reactive approach like what Nexus's procurement mechanism assists with will inevitably turn artifact approval into an agonizing bureaucratic process at exactly the wrong times for developers. To ensure that relatively arcane corners of dependency resolution do not hamstring them in the midst of coding frenzies, I need a big-bang approach to front-load the repository. Basically, how can I minimize the pain when someone tries to use an already approved artifact in an unanticipated configuration? Incidentally, I have been happily experimenting with Nexus for a little while now. Good work. In short, two handy URLs: http://books.sonatype.com/nexus-book/reference/procure.html http://blogs.sonatype.com/people/2009/01/nexus-professional-what-is-procurement/ Hope helps, ~t~ On Sat, Jan 31, 2009 at 9:36 PM, Merv Green paradeofh...@gmail.com wrote: So, in my quest to take Maven completely internal, I'm still grappling with a couple of use cases: 1. Gathering plugin
Re: POM element orders
Thanks Justin, sounds reasonable... there are so many phases to choose from I guess the expanding of the package could very well be in the pre-package phase. @Brian.. That`s just it, when I put the assembly bits in the parent POM it is systematically executed before anything in the children`s POM. I would`ve expected the opposite thereby giving children the opportunity to complete and add to the parent`s actions. Unless I did not get it right. The only way I found (without resorting to other phases) was to copy the assembly part in the children at the end of their POM. I'll give the prior phase definition a try, no reason for it not to work, though I am still puzzled by this behavior, could be a bug but I think the most likely cause is something I do not get in the maven build pattern. when you say userbound and default, in the example above which is considered default ? and which is considered user bound ? also where on the net can I find a bit of help regarding all this ? I find maven really helpfull in many ways, but there is one thing I still find very hard is to reach easy to read and usefull documentation on the plugins, and on the many capabilities of Maven. It is easy inough to find trivial examples but I grew out of these quite fast. Is there anything akin to the Javadoc system that maven plungins be documented in ? Is there a repository of documenatation for plugins ? again, thanks Éric
How to override src/site for site doc inputs?
Does anybody know of a good place to put some free-form documentation files in the maven project/pom.xml? I know the default location appears to be src/site, but I overrode the default source location when creating our pom.xml (to minimize changes) to be src. Therefore, stuffing docs into the actual source code tree would be confusing (at best). I couldn't see where to configure an override for the site input in a pom.xml. Our project pom overrides are: ... build sourceDirectorysrc/sourceDirectory ... testSourceDirectorytest/testSourceDirectory ... Thanks, Dan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: POM element orders
Take a look at: http://www.sonatype.com/book and http://www.maven.apache.org/plugins/ -Original Message- From: Éric Daigneault [mailto:dai...@gmail.com] Sent: Sunday, February 01, 2009 8:35 PM To: Maven Users List Subject: Re: POM element orders Thanks Justin, sounds reasonable... there are so many phases to choose from I guess the expanding of the package could very well be in the pre-package phase. @Brian.. That`s just it, when I put the assembly bits in the parent POM it is systematically executed before anything in the children`s POM. I would`ve expected the opposite thereby giving children the opportunity to complete and add to the parent`s actions. Unless I did not get it right. The only way I found (without resorting to other phases) was to copy the assembly part in the children at the end of their POM. I'll give the prior phase definition a try, no reason for it not to work, though I am still puzzled by this behavior, could be a bug but I think the most likely cause is something I do not get in the maven build pattern. when you say userbound and default, in the example above which is considered default ? and which is considered user bound ? also where on the net can I find a bit of help regarding all this ? I find maven really helpfull in many ways, but there is one thing I still find very hard is to reach easy to read and usefull documentation on the plugins, and on the many capabilities of Maven. It is easy inough to find trivial examples but I grew out of these quite fast. Is there anything akin to the Javadoc system that maven plungins be documented in ? Is there a repository of documenatation for plugins ? again, thanks Éric
Re: RE: nexus can't find maven-archetype-plugin?
well, here's my settings.xml- couldn't send it earlier.
I'm just using the standard repositories which are configured in nexus.
Original-Nachricht
Datum: Thu, 29 Jan 2009 15:16:04 -0500
Von: Brian E. Fox bri...@reply.infinity.nu
An: Maven Users List users@maven.apache.org
Betreff: RE: nexus can\'t find maven-archetype-plugin?
Little hard to diagnose with that info. How is your settings.xml setup?
What repos are in your group? What exactly is maven saying (log)?
We have a nexus user list where your questions will be noticed quicker:
http://nexus.sonatype.org/dev/mailing-lists.html
-Original Message-
From: Jens Rapp [mailto:tec_la...@gmx.de]
Sent: Wednesday, January 28, 2009 4:17 AM
To: users@maven.apache.org
Subject: nexus can't find maven-archetype-plugin?
hi,
i'm playing around with nexus as repository manager and now have a little
problem: the maven-archetype-plugin can't be found. most of the other
plugins work
maven uses the standard public repository group in nexus.
what do i have to do for being able to use em all???
--
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger
-
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
--
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
!--
| This is the configuration file for Maven. It can be specified at two levels:
|
| 1. User Level. This settings.xml file provides configuration for a single user,
| and is normally provided in $HOME/.m2/settings.xml.
|
| NOTE: This location can be overridden with the system property:
|
| -Dorg.apache.maven.user-settings=/path/to/user/settings.xml
|
| 2. Global Level. This settings.xml file provides configuration for all maven
| users on a machine (assuming they're all using the same maven
| installation). It's normally provided in
| ${maven.home}/conf/settings.xml.
|
| NOTE: This location can be overridden with the system property:
|
| -Dorg.apache.maven.global-settings=/path/to/global/settings.xml
|
| The sections in this sample file are intended to give you a running start at
| getting the most out of your Maven installation. Where appropriate, the default
| values (values used when the setting is not specified) are provided.
|
|--
settings
!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ~/.m2/repository
localRepository/path/to/local/repo/localRepository
--
!-- interactiveMode
| This will determine whether maven prompts you when it needs input. If set to false,
| maven will use a sensible default value, perhaps based on some other setting, for
| the parameter in question.
|
| Default: true
interactiveModetrue/interactiveMode
--
!-- offline
| Determines whether maven should attempt to connect to the network when executing a build.
| This will have an effect on artifact downloads, artifact deployment, and others.
|
| Default: false
offlinefalse/offline
--
!-- proxies
| This is a list of proxies which can be used on this machine to connect to the network.
| Unless otherwise specified (by system property or command-line switch), the first proxy
| specification in this list marked as active will be used.
|--
proxies
!-- proxy
| Specification for one proxy, to be used in connecting to the network.
|
proxy
idoptional/id
activetrue/active
protocolhttp/protocol
usernameproxyuser/username
passwordproxypass/password
hostproxy.host.net/host
port80/port
nonProxyHostslocal.net,some.host.com/nonProxyHosts
Re: Which is the right findbugs plugin?
the one as sourceforge is for maven 1, the one at codehaus is for maven 2 -D On Sun, Feb 1, 2009 at 10:48 PM, Sahoo sa...@sun.com wrote: I see two findbugs plugins: maven-findbugs-plugin [1] and findbugs-maven-plugin [2]. Which one is recommended? Looking at the activity, I see [1] is not updated for a long time, so does it mean [2] is the one to use? Thanks, Sahoo [1] http://maven-plugins.sourceforge.net/maven-findbugs-plugin/index.html [2] http://mojo.codehaus.org/findbugs-maven-plugin/usage.html - 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
Which is the right findbugs plugin?
I see two findbugs plugins: maven-findbugs-plugin [1] and findbugs-maven-plugin [2]. Which one is recommended? Looking at the activity, I see [1] is not updated for a long time, so does it mean [2] is the one to use? Thanks, Sahoo [1] http://maven-plugins.sourceforge.net/maven-findbugs-plugin/index.html [2] http://mojo.codehaus.org/findbugs-maven-plugin/usage.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
