Re: String index out of range: -12 in ReleaseUtils.loadResolvedDependencies() when using Parent-Module-Layout
Hi, maven-release-plugin:2.4:prepare failed: String index out of range: -12 at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:225) *snip* Have you tried running mvn -e -X ...? Perhaps there's something missing in your pom.xml, such as an invalid property that is referenced somewhere, an empty or missing plugin configuration section etc.pp. HTH Thorsten
Re: maven-nar-plugin (version?)
I assume you are renaming it to nar-maven-plugin To remove the confusion and clarify that this is not a plugin originating from the maven project -Stephen On Friday, 18 January 2013, Tim Astle wrote: Thanks for the clarification. I posted to this mailing list because that's what is listed on the maven-nar-plugin site. http://duns.github.com/maven-**nar-plugin/mail-lists.htmlhttp://duns.github.com/maven-nar-plugin/mail-lists.html Can that be updated as well? Is this the correct issue tracker: http://duns.github.com/maven-** nar-plugin/mail-lists.htmlhttp://duns.github.com/maven-nar-plugin/mail-lists.html FYI, I subscribed to the google mailing list. Certainly don't mind assisting in the project. Tim On 1/16/2013 4:17 PM, Curtis Rueden wrote: Hi all, We are still unifying the various forks of maven-nar-plugin, so there is no new official release version yet. The maven-nar mailing list is at: https://groups.google.com/**forum/?fromgroups#!forum/**maven-narhttps://groups.google.com/forum/?fromgroups#!forum/maven-nar It seems that all of the involved people are very busy, so progress is rather slow. We welcome any additional help! To avoid confusion, I updated the project readme (at https://github.com/maven-nar/**maven-nar-pluginhttps://github.com/maven-nar/maven-nar-plugin) to reflect the current project status and links, including a link to the mailing list. Regards, Curtis On Wed, Jan 16, 2013 at 8:53 AM, Mark Donszelmann mark.donszelm...@gmail.com wrote: Hi I wrote the NAR plugin, but have no longer time to maintain it. I donated it (with approval of Sonatype) to a bunch of people who would like to maintain it. Its under https://github.com/maven-nar I guess with mailing lists and doc Regards Mark Donszelmann (duns) On Jan 16, 2013, at 3:44 PM, Wayne Fay wayne...@gmail.com wrote: Nar is not a product of the Maven PMC, and so will never be an official org.apache.maven.plugin anything. Right, but whose product is it today and how do we find the latest official release? The groupId suggests that would be codeswarm.org. But there may be other parties who have their own branches etc. Wayne --**--** - 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: updatePolicyalways/updatePolicy not working for releases with Maven 3.0.4
Hi,
Maven User wrote:
We produce a large application from the artifacts of 15+ components, many
which contain multiple modules. The version numbers are all the same, and
a build cycle takes about four hours.
Late in a development cycle we run numbered (i.e. non “-SNAPSHOT”) builds
in continuous integration mode. Doing so facilitates quicker turnaround
times of last minute bugs. Once a package is actually delivered to QA we
return to producing -SNAPSHOT artifacts.
What does that mean in real?
We are aware re-producing numbered artifacts is not a best practice. Part
of the reason we felt like running a numbered build in CI mode would work
is the “update policy” option which is available for releases. See
http://maven.apache.org/ref/3.0.4/maven-settings/settings.html. By our
reading, this setting should enable the updating of numbered artifacts in
the local Maven cache with a newer version from the central repository (we
are using Artifactory Pro 2.5.1).
Instead, we observe this behavior:
Starting from an empty local Maven cache, the build of component #2 works
as designed.
However, after component #1 is rebuilt, a rebuild of component #2, which
is dependent on the jar file produced by the build of component #1, the
execution of “mvn –U clean deploy” fails to update the recently modified
numbered artifact in the local Maven cache.
The routine below is part of ${MAVEN_HOME}/conf/settings.xml:
profiles
profile
idRepositories/id
activation
activeByDefaulttrue/activeByDefault
/activation
repositories
repository
idArtifactory/id
nameArtifactory Public Mirror/name
urlhttp://machine.domain.com:8082/artifactory/repo/url
layoutdefault/layout
releases
enabledtrue/enabled
updatePolicyalways/updatePolicy
A release is a release i.e. a unique artifact. There will be no updates. You
may set this as well to none.
/releases
snapshots
enabledtrue/enabled
updatePolicyalways/updatePolicy
/snapshots
/repository
/repositories
/profile
/profiles
Does anyone have any insight into why the local Maven cache is not being
updated with the newer numbered artifacts from our Artifactory repository?
Depends on your real numbering scheme. E.g. as Maven n00bs we tried once a
development scheme like
1.0-SNAPSHOT -- 1.0.0 -- 1.0-SNAPSHOT -- 1.0.1 -- 1.0-SNAPSHOT
This fails miserably, because 1.0-SNAPHSOT is the equivalent of 1.0.0-
SNAPSHOT and therefore the SNAPSHOT is always considered to be of a lesser
number than any release.
See, what I mean?
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: updatePolicyalways/updatePolicy not working for releases with Maven 3.0.4
On Friday, 18 January 2013, Maven User 3150...@gmail.com wrote:
We produce a large application from the artifacts of 15+ components, many
which contain multiple modules. The version numbers are all the same, and
a build cycle takes about four hours.
Late in a development cycle we run numbered (i.e. non “-SNAPSHOT”) builds
in continuous integration mode. Doing so facilitates quicker turnaround
times of last minute bugs. Once a package is actually delivered to QA we
return to producing -SNAPSHOT artifacts.
We are aware re-producing numbered artifacts is not a best practice. Part
of the reason we felt like running a numbered build in CI mode would work
is the “update policy” option which is available for releases.
At first you think that it is a great pity that, at the time, the same
object was reused for the releases as we'll as snapshots properties.
and you think that by rights the snapshots property should be a
subtype of the releases property as it just causes confusion on the half
of users...
However what this actually refers to is the update policy *of the metadata
sourced from the release repository*
Thus when you have a version range (which turn out to be a bad plan) an
update policy of always means it will re-check the metadata to see if there
are any new versions which might affect the range resolution.
Release versions are *never* re-downloaded... But there are other files in
a release repo which do change (metadata) and that is what the policy
refers to
HTH
-Stephen
See
http://maven.apache.org/ref/3.0.4/maven-settings/settings.html. By our
reading, this setting should enable the updating of numbered artifacts in
the local Maven cache with a newer version from the central repository (we
are using Artifactory Pro 2.5.1).
Instead, we observe this behavior:
Starting from an empty local Maven cache, the build of component #2 works
as designed.
However, after component #1 is rebuilt, a rebuild of component #2, which is
dependent on the jar file produced by the build of component #1, the
execution of “mvn –U clean deploy” fails to update the recently modified
numbered artifact in the local Maven cache.
The routine below is part of ${MAVEN_HOME}/conf/settings.xml:
profiles
profile
idRepositories/id
activation
activeByDefaulttrue/activeByDefault
/activation
repositories
repository
idArtifactory/id
nameArtifactory Public Mirror/name
urlhttp://machine.domain.com:8082/artifactory/repo
/url
layoutdefault/layout
releases
enabledtrue/enabled
updatePolicyalways/updatePolicy
/releases
snapshots
enabledtrue/enabled
updatePolicyalways/updatePolicy
/snapshots
/repository
/repositories
/profile
/profiles
Does anyone have any insight into why the local Maven cache is not being
updated with the newer numbered artifacts from our Artifactory repository?
Re: Packaging up pre-existing jar and source jar
Am 17.01.2013 23:17, schrieb Stephen Connolly: First, when you are playing with install:install-file you will find that you regularly need to blow away your local cache (which is the real name of the local repository)... Turned out I'm not really installing to .m2/repository, but to something that m2eclipse calls Workspace Projects. This has been working well, so I hope I can stick with that. Seems like that local repository terminology had me confused. What about changing the docs so that they don't say local repository but repository cache? That would spare future maven newbies that confusions. The paragraph that introduces it can explain that it's technically just a normal repository, but that you shouldn't do anything with it but occasionally clean out old cruft (or whatever it is that's okay to do with the local repository cache). Second, repository routing... the killer feature of MRMs. Not everything is in central. There's the world of crazyness that is the redhat repos, the old java.net repos, the pile of people who have yet to get why you should push your stuff to central, or who think pushing to central is hard... and then you end up with a pom from one repo and an artifact from another... and the transitive deps are wrong because the poms are different. An MRM allows you to specify exactly what artifacts can be sourced from which repositories and also gives you a single flat repository for maven to pull from... Okay, this hasn't been an issue yet but I'll keep that in mind. Most of the MRMs are trivial to set up and give you a reliable store to cache in front of you. The issue being, this is another potential point of failure that I'll have to check if something goes wrong. So I'll want to postpone this until I'm familiar with the rest of the toolchain, getting that all to work hasn't been easy and I probably haven't seen all failure modes yet. Third, performance. When you list multiple repository in your pom or settings.xml you force artifact resolution to hit ALL of them. with an MRM you set mirrorOf*/mirrorOf and you now only hit one, it's local anyway, it's flattened (because it's a virtual repo) and you have a fast reliable build and you can scale it out to others. I supposes the m2eclipse repository manager does that already. It is hitting Maven Central on Eclipse startup, once (and takes minutes to complete). I think it allows building right away, so I'm probably fine. I can see that building from the command line might suck, because that won't have the m2eclipse Workspace Repositories ... erm, what's an MRM? A Maven Repository Manager? There's more reasons if you feel you still want some... I'd love to, but only if they are relevant. I have yet to look up what exactly the m2eclipse Workspace Projects thing is. Eclipse lists it in the Maven Repositories tab. Thanks for taking the effort to respond after my rant. Regards, Jo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Packaging up pre-existing jar and source jar
On 18 January 2013 09:35, Joachim Durchholz j...@durchholz.org wrote: Am 17.01.2013 23:17, schrieb Stephen Connolly: First, when you are playing with install:install-file you will find that you regularly need to blow away your local cache (which is the real name of the local repository)... Turned out I'm not really installing to .m2/repository, but to something that m2eclipse calls Workspace Projects. This has been working well, so I hope I can stick with that. Seems like that local repository terminology had me confused. What about changing the docs so that they don't say local repository but repository cache? That would spare future maven newbies that confusions. The paragraph that introduces it can explain that it's technically just a normal repository, but that you shouldn't do anything with it but occasionally clean out old cruft (or whatever it is that's okay to do with the local repository cache). Second, repository routing... the killer feature of MRMs. Not everything is in central. There's the world of crazyness that is the redhat repos, the old java.net repos, the pile of people who have yet to get why you should push your stuff to central, or who think pushing to central is hard... and then you end up with a pom from one repo and an artifact from another... and the transitive deps are wrong because the poms are different. An MRM allows you to specify exactly what artifacts can be sourced from which repositories and also gives you a single flat repository for maven to pull from... Okay, this hasn't been an issue yet but I'll keep that in mind. Most of the MRMs are trivial to set up and give you a reliable store to cache in front of you. The issue being, this is another potential point of failure that I'll have to check if something goes wrong. So I'll want to postpone this until I'm familiar with the rest of the toolchain, getting that all to work hasn't been easy and I probably haven't seen all failure modes yet. Run the MRM on your own machine. There is one MRM that claims to run in like JVM overhead + 64MB of RAM and consumes very few CPU resources (hint the company that makes it rhymes with Pony tripe and they have an OSS version, which is fine for your needs) I actually used to do this myself at my previous employers for when I needed to work from home. I would run all my builds through that. When I was commuting to and from work I could still work away, and when at home I didn't need to fire up the VPN to build. It made my on-line/off-line experience seamless. The other MRMs can provide the same experience, I just don't know how low you can push the memory usage of them and still have a functioning MRM. My point is, you think adding a MRM is adding a point of failure... actually it's taking away about 3-4 points of failure, so NET GAIN in reliability. Third, performance. When you list multiple repository in your pom or settings.xml you force artifact resolution to hit ALL of them. with an MRM you set mirrorOf*/mirrorOf and you now only hit one, it's local anyway, it's flattened (because it's a virtual repo) and you have a fast reliable build and you can scale it out to others. I supposes the m2eclipse repository manager does that already. It is hitting Maven Central on Eclipse startup, once (and takes minutes to complete). With an MRM this would be seconds not minutes I think it allows building right away, so I'm probably fine. I can see that building from the command line might suck, because that won't have the m2eclipse Workspace Repositories That, and I don't use eclipse, is just building a reactor out of all the projects in your workspace which is handy, but will cause issues for you. ... erm, what's an MRM? A Maven Repository Manager? Yes There's more reasons if you feel you still want some... I'd love to, but only if they are relevant. I have yet to look up what exactly the m2eclipse Workspace Projects thing is. Eclipse lists it in the Maven Repositories tab. If you are really trying to grok what maven is doing, forget eclipse, start from the CLI. Eclipse does all sorts of magic to try and protect you from people who don't grok Maven and set up insane builds. That's what an IDE should do, but for an engineer trying to grok what Maven is doing, you got to go back to vi and CLI... otherwise you are dealing with Magic and we have to resort to chants of Follow the Maven way and just because if we are dealing with somebody using Magic Thanks for taking the effort to respond after my rant. Our issue is we see this *every day*, so our short cut is to tell people: learn from us, this is the way to do it. Regards, Jo --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven copy-dependencies and excluding transitively
Hi. I'm using the Maven Dependency Plugin with the goal copy-dependencies. I would like to do the following: - Copy all transitive dependencies with the scope runtime to the target dir - exclude specific group ids *including their* transitive dependencies from that list I tried: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.6/version executions execution idcopy-dependencies/id phasepackage/phase goals goalcopy-dependencies/goal /goals configuration includeScoperuntime/includeScope excludeGroupIdsA,B/excludeGroupIds /configuration /execution /executions /plugin But that leaves all transient dependecies of A and B in the target dir. I also tried excludeTransitivetrue/excludeTransitive But that excludes *all* transitive deps - not only for A and B. That leaves only direct deps in the target dir. Is there any way to achieve what I want *without* specifying each transitive dependency (and theirs) manually via excludeGroupIds? Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-Module: How to download other project's as dependency's without build it locally
I'm not entirely sure, but I think that you might be looking for the copy goal in the Maven dependency plugin. https://maven.apache.org/plugins/maven-dependency-plugin/ On Thu, Jan 17, 2013 at 2:48 PM, daniel.todt danielt...@gmail.com wrote: Greetings, folks. My English is poor, so I apologize for possible errors. I have a multi-module environment like below, on a *Jboss server* using *Archiva* as Maven Repository Manager, *Jenkins* as CI and *Git* as Source Manager. When I run the Project C, I need both the Project B (projectb.jar) and Project C (projectc.war) into $JBOSS_HOME/Deployments and the Project A, need's to be into $JBOSS_HOME/Modules path. This solution already work. I just need to build every project, and put all in the right place, and it's done. The problem is, the front-end developer do not work on back-end developer's project neither on lib developer's project, so it's not in his Workspace, like this: Workflow: When the lib developer finish his work, he commit's on Git and run Jenkins, then the Project A is now updated on Archiva. When the back-end developer builds the Project B, Maven automatically download Project A's information (projecta.jar, projecta.pom, etc) but do not download the projecta-jar-with-dependencies.jar. When the back-end developer finish his work, he commit's on Git and run Jenkins, then the Project B is now updated on Archiva. When the front-end developer builds the Project C, Maven automatically download Project B's information (projectb.jar, projectb.pom, projecta.jar, projecta.pom, etc) but do not download the projecta-jar-with-dependencies.jar. 1) Is that so hard or bad practice, that I cant not find any implementation like that? 2) How can I (during build or after) of the Project C, update / download his dependencies (projecta-jar-with-dependencies.jar and projectb.jar) and put all in it's right place? 3) Without using ear or osgi, is there any other best practice of this? -- View this message in context: http://maven.40175.n5.nabble.com/Multi-Module-How-to-download-other-project-s-as-dependency-s-without-build-it-locally-tp5743668.html Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Maven copy-dependencies and excluding transitively
http://blog.artifact-software.com/tech/?p=121 Is that what you are trying to do? Ron On 18/01/2013 8:15 AM, Veit Guna wrote: Hi. I'm using the Maven Dependency Plugin with the goal copy-dependencies. I would like to do the following: - Copy all transitive dependencies with the scope runtime to the target dir - exclude specific group ids *including their* transitive dependencies from that list I tried: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.6/version executions execution idcopy-dependencies/id phasepackage/phase goals goalcopy-dependencies/goal /goals configuration includeScoperuntime/includeScope excludeGroupIdsA,B/excludeGroupIds /configuration /execution /executions /plugin But that leaves all transient dependecies of A and B in the target dir. I also tried excludeTransitivetrue/excludeTransitive But that excludes *all* transitive deps - not only for A and B. That leaves only direct deps in the target dir. Is there any way to achieve what I want *without* specifying each transitive dependency (and theirs) manually via excludeGroupIds? Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Stephen has laid out the case very well. Had I remembered that I wrote this, I should have referred you to http://blog.artifact-software.com/tech/?p=177 We had pretty good success starting in Eclipse and once we moved to Eclipse/STS and got our Nexus repo in place, we were in Maven heaven. We had a small team with never more that 5 people but we built and maintained an entire LMS with over 70 Maven projects producing over 60 war files. I spite of starting out in this business long before GUIs were available outside Xerox, I prefer to use a GUI when I can. If you have a look at the articles tagged with Maven you will find some things that we learned that seemed to help in various aspects of development with Maven. Ron On 18/01/2013 5:07 AM, Stephen Connolly wrote: On 18 January 2013 09:35, Joachim Durchholz j...@durchholz.org wrote: Am 17.01.2013 23:17, schrieb Stephen Connolly: First, when you are playing with install:install-file you will find that you regularly need to blow away your local cache (which is the real name of the local repository)... Turned out I'm not really installing to .m2/repository, but to something that m2eclipse calls Workspace Projects. This has been working well, so I hope I can stick with that. Seems like that local repository terminology had me confused. What about changing the docs so that they don't say local repository but repository cache? That would spare future maven newbies that confusions. The paragraph that introduces it can explain that it's technically just a normal repository, but that you shouldn't do anything with it but occasionally clean out old cruft (or whatever it is that's okay to do with the local repository cache). Second, repository routing... the killer feature of MRMs. Not everything is in central. There's the world of crazyness that is the redhat repos, the old java.net repos, the pile of people who have yet to get why you should push your stuff to central, or who think pushing to central is hard... and then you end up with a pom from one repo and an artifact from another... and the transitive deps are wrong because the poms are different. An MRM allows you to specify exactly what artifacts can be sourced from which repositories and also gives you a single flat repository for maven to pull from... Okay, this hasn't been an issue yet but I'll keep that in mind. Most of the MRMs are trivial to set up and give you a reliable store to cache in front of you. The issue being, this is another potential point of failure that I'll have to check if something goes wrong. So I'll want to postpone this until I'm familiar with the rest of the toolchain, getting that all to work hasn't been easy and I probably haven't seen all failure modes yet. Run the MRM on your own machine. There is one MRM that claims to run in like JVM overhead + 64MB of RAM and consumes very few CPU resources (hint the company that makes it rhymes with Pony tripe and they have an OSS version, which is fine for your needs) I actually used to do this myself at my previous employers for when I needed to work from home. I would run all my builds through that. When I was commuting to and from work I could still work away, and when at home I didn't need to fire up the VPN to build. It made my on-line/off-line experience seamless. The other MRMs can provide the same experience, I just don't know how low you can push the memory usage of them and still have a functioning MRM. My point is, you think adding a MRM is adding a point of failure... actually it's taking away about 3-4 points of failure, so NET GAIN in reliability. Third, performance. When you list multiple repository in your pom or settings.xml you force artifact resolution to hit ALL of them. with an MRM you set mirrorOf*/mirrorOf and you now only hit one, it's local anyway, it's flattened (because it's a virtual repo) and you have a fast reliable build and you can scale it out to others. I supposes the m2eclipse repository manager does that already. It is hitting Maven Central on Eclipse startup, once (and takes minutes to complete). With an MRM this would be seconds not minutes I think it allows building right away, so I'm probably fine. I can see that building from the command line might suck, because that won't have the m2eclipse Workspace Repositories That, and I don't use eclipse, is just building a reactor out of all the projects in your workspace which is handy, but will cause issues for you. ... erm, what's an MRM? A Maven Repository Manager? Yes There's more reasons if you feel you still want some... I'd love to, but only if they are relevant. I have yet to look up what exactly the m2eclipse Workspace Projects thing is. Eclipse lists it in the Maven Repositories tab. If you are really trying to grok what maven is doing, forget eclipse, start from the CLI. Eclipse does all sorts of magic to try and protect you from people who don't grok Maven and set up insane
Re: String index out of range: -12 in ReleaseUtils.loadResolvedDependencies() when using Parent-Module-Layout
http://maven.apache.org/maven-release/maven-release-manager/xref/org/apache/maven/shared/release/config/ReleaseUtils.html#256 I'm interested in your release.properties as well. It looks like there's a property starting with 'dependency.' which doesn't end with '.development' or '.release' This should not be possible. thanks, Robert Op Fri, 18 Jan 2013 09:11:39 +0100 schreef thorsten.h...@vkb.de: Hi, maven-release-plugin:2.4:prepare failed: String index out of range: -12 at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:225) *snip* Have you tried running mvn -e -X ...? Perhaps there's something missing in your pom.xml, such as an invalid property that is referenced somewhere, an empty or missing plugin configuration section etc.pp. HTH Thorsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using maven properties inside .java inside annotation in a clean way
I tried to subscribe and write many times to mojo-dev without much luck. This might be a PEBKAC issue, but at least xircles seems to confirm I'm subscribed, but I won't receive any mail and be able to post there. Is there any current known issue on mojo-dev? Thanks a lot. 2013/1/17 Baptiste MATHUS bmat...@batmat.net Nope, not yet. But I didn't submit much work today. But that could push me to finally move my arse a bit more about it. Thanks! 2013/1/17 Stephen Connolly stephen.alan.conno...@gmail.com Have you got commit for mojo? if not I will start a vote... you've been knocking around long enough! On 17 January 2013 10:28, Baptiste MATHUS bmat...@batmat.net wrote: 2013/1/17 Stephen Connolly stephen.alan.conno...@gmail.com src/main/java-template Yop, I think you're right, I was already considering writing a dedicated plugin. That's actually something a lot of people needs and the various solutions around the web always require something like 30+ lines of pom magic. Recommending people to use .properties file is good for other cases, but it's just impossible. So, I guess I should start a thread on mojo-dev about that. Thanks all. -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;!
Re: Using maven properties inside .java inside annotation in a clean way
Very strange... On Friday, 18 January 2013, Baptiste MATHUS wrote: I tried to subscribe and write many times to mojo-dev without much luck. This might be a PEBKAC issue, but at least xircles seems to confirm I'm subscribed, but I won't receive any mail and be able to post there. Is there any current known issue on mojo-dev? Thanks a lot. 2013/1/17 Baptiste MATHUS bmat...@batmat.net javascript:; Nope, not yet. But I didn't submit much work today. But that could push me to finally move my arse a bit more about it. Thanks! 2013/1/17 Stephen Connolly stephen.alan.conno...@gmail.comjavascript:; Have you got commit for mojo? if not I will start a vote... you've been knocking around long enough! On 17 January 2013 10:28, Baptiste MATHUS bmat...@batmat.netjavascript:; wrote: 2013/1/17 Stephen Connolly stephen.alan.conno...@gmail.comjavascript:; src/main/java-template Yop, I think you're right, I was already considering writing a dedicated plugin. That's actually something a lot of people needs and the various solutions around the web always require something like 30+ lines of pom magic. Recommending people to use .properties file is good for other cases, but it's just impossible. So, I guess I should start a thread on mojo-dev about that. Thanks all. -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;!
Re: updatePolicyalways/updatePolicy not working for releases with Maven 3.0.4
Version 1.0 is not newer than version 1.0.
No need to download a new copy since there is not one any newer than 1.0
which it already has.
You probably should go to SNAPSHOTs and try to find a way to release in
stages- low level code should be able to be tested and released without
releasing the high level stuff.
It requires a bit more discipline in the development cycle and a
willingness to admit to testing errors which require manual deletion of
artifacts that get released before all the bugs are out.
On the bright side:
It is kind of motivating (at least to the project manager) to be able to
say that you have released 10 of the 15+ components and only have 5+ to
go before the release is done.
It also makes everyone aware of the importance on interface
specifications and the need to test at the component level.
It also makes programmers stand behind their work and give an implied
warranty to their colleagues with each new SNAPSHOT and release.
Ron
On 18/01/2013 3:22 AM, Jörg Schaible wrote:
Hi,
Maven User wrote:
We produce a large application from the artifacts of 15+ components, many
which contain multiple modules. The version numbers are all the same, and
a build cycle takes about four hours.
Late in a development cycle we run numbered (i.e. non “-SNAPSHOT”) builds
in continuous integration mode. Doing so facilitates quicker turnaround
times of last minute bugs. Once a package is actually delivered to QA we
return to producing -SNAPSHOT artifacts.
What does that mean in real?
We are aware re-producing numbered artifacts is not a best practice. Part
of the reason we felt like running a numbered build in CI mode would work
is the “update policy” option which is available for releases. See
http://maven.apache.org/ref/3.0.4/maven-settings/settings.html. By our
reading, this setting should enable the updating of numbered artifacts in
the local Maven cache with a newer version from the central repository (we
are using Artifactory Pro 2.5.1).
Instead, we observe this behavior:
Starting from an empty local Maven cache, the build of component #2 works
as designed.
However, after component #1 is rebuilt, a rebuild of component #2, which
is dependent on the jar file produced by the build of component #1, the
execution of “mvn –U clean deploy” fails to update the recently modified
numbered artifact in the local Maven cache.
The routine below is part of ${MAVEN_HOME}/conf/settings.xml:
profiles
profile
idRepositories/id
activation
activeByDefaulttrue/activeByDefault
/activation
repositories
repository
idArtifactory/id
nameArtifactory Public Mirror/name
urlhttp://machine.domain.com:8082/artifactory/repo/url
layoutdefault/layout
releases
enabledtrue/enabled
updatePolicyalways/updatePolicy
A release is a release i.e. a unique artifact. There will be no updates. You
may set this as well to none.
/releases
snapshots
enabledtrue/enabled
updatePolicyalways/updatePolicy
/snapshots
/repository
/repositories
/profile
/profiles
Does anyone have any insight into why the local Maven cache is not being
updated with the newer numbered artifacts from our Artifactory repository?
Depends on your real numbering scheme. E.g. as Maven n00bs we tried once a
development scheme like
1.0-SNAPSHOT -- 1.0.0 -- 1.0-SNAPSHOT -- 1.0.1 -- 1.0-SNAPSHOT
This fails miserably, because 1.0-SNAPHSOT is the equivalent of 1.0.0-
SNAPSHOT and therefore the SNAPSHOT is always considered to be of a lesser
number than any release.
See, what I mean?
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Using maven properties inside .java inside annotation in a clean way
Have you created a full account on xircles... I cannot find you in it On Friday, 18 January 2013, Stephen Connolly wrote: Very strange... On Friday, 18 January 2013, Baptiste MATHUS wrote: I tried to subscribe and write many times to mojo-dev without much luck. This might be a PEBKAC issue, but at least xircles seems to confirm I'm subscribed, but I won't receive any mail and be able to post there. Is there any current known issue on mojo-dev? Thanks a lot. 2013/1/17 Baptiste MATHUS bmat...@batmat.net Nope, not yet. But I didn't submit much work today. But that could push me to finally move my arse a bit more about it. Thanks! 2013/1/17 Stephen Connolly stephen.alan.conno...@gmail.com Have you got commit for mojo? if not I will start a vote... you've been knocking around long enough! On 17 January 2013 10:28, Baptiste MATHUS bmat...@batmat.net wrote: 2013/1/17 Stephen Connolly stephen.alan.conno...@gmail.com src/main/java-template Yop, I think you're right, I was already considering writing a dedicated plugin. That's actually something a lot of people needs and the various solutions around the web always require something like 30+ lines of pom magic. Recommending people to use .properties file is good for other cases, but it's just impossible. So, I guess I should start a thread on mojo-dev about that. Thanks all. -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;!
Re: Maven copy-dependencies and excluding transitively
Not really, no :). If I read the article correctly, it describes how to merge n jar's into one. I just need to copy them to a specific location. Original-Nachricht Datum: Fri, 18 Jan 2013 08:50:36 -0500 Von: Ron Wheeler rwhee...@artifact-software.com An: users@maven.apache.org Betreff: Re: Maven copy-dependencies and excluding transitively http://blog.artifact-software.com/tech/?p=121 Is that what you are trying to do? Ron On 18/01/2013 8:15 AM, Veit Guna wrote: Hi. I'm using the Maven Dependency Plugin with the goal copy-dependencies. I would like to do the following: - Copy all transitive dependencies with the scope runtime to the target dir - exclude specific group ids *including their* transitive dependencies from that list I tried: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.6/version executions execution idcopy-dependencies/id phasepackage/phase goals goalcopy-dependencies/goal /goals configuration includeScoperuntime/includeScope excludeGroupIdsA,B/excludeGroupIds /configuration /execution /executions /plugin But that leaves all transient dependecies of A and B in the target dir. I also tried excludeTransitivetrue/excludeTransitive But that excludes *all* transitive deps - not only for A and B. That leaves only direct deps in the target dir. Is there any way to achieve what I want *without* specifying each transitive dependency (and theirs) manually via excludeGroupIds? Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - 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:updatePolicyalways/updatePolicy not working for releases with Maven 3.0.4
Thank you for the information - we will make appropriate adjustments to our approach. I believe it would be helpful to make it more obvious in the documentation that updatePolicy for releases only refers to the artifact metadata, and release versions are *never* re-downloaded (which is VERY easy to understand). In their current form, the updatePolicy section in http://maven.apache.org/ref/3.0.4/maven-settings/settings.html and Maven help for the -U option can easily be interpreted to mean Maven is capable of updating release artifacts in the local cache. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Friday, January 18, 2013 3:35 AM To: Maven Users List Subject: Re: updatePolicyalways/updatePolicy not working for releases with Maven 3.0.4 On Friday, 18 January 2013, Maven User 3150...@gmail.com wrote: We produce a large application from the artifacts of 15+ components, many which contain multiple modules. The version numbers are all the same, and a build cycle takes about four hours. Late in a development cycle we run numbered (i.e. non -SNAPSHOT) builds in continuous integration mode. Doing so facilitates quicker turnaround times of last minute bugs. Once a package is actually delivered to QA we return to producing -SNAPSHOT artifacts. We are aware re-producing numbered artifacts is not a best practice. Part of the reason we felt like running a numbered build in CI mode would work is the update policy option which is available for releases. At first you think that it is a great pity that, at the time, the same object was reused for the releases as we'll as snapshots properties. and you think that by rights the snapshots property should be a subtype of the releases property as it just causes confusion on the half of users... However what this actually refers to is the update policy *of the metadata sourced from the release repository* Thus when you have a version range (which turn out to be a bad plan) an update policy of always means it will re-check the metadata to see if there are any new versions which might affect the range resolution. Release versions are *never* re-downloaded... But there are other files in a release repo which do change (metadata) and that is what the policy refers to HTH -Stephen
Re: String index out of range: -12 in ReleaseUtils.loadResolvedDependencies() when using Parent-Module-Layout
Looks like a section of code that could benefit from some debug-level logging. Then OP could just turn on -X and send us more useful output. Wayne On Fri, Jan 18, 2013 at 8:26 AM, Robert Scholte rfscho...@apache.org wrote: http://maven.apache.org/maven-release/maven-release-manager/xref/org/apache/maven/shared/release/config/ReleaseUtils.html#256 I'm interested in your release.properties as well. It looks like there's a property starting with 'dependency.' which doesn't end with '.development' or '.release' This should not be possible. thanks, Robert Op Fri, 18 Jan 2013 09:11:39 +0100 schreef thorsten.h...@vkb.de: Hi, maven-release-plugin:2.4:prepare failed: String index out of range: -12 at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:225) *snip* Have you tried running mvn -e -X ...? Perhaps there's something missing in your pom.xml, such as an invalid property that is referenced somewhere, an empty or missing plugin configuration section etc.pp. HTH Thorsten - 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 get Maven's own version into an artifact?
There's a desire for our product to be able to say, at runtime, what version of Maven was used to build it. Somewhat surprisingly I wasn't able to find a predefined property holding this information. There *is* a class one can instantiate which offers a method to return that information, but before I go writing up a whole plugin just for this little thing, I thought I should ask if there's an easier way that I missed. Ultimately I will likely filter the value into a Properties-formatted file to be loaded at need. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu There's an app for that: your browser pgpKqN7rEoTtB.pgp Description: PGP signature
Re: How to get Maven's own version into an artifact?
Last version of jar plugin should add an entry in MANIFEST
with Created-By: Apache Maven ${maven.version}
2013/1/18 Mark H. Wood mw...@iupui.edu:
There's a desire for our product to be able to say, at runtime, what
version of Maven was used to build it. Somewhat surprisingly I wasn't
able to find a predefined property holding this information.
There *is* a class one can instantiate which offers a method to return
that information, but before I go writing up a whole plugin just for
this little thing, I thought I should ask if there's an easier way
that I missed.
Ultimately I will likely filter the value into a Properties-formatted
file to be loaded at need.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
There's an app for that: your browser
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to get Maven's own version into an artifact?
This requires Maven 3.0.4+.
/Anders
On Fri, Jan 18, 2013 at 5:52 PM, Olivier Lamy ol...@apache.org wrote:
Last version of jar plugin should add an entry in MANIFEST
with Created-By: Apache Maven ${maven.version}
2013/1/18 Mark H. Wood mw...@iupui.edu:
There's a desire for our product to be able to say, at runtime, what
version of Maven was used to build it. Somewhat surprisingly I wasn't
able to find a predefined property holding this information.
There *is* a class one can instantiate which offers a method to return
that information, but before I go writing up a whole plugin just for
this little thing, I thought I should ask if there's an easier way
that I missed.
Ultimately I will likely filter the value into a Properties-formatted
file to be loaded at need.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
There's an app for that: your browser
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to get Maven's own version into an artifact?
If it works, go for Olivier'd answer.
If for whatever reason you can't upgrade jar plugin or read the manifest,
there's also a goal in build-helper-maven-plugin (currently offline and
dont remember the name) that will create a runtime property you can use
wherever you want.
Cheers
Le 18 janv. 2013 17:53, Olivier Lamy ol...@apache.org a écrit :
Last version of jar plugin should add an entry in MANIFEST
with Created-By: Apache Maven ${maven.version}
2013/1/18 Mark H. Wood mw...@iupui.edu:
There's a desire for our product to be able to say, at runtime, what
version of Maven was used to build it. Somewhat surprisingly I wasn't
able to find a predefined property holding this information.
There *is* a class one can instantiate which offers a method to return
that information, but before I go writing up a whole plugin just for
this little thing, I thought I should ask if there's an easier way
that I missed.
Ultimately I will likely filter the value into a Properties-formatted
file to be loaded at need.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
There's an app for that: your browser
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Am 18.01.2013 11:07, schrieb Stephen Connolly: My point is, you think adding a MRM is adding a point of failure... actually it's taking away about 3-4 points of failure, so NET GAIN in reliability. Well, right now, everything is bootstrapping nicely from a Bitbucket repository. I'm using Maven as a build tool. Dependency consolidation is via Bitbucket, so that part of MRM functionality isn't very relevant to me. Third, performance. When you list multiple repository in your pom or settings.xml you force artifact resolution to hit ALL of them. with an MRM you set mirrorOf*/mirrorOf and you now only hit one, it's local anyway, it's flattened (because it's a virtual repo) and you have a fast reliable build and you can scale it out to others. I supposes the m2eclipse repository manager does that already. It is hitting Maven Central on Eclipse startup, once (and takes minutes to complete). With an MRM this would be seconds not minutes Yep, it would be the MRM waiting for the repo information and not Eclipse :-) It looks like m2e is doing the proxying already, so that part of an MRM isn't relevant either. I can see that building from the command line might suck, because that won't have the m2eclipse Workspace Repositories That, and I don't use eclipse, is just building a reactor out of all the projects in your workspace which is handy, but will cause issues for you. Not sure what kinds of issues these might be. If you are really trying to grok what maven is doing, forget eclipse, start from the CLI. Eclipse does all sorts of magic to try and protect you from people who don't grok Maven and set up insane builds. Oh, I don't think it's so hard. I'm avoiding the pom wizards (don't give me any value anymore), and I'm editing the poms in the XML editor. That's what an IDE should do, but for an engineer trying to grok what Maven is doing, you got to go back to vi and CLI... otherwise you are dealing with Magic Not much magic seems to be left with that. I'm starting the builds through a Maven launch configuration. That's essentially the command line. The only magic thing that happens is that I can have multiple projects open, modify code in any of them, and debug the whole system without having to mvn install. If that should fail - well, the launch configuration for mvn install is just a mouse click away. Our issue is we see this *every day*, so our short cut is to tell people: learn from us, this is the way to do it. It would probably be easier if the online docs were better indexed. I mean, the Documentation link on http://eclipse.org/m2e/ leads to http://eclipse.org/m2e/documentation/, which has a single link to http://wiki.eclipse.org/Maven_Integration, which is essentially just a blurb and installation instructions, but no documentation on what it actually does (what you referred to as magic above). The info on, for example, the items in the Maven repositories tab is available, but you need to ask Google, it's not linked from the pages. There are more problems like that: The Maven documentation site (http://maven.apache.org/users/index.html) contains links to tutorials, to the POM and Settings references - but no link to http://maven.apache.org/guides/index.html . The list of standard plugins is under Maven Projects. I ignored that section because, you see, a project is something that you contribute to; that section should be labelled Maven Usage or something. Plugin descriptions abound with terminology but lack links to the explanations of that terminology. Sample excerpts from pom files do not highlight those parts that are relevant to the plugin itself. Grouping the codehaus.org etc. plugins in a separate section creates more questions than answers. Are these plugins of lesser quality? Do they have some other technical quality? 'cause when I'm looking for a plugin that fulfills a specific task, the most important distinction is the class of tasks - core, packaging, reporting. (And the Tools section should be split up into Publication, Build process orchestration and Miscellaneous, Tools could apply to any plugin.) The boilerplate text in the Usage section of all the plugins is less than useful. It's always the same, except where it isn't but you don't see it because the differences drown in a sea of, well, boilerplate. Besides, what good is General instructions on how to use the Shade Plugin can be found on the usage page. if the Usage entry is right in the Overview section to the left? The remaining boilerplate text follows just the same pattern: replicating links that are already present in the sidebar. And To provide you with better understanding on some usages of the Shade Plugin, you can take a look into the following examples: is just fluff. It's just text that needs to be scanned to see whether anything relevant is in it, but there isn't; a list of bullets under a heading of Examples is enough. The whole plugin
Configure Wagon Logging in Maven
I'm trying to track down some unexpected slowness while downloading Maven dependencies through Wagon. I'd like to get at all the great logging that is inside Wagon. How can I run Maven with those logs enabled?
Re: Multi-Module: How to download other project's as dependency's without build it locally
Am 18.01.2013 14:35, schrieb Andrew Todd: I'm not entirely sure, but I think that you might be looking for the copy goal in the Maven dependency plugin. https://maven.apache.org/plugins/maven-dependency-plugin/ I'm feeling uneasy about this one. Having to disable the true purpose of the plugin just to use one its minor functions seems strange and potentially backwards to me. Has anybody tried Evgeny Goldin's copy-maven-plugin? It claims to be just about moving files from A to B, including into or out of archives. http://evgeny-goldin.com/wiki/Copy-maven-plugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-nar-plugin (version?)
Hi Stephen, I assume you are renaming it to nar-maven-plugin To remove the confusion and clarify that this is not a plugin originating from the maven project Yep, I filed an issue after the last conversation about it: https://github.com/maven-nar/maven-nar-plugin/issues/9 Regards, Curtis On Fri, Jan 18, 2013 at 2:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I assume you are renaming it to nar-maven-plugin To remove the confusion and clarify that this is not a plugin originating from the maven project -Stephen On Friday, 18 January 2013, Tim Astle wrote: Thanks for the clarification. I posted to this mailing list because that's what is listed on the maven-nar-plugin site. http://duns.github.com/maven-**nar-plugin/mail-lists.html http://duns.github.com/maven-nar-plugin/mail-lists.html Can that be updated as well? Is this the correct issue tracker: http://duns.github.com/maven-** nar-plugin/mail-lists.html http://duns.github.com/maven-nar-plugin/mail-lists.html FYI, I subscribed to the google mailing list. Certainly don't mind assisting in the project. Tim On 1/16/2013 4:17 PM, Curtis Rueden wrote: Hi all, We are still unifying the various forks of maven-nar-plugin, so there is no new official release version yet. The maven-nar mailing list is at: https://groups.google.com/**forum/?fromgroups#!forum/**maven-nar https://groups.google.com/forum/?fromgroups#!forum/maven-nar It seems that all of the involved people are very busy, so progress is rather slow. We welcome any additional help! To avoid confusion, I updated the project readme (at https://github.com/maven-nar/**maven-nar-plugin https://github.com/maven-nar/maven-nar-plugin) to reflect the current project status and links, including a link to the mailing list. Regards, Curtis On Wed, Jan 16, 2013 at 8:53 AM, Mark Donszelmann mark.donszelm...@gmail.com wrote: Hi I wrote the NAR plugin, but have no longer time to maintain it. I donated it (with approval of Sonatype) to a bunch of people who would like to maintain it. Its under https://github.com/maven-nar I guess with mailing lists and doc Regards Mark Donszelmann (duns) On Jan 16, 2013, at 3:44 PM, Wayne Fay wayne...@gmail.com wrote: Nar is not a product of the Maven PMC, and so will never be an official org.apache.maven.plugin anything. Right, but whose product is it today and how do we find the latest official release? The groupId suggests that would be codeswarm.org. But there may be other parties who have their own branches etc. Wayne --**--** - 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: maven-nar-plugin (version?)
Hi Tim, http://duns.github.com/maven-nar-plugin/ That is the old site, and it is up to Mark whether he has time to update it. (Mark, if you do have time, it would solve a lot of confusion to update some of the information in your GitHub space, since there are still an overwhelming number of links to duns.github.com as the definitive maven-nar-plugin site.) FYI, I subscribed to the google mailing list. Certainly don't mind assisting in the project. Great, thanks! Regards, Curtis On Thu, Jan 17, 2013 at 9:02 PM, Tim Astle tas...@nbnet.nb.ca wrote: Thanks for the clarification. I posted to this mailing list because that's what is listed on the maven-nar-plugin site. http://duns.github.com/maven-**nar-plugin/mail-lists.htmlhttp://duns.github.com/maven-nar-plugin/mail-lists.html Can that be updated as well? Is this the correct issue tracker: http://duns.github.com/maven-** nar-plugin/mail-lists.htmlhttp://duns.github.com/maven-nar-plugin/mail-lists.html FYI, I subscribed to the google mailing list. Certainly don't mind assisting in the project. Tim On 1/16/2013 4:17 PM, Curtis Rueden wrote: Hi all, We are still unifying the various forks of maven-nar-plugin, so there is no new official release version yet. The maven-nar mailing list is at: https://groups.google.com/**forum/?fromgroups#!forum/**maven-narhttps://groups.google.com/forum/?fromgroups#!forum/maven-nar It seems that all of the involved people are very busy, so progress is rather slow. We welcome any additional help! To avoid confusion, I updated the project readme (at https://github.com/maven-nar/**maven-nar-pluginhttps://github.com/maven-nar/maven-nar-plugin) to reflect the current project status and links, including a link to the mailing list. Regards, Curtis On Wed, Jan 16, 2013 at 8:53 AM, Mark Donszelmann mark.donszelm...@gmail.com wrote: Hi I wrote the NAR plugin, but have no longer time to maintain it. I donated it (with approval of Sonatype) to a bunch of people who would like to maintain it. Its under https://github.com/maven-nar I guess with mailing lists and doc Regards Mark Donszelmann (duns) On Jan 16, 2013, at 3:44 PM, Wayne Fay wayne...@gmail.com wrote: Nar is not a product of the Maven PMC, and so will never be an official org.apache.maven.plugin anything. Right, but whose product is it today and how do we find the latest official release? The groupId suggests that would be codeswarm.org. But there may be other parties who have their own branches etc. Wayne --**--** - To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven copy-dependencies and excluding transitively
What are you trying to accomplish? Why? That might get you a solution that is a bit different from what you expect. Ron On 18/01/2013 10:07 AM, Veit Guna wrote: Not really, no :). If I read the article correctly, it describes how to merge n jar's into one. I just need to copy them to a specific location. Original-Nachricht Datum: Fri, 18 Jan 2013 08:50:36 -0500 Von: Ron Wheeler rwhee...@artifact-software.com An: users@maven.apache.org Betreff: Re: Maven copy-dependencies and excluding transitively http://blog.artifact-software.com/tech/?p=121 Is that what you are trying to do? Ron On 18/01/2013 8:15 AM, Veit Guna wrote: Hi. I'm using the Maven Dependency Plugin with the goal copy-dependencies. I would like to do the following: - Copy all transitive dependencies with the scope runtime to the target dir - exclude specific group ids *including their* transitive dependencies from that list I tried: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.6/version executions execution idcopy-dependencies/id phasepackage/phase goals goalcopy-dependencies/goal /goals configuration includeScoperuntime/includeScope excludeGroupIdsA,B/excludeGroupIds /configuration /execution /executions /plugin But that leaves all transient dependecies of A and B in the target dir. I also tried excludeTransitivetrue/excludeTransitive But that excludes *all* transitive deps - not only for A and B. That leaves only direct deps in the target dir. Is there any way to achieve what I want *without* specifying each transitive dependency (and theirs) manually via excludeGroupIds? Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Packaging up pre-existing jar and source jar
If you look at the list of project commiters, you can see that you got the best advice possible. I agree with your comments about the documentation in general and one has to browse some of the books to get oriented to a point where the docs are useful. Good luck Ron On 18/01/2013 12:41 PM, Joachim Durchholz wrote: Am 18.01.2013 11:07, schrieb Stephen Connolly: My point is, you think adding a MRM is adding a point of failure... actually it's taking away about 3-4 points of failure, so NET GAIN in reliability. Well, right now, everything is bootstrapping nicely from a Bitbucket repository. I'm using Maven as a build tool. Dependency consolidation is via Bitbucket, so that part of MRM functionality isn't very relevant to me. Third, performance. When you list multiple repository in your pom or settings.xml you force artifact resolution to hit ALL of them. with an MRM you set mirrorOf*/mirrorOf and you now only hit one, it's local anyway, it's flattened (because it's a virtual repo) and you have a fast reliable build and you can scale it out to others. I supposes the m2eclipse repository manager does that already. It is hitting Maven Central on Eclipse startup, once (and takes minutes to complete). With an MRM this would be seconds not minutes Yep, it would be the MRM waiting for the repo information and not Eclipse :-) It looks like m2e is doing the proxying already, so that part of an MRM isn't relevant either. I can see that building from the command line might suck, because that won't have the m2eclipse Workspace Repositories That, and I don't use eclipse, is just building a reactor out of all the projects in your workspace which is handy, but will cause issues for you. Not sure what kinds of issues these might be. If you are really trying to grok what maven is doing, forget eclipse, start from the CLI. Eclipse does all sorts of magic to try and protect you from people who don't grok Maven and set up insane builds. Oh, I don't think it's so hard. I'm avoiding the pom wizards (don't give me any value anymore), and I'm editing the poms in the XML editor. That's what an IDE should do, but for an engineer trying to grok what Maven is doing, you got to go back to vi and CLI... otherwise you are dealing with Magic Not much magic seems to be left with that. I'm starting the builds through a Maven launch configuration. That's essentially the command line. The only magic thing that happens is that I can have multiple projects open, modify code in any of them, and debug the whole system without having to mvn install. If that should fail - well, the launch configuration for mvn install is just a mouse click away. Our issue is we see this *every day*, so our short cut is to tell people: learn from us, this is the way to do it. It would probably be easier if the online docs were better indexed. I mean, the Documentation link on http://eclipse.org/m2e/ leads to http://eclipse.org/m2e/documentation/, which has a single link to http://wiki.eclipse.org/Maven_Integration, which is essentially just a blurb and installation instructions, but no documentation on what it actually does (what you referred to as magic above). The info on, for example, the items in the Maven repositories tab is available, but you need to ask Google, it's not linked from the pages. There are more problems like that: The Maven documentation site (http://maven.apache.org/users/index.html) contains links to tutorials, to the POM and Settings references - but no link to http://maven.apache.org/guides/index.html . The list of standard plugins is under Maven Projects. I ignored that section because, you see, a project is something that you contribute to; that section should be labelled Maven Usage or something. Plugin descriptions abound with terminology but lack links to the explanations of that terminology. Sample excerpts from pom files do not highlight those parts that are relevant to the plugin itself. Grouping the codehaus.org etc. plugins in a separate section creates more questions than answers. Are these plugins of lesser quality? Do they have some other technical quality? 'cause when I'm looking for a plugin that fulfills a specific task, the most important distinction is the class of tasks - core, packaging, reporting. (And the Tools section should be split up into Publication, Build process orchestration and Miscellaneous, Tools could apply to any plugin.) The boilerplate text in the Usage section of all the plugins is less than useful. It's always the same, except where it isn't but you don't see it because the differences drown in a sea of, well, boilerplate. Besides, what good is General instructions on how to use the Shade Plugin can be found on the usage page. if the Usage entry is right in the Overview section to the left? The remaining boilerplate text follows just the same pattern: replicating links that are already present in the
Re: Maven copy-dependencies and excluding transitively
I have a server and plugin project. The server artifacts are deployed to a jboss server. The plugin depends on some server plugin-api artifacts and is optional. Now I want the user to be able to deploy only the plugin with its defined deps without the server plugin-api artifacts - since they are already deployed. So the plan is to take ALL plugin deps minus the server artifacts (transitively!). Hm, as I'm writing this, maybe the right way is to mark the server artifacts as provided :)... Am 18.01.2013 20:38, schrieb Ron Wheeler: What are you trying to accomplish? Why? That might get you a solution that is a bit different from what you expect. Ron On 18/01/2013 10:07 AM, Veit Guna wrote: Not really, no :). If I read the article correctly, it describes how to merge n jar's into one. I just need to copy them to a specific location. Original-Nachricht Datum: Fri, 18 Jan 2013 08:50:36 -0500 Von: Ron Wheeler rwhee...@artifact-software.com An: users@maven.apache.org Betreff: Re: Maven copy-dependencies and excluding transitively http://blog.artifact-software.com/tech/?p=121 Is that what you are trying to do? Ron On 18/01/2013 8:15 AM, Veit Guna wrote: Hi. I'm using the Maven Dependency Plugin with the goal copy-dependencies. I would like to do the following: - Copy all transitive dependencies with the scope runtime to the target dir - exclude specific group ids *including their* transitive dependencies from that list I tried: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.6/version executions execution idcopy-dependencies/id phasepackage/phase goals goalcopy-dependencies/goal /goals configuration includeScoperuntime/includeScope excludeGroupIdsA,B/excludeGroupIds /configuration /execution /executions /plugin But that leaves all transient dependecies of A and B in the target dir. I also tried excludeTransitivetrue/excludeTransitive But that excludes *all* transitive deps - not only for A and B. That leaves only direct deps in the target dir. Is there any way to achieve what I want *without* specifying each transitive dependency (and theirs) manually via excludeGroupIds? Thanks. - 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 copy-dependencies and excluding transitively
On 18/01/2013 2:58 PM, Veit Guna wrote: I have a server and plugin project. The server artifacts are deployed to a jboss server. The plugin depends on some server plugin-api artifacts and is optional. Now I want the user to be able to deploy only the plugin with its defined deps without the server plugin-api artifacts - since they are already deployed. So the plan is to take ALL plugin deps minus the server artifacts (transitively!). Hm, as I'm writing this, maybe the right way is to mark the server artifacts as provided :)... Sounds like what provided is supposed to do. Means that you need them to compile and build but you don't want Maven to put them in the artifact(plug-in) since they are already going to be there when the artifact is ready to run. Am 18.01.2013 20:38, schrieb Ron Wheeler: What are you trying to accomplish? Why? That might get you a solution that is a bit different from what you expect. Ron On 18/01/2013 10:07 AM, Veit Guna wrote: Not really, no :). If I read the article correctly, it describes how to merge n jar's into one. I just need to copy them to a specific location. Original-Nachricht Datum: Fri, 18 Jan 2013 08:50:36 -0500 Von: Ron Wheeler rwhee...@artifact-software.com An: users@maven.apache.org Betreff: Re: Maven copy-dependencies and excluding transitively http://blog.artifact-software.com/tech/?p=121 Is that what you are trying to do? Ron On 18/01/2013 8:15 AM, Veit Guna wrote: Hi. I'm using the Maven Dependency Plugin with the goal copy-dependencies. I would like to do the following: - Copy all transitive dependencies with the scope runtime to the target dir - exclude specific group ids *including their* transitive dependencies from that list I tried: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.6/version executions execution idcopy-dependencies/id phasepackage/phase goals goalcopy-dependencies/goal /goals configuration includeScoperuntime/includeScope excludeGroupIdsA,B/excludeGroupIds /configuration /execution /executions /plugin But that leaves all transient dependecies of A and B in the target dir. I also tried excludeTransitivetrue/excludeTransitive But that excludes *all* transitive deps - not only for A and B. That leaves only direct deps in the target dir. Is there any way to achieve what I want *without* specifying each transitive dependency (and theirs) manually via excludeGroupIds? Thanks. - 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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven copy-dependencies and excluding transitively
Exactly. I'll try provided on monday. Thanks for your help! Am 18.01.2013 21:46, schrieb Ron Wheeler: On 18/01/2013 2:58 PM, Veit Guna wrote: I have a server and plugin project. The server artifacts are deployed to a jboss server. The plugin depends on some server plugin-api artifacts and is optional. Now I want the user to be able to deploy only the plugin with its defined deps without the server plugin-api artifacts - since they are already deployed. So the plan is to take ALL plugin deps minus the server artifacts (transitively!). Hm, as I'm writing this, maybe the right way is to mark the server artifacts as provided :)... Sounds like what provided is supposed to do. Means that you need them to compile and build but you don't want Maven to put them in the artifact(plug-in) since they are already going to be there when the artifact is ready to run. Am 18.01.2013 20:38, schrieb Ron Wheeler: What are you trying to accomplish? Why? That might get you a solution that is a bit different from what you expect. Ron On 18/01/2013 10:07 AM, Veit Guna wrote: Not really, no :). If I read the article correctly, it describes how to merge n jar's into one. I just need to copy them to a specific location. Original-Nachricht Datum: Fri, 18 Jan 2013 08:50:36 -0500 Von: Ron Wheeler rwhee...@artifact-software.com An: users@maven.apache.org Betreff: Re: Maven copy-dependencies and excluding transitively http://blog.artifact-software.com/tech/?p=121 Is that what you are trying to do? Ron On 18/01/2013 8:15 AM, Veit Guna wrote: Hi. I'm using the Maven Dependency Plugin with the goal copy-dependencies. I would like to do the following: - Copy all transitive dependencies with the scope runtime to the target dir - exclude specific group ids *including their* transitive dependencies from that list I tried: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.6/version executions execution idcopy-dependencies/id phasepackage/phase goals goalcopy-dependencies/goal /goals configuration includeScoperuntime/includeScope excludeGroupIdsA,B/excludeGroupIds /configuration /execution /executions /plugin But that leaves all transient dependecies of A and B in the target dir. I also tried excludeTransitivetrue/excludeTransitive But that excludes *all* transitive deps - not only for A and B. That leaves only direct deps in the target dir. Is there any way to achieve what I want *without* specifying each transitive dependency (and theirs) manually via excludeGroupIds? Thanks. - 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
custom build extension
Do build extensions need to be installed in the local maven repo or can they be downloaded like normal dependencies? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom build extension
They download normally. On Fri, Jan 18, 2013 at 5:20 PM, Marcos Mendez mar...@jitisoft.com wrote: Do build extensions need to be installed in the local maven repo or can they be downloaded like normal dependencies? - 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: custom build extension
Thanks. Found the issue. Needed to add the plugin repository for it. On Jan 18, 2013, at 5:37 PM, Benson Margulies wrote: They download normally. On Fri, Jan 18, 2013 at 5:20 PM, Marcos Mendez mar...@jitisoft.com wrote: Do build extensions need to be installed in the local maven repo or can they be downloaded like normal dependencies? - 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
[ANN] License maven plugin 1.4 released
Hi, The Mojo team is pleased to announce the release of the License Maven Plugin, version 1.4. This plugin manages the license of a maven project and its dependencies (update file headers, download dependencies licenses, check thirdparty licenses, ...). This License Plugin has the following goals: * license:add-third-party Goal to generate the third-party license file. This file contains a list of the dependencies and their licenses. Each dependency and it's license is displayed on a single line in the format (license-name) project-name groupId:artifactId:version - project-url It will also copy it in the class-path (says add the generated directory as a resource of the build). * license:aggregate-add-third-party This aggregator goal (will be executed only once and only on pom projects) executed the add-third-party on all his modules (in a parellel build cycle) then aggreates all the third-party files in final one in the pom project. * license:check-file-header The goal to check if the state of header on project source files. * license:comment-style-list Displays all the available comment style to box file headers. * license:download-licenses Download the license files of all the current project's dependencies, and generate a summary file containing a list of all dependencies and their licenses. * license:license-list Display all available licenses. * license:third-party-report Generates a report of all third-parties detected in the module. * license:update-file-header The goal to update (or add) the header on project source files. This goal replace the update-header goal which can not deal with Copyright. This goal use a specific project file descriptor project.xml to describe all files to update for a whole project. * license:update-project-license Updates (or creates) the main project license file according to the given license defines as licenseName. Can also generate a bundled license file (to avoid collision names in class-path). This file is by default generated in META-INF class-path directory. Some useful links: Documentation: http://mojo.codehaus.org/license-maven-plugin JIRA: http://jira.codehaus.org/browse/MLICENSE svn: https://svn.codehaus.org/mojo/tags/license-maven-plugin-1.4 To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdlicense-maven-plugin/artifactId version1.4/version /plugin The artifacts have been deployed to the mojo repository and will be mirrored to central. Release Notes - Mojo's License Maven Plugin - Version 1.4 ** Bug * [MLICENSE-48] - No support for proxy settings * [MLICENSE-50] - settings.xml file and pom example for license resolver use invalid file url * [MLICENSE-51] - Incorrect information on example usage pages * [MLICENSE-54] - Incorrect command line and broken links in online documentation * [MLICENSE-56] - SQL header not compatible with MySQL * [MLICENSE-58] - Doc improvements * [MLICENSE-59] - Dead links on example page(s) * [MLICENSE-61] - New year bug in it update-file-header/test-mojo ** Improvement * [MLICENSE-53] - Allow includedLicenses to be specified in sub-tags * [MLICENSE-63] - Please allow 'quiet' configuration option to disable excess messages * [MLICENSE-64] - Please allow multiple additive licenseMerge elements ** New Feature * [MLICENSE-60] - Provide mechanism for shared data store for 'missing' licenses ** Task * [MLICENSE-57] - Updates dependencies Enjoy, The Mojo team. tony - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Configure Wagon Logging in Maven
Hi, Did you already try mvn -X? Cheers Le 18 janv. 2013 19:00, Matt Hughes mhug...@ccadllc.us a écrit : I'm trying to track down some unexpected slowness while downloading Maven dependencies through Wagon. I'd like to get at all the great logging that is inside Wagon. How can I run Maven with those logs enabled?
