Re: Remove auto-resolution of plugin versions from Maven 2.1
On 1 May 07, at 5:37 PM 1 May 07, Clark, Gil W. wrote: I know I'm getting into iffy territory here and my thoughts on this were kind of rejected on the users list but I think that if the version selection algorithm were to include some sort of quality identifier it would solve some of these problems. The idea here is that some folks are going to want "latest" regardless of the quality of the latest while others are going to want the latest, highest quality release of a plug-in or component. This can be used in conjunction with a version range. So I could say [1.0-STABLE, 2.0-STABLE) and I'd only get stable releases. Or I could say [1.0-WORKING, 2.0-STABLE) and I'd get defaulted to STABLE as long as there is a stable version within the numeric range or if none exists I'd get WORKING if a version at that quality level falls in the range. Or I could say WORKING if I only want the absolute latest working version of a component - kind of like SNAPSHOT. This allows a POM to be targeted at a particular level of quality while still leaving it open to select from a range of versions. For final releases of a project good practice dictates the version numbers be locked down for all dependencies. That does mean modifying the POM but that seems unavoidable. Of course, there may be multiple levels of quality like WORKING, TESTED, FOO, RELEASE, etc. This is the way Ivy works. Maven has the notion of pluggable version transformations. This is the mechanism which looks at the token "SNAPSHOT" and performs the necessary logic to examine the metadata and retrieve the last built version. It's technically not hard to look at an arbitrary token and perform some logic to change the version that is slotted in. The problem here is not a technical one of allowing any token, the problem is that what these things mean to people and the process they go through to arrive to determine the meaning will be arbitrary. I think what people really want here is "something that has some functional improvements but are binary compatible with what I'm using". What "WORKING", or "RELEASE" means vary. Especially in the case of a release as people currently have different processes. We have already standard testing patterns and surefire, and we are starting to see standard release procedures so what we want to move toward is the use of ranges which would be good but coupled with some criteria for quality. So you would simply say I want [1.0,) which is anything 1.0 or above that 1) is binary compatible with what I used last time (we go and find the last release and see what version was resolved), and 2) has the same or better coverage. This is the only way you can deterministically be safe of picking something further down in a range. Who's going to assign these arbitrary labels to releases? I mean who is doing this for Ivy? This stuff cannot be tacked on by the third party it simply is not scalable. Maven has the social capital (the necessary mass of users doing the same thing) to pull off these coverage and binary compatibility standards to make this transparent. That being said I still think people would benefit more from a daily report produced from a build server that pulled in new versions of dependencies that purport to work and actually run your tests. If successful then you click a button and your POMs are upgrade. The computer should do the crap work. We are really not that far away from something like this. The hardest part in all this is standardizing on these quality levels - t Bingo. This can only happen in a community like Maven where we have striven for standard everything from day one because this is the only way these types of things are possible. This will never be possible using Ant with Ivy, it was never the goal of Ant. They might say they can but that will require the addition of everything we already have. Then it will be converging toward what Maven actually is. The key difference is that Maven from day one was designed to have a complete and holistic approach to solving problems like this. For example right now for releases, using the profile we have created, we require PGP signatures, javadocs, sources, and the licenses and notice files are inserted automatically (with the available overriding for cases where the metadata is insufficient). As our profile spreads into common use we can then also mixin Clirr to produce a small file indicating the level of binary compatibility, and a file indicating coverage. Even if this was not done in the original build we can inject those plugins for the release. How? Because all our builds are the same. Intervention on our part, but entirely scalable because of the common structure of our projects. I don't think many people using Maven, let alone detractors understand the power and utility of our model. We let the computer do w
RE: Remove auto-resolution of plugin versions from Maven 2.1
I know I'm getting into iffy territory here and my thoughts on this were kind of rejected on the users list but I think that if the version selection algorithm were to include some sort of quality identifier it would solve some of these problems. The idea here is that some folks are going to want "latest" regardless of the quality of the latest while others are going to want the latest, highest quality release of a plug-in or component. This can be used in conjunction with a version range. So I could say [1.0-STABLE, 2.0-STABLE) and I'd only get stable releases. Or I could say [1.0-WORKING, 2.0-STABLE) and I'd get defaulted to STABLE as long as there is a stable version within the numeric range or if none exists I'd get WORKING if a version at that quality level falls in the range. Or I could say WORKING if I only want the absolute latest working version of a component - kind of like SNAPSHOT. This allows a POM to be targeted at a particular level of quality while still leaving it open to select from a range of versions. For final releases of a project good practice dictates the version numbers be locked down for all dependencies. That does mean modifying the POM but that seems unavoidable. Of course, there may be multiple levels of quality like WORKING, TESTED, FOO, RELEASE, etc. This is the way Ivy works. The hardest part in all this is standardizing on these quality levels - they can be dynamic - specified in the settings file or top level POM... -Original Message- From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 1:36 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Le mardi 1 mai 2007, Tomasz Pik a écrit : > On 5/1/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote: > > Le mardi 1 mai 2007, Jerome Lacoste a écrit : > > > Maybe there could be an easy way to let users use the latest ? > > > maybe something like > > > mvn -L ... ( L for latest) > > > that would ignore all specified versions, without requiring a POM > > > change ? Maybe too radical. > > > > such a LATEST option would be very usefull, not only for plugins but > > for every dependencies, to do regression testing against latest > > development version of everything. It would be like if Gump was > > integrated into > > Maven: > > http://gump.apache.org/ > > > > I think we would need to differentiate plugin latest from > > dependencies latest. > > This LATEST thing is already in jira: > http://jira.codehaus.org/browse/MNG-2431 And I think it would be very > useful, both for plugins and for 'normal dependencies'. not exactly: - LATEST STABLE is not LATEST : LATEST doesn't try to differentiate STABLE or not, just get any change to check ASAP if it breaks something - "mvn -L" is on the command line, not in the pom : the pom refers to chosen versions, for normal builds, but "mvn -L" is for continuous builds, overriding chosen versions of the pom, to check if a dependency has an evolution that will break something. The artifact built with "mvn -L" is not intended for use, but only as a pro-active test against dependencies evolution > > Regards, > Tomek > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
Le mardi 1 mai 2007, Tomasz Pik a écrit : > On 5/1/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote: > > Le mardi 1 mai 2007, Jerome Lacoste a écrit : > > > Maybe there could be an easy way to let users use the latest ? maybe > > > something like > > > mvn -L ... ( L for latest) > > > that would ignore all specified versions, without requiring a POM > > > change ? Maybe too radical. > > > > such a LATEST option would be very usefull, not only for plugins but for > > every dependencies, to do regression testing against latest development > > version of everything. It would be like if Gump was integrated into > > Maven: > > http://gump.apache.org/ > > > > I think we would need to differentiate plugin latest from dependencies > > latest. > > This LATEST thing is already in jira: > http://jira.codehaus.org/browse/MNG-2431 And I think it would be very > useful, both for plugins and for 'normal dependencies'. not exactly: - LATEST STABLE is not LATEST : LATEST doesn't try to differentiate STABLE or not, just get any change to check ASAP if it breaks something - "mvn -L" is on the command line, not in the pom : the pom refers to chosen versions, for normal builds, but "mvn -L" is for continuous builds, overriding chosen versions of the pom, to check if a dependency has an evolution that will break something. The artifact built with "mvn -L" is not intended for use, but only as a pro-active test against dependencies evolution > > Regards, > Tomek > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] [m1] couple of plugins for rc1
Hi, Here's a bunch of plugins I'd like to release for inclusion in m11-rc1: maven-artifact-plugin-1.9 maven-changelog-plugin-1.9.2 maven-dist-plugin-1.7.1 maven-eclipse-plugin-1.12 maven-ejb-plugin-1.7.3 maven-linkcheck-plugin-1.4.1 maven-multiproject-plugin-1.5.1 maven-test-plugin-1.8.1 maven-war-plugin-1.6.3 maven-xdoc-plugin-1.10.1 Most of them were ready since a long time and were only waiting for the maven-model-3.0.2 release that happened last week. Otherwise changes are mostly minor, except for the artifact plugin, which will now only work with rc1. Due to the maven-model dependency, I plan to announce the release of these plugins together with the rc1 release only. +1 from me, 72h to vote... Thanks, -Lukas http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/artifact/ http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/changelog/ http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/dist/ http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/eclipse/ http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/ejb/ http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/linkcheck/ http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/multiproject/ http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/test/ http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/war/ http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/xdoc/ maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.9-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-changelog-plugin -Dversion=1.9.2-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-dist-plugin -Dversion=1.7.1-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-eclipse-plugin -Dversion=1.12-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-ejb-plugin -Dversion=1.7.3-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-linkcheck-plugin -Dversion=1.4.1-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-multiproject-plugin -Dversion=1.5.1-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-test-plugin -Dversion=1.8.1-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-war-plugin -Dversion=1.6.3-SNAPSHOT maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-xdoc-plugin -Dversion=1.10.1-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Complete: trunk version upgraded to 1.0-alpha-1-SNAPSHOT
\o/ nice job :) On 5/1/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: The merge is complete. Trunk is now on version 1.0-alpha-1-SNAPSHOT using the former database branch. Old trunk is now located in https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-0.9 - Joakim Joakim Erdfelt wrote: > Steps 1-4 are now complete. > Working on Step 5 (make version in trunk 1.0-alpha-1-SNAPSHOT) now ... > > - Joakim > > Joakim Erdfelt wrote: >> Ok. >> >> Here's the vote breakdown. >> >> option A - Make the branch the new trunk. >> * Emmanuel Venisse >> * Arnaud Heriter >> * Nicolas De Loof >> * Jesse McConnell >> * Brett Porter >> * Wendy Smoak >> >> option B - Merge the branch into the existing trunk. >> * Maria Odea Ching >> >> option C - Do not merge the branch into trunk. >> * (n/a) >> >> Looks like option A wins! >> >> The current plan >> >> 1) Identify the changes since the branch has been made. >>Branch was created on March 15, 2007 - on revision 518676 >> 2) Merge in changes made on trunk since branch into the branch. >> 3) Rename the current trunk as branch-0.9 >> 4) Rename the archiva-jpox-database branch as the new trunk. >> 5) Set the versions in the trunk to 1.0-alpha-1-SNAPSHOT >> 6) Announce completion of merge to archiva-dev >> 7) Continue working on admin screens. >> 8) Once admin screens are stable, get the ball rolling on a >> 1.0-alpha-1 release. >> >> - Joakim Erdfelt > -- jesse mcconnell [EMAIL PROTECTED]
Complete: trunk version upgraded to 1.0-alpha-1-SNAPSHOT
The merge is complete. Trunk is now on version 1.0-alpha-1-SNAPSHOT using the former database branch. Old trunk is now located in https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-0.9 - Joakim Joakim Erdfelt wrote: Steps 1-4 are now complete. Working on Step 5 (make version in trunk 1.0-alpha-1-SNAPSHOT) now ... - Joakim Joakim Erdfelt wrote: Ok. Here's the vote breakdown. option A - Make the branch the new trunk. * Emmanuel Venisse * Arnaud Heriter * Nicolas De Loof * Jesse McConnell * Brett Porter * Wendy Smoak option B - Merge the branch into the existing trunk. * Maria Odea Ching option C - Do not merge the branch into trunk. * (n/a) Looks like option A wins! The current plan 1) Identify the changes since the branch has been made. Branch was created on March 15, 2007 - on revision 518676 2) Merge in changes made on trunk since branch into the branch. 3) Rename the current trunk as branch-0.9 4) Rename the archiva-jpox-database branch as the new trunk. 5) Set the versions in the trunk to 1.0-alpha-1-SNAPSHOT 6) Announce completion of merge to archiva-dev 7) Continue working on admin screens. 8) Once admin screens are stable, get the ball rolling on a 1.0-alpha-1 release. - Joakim Erdfelt
Re: [M1] War plugin ready
Thanks Stephane!
I have deployed a stage site with your last changes [1] and a snapshot
as well. I will call a vote for a number of plugins later.
Apparently, we don't have a paragraph explaining how to deploy snapshots
[2] but it's basically just 'maven plugin:repository-deploy' for the
snapshot and 'maven site:{type}deploy' for the site (use
-Dmaven.site.deploy.live=true for the live site).
Cheers,
-Lukas
[1]
http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugins/war/
[2] http://maven.apache.org/maven-1.x/developers/making-releases.html
Stephane Nicoll wrote:
Lukas, Emmanuel (and others ;),
The war plugin 1.6.3 is ready to be released. could you please deploy
a staging version of the plugin somewhere. I've not used m1 for months
now and I don't have the setup here. If you have a link that explains
how to do this i'll do it myself.
Thanks,
Stéphane
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
g
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[M1] War plugin ready
Lukas, Emmanuel (and others ;), The war plugin 1.6.3 is ready to be released. could you please deploy a staging version of the plugin somewhere. I've not used m1 for months now and I don't have the setup here. If you have a link that explains how to do this i'll do it myself. Thanks, Stéphane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-release-plugin 2.0-beta-5
On 5/1/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Have you tried releasing many things with it?
I'm using the snapshot for a few weeks. I released 30+ projects.
Stéphane
Jason.
On 1 May 07, at 5:07 AM 1 May 07, Stephane Nicoll wrote:
> Hi,
>
> I'd like to release the maven release plugin which includes the maven
> release manager and the maven release parent pom.
>
> The staging bits are available here:
> http://people.apache.org/~snicoll/maven-staging/repo/
>
>
> Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-5
>
> ** Bug
>* [MRELEASE-3] - release:prepare should not require multimodule
> artifacts to be in the local repository
>* [MRELEASE-6] - Multiproject Release: No check in
>* [MRELEASE-16] - release-pom is changed too much
>* [MRELEASE-35] - release plugin doesn't tag correctly with
> svn+ssh when remote and local username don't match
>* [MRELEASE-90] - Exception if version is SNAPSHOT
>* [MRELEASE-91] - Updating of dependencyManagement inconsistent
> with updating of dependencies with regard to SNAPSHOTs
>* [MRELEASE-94] - Modified Parent POM is not commited
>* [MRELEASE-107] - scm.url gets translated incorrectly during
> release
>* [MRELEASE-110] - release:prepare generates tags with dots,
> causing problems with CVS
>* [MRELEASE-114] - ${project.artifactId} was replaced with it's
> value during release:perform
>* [MRELEASE-115] - Issue URL on pom is incorrect
>* [MRELEASE-116] - Wrong SCM info put by the release plugin for
> modules
>* [MRELEASE-122] - Versionless Extension causes
> NullPointerException in release:prepare
>* [MRELEASE-128] - SCM properties being replaced during
> release:perform
>* [MRELEASE-131] - release:prepare failed in 'cvs ... commit'
> phase for multi-module build
>* [MRELEASE-137] - proposed SCM release tag or label in
> multiproject
>* [MRELEASE-142] - Batch mode release plugin uses an invalid tag
>* [MRELEASE-144] - Release plugin did not ask for a Subversion tag
>* [MRELEASE-147] - Version number for a dependency with
> ${pom.groupId} not updated in multi-module.
>* [MRELEASE-151] - All child modules are forced to share the
> same parent POM
>* [MRELEASE-160] - The next snapshot version is not used un
> submodules
>* [MRELEASE-168] - All submodule projects must be from the same
> subversion repository
>* [MRELEASE-180] - Rewritten poms loose comments
>* [MRELEASE-190] - scmTagPhase scm comment when creating the
> branch/tag directory uses the prefix [maven-scm]
>* [MRELEASE-191] - Certain tests fail when checked-out in
> 'projects' subdir
>* [MRELEASE-194] - SNAPSHOT as property bypasses dependency
> snapshot check
>* [MRELEASE-197] - Release plugin documentation on
> maven.apache.org has broken link to release:rollback
>* [MRELEASE-202] - snapshot versions in dependencyManagement are
> not updated
>* [MRELEASE-209] - Snapshot versions are not restored correctly on
> next development version
>* [MRELEASE-219] - Spurious warnings given when a release contains
> subversion externals
>* [MRELEASE-221] - XML header missing in modified POM after
> release:prepare
>* [MRELEASE-222] - Wrong default tag name when used in a reactor
> environment
>
> ** Improvement
>* [MRELEASE-112] - release plugin should have option to ignore
> snapshots of the release plugin
>* [MRELEASE-145] - release:prepare requires all modules to be
> SNAPSHOTS
>* [MRELEASE-183] - should report all unresolved dependencies, not
> just the first encountered.
>* [MRELEASE-208] - Support for ClearCase, and other SCMs that do
> checkout projects to subdirectories of the checkout directory
>* [MRELEASE-214] - scm:tag with scmCommentPrefix
>* [MRELEASE-220] - Add property to keep released versions for
> dependencies
>
> ** New Feature
>* [MRELEASE-130] - Create a model for a release
>* [MRELEASE-157] - Share version for multi-module releases
>* [MRELEASE-169] - Provide a mechanism to undo the effects of
> prepare
>
> ** Task
>* [MRELEASE-141] - Review Plugin Documentation
>* [MRELEASE-162] - Move all release core code in maven/shared
>
> Vote open for 72 hours
>
> My +1
>
> Thanks,
> Stéphane
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Artifact version range behavior bug?
On 30/04/07, dhoffer <[EMAIL PROTECTED]> wrote: Plugins seem to resolve version ranges in an inconsistent manor. If I have a dependency version specified as [1.0,) how should this be resolved with respect to SNAPSHOTS (in the opinion of the maven2 developers)? Test case: Assume you have released versions 1.0, 1.1, 1.2, 1.3, 1.4 & 1.5. In addition snapshot releases exist for all versions as well as 1.6-SNAPSHOT. Behavior: Currently the idea, assembly & dependency plugis resolve this to version 1.6-SNAPSHOT, however the release plugin trunk logic does not, it will resolve this to 1.5 (prior beta releases did resolve to 1.6-SNAPSHOT). In my opinion the later case is how it should behave (resolve to 1.5); set-notation should never resolve to SNAPSHOTS. We use set-notation as our primary dependency management technique for artifacts created inhouse. We unbound the high end of the version to mean we want the latest released version. If we want SNAPSHOTS to be included we manually change the version to state this. Depending on the opinion of the maven2 developers, another option that I think would also work well is to have another tag in the dependency section turning on/off inclusion of snapshots, i.e. . Sounds like a bug in those plugins, since the release plugin exhibits the correct behaviour that you described - as per the design docs: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification I'd suggest creating a minimal test project that reproduces the problem and raise some JIRAs. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 5/1/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote: Le mardi 1 mai 2007, Jerome Lacoste a écrit : > Maybe there could be an easy way to let users use the latest ? maybe > something like > mvn -L ... ( L for latest) > that would ignore all specified versions, without requiring a POM > change ? Maybe too radical. such a LATEST option would be very usefull, not only for plugins but for every dependencies, to do regression testing against latest development version of everything. It would be like if Gump was integrated into Maven: http://gump.apache.org/ I think we would need to differentiate plugin latest from dependencies latest. This LATEST thing is already in jira: http://jira.codehaus.org/browse/MNG-2431 And I think it would be very useful, both for plugins and for 'normal dependencies'. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Complete: update db-branch / trunk->branch-0.9 / db-branch->trunk swap
Steps 1-4 are now complete. Working on Step 5 (make version in trunk 1.0-alpha-1-SNAPSHOT) now ... - Joakim Joakim Erdfelt wrote: Ok. Here's the vote breakdown. option A - Make the branch the new trunk. * Emmanuel Venisse * Arnaud Heriter * Nicolas De Loof * Jesse McConnell * Brett Porter * Wendy Smoak option B - Merge the branch into the existing trunk. * Maria Odea Ching option C - Do not merge the branch into trunk. * (n/a) Looks like option A wins! The current plan 1) Identify the changes since the branch has been made. Branch was created on March 15, 2007 - on revision 518676 2) Merge in changes made on trunk since branch into the branch. 3) Rename the current trunk as branch-0.9 4) Rename the archiva-jpox-database branch as the new trunk. 5) Set the versions in the trunk to 1.0-alpha-1-SNAPSHOT 6) Announce completion of merge to archiva-dev 7) Continue working on admin screens. 8) Once admin screens are stable, get the ball rolling on a 1.0-alpha-1 release. - Joakim Erdfelt
Re: [vote] release maven-release-plugin 2.0-beta-5
I tried with success at work (with a snaphot built some days ago)
Arnaud
On 01/05/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Have you tried releasing many things with it?
Jason.
On 1 May 07, at 5:07 AM 1 May 07, Stephane Nicoll wrote:
> Hi,
>
> I'd like to release the maven release plugin which includes the maven
> release manager and the maven release parent pom.
>
> The staging bits are available here:
> http://people.apache.org/~snicoll/maven-staging/repo/
>
>
> Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-5
>
> ** Bug
>* [MRELEASE-3] - release:prepare should not require multimodule
> artifacts to be in the local repository
>* [MRELEASE-6] - Multiproject Release: No check in
>* [MRELEASE-16] - release-pom is changed too much
>* [MRELEASE-35] - release plugin doesn't tag correctly with
> svn+ssh when remote and local username don't match
>* [MRELEASE-90] - Exception if version is SNAPSHOT
>* [MRELEASE-91] - Updating of dependencyManagement inconsistent
> with updating of dependencies with regard to SNAPSHOTs
>* [MRELEASE-94] - Modified Parent POM is not commited
>* [MRELEASE-107] - scm.url gets translated incorrectly during
> release
>* [MRELEASE-110] - release:prepare generates tags with dots,
> causing problems with CVS
>* [MRELEASE-114] - ${project.artifactId} was replaced with it's
> value during release:perform
>* [MRELEASE-115] - Issue URL on pom is incorrect
>* [MRELEASE-116] - Wrong SCM info put by the release plugin for
> modules
>* [MRELEASE-122] - Versionless Extension causes
> NullPointerException in release:prepare
>* [MRELEASE-128] - SCM properties being replaced during
> release:perform
>* [MRELEASE-131] - release:prepare failed in 'cvs ... commit'
> phase for multi-module build
>* [MRELEASE-137] - proposed SCM release tag or label in
> multiproject
>* [MRELEASE-142] - Batch mode release plugin uses an invalid tag
>* [MRELEASE-144] - Release plugin did not ask for a Subversion tag
>* [MRELEASE-147] - Version number for a dependency with
> ${pom.groupId} not updated in multi-module.
>* [MRELEASE-151] - All child modules are forced to share the
> same parent POM
>* [MRELEASE-160] - The next snapshot version is not used un
> submodules
>* [MRELEASE-168] - All submodule projects must be from the same
> subversion repository
>* [MRELEASE-180] - Rewritten poms loose comments
>* [MRELEASE-190] - scmTagPhase scm comment when creating the
> branch/tag directory uses the prefix [maven-scm]
>* [MRELEASE-191] - Certain tests fail when checked-out in
> 'projects' subdir
>* [MRELEASE-194] - SNAPSHOT as property bypasses dependency
> snapshot check
>* [MRELEASE-197] - Release plugin documentation on
> maven.apache.org has broken link to release:rollback
>* [MRELEASE-202] - snapshot versions in dependencyManagement are
> not updated
>* [MRELEASE-209] - Snapshot versions are not restored correctly on
> next development version
>* [MRELEASE-219] - Spurious warnings given when a release contains
> subversion externals
>* [MRELEASE-221] - XML header missing in modified POM after
> release:prepare
>* [MRELEASE-222] - Wrong default tag name when used in a reactor
> environment
>
> ** Improvement
>* [MRELEASE-112] - release plugin should have option to ignore
> snapshots of the release plugin
>* [MRELEASE-145] - release:prepare requires all modules to be
> SNAPSHOTS
>* [MRELEASE-183] - should report all unresolved dependencies, not
> just the first encountered.
>* [MRELEASE-208] - Support for ClearCase, and other SCMs that do
> checkout projects to subdirectories of the checkout directory
>* [MRELEASE-214] - scm:tag with scmCommentPrefix
>* [MRELEASE-220] - Add property to keep released versions for
> dependencies
>
> ** New Feature
>* [MRELEASE-130] - Create a model for a release
>* [MRELEASE-157] - Share version for multi-module releases
>* [MRELEASE-169] - Provide a mechanism to undo the effects of
> prepare
>
> ** Task
>* [MRELEASE-141] - Review Plugin Documentation
>* [MRELEASE-162] - Move all release core code in maven/shared
>
> Vote open for 72 hours
>
> My +1
>
> Thanks,
> Stéphane
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Merge Archiva Database Branch to Trunk
Joakim Erdfelt a écrit : Emmanuel Venisse wrote: Joakim Erdfelt a écrit : Ok. Here's the vote breakdown. option A - Make the branch the new trunk. * Emmanuel Venisse * Arnaud Heriter * Nicolas De Loof * Jesse McConnell * Brett Porter * Wendy Smoak option B - Merge the branch into the existing trunk. * Maria Odea Ching option C - Do not merge the branch into trunk. * (n/a) Looks like option A wins! The current plan 1) Identify the changes since the branch has been made. Branch was created on March 15, 2007 - on revision 518676 2) Merge in changes made on trunk since branch into the branch. 3) Rename the current trunk as branch-0.9 Maybe it would be better to use this process: 3) copy trunk as branch-0.9 3.1) Remove trunk I think that with this process a 'svn up' will work fine instead of to do a clean checkout. I was just going to use ... $ svn mv \ https://svn.apache.org/repos/asf/maven/archiva/trunk \ https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-0.9 and then ... $ svn mv \ https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-jpox-database-refactor \ https://svn.apache.org/repos/asf/maven/archiva/trunk After all the docs for "svn mv" state ... move (mv, rename, ren): Move and/or rename something in working copy or repository. usage: move SRC DST Note: *this subcommand is equivalent to a 'copy' and 'delete'.* Note: the --revision option has no use and is deprecated. SRC and DST can both be working copy (WC) paths or URLs: WC -> WC: move and schedule for addition (with history) URL -> URL: complete server-side rename. See any problem with this approach? It should be ok and should update correctly working copies. Emmanuel
Re: [vote] release maven-release-plugin 2.0-beta-5
Yes, I tried it on few projects (ASF and others) in my svn server.
Emmanuel
Jason van Zyl a écrit :
Have you tried releasing many things with it?
Jason.
On 1 May 07, at 5:07 AM 1 May 07, Stephane Nicoll wrote:
Hi,
I'd like to release the maven release plugin which includes the maven
release manager and the maven release parent pom.
The staging bits are available here:
http://people.apache.org/~snicoll/maven-staging/repo/
Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-5
** Bug
* [MRELEASE-3] - release:prepare should not require multimodule
artifacts to be in the local repository
* [MRELEASE-6] - Multiproject Release: No check in
* [MRELEASE-16] - release-pom is changed too much
* [MRELEASE-35] - release plugin doesn't tag correctly with
svn+ssh when remote and local username don't match
* [MRELEASE-90] - Exception if version is SNAPSHOT
* [MRELEASE-91] - Updating of dependencyManagement inconsistent
with updating of dependencies with regard to SNAPSHOTs
* [MRELEASE-94] - Modified Parent POM is not commited
* [MRELEASE-107] - scm.url gets translated incorrectly during release
* [MRELEASE-110] - release:prepare generates tags with dots,
causing problems with CVS
* [MRELEASE-114] - ${project.artifactId} was replaced with it's
value during release:perform
* [MRELEASE-115] - Issue URL on pom is incorrect
* [MRELEASE-116] - Wrong SCM info put by the release plugin for
modules
* [MRELEASE-122] - Versionless Extension causes
NullPointerException in release:prepare
* [MRELEASE-128] - SCM properties being replaced during
release:perform
* [MRELEASE-131] - release:prepare failed in 'cvs ... commit'
phase for multi-module build
* [MRELEASE-137] - proposed SCM release tag or label in multiproject
* [MRELEASE-142] - Batch mode release plugin uses an invalid tag
* [MRELEASE-144] - Release plugin did not ask for a Subversion tag
* [MRELEASE-147] - Version number for a dependency with
${pom.groupId} not updated in multi-module.
* [MRELEASE-151] - All child modules are forced to share the same
parent POM
* [MRELEASE-160] - The next snapshot version is not used un submodules
* [MRELEASE-168] - All submodule projects must be from the same
subversion repository
* [MRELEASE-180] - Rewritten poms loose comments
* [MRELEASE-190] - scmTagPhase scm comment when creating the
branch/tag directory uses the prefix [maven-scm]
* [MRELEASE-191] - Certain tests fail when checked-out in
'projects' subdir
* [MRELEASE-194] - SNAPSHOT as property bypasses dependency
snapshot check
* [MRELEASE-197] - Release plugin documentation on
maven.apache.org has broken link to release:rollback
* [MRELEASE-202] - snapshot versions in dependencyManagement are
not updated
* [MRELEASE-209] - Snapshot versions are not restored correctly on
next development version
* [MRELEASE-219] - Spurious warnings given when a release contains
subversion externals
* [MRELEASE-221] - XML header missing in modified POM after
release:prepare
* [MRELEASE-222] - Wrong default tag name when used in a reactor
environment
** Improvement
* [MRELEASE-112] - release plugin should have option to ignore
snapshots of the release plugin
* [MRELEASE-145] - release:prepare requires all modules to be
SNAPSHOTS
* [MRELEASE-183] - should report all unresolved dependencies, not
just the first encountered.
* [MRELEASE-208] - Support for ClearCase, and other SCMs that do
checkout projects to subdirectories of the checkout directory
* [MRELEASE-214] - scm:tag with scmCommentPrefix
* [MRELEASE-220] - Add property to keep released versions for
dependencies
** New Feature
* [MRELEASE-130] - Create a model for a release
* [MRELEASE-157] - Share version for multi-module releases
* [MRELEASE-169] - Provide a mechanism to undo the effects of prepare
** Task
* [MRELEASE-141] - Review Plugin Documentation
* [MRELEASE-162] - Move all release core code in maven/shared
Vote open for 72 hours
My +1
Thanks,
Stéphane
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
On 5/1/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: How on earth would you ever debug the inevitable issues when you suddenly upgrade to all new versions of plugins (and worse dependencies?)? because you don't do it "suddenly", you would do it continuously. Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
How on earth would you ever debug the inevitable issues when you suddenly upgrade to all new versions of plugins (and worse dependencies?)? -Original Message- From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 4:18 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Le mardi 1 mai 2007, Jerome Lacoste a écrit : > Maybe there could be an easy way to let users use the latest ? maybe > something like > mvn -L ... ( L for latest) > that would ignore all specified versions, without requiring a POM > change ? Maybe too radical. such a LATEST option would be very usefull, not only for plugins but for every dependencies, to do regression testing against latest development version of everything. It would be like if Gump was integrated into Maven: http://gump.apache.org/ I think we would need to differentiate plugin latest from dependencies latest. Hervé > > Cheers, > > Jerome > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-release-plugin 2.0-beta-5
Have you tried releasing many things with it?
Jason.
On 1 May 07, at 5:07 AM 1 May 07, Stephane Nicoll wrote:
Hi,
I'd like to release the maven release plugin which includes the maven
release manager and the maven release parent pom.
The staging bits are available here:
http://people.apache.org/~snicoll/maven-staging/repo/
Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-5
** Bug
* [MRELEASE-3] - release:prepare should not require multimodule
artifacts to be in the local repository
* [MRELEASE-6] - Multiproject Release: No check in
* [MRELEASE-16] - release-pom is changed too much
* [MRELEASE-35] - release plugin doesn't tag correctly with
svn+ssh when remote and local username don't match
* [MRELEASE-90] - Exception if version is SNAPSHOT
* [MRELEASE-91] - Updating of dependencyManagement inconsistent
with updating of dependencies with regard to SNAPSHOTs
* [MRELEASE-94] - Modified Parent POM is not commited
* [MRELEASE-107] - scm.url gets translated incorrectly during
release
* [MRELEASE-110] - release:prepare generates tags with dots,
causing problems with CVS
* [MRELEASE-114] - ${project.artifactId} was replaced with it's
value during release:perform
* [MRELEASE-115] - Issue URL on pom is incorrect
* [MRELEASE-116] - Wrong SCM info put by the release plugin for
modules
* [MRELEASE-122] - Versionless Extension causes
NullPointerException in release:prepare
* [MRELEASE-128] - SCM properties being replaced during
release:perform
* [MRELEASE-131] - release:prepare failed in 'cvs ... commit'
phase for multi-module build
* [MRELEASE-137] - proposed SCM release tag or label in
multiproject
* [MRELEASE-142] - Batch mode release plugin uses an invalid tag
* [MRELEASE-144] - Release plugin did not ask for a Subversion tag
* [MRELEASE-147] - Version number for a dependency with
${pom.groupId} not updated in multi-module.
* [MRELEASE-151] - All child modules are forced to share the
same parent POM
* [MRELEASE-160] - The next snapshot version is not used un
submodules
* [MRELEASE-168] - All submodule projects must be from the same
subversion repository
* [MRELEASE-180] - Rewritten poms loose comments
* [MRELEASE-190] - scmTagPhase scm comment when creating the
branch/tag directory uses the prefix [maven-scm]
* [MRELEASE-191] - Certain tests fail when checked-out in
'projects' subdir
* [MRELEASE-194] - SNAPSHOT as property bypasses dependency
snapshot check
* [MRELEASE-197] - Release plugin documentation on
maven.apache.org has broken link to release:rollback
* [MRELEASE-202] - snapshot versions in dependencyManagement are
not updated
* [MRELEASE-209] - Snapshot versions are not restored correctly on
next development version
* [MRELEASE-219] - Spurious warnings given when a release contains
subversion externals
* [MRELEASE-221] - XML header missing in modified POM after
release:prepare
* [MRELEASE-222] - Wrong default tag name when used in a reactor
environment
** Improvement
* [MRELEASE-112] - release plugin should have option to ignore
snapshots of the release plugin
* [MRELEASE-145] - release:prepare requires all modules to be
SNAPSHOTS
* [MRELEASE-183] - should report all unresolved dependencies, not
just the first encountered.
* [MRELEASE-208] - Support for ClearCase, and other SCMs that do
checkout projects to subdirectories of the checkout directory
* [MRELEASE-214] - scm:tag with scmCommentPrefix
* [MRELEASE-220] - Add property to keep released versions for
dependencies
** New Feature
* [MRELEASE-130] - Create a model for a release
* [MRELEASE-157] - Share version for multi-module releases
* [MRELEASE-169] - Provide a mechanism to undo the effects of
prepare
** Task
* [MRELEASE-141] - Review Plugin Documentation
* [MRELEASE-162] - Move all release core code in maven/shared
Vote open for 72 hours
My +1
Thanks,
Stéphane
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2-wsdl2code-maven-plugin
Jochen Wiedmann wrote: On 4/30/07, Armin Ehrenfels <[EMAIL PROTECTED]> wrote: I'm trying to find out how to specify a bindingfile for the JiBX in my pom.xml. Please understand, that I've got absolutely no idea about JiBX. I do not know, what's required for a JiBX binding or not. I do not know, whether the binding file is required at runtime, at compile time or whenever else. You've got to tell me more details. No problem :-) . I'm glad that someone has taken on the work at all. integration test with *WSDL2CodeMojo*. Also, as far as I could find out, the mojo wouldn't evaluate Ebindingfile anyway which is obviously reasonable since it's a JiBX specific option. If there is a requirement for these things, we've got to solve it. OK. I'm going to continue the discussion off list to avoid too much noise. Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-release-plugin 2.0-beta-5
+1
Arnaud
On 01/05/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
+1
Emmanuel
Stephane Nicoll a écrit :
> Hi,
>
> I'd like to release the maven release plugin which includes the maven
> release manager and the maven release parent pom.
>
> The staging bits are available here:
> http://people.apache.org/~snicoll/maven-staging/repo/
>
>
> Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-5
>
> ** Bug
>* [MRELEASE-3] - release:prepare should not require multimodule
> artifacts to be in the local repository
>* [MRELEASE-6] - Multiproject Release: No check in
>* [MRELEASE-16] - release-pom is changed too much
>* [MRELEASE-35] - release plugin doesn't tag correctly with
> svn+ssh when remote and local username don't match
>* [MRELEASE-90] - Exception if version is SNAPSHOT
>* [MRELEASE-91] - Updating of dependencyManagement inconsistent
> with updating of dependencies with regard to SNAPSHOTs
>* [MRELEASE-94] - Modified Parent POM is not commited
>* [MRELEASE-107] - scm.url gets translated incorrectly during release
>* [MRELEASE-110] - release:prepare generates tags with dots,
> causing problems with CVS
>* [MRELEASE-114] - ${project.artifactId} was replaced with it's
> value during release:perform
>* [MRELEASE-115] - Issue URL on pom is incorrect
>* [MRELEASE-116] - Wrong SCM info put by the release plugin for
modules
>* [MRELEASE-122] - Versionless Extension causes
> NullPointerException in release:prepare
>* [MRELEASE-128] - SCM properties being replaced during
release:perform
>* [MRELEASE-131] - release:prepare failed in 'cvs ... commit'
> phase for multi-module build
>* [MRELEASE-137] - proposed SCM release tag or label in multiproject
>* [MRELEASE-142] - Batch mode release plugin uses an invalid tag
>* [MRELEASE-144] - Release plugin did not ask for a Subversion tag
>* [MRELEASE-147] - Version number for a dependency with
> ${pom.groupId} not updated in multi-module.
>* [MRELEASE-151] - All child modules are forced to share the same
> parent POM
>* [MRELEASE-160] - The next snapshot version is not used un
submodules
>* [MRELEASE-168] - All submodule projects must be from the same
> subversion repository
>* [MRELEASE-180] - Rewritten poms loose comments
>* [MRELEASE-190] - scmTagPhase scm comment when creating the
> branch/tag directory uses the prefix [maven-scm]
>* [MRELEASE-191] - Certain tests fail when checked-out in 'projects'
> subdir
>* [MRELEASE-194] - SNAPSHOT as property bypasses dependency snapshot
> check
>* [MRELEASE-197] - Release plugin documentation on
> maven.apache.org has broken link to release:rollback
>* [MRELEASE-202] - snapshot versions in dependencyManagement are not
> updated
>* [MRELEASE-209] - Snapshot versions are not restored correctly on
> next development version
>* [MRELEASE-219] - Spurious warnings given when a release contains
> subversion externals
>* [MRELEASE-221] - XML header missing in modified POM after
> release:prepare
>* [MRELEASE-222] - Wrong default tag name when used in a reactor
> environment
>
> ** Improvement
>* [MRELEASE-112] - release plugin should have option to ignore
> snapshots of the release plugin
>* [MRELEASE-145] - release:prepare requires all modules to be
SNAPSHOTS
>* [MRELEASE-183] - should report all unresolved dependencies, not
> just the first encountered.
>* [MRELEASE-208] - Support for ClearCase, and other SCMs that do
> checkout projects to subdirectories of the checkout directory
>* [MRELEASE-214] - scm:tag with scmCommentPrefix
>* [MRELEASE-220] - Add property to keep released versions for
> dependencies
>
> ** New Feature
>* [MRELEASE-130] - Create a model for a release
>* [MRELEASE-157] - Share version for multi-module releases
>* [MRELEASE-169] - Provide a mechanism to undo the effects of prepare
>
> ** Task
>* [MRELEASE-141] - Review Plugin Documentation
>* [MRELEASE-162] - Move all release core code in maven/shared
>
> Vote open for 72 hours
>
> My +1
>
> Thanks,
> Stéphane
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Really bizarre scpexe deployment bug
I've just found an utterly bizarre deployment bug. On one particular developer's workstation, deployment, using scpexe, was failing - and it turned out to be that somehow the environment variables are getting corrupted, such that the SSH_AUTH_SOCK variable actually contained its own previous value, followed by a newline, and then the name, an equals sign, and value of another unrelated environment variable! Like so: echo "[$SSH_AUTH_SOCK]" gave: [/tmp/ssh-JAaMN11207/agent.11207 r=svn+ssh://[EMAIL PROTECTED]/svn] Even weirder, this happened with Maven 2.0.6, but not 2.0.5, despite them using the same wagon version. Is there any point in Maven where the environment variables are manipulated in a rather low level way, that could potentially corrupt the environment block itself? The only way I can imagine this particular symptom occurring would be something somehow overwriting one of the null terminators within a raw environment block with a newline character - but that doesn't seem all that likely, especially from Java code, which I would imagine wouldn't even have access to do that. Anyway, any light shed on the mystery, or further debugging suggestions, would be appreciated! Thanks, Max. signature.asc Description: OpenPGP digital signature
Re: maven-install-plugin :: Cannot override read-only parameter: artifactId ?
np :) There's a couple of issues before we can release it though. Cheers, Stéphane On 5/1/07, Vincent Siveton <[EMAIL PROTECTED]> wrote: Hi Stephane, Thanks for this! FYI, we need the 2.2 for the ant plugin release. Cheers, Vincent 2007/5/1, Stephane Nicoll <[EMAIL PROTECTED]>: > On 5/1/07, jbonevich <[EMAIL PROTECTED]> wrote: > > > > I can confirm that a download of the source from svn and building a snapshot > > locally does the trick. > > > > Please, oh, please, maven-lords that be! Please, deploy a new snapshot of > > 2.2 - the one on the snapshot site is almost a year old now. Thanx! > > Done. We can also release it if there is no more pending issues. I'll > have a look. > > Cheers, > Stéphane > > > > jeff > > > > > > > > Jason Dillon wrote: > > > > > > Aighty I figured this out... the tag for maven-install-plugin-2.1 has > > > groupId, artifactId, version, packaging and file all marked with > > > '@readonly'. The latest trunk of maven-install-plugin does not have > > > these tags. > > > > > > So, with 2.1 you can only `mvn install:install-file` from the command- > > > line, and can not use the install-file goal from an execution. > > > > > > We need to get 2.2 released. > > > > > > * * * > > > > > > This worked for me before because I had built 2.2-SNAPSHOT locally > > > (to test my forceVersion patch) and mvn decided to pick that up... > > > not sure why though. Why would mvn pick up a locally built SNAPSHOT > > > and use that instead of the released 2.1? I don't like the magical > > > RELEASE stuff anyways... but I'd not expect that when a for > > > a plugin is omitted that mvn would pick up a non-release to use > > > instead if it finds one in my repo cache. > > > > > > --jason > > > > > > > > > On Apr 2, 2007, at 4:44 PM, Brett Porter wrote: > > > > > >> I thought that had always been the case and was a known issue in > > >> the install plugin. > > >> > > >> On 03/04/2007, at 6:32 AM, Jason Dillon wrote: > > >> > > >>> I all of a sudden started to see this today: > > >>> > > >>> > > >>> [INFO] > > >>> - > > >>> --- > > >>> [ERROR] BUILD ERROR > > >>> [INFO] > > >>> - > > >>> --- > > >>> [INFO] Error configuring: org.apache.maven.plugins:maven-install- > > >>> plugin. Reason: ERROR: Cannot override read-only parameter: > > >>> artifactId in goal: install:install-file > > >>> > > >>> > > >>> From what I can tell this is using maven-install-plugin 2.1. > > >>> > > >>> Anyone know whats going on? I get the same problem with Maven > > >>> 2.0.5 and 2.0.6 :-( > > >>> > > >>> --jason > > >>> > > >>> - > > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> - > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > > View this message in context: http://www.nabble.com/maven-install-plugin-%3A%3A-Cannot-override-read-only-parameter%3A-artifactId---tf3508089s177.html#a10263145 > > Sent from the Maven Developers mailing list archive at Nabble.com. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-install-plugin :: Cannot override read-only parameter: artifactId ?
Hi Stephane, Thanks for this! FYI, we need the 2.2 for the ant plugin release. Cheers, Vincent 2007/5/1, Stephane Nicoll <[EMAIL PROTECTED]>: On 5/1/07, jbonevich <[EMAIL PROTECTED]> wrote: > > I can confirm that a download of the source from svn and building a snapshot > locally does the trick. > > Please, oh, please, maven-lords that be! Please, deploy a new snapshot of > 2.2 - the one on the snapshot site is almost a year old now. Thanx! Done. We can also release it if there is no more pending issues. I'll have a look. Cheers, Stéphane > > jeff > > > > Jason Dillon wrote: > > > > Aighty I figured this out... the tag for maven-install-plugin-2.1 has > > groupId, artifactId, version, packaging and file all marked with > > '@readonly'. The latest trunk of maven-install-plugin does not have > > these tags. > > > > So, with 2.1 you can only `mvn install:install-file` from the command- > > line, and can not use the install-file goal from an execution. > > > > We need to get 2.2 released. > > > > * * * > > > > This worked for me before because I had built 2.2-SNAPSHOT locally > > (to test my forceVersion patch) and mvn decided to pick that up... > > not sure why though. Why would mvn pick up a locally built SNAPSHOT > > and use that instead of the released 2.1? I don't like the magical > > RELEASE stuff anyways... but I'd not expect that when a for > > a plugin is omitted that mvn would pick up a non-release to use > > instead if it finds one in my repo cache. > > > > --jason > > > > > > On Apr 2, 2007, at 4:44 PM, Brett Porter wrote: > > > >> I thought that had always been the case and was a known issue in > >> the install plugin. > >> > >> On 03/04/2007, at 6:32 AM, Jason Dillon wrote: > >> > >>> I all of a sudden started to see this today: > >>> > >>> > >>> [INFO] > >>> - > >>> --- > >>> [ERROR] BUILD ERROR > >>> [INFO] > >>> - > >>> --- > >>> [INFO] Error configuring: org.apache.maven.plugins:maven-install- > >>> plugin. Reason: ERROR: Cannot override read-only parameter: > >>> artifactId in goal: install:install-file > >>> > >>> > >>> From what I can tell this is using maven-install-plugin 2.1. > >>> > >>> Anyone know whats going on? I get the same problem with Maven > >>> 2.0.5 and 2.0.6 :-( > >>> > >>> --jason > >>> > >>> - > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: http://www.nabble.com/maven-install-plugin-%3A%3A-Cannot-override-read-only-parameter%3A-artifactId---tf3508089s177.html#a10263145 > Sent from the Maven Developers mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-release-plugin 2.0-beta-5
+1
Emmanuel
Stephane Nicoll a écrit :
Hi,
I'd like to release the maven release plugin which includes the maven
release manager and the maven release parent pom.
The staging bits are available here:
http://people.apache.org/~snicoll/maven-staging/repo/
Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-5
** Bug
* [MRELEASE-3] - release:prepare should not require multimodule
artifacts to be in the local repository
* [MRELEASE-6] - Multiproject Release: No check in
* [MRELEASE-16] - release-pom is changed too much
* [MRELEASE-35] - release plugin doesn't tag correctly with
svn+ssh when remote and local username don't match
* [MRELEASE-90] - Exception if version is SNAPSHOT
* [MRELEASE-91] - Updating of dependencyManagement inconsistent
with updating of dependencies with regard to SNAPSHOTs
* [MRELEASE-94] - Modified Parent POM is not commited
* [MRELEASE-107] - scm.url gets translated incorrectly during release
* [MRELEASE-110] - release:prepare generates tags with dots,
causing problems with CVS
* [MRELEASE-114] - ${project.artifactId} was replaced with it's
value during release:perform
* [MRELEASE-115] - Issue URL on pom is incorrect
* [MRELEASE-116] - Wrong SCM info put by the release plugin for modules
* [MRELEASE-122] - Versionless Extension causes
NullPointerException in release:prepare
* [MRELEASE-128] - SCM properties being replaced during release:perform
* [MRELEASE-131] - release:prepare failed in 'cvs ... commit'
phase for multi-module build
* [MRELEASE-137] - proposed SCM release tag or label in multiproject
* [MRELEASE-142] - Batch mode release plugin uses an invalid tag
* [MRELEASE-144] - Release plugin did not ask for a Subversion tag
* [MRELEASE-147] - Version number for a dependency with
${pom.groupId} not updated in multi-module.
* [MRELEASE-151] - All child modules are forced to share the same
parent POM
* [MRELEASE-160] - The next snapshot version is not used un submodules
* [MRELEASE-168] - All submodule projects must be from the same
subversion repository
* [MRELEASE-180] - Rewritten poms loose comments
* [MRELEASE-190] - scmTagPhase scm comment when creating the
branch/tag directory uses the prefix [maven-scm]
* [MRELEASE-191] - Certain tests fail when checked-out in 'projects'
subdir
* [MRELEASE-194] - SNAPSHOT as property bypasses dependency snapshot
check
* [MRELEASE-197] - Release plugin documentation on
maven.apache.org has broken link to release:rollback
* [MRELEASE-202] - snapshot versions in dependencyManagement are not
updated
* [MRELEASE-209] - Snapshot versions are not restored correctly on
next development version
* [MRELEASE-219] - Spurious warnings given when a release contains
subversion externals
* [MRELEASE-221] - XML header missing in modified POM after
release:prepare
* [MRELEASE-222] - Wrong default tag name when used in a reactor
environment
** Improvement
* [MRELEASE-112] - release plugin should have option to ignore
snapshots of the release plugin
* [MRELEASE-145] - release:prepare requires all modules to be SNAPSHOTS
* [MRELEASE-183] - should report all unresolved dependencies, not
just the first encountered.
* [MRELEASE-208] - Support for ClearCase, and other SCMs that do
checkout projects to subdirectories of the checkout directory
* [MRELEASE-214] - scm:tag with scmCommentPrefix
* [MRELEASE-220] - Add property to keep released versions for
dependencies
** New Feature
* [MRELEASE-130] - Create a model for a release
* [MRELEASE-157] - Share version for multi-module releases
* [MRELEASE-169] - Provide a mechanism to undo the effects of prepare
** Task
* [MRELEASE-141] - Review Plugin Documentation
* [MRELEASE-162] - Move all release core code in maven/shared
Vote open for 72 hours
My +1
Thanks,
Stéphane
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[vote] release maven-release-plugin 2.0-beta-5
Hi,
I'd like to release the maven release plugin which includes the maven
release manager and the maven release parent pom.
The staging bits are available here:
http://people.apache.org/~snicoll/maven-staging/repo/
Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-5
** Bug
* [MRELEASE-3] - release:prepare should not require multimodule
artifacts to be in the local repository
* [MRELEASE-6] - Multiproject Release: No check in
* [MRELEASE-16] - release-pom is changed too much
* [MRELEASE-35] - release plugin doesn't tag correctly with
svn+ssh when remote and local username don't match
* [MRELEASE-90] - Exception if version is SNAPSHOT
* [MRELEASE-91] - Updating of dependencyManagement inconsistent
with updating of dependencies with regard to SNAPSHOTs
* [MRELEASE-94] - Modified Parent POM is not commited
* [MRELEASE-107] - scm.url gets translated incorrectly during release
* [MRELEASE-110] - release:prepare generates tags with dots,
causing problems with CVS
* [MRELEASE-114] - ${project.artifactId} was replaced with it's
value during release:perform
* [MRELEASE-115] - Issue URL on pom is incorrect
* [MRELEASE-116] - Wrong SCM info put by the release plugin for modules
* [MRELEASE-122] - Versionless Extension causes
NullPointerException in release:prepare
* [MRELEASE-128] - SCM properties being replaced during release:perform
* [MRELEASE-131] - release:prepare failed in 'cvs ... commit'
phase for multi-module build
* [MRELEASE-137] - proposed SCM release tag or label in multiproject
* [MRELEASE-142] - Batch mode release plugin uses an invalid tag
* [MRELEASE-144] - Release plugin did not ask for a Subversion tag
* [MRELEASE-147] - Version number for a dependency with
${pom.groupId} not updated in multi-module.
* [MRELEASE-151] - All child modules are forced to share the same parent POM
* [MRELEASE-160] - The next snapshot version is not used un submodules
* [MRELEASE-168] - All submodule projects must be from the same
subversion repository
* [MRELEASE-180] - Rewritten poms loose comments
* [MRELEASE-190] - scmTagPhase scm comment when creating the
branch/tag directory uses the prefix [maven-scm]
* [MRELEASE-191] - Certain tests fail when checked-out in 'projects' subdir
* [MRELEASE-194] - SNAPSHOT as property bypasses dependency snapshot check
* [MRELEASE-197] - Release plugin documentation on
maven.apache.org has broken link to release:rollback
* [MRELEASE-202] - snapshot versions in dependencyManagement are not updated
* [MRELEASE-209] - Snapshot versions are not restored correctly on
next development version
* [MRELEASE-219] - Spurious warnings given when a release contains
subversion externals
* [MRELEASE-221] - XML header missing in modified POM after release:prepare
* [MRELEASE-222] - Wrong default tag name when used in a reactor environment
** Improvement
* [MRELEASE-112] - release plugin should have option to ignore
snapshots of the release plugin
* [MRELEASE-145] - release:prepare requires all modules to be SNAPSHOTS
* [MRELEASE-183] - should report all unresolved dependencies, not
just the first encountered.
* [MRELEASE-208] - Support for ClearCase, and other SCMs that do
checkout projects to subdirectories of the checkout directory
* [MRELEASE-214] - scm:tag with scmCommentPrefix
* [MRELEASE-220] - Add property to keep released versions for dependencies
** New Feature
* [MRELEASE-130] - Create a model for a release
* [MRELEASE-157] - Share version for multi-module releases
* [MRELEASE-169] - Provide a mechanism to undo the effects of prepare
** Task
* [MRELEASE-141] - Review Plugin Documentation
* [MRELEASE-162] - Move all release core code in maven/shared
Vote open for 72 hours
My +1
Thanks,
Stéphane
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove auto-resolution of plugin versions from Maven 2.1
Le mardi 1 mai 2007, Jerome Lacoste a écrit : > Maybe there could be an easy way to let users use the latest ? maybe > something like > mvn -L ... ( L for latest) > that would ignore all specified versions, without requiring a POM > change ? Maybe too radical. such a LATEST option would be very usefull, not only for plugins but for every dependencies, to do regression testing against latest development version of everything. It would be like if Gump was integrated into Maven: http://gump.apache.org/ I think we would need to differentiate plugin latest from dependencies latest. Hervé > > Cheers, > > Jerome > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release the maven-release-plugin?
You can keep it. Emmanuel Stephane Nicoll a écrit : Howdy, The release manager depends on plexus-utils 1.3. Is this a good idea/supported? Thanks, Stéphane On 4/30/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: Stephane, you can send the vote and release it, I'll continue on the next version. Emmanuel Stephane Nicoll a écrit : > Emmanuel is still working on the release manager so I need to check > with him before releasing the manager and the plugin. > > Emmanuel? > > Thanks, > Stéphane > > On 4/29/07, Robert Kopco <[EMAIL PROTECTED]> wrote: >> Is there any progress on that? >> >> 2007/4/20, Stephane Nicoll <[EMAIL PROTECTED]>: >> >> Okay. I am taking care of that and I'll cast for a vote tonight. >> >> (Unless someone wants to do it earlier) >> >> Cheers, >> Stéphane >> >> On 4/20/07, Dan Tran <[EMAIL PROTECTED]> wrote: >> > +1, please cut beta-5 >> > >> > >> > On 4/19/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: >> > > >> > > I agree. Why not release beta-5 now and then 6 when your >> changes are >> > > ready? >> > > >> > > -Original Message- >> > > From: Stephane Nicoll [mailto:[EMAIL PROTECTED] >> > > Sent: Thursday, April 19, 2007 10:14 AM >> > > To: Maven Developers List >> > > Subject: Re: Release the maven-release-plugin? >> > > >> > > I think it makes sense to release a beta-5 if the changes are >> major >> > > enough. There's nothing that prevents you from releasing >> beta-6 or >> > > -rc1 afterwards. >> > > >> > > Robert, I'll have a look to the issues now. >> > > >> > > Thanks, >> > > Stéphane >> > > >> > > On 4/19/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> > > > I'd like to add more features in this plugin before to >> release it >> like >> > > branch creation, check SNAPSHOTS in properties and not used in >> dependencies >> > > versions >> > > > >> > > > For the moment, the release is planned to be done in one month, >> after >> > > the release of Maven-SCM 1.0 final. >> > > > >> > > > Emmanuel >> > > > >> > > > Robert Kopco a écrit : >> > > > > Thank you very much! >> > > > > >> > > > > Now there are 19 of 25 issues fixed. In would be very >> happy if >> the >> > > > > current state could be released as 2.0-beta-5. The rest >> should >> be >> > > moved >> > > > > to the next version. Besides MRELEASE-6 (which has been >> open for >> 1 1/2 >> > > > > years) none of the remaining issues is critical. >> > > > > >> > > > > What do you think? >> > > > > >> > > > > Best regards, >> > > > > Robert >> > > > > >> > > > > 2007/4/15, Stephane Nicoll <[EMAIL PROTECTED]>: >> > > > > >> > > > >On 4/15/07, Robert Kopco <[EMAIL PROTECTED]> wrote: >> > > > >> It has been 11 month since the last release of the >> > > > > maven-release-plugin. >> > > > >> When will the next release of the plugin >> approximately be? >> > > > >> >> > > > >> There are 10 open issues. For a lot of issues patches >> have >> been >> > > > > provided: >> > > > >> >> > > > >> MRELEASE-128 >> > > > >> MRELEASE-122 >> > > > >> MRELEASE-116 >> > > > >> MRELEASE-90 >> > > > >> MRELEASE-91 >> > > > >> MRELEASE-137 >> > > > >> >> > > > >> Maybe a committer could have a look at one of these. >> > > > > >> > > > >Will do. >> > > > > >> > > > >Thanks, >> > > > >Stéphane >> > > > >> >> > > > >> >> _ >> > > > >> Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN >> Suche >> > > > > Toolbar mit >> > > > >> Windows-Desktopsuche liefert in sekundenschnelle >> Ergebnisse. >> > > Jetzt >> > > > > neu! >> > > > >> http://desktop.msn.de/ Jetzt gratis downloaden! >> > > > >> >> > > > >> >> > > > >> >> > > >> - >> > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > > >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> > > > >> >> > > > >> >> > > > > >> > > > >> > > > >> - >> > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > > >For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > >> > > > > >> _ >> > > > > Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche >> Toolbar >> > > mit >> > > > > Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. >> Jetzt >> > > neu! >> > > > > http://desktop.msn.de/ Jetzt gratis downloaden! >> > > > > >> > > > > >> > > > > >>
Re: Release the maven-release-plugin?
Howdy, The release manager depends on plexus-utils 1.3. Is this a good idea/supported? Thanks, Stéphane On 4/30/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: Stephane, you can send the vote and release it, I'll continue on the next version. Emmanuel Stephane Nicoll a écrit : > Emmanuel is still working on the release manager so I need to check > with him before releasing the manager and the plugin. > > Emmanuel? > > Thanks, > Stéphane > > On 4/29/07, Robert Kopco <[EMAIL PROTECTED]> wrote: >> Is there any progress on that? >> >> 2007/4/20, Stephane Nicoll <[EMAIL PROTECTED]>: >> >> Okay. I am taking care of that and I'll cast for a vote tonight. >> >> (Unless someone wants to do it earlier) >> >> Cheers, >> Stéphane >> >> On 4/20/07, Dan Tran <[EMAIL PROTECTED]> wrote: >> > +1, please cut beta-5 >> > >> > >> > On 4/19/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: >> > > >> > > I agree. Why not release beta-5 now and then 6 when your >> changes are >> > > ready? >> > > >> > > -Original Message- >> > > From: Stephane Nicoll [mailto:[EMAIL PROTECTED] >> > > Sent: Thursday, April 19, 2007 10:14 AM >> > > To: Maven Developers List >> > > Subject: Re: Release the maven-release-plugin? >> > > >> > > I think it makes sense to release a beta-5 if the changes are >> major >> > > enough. There's nothing that prevents you from releasing >> beta-6 or >> > > -rc1 afterwards. >> > > >> > > Robert, I'll have a look to the issues now. >> > > >> > > Thanks, >> > > Stéphane >> > > >> > > On 4/19/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: >> > > > I'd like to add more features in this plugin before to >> release it >> like >> > > branch creation, check SNAPSHOTS in properties and not used in >> dependencies >> > > versions >> > > > >> > > > For the moment, the release is planned to be done in one month, >> after >> > > the release of Maven-SCM 1.0 final. >> > > > >> > > > Emmanuel >> > > > >> > > > Robert Kopco a écrit : >> > > > > Thank you very much! >> > > > > >> > > > > Now there are 19 of 25 issues fixed. In would be very >> happy if >> the >> > > > > current state could be released as 2.0-beta-5. The rest >> should >> be >> > > moved >> > > > > to the next version. Besides MRELEASE-6 (which has been >> open for >> 1 1/2 >> > > > > years) none of the remaining issues is critical. >> > > > > >> > > > > What do you think? >> > > > > >> > > > > Best regards, >> > > > > Robert >> > > > > >> > > > > 2007/4/15, Stephane Nicoll <[EMAIL PROTECTED]>: >> > > > > >> > > > >On 4/15/07, Robert Kopco <[EMAIL PROTECTED]> wrote: >> > > > >> It has been 11 month since the last release of the >> > > > > maven-release-plugin. >> > > > >> When will the next release of the plugin >> approximately be? >> > > > >> >> > > > >> There are 10 open issues. For a lot of issues patches >> have >> been >> > > > > provided: >> > > > >> >> > > > >> MRELEASE-128 >> > > > >> MRELEASE-122 >> > > > >> MRELEASE-116 >> > > > >> MRELEASE-90 >> > > > >> MRELEASE-91 >> > > > >> MRELEASE-137 >> > > > >> >> > > > >> Maybe a committer could have a look at one of these. >> > > > > >> > > > >Will do. >> > > > > >> > > > >Thanks, >> > > > >Stéphane >> > > > >> >> > > > >> >> _ >> > > > >> Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN >> Suche >> > > > > Toolbar mit >> > > > >> Windows-Desktopsuche liefert in sekundenschnelle >> Ergebnisse. >> > > Jetzt >> > > > > neu! >> > > > >> http://desktop.msn.de/ Jetzt gratis downloaden! >> > > > >> >> > > > >> >> > > > >> >> > > >> - >> > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > > >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> > > > >> >> > > > >> >> > > > > >> > > > >> > > > >> - >> > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > > >For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > >> > > > > >> _ >> > > > > Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche >> Toolbar >> > > mit >> > > > > Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. >> Jetzt >> > > neu! >> > > > > http://desktop.msn.de/ Jetzt gratis downloaden! >> > > > > >> > > > > >> > > > > >> - >> > >
Re: maven-install-plugin :: Cannot override read-only parameter: artifactId ?
On 5/1/07, jbonevich <[EMAIL PROTECTED]> wrote: I can confirm that a download of the source from svn and building a snapshot locally does the trick. Please, oh, please, maven-lords that be! Please, deploy a new snapshot of 2.2 - the one on the snapshot site is almost a year old now. Thanx! Done. We can also release it if there is no more pending issues. I'll have a look. Cheers, Stéphane jeff Jason Dillon wrote: > > Aighty I figured this out... the tag for maven-install-plugin-2.1 has > groupId, artifactId, version, packaging and file all marked with > '@readonly'. The latest trunk of maven-install-plugin does not have > these tags. > > So, with 2.1 you can only `mvn install:install-file` from the command- > line, and can not use the install-file goal from an execution. > > We need to get 2.2 released. > > * * * > > This worked for me before because I had built 2.2-SNAPSHOT locally > (to test my forceVersion patch) and mvn decided to pick that up... > not sure why though. Why would mvn pick up a locally built SNAPSHOT > and use that instead of the released 2.1? I don't like the magical > RELEASE stuff anyways... but I'd not expect that when a for > a plugin is omitted that mvn would pick up a non-release to use > instead if it finds one in my repo cache. > > --jason > > > On Apr 2, 2007, at 4:44 PM, Brett Porter wrote: > >> I thought that had always been the case and was a known issue in >> the install plugin. >> >> On 03/04/2007, at 6:32 AM, Jason Dillon wrote: >> >>> I all of a sudden started to see this today: >>> >>> >>> [INFO] >>> - >>> --- >>> [ERROR] BUILD ERROR >>> [INFO] >>> - >>> --- >>> [INFO] Error configuring: org.apache.maven.plugins:maven-install- >>> plugin. Reason: ERROR: Cannot override read-only parameter: >>> artifactId in goal: install:install-file >>> >>> >>> From what I can tell this is using maven-install-plugin 2.1. >>> >>> Anyone know whats going on? I get the same problem with Maven >>> 2.0.5 and 2.0.6 :-( >>> >>> --jason >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/maven-install-plugin-%3A%3A-Cannot-override-read-only-parameter%3A-artifactId---tf3508089s177.html#a10263145 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
