[jira] (SCM-188) Add the posibility of adding an entire directory to SCM
[ https://jira.codehaus.org/browse/SCM-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed SCM-188. -- Resolution: Incomplete Fix Version/s: (was: future) I'm closing it as it's probably no longer needed 6 years later > Add the posibility of adding an entire directory to SCM > --- > > Key: SCM-188 > URL: https://jira.codehaus.org/browse/SCM-188 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-api >Affects Versions: 1.0-beta-3 >Reporter: Carlos Sanchez >Priority: Critical > > For the scm wagon I'd need to add a whole directory to scm. > Right now the only solution is create a ScmFileSet, but none of the current > methods adds directories, i have to look for them and add in order so the svn > add works correctly. > It'd be a nice to have in the API an addDirectory or make the add command add > directories recursively (I don't know what's the use case of the current > behaviour) > eg. translated to svn it would call a svn add recursively, also optimizing > the current approach of calling lots of times to external svn -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-747) Support Jazz SCM
[ https://jira.codehaus.org/browse/MRELEASE-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRELEASE-747. - Resolution: Fixed Assignee: Olivier Lamy fixed r1329108 Thanks! > Support Jazz SCM > > > Key: MRELEASE-747 > URL: https://jira.codehaus.org/browse/MRELEASE-747 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: scm >Affects Versions: 2.2.2 > Environment: N/A >Reporter: Chris Graham >Assignee: Olivier Lamy > Fix For: 2.3 > > Attachments: maven-release-2.2.2-patch-jazz.patch > > > The Jazz SCM plugin requires SCM translation of the URL's in the POM. > This patch addresses that. > Note. This issue will ultimately depend on mavn-scm 1.7 being released, as > that version will include the maven-scm-providers-jazz module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-670) Support Jazz SCM
[ https://jira.codehaus.org/browse/SCM-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-670. Resolution: Fixed Fix Version/s: 1.7 Assignee: Olivier Lamy fixed r1329106 Thanks! > Support Jazz SCM > > > Key: SCM-670 > URL: https://jira.codehaus.org/browse/SCM-670 > Project: Maven SCM > Issue Type: New Feature >Affects Versions: 1.7 > Environment: Win XP >Reporter: Chris Graham >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: FlowDiagram.png, FlowDiagramWithMultipleStreams.png, > maven-scm-1.7-snapshot-r1328783-jazz.patch, WorkspaceOnly.png, > WorkspaceWithStream.png > > > This issue, and it's associated patch, adds support for Jazz SCM, the SCM > component of the Jazz/IBM RTC platform. > The four attached images (don't get put into the .patch file!) so they are > attached here. > They need to be saved into the src/site/resources/images folder of the > maven-scm-provider-jazz folder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-154) Bazaar tests should not assume bzr is installed
[ https://jira.codehaus.org/browse/SCM-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-154. Resolution: Fixed Fix Version/s: (was: future) 1.7 Assignee: Olivier Lamy (was: Torbjørn EIkli Smørgrav) > Bazaar tests should not assume bzr is installed > --- > > Key: SCM-154 > URL: https://jira.codehaus.org/browse/SCM-154 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-bazaar >Affects Versions: 1.0-beta-3 >Reporter: Mike Perham >Assignee: Olivier Lamy >Priority: Critical > Fix For: 1.7 > > > Bazaar breaks my SCM build because it assumes it is installed. I do not > think the user should be forced to install Bazaar just to compile the SCM > codebase. See the StarTeam, Perforce and ClearCase providers for examples of > providers which do not assume an installation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-632) Faulty svn commandline is generated for passwords containing redirection characters
[
https://jira.codehaus.org/browse/SCM-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed SCM-632.
Resolution: Fixed
Fix Version/s: 1.7
Assignee: Olivier Lamy
recent p-u version should fix that.
> Faulty svn commandline is generated for passwords containing redirection
> characters
> ---
>
> Key: SCM-632
> URL: https://jira.codehaus.org/browse/SCM-632
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.3
> Environment: Windows Server 2008 R2, Java 6 JDK, Maven 2.2.1
>Reporter: Karl M. Davis
>Assignee: Olivier Lamy
> Fix For: 1.7
>
>
> Similar to SCM-334, I'm getting errors attempting to run a release using a
> password that contains DOS redirection characters-- a pipe character, in my
> case, though I suspect angle brackets would cause similar problems. For the
> time being, the only workarounds seem to be either manually escaping the
> password in my settings.xml (which may cause problems elsewhere) or changing
> the password to not include a pipe (which would be a giant hassle).
> At the start of the Maven debug log I see:
> {code}
> [DEBUG] Plugin dependencies for:
> org.apache.maven.plugins:maven-release-plugin:2.0
> are:
> ...
> org.apache.maven.scm:maven-scm-api:jar:1.3:runtime
> ...
> {code}
> At the end of the debug log I get the following error (edited to obfuscate
> username and half a password):
> {code}
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "svn --username MyUsername --password *
> --non-interactive status"
> [INFO] Working directory:
> J:\DevTools\hudson\jobs\lookups-app-releaseUpdates\workspace\releaseUpdates-3.4
> [HUDSON] Archiving
> J:\DevTools\hudson\jobs\lookups-app-releaseUpdates\workspace\releaseUpdates-3.4\pom.xml
> to
> J:\DevTools\hudson\jobs\lookups-app-releaseUpdates\modules\com.knowledgecc.coplink$lookups-app-parent\builds\2011-09-09_16-35-44\archive\com.knowledgecc.coplink\lookups-app-parent\3.4.76-SNAPSHOT\pom.xml
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to check for local modifications
> Provider message:
> The svn command failed.
> Command output:
> 'halfpass' is not recognized as an internal or external command,
> operable program or batch file.
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.BuildFailureException: Unable to check for local
> modifications
> Provider message:
> The svn command failed.
> Command output:
> 'halfpass' is not recognized as an internal or external command,
> operable program or batch file.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at hudson.maven.agent.Main.launch(Main.java:173)
> at hudson.maven.MavenBuilder.call(MavenBuilder.java:164)
> at
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:868)
> at
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:799)
> at hudson.remoting.UserRequest.perform(UserRequest.java:114)
> at hudson.remoting.UserRequest.perform(UserRequest.
[jira] (SCM-672) Perforce checking (submit) incorrectly ignores working directory
[ https://jira.codehaus.org/browse/SCM-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-672: - Fix Version/s: 1.7 Assignee: Olivier Lamy > Perforce checking (submit) incorrectly ignores working directory > > > Key: SCM-672 > URL: https://jira.codehaus.org/browse/SCM-672 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.6 > Environment: maven 3.0.3 >Reporter: Don Walling >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: patch > > > Similar to SCM-671 for the scm:edit goal, the scm:checkin exeuctes a p4 > submit -i but the command line is being assembled by looking for the files in > the basedir rather than relative to the working dir -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-671) Perforce provider Edit command incorrectly ignores working Directory
[ https://jira.codehaus.org/browse/SCM-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-671: - Fix Version/s: 1.7 Assignee: Olivier Lamy > Perforce provider Edit command incorrectly ignores working Directory > > > Key: SCM-671 > URL: https://jira.codehaus.org/browse/SCM-671 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.6 > Environment: maven 3.0.3 >Reporter: Don Walling >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: patch, PerforceEditCommandTest.java > > > When the working directory is something other than "." the perforce edit > command does not include the relative path to the files actually being > edited. For instance in the case where the directory structure is: > pom.xml > a/pom.xml > a/foo.xml > The command > mvn scm:edit -f a/pom.xml -Dincludes=foo.xml > will result in a failure because the method > PerforceEditCommand.createCommandLine is assembling the path as if foo/.xml > were at the top level. > > A second instance is the case where the directory structure is: > pom.xml > a/pom.xml > a/b/pom.xml > a/b/c/pom.xml > The command > mvn scm:edit -f a/pom.xml -Dincludes=**/pom.xml > will result in only the top-level pom.xml being opened for editing, when it > should open b/pom.xml and b/c/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-672) Perforce checking (submit) incorrectly ignores working directory
[ https://jira.codehaus.org/browse/SCM-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-672. Resolution: Fixed applied. Thanks! > Perforce checking (submit) incorrectly ignores working directory > > > Key: SCM-672 > URL: https://jira.codehaus.org/browse/SCM-672 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.6 > Environment: maven 3.0.3 >Reporter: Don Walling >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: patch > > > Similar to SCM-671 for the scm:edit goal, the scm:checkin exeuctes a p4 > submit -i but the command line is being assembled by looking for the files in > the basedir rather than relative to the working dir -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-671) Perforce provider Edit command incorrectly ignores working Directory
[ https://jira.codehaus.org/browse/SCM-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297017#comment-297017 ] Olivier Lamy commented on SCM-671: -- applied. Thanks! > Perforce provider Edit command incorrectly ignores working Directory > > > Key: SCM-671 > URL: https://jira.codehaus.org/browse/SCM-671 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.6 > Environment: maven 3.0.3 >Reporter: Don Walling >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: patch, PerforceEditCommandTest.java > > > When the working directory is something other than "." the perforce edit > command does not include the relative path to the files actually being > edited. For instance in the case where the directory structure is: > pom.xml > a/pom.xml > a/foo.xml > The command > mvn scm:edit -f a/pom.xml -Dincludes=foo.xml > will result in a failure because the method > PerforceEditCommand.createCommandLine is assembling the path as if foo/.xml > were at the top level. > > A second instance is the case where the directory structure is: > pom.xml > a/pom.xml > a/b/pom.xml > a/b/c/pom.xml > The command > mvn scm:edit -f a/pom.xml -Dincludes=**/pom.xml > will result in only the top-level pom.xml being opened for editing, when it > should open b/pom.xml and b/c/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-406) Support of velocity expressions for user-defined properties
[
https://jira.codehaus.org/browse/ARCHETYPE-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297022#comment-297022
]
Alistair A. Israel commented on ARCHETYPE-406:
--
Does [ARCHETYPE-397|https://jira.codehaus.org/browse/ARCHETYPE-397] address
this, too?
> Support of velocity expressions for user-defined properties
> ---
>
> Key: ARCHETYPE-406
> URL: https://jira.codehaus.org/browse/ARCHETYPE-406
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.x
>Reporter: Bue Pierre-Christophe
>
> Standard properties (artifactId, groupId, ...) are supported in Velocity
> expressiosn, but still does not work with user defined properties. For
> example:
>
> ${artifactId}.substring(0,1).toUpperCase()
>
> with artifactId=toto will give a=T, but
>
>
> ${b}.substring(0,1).toUpperCase()
>
> with b=toto will give a=${b}.substring(0,1).toUpperCase()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-351) dependency:tree is not resolved on assembly project with ear dependency type
Eric TOUTUT created MDEP-351: Summary: dependency:tree is not resolved on assembly project with ear dependency type Key: MDEP-351 URL: https://jira.codehaus.org/browse/MDEP-351 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: tree Affects Versions: 2.4 Environment: Maven 3.0.4, Windows Vista Reporter: Eric TOUTUT Attachments: assembly-projects.zip I'd like to get complete dependency:tree on an assembly project that depends on ear artifacts When dependency type is ear, the tree ends at 1st level : [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ assembly --- [INFO] demo.assembly:assembly:pom:1.0-SNAPSHOT [INFO] \- demo.assembly:deploy:ear:1.0-SNAPSHOT:compile If i change dependency type to pom, the tree is complete (i see ear's modules) : [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ assembly --- [INFO] demo.assembly:assembly:pom:1.0-SNAPSHOT [INFO] \- demo.assembly:deploy:pom:1.0-SNAPSHOT:compile [INFO]\- demo.assembly:webservice:ejb:1.0-SNAPSHOT:compile [INFO] \- javax.ejb:ejb-api:jar:3.0:compile Best regards Eric -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Latombe updated MSITE-604:
--
Attachment: MSITE-604-maven3-2.patch
Second patch only on site-plugin, still limited to Maven 3
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: 3.1
>
> Attachments: MSITE-604-maven3-2.patch, MSITE-604-maven3.patch,
> MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-272) Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions.
[ https://jira.codehaus.org/browse/MCHANGES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297028#comment-297028 ] Benson Margulies commented on MCHANGES-272: --- What about timestamp snapshots? Those don't have -SNAPSHOT in their name anywhere. > Please add an option to the 'changes-check' goal to allow skipping release > date checks of snapshot versions. > > > Key: MCHANGES-272 > URL: https://jira.codehaus.org/browse/MCHANGES-272 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Affects Versions: 2.6 >Reporter: Christian Schulte >Assignee: Benson Margulies >Priority: Trivial > Attachments: MCHANGES-272.patch > > > The 'changes-check' goal treats snapshot versions the same way as release > versions by removing the '-SNAPSHOT' suffix prior to checking the release > date. Please add an option to the 'changes-check' goal to allow skipping > snapshot versions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-187) dependency:copy fails when invoked from m2e with workspace resolution enabled
[ https://jira.codehaus.org/browse/MDEP-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolás Cornaglia updated MDEP-187: --- Attachment: MDEP-187c.diff My 2cents to this bug with m2e. Added support to copy the expanded directory to expanded folders. > dependency:copy fails when invoked from m2e with workspace resolution enabled > - > > Key: MDEP-187 > URL: https://jira.codehaus.org/browse/MDEP-187 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Igor Fedorenko >Assignee: Brian Fox > Attachments: MDEP-187b.diff, MDEP-187c.diff, MDEP-187.diff > > > m2e resolves workspace artifacts to their output folders but dependency:copy > expects all artifacts to be files. I will provide trivial patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-679) CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
https://jira.codehaus.org/browse/MRELEASE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297036#comment-297036
]
Vedavyas Panneershelvam commented on MRELEASE-679:
--
Using Maven version 3.0.3 and Maven Release Plugin version from (2.0 - 2.2),
the content of the created tag includes
|-- branches
|-- tags
|-- trunk
The SCM structure is
Repo
|-- branches
|-- tags
|-- trunk
|-- parent
|-- module1
|-- module2
|-- etc
The parent-pom.xml aggregates the child modules and all the child modules refer
the parent module as the parent.
And Frans suggestion of passing -DConnectionUrl didn't work either.
> CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/
> instead of project/trunk
> --
>
> Key: MRELEASE-679
> URL: https://jira.codehaus.org/browse/MRELEASE-679
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Claus Gebert
>Assignee: Brett Porter
>Priority: Critical
>
> We have switched to the release plug-in 2.0 and are using the prepare goal as
> we did before using version 2.0-beta-9. Unfortunately, the tag which is now
> created is copied from the project level, and from the trunk. With version
> 2.0-beta-9, the tag was correctly copied from the trunk.
> With 2.0-beta-9:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- pom.xml
> |-- src/
> {noformat}
> With 2.0:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- trunk/
>|-- pom.xml
>|-- src/
> |-- tags/
> |-- branches/
> {noformat}
> Our _pom.xml_ SCM information is declared as follow:
> {noformat}
>
>
> scm:svn:svn://host/path/project/trunk
>
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-679) CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
https://jira.codehaus.org/browse/MRELEASE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297036#comment-297036
]
Vedavyas Panneershelvam edited comment on MRELEASE-679 at 4/23/12 9:03 AM:
---
Using Maven version 3.0.3 and Maven Release Plugin version from (2.0 - 2.2),
the content of the created tag includes branches, tags and trunk instead of the
contents of trunk alone.
The SCM structure is
Repo
|-- branches
|-- tags
|-- trunk
|-- parent
|-- module1
|-- module2
|-- etc
The parent-pom.xml aggregates the child modules and all the child modules refer
the parent module as the parent.
And Frans suggestion of passing -DConnectionUrl didn't work either.
was (Author: ved):
Using Maven version 3.0.3 and Maven Release Plugin version from (2.0 -
2.2), the content of the created tag includes
|-- branches
|-- tags
|-- trunk
The SCM structure is
Repo
|-- branches
|-- tags
|-- trunk
|-- parent
|-- module1
|-- module2
|-- etc
The parent-pom.xml aggregates the child modules and all the child modules refer
the parent module as the parent.
And Frans suggestion of passing -DConnectionUrl didn't work either.
> CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/
> instead of project/trunk
> --
>
> Key: MRELEASE-679
> URL: https://jira.codehaus.org/browse/MRELEASE-679
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Claus Gebert
>Assignee: Brett Porter
>Priority: Critical
>
> We have switched to the release plug-in 2.0 and are using the prepare goal as
> we did before using version 2.0-beta-9. Unfortunately, the tag which is now
> created is copied from the project level, and from the trunk. With version
> 2.0-beta-9, the tag was correctly copied from the trunk.
> With 2.0-beta-9:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- pom.xml
> |-- src/
> {noformat}
> With 2.0:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- trunk/
>|-- pom.xml
>|-- src/
> |-- tags/
> |-- branches/
> {noformat}
> Our _pom.xml_ SCM information is declared as follow:
> {noformat}
>
>
> scm:svn:svn://host/path/project/trunk
>
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-679) CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
https://jira.codehaus.org/browse/MRELEASE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297036#comment-297036
]
Vedavyas Panneershelvam edited comment on MRELEASE-679 at 4/23/12 9:07 AM:
---
Using Maven version 3.0.3 and Maven Release Plugin version from (2.0 - 2.2),
the content of the created tag includes
{noformat}
tagname
|-- branches
|-- tags
|-- trunk
{noformat}
The SCM structure is
{noformat}
Repo
|-- branches
|-- tags
|-- trunk
|-- parent
|-- module1
|-- module2
|-- etc
{noformat}
The parent-pom.xml aggregates the child modules and all the child modules refer
the parent module as the parent.
And Frans suggestion of passing -DConnectionUrl didn't work either.
was (Author: ved):
Using Maven version 3.0.3 and Maven Release Plugin version from (2.0 -
2.2), the content of the created tag includes branches, tags and trunk instead
of the contents of trunk alone.
The SCM structure is
Repo
|-- branches
|-- tags
|-- trunk
|-- parent
|-- module1
|-- module2
|-- etc
The parent-pom.xml aggregates the child modules and all the child modules refer
the parent module as the parent.
And Frans suggestion of passing -DConnectionUrl didn't work either.
> CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/
> instead of project/trunk
> --
>
> Key: MRELEASE-679
> URL: https://jira.codehaus.org/browse/MRELEASE-679
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Claus Gebert
>Assignee: Brett Porter
>Priority: Critical
>
> We have switched to the release plug-in 2.0 and are using the prepare goal as
> we did before using version 2.0-beta-9. Unfortunately, the tag which is now
> created is copied from the project level, and from the trunk. With version
> 2.0-beta-9, the tag was correctly copied from the trunk.
> With 2.0-beta-9:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- pom.xml
> |-- src/
> {noformat}
> With 2.0:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- trunk/
>|-- pom.xml
>|-- src/
> |-- tags/
> |-- branches/
> {noformat}
> Our _pom.xml_ SCM information is declared as follow:
> {noformat}
>
>
> scm:svn:svn://host/path/project/trunk
>
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAR-153) Missing continuation characters in Export-Package field
Rich Seddon created MJAR-153:
Summary: Missing continuation characters in Export-Package field
Key: MJAR-153
URL: https://jira.codehaus.org/browse/MJAR-153
Project: Maven 2.x JAR Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Linux, Maven 3.0.4
Reporter: Rich Seddon
Attachments: pom.xml
The following plugin configuration results in an "Export-Package" field which
has two problems. First, every other line has "CR" instead of just "CRLF'.
Second, every other line is missing the continuation character. This latter
problem results in an invalid header exception when the jar is opened by Java.
{code:XML}
maven-jar-plugin
2.4
a.test.of.maven-jar-plugin
2
org.jboss.weld.osgi-bundle
org.jboss.weld.literal,
org.jboss.weld.logging,
org.jboss.weld.logging.messages,
org.jboss.metadata.validation,
org.jboss.weld.bean.interceptor,
org.jboss.weld.metadata,
org.jboss.weld.metadata.cache,
org.jboss.weld.resources,
org.jboss.weld.test,
org.jboss.weld.tests,
org.jboss.weld.tests.extensions,
org.jboss.weld.tests.extensions.injectionTarget,
org.jboss.weld.exceptions,
a.test.of.maven-jar-plugin
{code}
Here's the manifest contents:
{noformat}
Manifest-Version: 1.0^M
Export-Package: org.jboss.weld.literal,
org.jboss.weld.logging,
org.jb^M
oss.weld.logging.messages,
org.jboss.metadata.validation,
org.jboss.w^M
eld.bean.interceptor,
org.jboss.weld.metadata,
org.jboss.weld.metadat^M
a.cache,
org.jboss.weld.resources,
org.jboss.weld.test,
org.jboss.wel^M
d.tests,
org.jboss.weld.tests.extensions,
org.jboss.weld.tests.extens^M
ions.injectionTarget,
org.jboss.weld.exceptions,^M
Fragment-Host: org.jboss.weld.osgi-bundle^M
Built-By: rseddon^M
Build-Jdk: 1.6.0_29^M
Bundle-ManifestVersion: 2^M
Created-By: Apache Maven^M
Bundle-Description: a.test.of.maven-jar-plugin^M
Bundle-SymbolicName: a.test.of.maven-jar-plugin^M
Archiver-Version: Plexus Archiver^M
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5278) deploy:deploy does not work for only Deploying artifact to Maven Remote repo
Himanshu Goyal created MNG-5278: --- Summary: deploy:deploy does not work for only Deploying artifact to Maven Remote repo Key: MNG-5278 URL: https://jira.codehaus.org/browse/MNG-5278 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0.3, 2.2.1 Environment: Windows Reporter: Himanshu Goyal Priority: Critical Attachments: mvnDeployException.jpeg I did a mvn install in the first place in order to generate artifact for my maven project. As a second step I wanted to make a decision to only "deploy" the generated artifact to the remote repo using "mvn deploy:deploy" command Since the artifact is already been compiled, created inside target folders, there should not be any need to force a developer to rerun everything if we wish to only upload the artifact to remote repo. When we execute "mvn deploy:deploy", it gives the following error: org.apache.maven.lifecycle.LifecycleExecutionException: The packaging for this project did not assign a file to the build artifact at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: The packaging for this project did not assign a file to the build artifact at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:182) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAR-153) Missing continuation characters in Export-Package field
[
https://jira.codehaus.org/browse/MJAR-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297052#comment-297052
]
Jane Young commented on MJAR-153:
-
The same problem is happening in "Import-Package" field.
> Missing continuation characters in Export-Package field
> ---
>
> Key: MJAR-153
> URL: https://jira.codehaus.org/browse/MJAR-153
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Linux, Maven 3.0.4
>Reporter: Rich Seddon
> Attachments: pom.xml
>
>
> The following plugin configuration results in an "Export-Package" field which
> has two problems. First, every other line has "CR" instead of just "CRLF'.
> Second, every other line is missing the continuation character. This latter
> problem results in an invalid header exception when the jar is opened by Java.
> {code:XML}
>
> maven-jar-plugin
> 2.4
>
>
>
>
> a.test.of.maven-jar-plugin
> 2
>
> org.jboss.weld.osgi-bundle
>
> org.jboss.weld.literal,
> org.jboss.weld.logging,
> org.jboss.weld.logging.messages,
> org.jboss.metadata.validation,
> org.jboss.weld.bean.interceptor,
> org.jboss.weld.metadata,
> org.jboss.weld.metadata.cache,
> org.jboss.weld.resources,
> org.jboss.weld.test,
> org.jboss.weld.tests,
> org.jboss.weld.tests.extensions,
> org.jboss.weld.tests.extensions.injectionTarget,
> org.jboss.weld.exceptions,
>
>
> a.test.of.maven-jar-plugin
>
>
>
>
> {code}
> Here's the manifest contents:
> {noformat}
> Manifest-Version: 1.0^M
> Export-Package: org.jboss.weld.literal,
> org.jboss.weld.logging,
> org.jb^M
> oss.weld.logging.messages,
> org.jboss.metadata.validation,
> org.jboss.w^M
> eld.bean.interceptor,
> org.jboss.weld.metadata,
> org.jboss.weld.metadat^M
> a.cache,
> org.jboss.weld.resources,
> org.jboss.weld.test,
> org.jboss.wel^M
> d.tests,
> org.jboss.weld.tests.extensions,
> org.jboss.weld.tests.extens^M
> ions.injectionTarget,
> org.jboss.weld.exceptions,^M
> Fragment-Host: org.jboss.weld.osgi-bundle^M
> Built-By: rseddon^M
> Build-Jdk: 1.6.0_29^M
> Bundle-ManifestVersion: 2^M
> Created-By: Apache Maven^M
> Bundle-Description: a.test.of.maven-jar-plugin^M
> Bundle-SymbolicName: a.test.of.maven-jar-plugin^M
> Archiver-Version: Plexus Archiver^M
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-577) SvnCheckInConsumer is "English locale" dependent
[ https://jira.codehaus.org/browse/SCM-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed SCM-577. -- Resolution: Duplicate Assignee: Robert Scholte > SvnCheckInConsumer is "English locale" dependent > > > Key: SCM-577 > URL: https://jira.codehaus.org/browse/SCM-577 > Project: Maven SCM > Issue Type: Bug > Environment: Debian > Locale fr_FR >Reporter: Frédéric Camblor >Assignee: Robert Scholte >Priority: Critical > > Looking at the SvnCheckInConsumer class (here : > http://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.3/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/main/java/org/apache/maven/scm/provider/svn/svnexe/command/checkin/SvnCheckInConsumer.java) > we can say that if message displayed while commiting file is not "Committed > revision XXX", revision parsing will fail ! > Maybe the implementation should look at the current Locale ? > Or (maybe simplier) some regex such as [^0-9]*([0-9]+)[^0-9]* should be used > to match/retrieve current revision number after commit ? > When using French locale, revision 0 is returned to the SVN commit result ... > so, later, tagging fails with some spacy message "revision 0 doesn't exist". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[ https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Friedenhagen updated MRELEASE-723: Attachment: add-tag-to-release-poms-1329108.patch Modify patch to work with r1329108. > DCVS tagging commands should store the tag-name (or hash) in the the > //project/scm/tag element. > --- > > Key: MRELEASE-723 > URL: https://jira.codehaus.org/browse/MRELEASE-723 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: Git, Mercurial, Subversion > Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 > 14:58:54+0100) > Maven home: /usr/local/Cellar/maven/current/libexec > Java version: 1.6.0_29, vendor: Apple Inc. > Java home: > /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home > Default locale: de_DE, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac" >Reporter: Mirko Friedenhagen > Fix For: 2.3 > > Attachments: add-tag-to-release-poms-1329108.patch, > add-tag-to-release-poms.patch > > > With SVN the developerConnection and connection are > updated to the "real" release URL, that is when I invoke release:prepare with > a URL like: > https://SVNSERVER/svn/REPO/myproject/branches/release it will be > replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 > which is fine because now you know which revision to checkout for > building the release. > With git there is no such possibility to realize this with rewriting > the URL AFAIK. So I would have expected however, that maybe the > //project/scm/tag > element would be updated to reflect the fact, that the pom is the one > of release, either to the "symbolic name" myproject-1.0 or to the hash > of the tag. > See http://markmail.org/thread/m77cvhqqq56krzzd as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-272) Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions.
[ https://jira.codehaus.org/browse/MCHANGES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297061#comment-297061 ] Dennis Lundberg commented on MCHANGES-272: -- The need for such an option indicates to me that you might not be using this goal the way it was intended. For me this goal is supposed to be used in a release profile or something similar, so that it is only run prior to a release being made. What is your use case? > Please add an option to the 'changes-check' goal to allow skipping release > date checks of snapshot versions. > > > Key: MCHANGES-272 > URL: https://jira.codehaus.org/browse/MCHANGES-272 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Affects Versions: 2.6 >Reporter: Christian Schulte >Assignee: Benson Margulies >Priority: Trivial > Attachments: MCHANGES-272.patch > > > The 'changes-check' goal treats snapshot versions the same way as release > versions by removing the '-SNAPSHOT' suffix prior to checking the release > date. Please add an option to the 'changes-check' goal to allow skipping > snapshot versions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-679) CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
https://jira.codehaus.org/browse/MRELEASE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297063#comment-297063
]
Robert Scholte commented on MRELEASE-679:
-
Vedavyas,
Does the pom.xml from which you try to release contain a {{}}-section and
if yes: what is its content?
The most recent version of the maven-release-plugin is 2.2.2, does this version
have the same issue?
> CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/
> instead of project/trunk
> --
>
> Key: MRELEASE-679
> URL: https://jira.codehaus.org/browse/MRELEASE-679
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Claus Gebert
>Assignee: Brett Porter
>Priority: Critical
>
> We have switched to the release plug-in 2.0 and are using the prepare goal as
> we did before using version 2.0-beta-9. Unfortunately, the tag which is now
> created is copied from the project level, and from the trunk. With version
> 2.0-beta-9, the tag was correctly copied from the trunk.
> With 2.0-beta-9:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- pom.xml
> |-- src/
> {noformat}
> With 2.0:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- trunk/
>|-- pom.xml
>|-- src/
> |-- tags/
> |-- branches/
> {noformat}
> Our _pom.xml_ SCM information is declared as follow:
> {noformat}
>
>
> scm:svn:svn://host/path/project/trunk
>
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-272) Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions.
[ https://jira.codehaus.org/browse/MCHANGES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297064#comment-297064 ] Christian Schulte commented on MCHANGES-272: I would like to be able to enable the release profile when building snapshots (e.g. for testing the release build or for deploying snapshots publicly). Just like 'mvn deploy' automatically chooses a repository to upload to based on the kind of artifact acted upon, I would like to avoid having to invoke maven differently based on the kind of artifact acted upon when enabling the release profile. The current behavior of the 'changes-check' goal makes this impossible, since it will fail the build when building a snapshot for which no matching release version is found in the 'changes.xml' file or for which no release date is found which makes no sense for snapshots, IMHO. Therefore, the goal should automatically skip itself, when building a snapshot. > Please add an option to the 'changes-check' goal to allow skipping release > date checks of snapshot versions. > > > Key: MCHANGES-272 > URL: https://jira.codehaus.org/browse/MCHANGES-272 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Affects Versions: 2.6 >Reporter: Christian Schulte >Assignee: Benson Margulies >Priority: Trivial > Attachments: MCHANGES-272.patch > > > The 'changes-check' goal treats snapshot versions the same way as release > versions by removing the '-SNAPSHOT' suffix prior to checking the release > date. Please add an option to the 'changes-check' goal to allow skipping > snapshot versions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-272) Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions.
[ https://jira.codehaus.org/browse/MCHANGES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297065#comment-297065 ] Benson Margulies commented on MCHANGES-272: --- I would commit this if I could find the recipe for looking a a timestamp snapshot version and determining that it is, in fact, a snapshot version. It has to be in maven core somewhere. > Please add an option to the 'changes-check' goal to allow skipping release > date checks of snapshot versions. > > > Key: MCHANGES-272 > URL: https://jira.codehaus.org/browse/MCHANGES-272 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Affects Versions: 2.6 >Reporter: Christian Schulte >Assignee: Benson Margulies >Priority: Trivial > Attachments: MCHANGES-272.patch > > > The 'changes-check' goal treats snapshot versions the same way as release > versions by removing the '-SNAPSHOT' suffix prior to checking the release > date. Please add an option to the 'changes-check' goal to allow skipping > snapshot versions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-272) Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions.
[ https://jira.codehaus.org/browse/MCHANGES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MCHANGES-272: --- Attachment: MCHANGES-272.patch Updated patch to use 'ArtifactUtils.isSnapshot'. I am not sure if method 'ReleaseUtils.getLatestRelease' also needs updating to support timestamp snapshot version. > Please add an option to the 'changes-check' goal to allow skipping release > date checks of snapshot versions. > > > Key: MCHANGES-272 > URL: https://jira.codehaus.org/browse/MCHANGES-272 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Affects Versions: 2.6 >Reporter: Christian Schulte >Assignee: Benson Margulies >Priority: Trivial > Attachments: MCHANGES-272.patch, MCHANGES-272.patch > > > The 'changes-check' goal treats snapshot versions the same way as release > versions by removing the '-SNAPSHOT' suffix prior to checking the release > date. Please add an option to the 'changes-check' goal to allow skipping > snapshot versions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-272) Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions.
[ https://jira.codehaus.org/browse/MCHANGES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MCHANGES-272. - Resolution: Fixed Fix Version/s: 2.7 r1329514 | bimargulies | 2012-04-23 20:39:20 -0400 (Mon, 23 Apr 2012) | 2 lines [MCHANGES-272]: Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions. > Please add an option to the 'changes-check' goal to allow skipping release > date checks of snapshot versions. > > > Key: MCHANGES-272 > URL: https://jira.codehaus.org/browse/MCHANGES-272 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Affects Versions: 2.6 >Reporter: Christian Schulte >Assignee: Benson Margulies >Priority: Trivial > Fix For: 2.7 > > Attachments: MCHANGES-272.patch, MCHANGES-272.patch > > > The 'changes-check' goal treats snapshot versions the same way as release > versions by removing the '-SNAPSHOT' suffix prior to checking the release > date. Please add an option to the 'changes-check' goal to allow skipping > snapshot versions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-670) Support Jazz SCM
[ https://jira.codehaus.org/browse/SCM-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Graham updated SCM-670: - Attachment: jazz-site-xml-update.patch patch to add in the missing site link to the tck tests page generated by the site goal. > Support Jazz SCM > > > Key: SCM-670 > URL: https://jira.codehaus.org/browse/SCM-670 > Project: Maven SCM > Issue Type: New Feature >Affects Versions: 1.7 > Environment: Win XP >Reporter: Chris Graham >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: FlowDiagram.png, FlowDiagramWithMultipleStreams.png, > jazz-site-xml-update.patch, maven-scm-1.7-snapshot-r1328783-jazz.patch, > WorkspaceOnly.png, WorkspaceWithStream.png > > > This issue, and it's associated patch, adds support for Jazz SCM, the SCM > component of the Jazz/IBM RTC platform. > The four attached images (don't get put into the .patch file!) so they are > attached here. > They need to be saved into the src/site/resources/images folder of the > maven-scm-provider-jazz folder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-670) Support Jazz SCM
[ https://jira.codehaus.org/browse/SCM-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Graham reopened SCM-670: -- Oops. I forgot to add in the TCK Tests degtails page into site.xml. Patch attached, > Support Jazz SCM > > > Key: SCM-670 > URL: https://jira.codehaus.org/browse/SCM-670 > Project: Maven SCM > Issue Type: New Feature >Affects Versions: 1.7 > Environment: Win XP >Reporter: Chris Graham >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: FlowDiagram.png, FlowDiagramWithMultipleStreams.png, > jazz-site-xml-update.patch, maven-scm-1.7-snapshot-r1328783-jazz.patch, > WorkspaceOnly.png, WorkspaceWithStream.png > > > This issue, and it's associated patch, adds support for Jazz SCM, the SCM > component of the Jazz/IBM RTC platform. > The four attached images (don't get put into the .patch file!) so they are > attached here. > They need to be saved into the src/site/resources/images folder of the > maven-scm-provider-jazz folder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-388) scm:clearcase:load ..... should support more than one loadrule
[
https://jira.codehaus.org/browse/SCM-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297081#comment-297081
]
Chris Graham commented on SCM-388:
--
Does that mean that this issue can be closed?
> scm:clearcase:load . should support more than one loadrule
> --
>
> Key: SCM-388
> URL: https://jira.codehaus.org/browse/SCM-388
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.0-beta-3
> Environment: Windows XP, Maven 2.0.9
>Reporter: Torsten Reinhard
>
> With auto-generated configSpecs actually there is a limitation:
> ...
> Specify one load rule for the project you want to check out within the SCM URL
> ...
> In many cases, more than one loadRule would be very useful - this will also
> prevent from moving modules from one directory to another, just for having
> them all under one parent-directory for scm:goal purposes.
> Therefore specifying
> scm:clearcase:load /MY_VOB/my/project/dir, load /MY_VOB/my/project/dir2, load
> /MY_VOB/my/project/dir3
> could be an idea?
> The fix for that is just a StringTokenizer in the method
> protected String createConfigSpec( String loadDirectory, ScmVersion
> version )
> {
>
> // TODO replace this with a StringTokenizer
> configSpec.append( "load " + loadDirectory + "\n" );
> return configSpec.toString();
> }
> at
> org.apache.maven.scm.provider.clearcase.command.checkout.ClearCaseCheckOutCommand
>
> Can anyone do that little enhancement?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-388) scm:clearcase:load ..... should support more than one loadrule
[
https://jira.codehaus.org/browse/SCM-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297083#comment-297083
]
Anders Hammar commented on SCM-388:
---
I think that some documentation update around this would be good.
> scm:clearcase:load . should support more than one loadrule
> --
>
> Key: SCM-388
> URL: https://jira.codehaus.org/browse/SCM-388
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.0-beta-3
> Environment: Windows XP, Maven 2.0.9
>Reporter: Torsten Reinhard
>
> With auto-generated configSpecs actually there is a limitation:
> ...
> Specify one load rule for the project you want to check out within the SCM URL
> ...
> In many cases, more than one loadRule would be very useful - this will also
> prevent from moving modules from one directory to another, just for having
> them all under one parent-directory for scm:goal purposes.
> Therefore specifying
> scm:clearcase:load /MY_VOB/my/project/dir, load /MY_VOB/my/project/dir2, load
> /MY_VOB/my/project/dir3
> could be an idea?
> The fix for that is just a StringTokenizer in the method
> protected String createConfigSpec( String loadDirectory, ScmVersion
> version )
> {
>
> // TODO replace this with a StringTokenizer
> configSpec.append( "load " + loadDirectory + "\n" );
> return configSpec.toString();
> }
> at
> org.apache.maven.scm.provider.clearcase.command.checkout.ClearCaseCheckOutCommand
>
> Can anyone do that little enhancement?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
