[jira] (MDEP-187) dependency:copy fails when invoked from m2e with workspace resolution enabled, or more generally when copying within reactor for phases earlier than package
[ https://jira.codehaus.org/browse/MDEP-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=364538#comment-364538 ] Torben Knerr commented on MDEP-187: --- Also having this issue. Updating maven-dependency-plugin to >= 2.5 gives me the improved error message, however I do not get rid of the warning. No matter which phase I'm using, it will be always there after doing "Maven -> Update Project..." @Warren: the error disappears after a "mvn clean", but it comes back right after "Maven -> Update Project..."... > dependency:copy fails when invoked from m2e with workspace resolution > enabled, or more generally when copying within reactor for phases earlier > than package > > > Key: MDEP-187 > URL: https://jira.codehaus.org/browse/MDEP-187 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: copy, copy-dependencies >Affects Versions: 2.1 >Reporter: Igor Fedorenko > 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 was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-875) release:prepare does not commit pom.xml if not in the git root
[
https://jira.codehaus.org/browse/MRELEASE-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351113#comment-351113
]
Torben Knerr commented on MRELEASE-875:
---
workaround above {{git config --add status.displayCommentPrefix true}} did not
work for me with Git 1.9.1 and release plugin 2.4.2
> release:prepare does not commit pom.xml if not in the git root
> --
>
> Key: MRELEASE-875
> URL: https://jira.codehaus.org/browse/MRELEASE-875
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, scm
>Affects Versions: 2.5
> Environment: git 1.9.0
>Reporter: john ten Den
>Assignee: Dominik Bartholdi
>
> When the project pom.xml is not in the Git project root (f.e. in the "src"
> directory) the pom.xml not committed and pushed (before tagging)
> Commit of the pom.xml during release:prepare works fine if it is in the /
> (root) of the git repository
> Using the pom.xml in a subdirectory worked well with version 2.4.2 using git
> 1.7.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[
https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35#comment-35
]
Torben Knerr commented on MRELEASE-812:
---
Re: 2.5 solved the problem only for projects with top-level pom files, run into
MRELEASE-875 as well :-/
I tried switching back to 2.4.2 or 2.3.2 but none of the suggested approaches
worked for me (neither with {{LANG=en_US.UTF8}} nor with the git-exe 1.9 plugin
dependency)
> "prepare" does not commit before tagging and therefore deploys snapshot
> instead of release
> --
>
> Key: MRELEASE-812
> URL: https://jira.codehaus.org/browse/MRELEASE-812
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.3.2, 2.4
>Reporter: Andrei Pozolotin
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 2.5
>
> Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt
>
>
> thank you very much for new release!
> http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E
> it seems we need an emergency fix:
> attached are 2 logs:
> 1) mvn-2.3.2.txt invocation that works fine with 2.3.2
> 2) mvn-2.4.0.txt invocation that fails with 2.4
> problem:
> "perform" does not commit tags, deploys snapshot instead of release
> here is project parent:
> http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom
> build is invoked both times with this:
> mvn --define resume=false release:prepare
> mvn --define resume=false release:perform
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[
https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351075#comment-351075
]
Torben Knerr commented on MRELEASE-812:
---
Interestingly, I'm seeing this with maven-3.0.5 / maven-release-plugin 2.4.2 on
our build server (ubuntu) but not on my local windows machine (windows).
I had run exactly the same commands ({{mvn release:clean release:prepare -B -X
-DreleaseVersion=1.0-alpha-1 -DupdateWorkingCopyVersions=false}}) on both my
windows workstation and on our ubuntu buildserver.
They produced exactly the same output, same plugin dependencies (run with
{{-X}} flag), but on the buildserver the commit / push of the modified pom was
missing.
I have no clue why this behaves differently on my windows workstation vs.
buildserver.
Pinning maven-release-plugin to 2.5 in pluginManagement solved the problem for
me.
> "prepare" does not commit before tagging and therefore deploys snapshot
> instead of release
> --
>
> Key: MRELEASE-812
> URL: https://jira.codehaus.org/browse/MRELEASE-812
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.3.2, 2.4
>Reporter: Andrei Pozolotin
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 2.5
>
> Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt
>
>
> thank you very much for new release!
> http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E
> it seems we need an emergency fix:
> attached are 2 logs:
> 1) mvn-2.3.2.txt invocation that works fine with 2.3.2
> 2) mvn-2.4.0.txt invocation that fails with 2.4
> problem:
> "perform" does not commit tags, deploys snapshot instead of release
> here is project parent:
> http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom
> build is invoked both times with this:
> mvn --define resume=false release:prepare
> mvn --define resume=false release:perform
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-484) release:rollback fails after branch with NPE and complaint about missing scm URL
[
https://jira.codehaus.org/browse/MRELEASE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350736#comment-350736
]
Torben Knerr commented on MRELEASE-484:
---
Still seeing this in 2.4.2 with Git scm provider and both
and being set in the releaseBackup pom
> release:rollback fails after branch with NPE and complaint about missing scm
> URL
>
>
> Key: MRELEASE-484
> URL: https://jira.codehaus.org/browse/MRELEASE-484
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch, rollback
>Affects Versions: 2.0-beta-9
>Reporter: Benson Margulies
>Assignee: Robert Scholte
> Fix For: 2.3.2
>
>
> After a problem with release:branch (possibly the 'remoteTagging' problem) an
> attempt to run rollback got me the following. The SCM urls are indeed in the
> POM.
> {noformat}
> [INFO] Trace
> java.lang.NullPointerException: The scm url cannot be null.
> at
> org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:181)
> at
> org.apache.maven.shared.release.scm.DefaultScmRepositoryConfigurator.getConfiguredRepository(DefaultScmRepositoryConfigurator.java:62)
> at
> org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.restorePomBackup(RestoreBackupPomsPhase.java:100)
> at
> org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.execute(RestoreBackupPomsPhase.java:69)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:250)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:227)
> at
> org.apache.maven.plugins.release.RollbackReleaseMojo.execute(RollbackReleaseMojo.java:54)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> 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)
> [INFO]
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3890) Transitive dependencies override explicitly set scope.
[
https://jira.codehaus.org/browse/MNG-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334847#comment-334847
]
Torben Knerr commented on MNG-3890:
---
@Jörg Schaible you mean if I set the {{validation-api}} to {{provided}} scope
within {{}} I don't need the exclusion anymore?
Can not test right now, but that would be great!
> Transitive dependencies override explicitly set scope.
> --
>
> Key: MNG-3890
> URL: https://jira.codehaus.org/browse/MNG-3890
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
>Reporter: Stephan Kleine
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: MMG-3890-core-it-suite.patch, testcase.tar.bz2
>
>
> Transitive dependencies override explicitly set scope.
> E.g. a project A depends on "Hibernate" with default scope and a project B
> depends on project A as well as on "Hibernate" for which it sets the scope
> explicitly to "provided". Further an EAR project C depends on project B (see
> the attached testcase).
> Now I would expect that C does not contain any jars for Hibernate and its
> dependencies since B explicitly set the scope to "provided". Sadly this is
> not the case and C contains all hibernate jars. The only way around this I
> have found is setting the scope to "provided" for Hibernate in A as well -
> which is just a crude hack that produces other issues.
> IMHO this is a bug because Maven should respect the overridden dependency
> scope since the current way forces me to set the scope to provided in A which
> is just wrong.
> Please try to get this fixed for 2.10 or 2.1 since it's a real pita atm.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3890) Transitive dependencies override explicitly set scope.
[
https://jira.codehaus.org/browse/MNG-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334782#comment-334782
]
Torben Knerr commented on MNG-3890:
---
Same problem here. Want to set {{javax.validation:validation-api}} to
{{provided}} but it still ends up being packaged in the .war file, because it
turns out to be a transitive dependency of {{gwt-user}} as well.
Workaround: set it to {{provided}} scope AND {{excludes}} it from the other
artifact:
{code}
com.google.gwt
gwt-user
${gwtVersion}
javax.validation
validation-api
...
javax.validation
validation-api
provided
...
{code}
> Transitive dependencies override explicitly set scope.
> --
>
> Key: MNG-3890
> URL: https://jira.codehaus.org/browse/MNG-3890
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
>Reporter: Stephan Kleine
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: MMG-3890-core-it-suite.patch, testcase.tar.bz2
>
>
> Transitive dependencies override explicitly set scope.
> E.g. a project A depends on "Hibernate" with default scope and a project B
> depends on project A as well as on "Hibernate" for which it sets the scope
> explicitly to "provided". Further an EAR project C depends on project B (see
> the attached testcase).
> Now I would expect that C does not contain any jars for Hibernate and its
> dependencies since B explicitly set the scope to "provided". Sadly this is
> not the case and C contains all hibernate jars. The only way around this I
> have found is setting the scope to "provided" for Hibernate in A as well -
> which is just a crude hack that produces other issues.
> IMHO this is a bug because Maven should respect the overridden dependency
> scope since the current way forces me to set the scope to provided in A which
> is just wrong.
> Please try to get this fixed for 2.10 or 2.1 since it's a real pita atm.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-279) an patterns do not work with .tar.gz packaging
an patterns do not work with .tar.gz packaging
Key: MDEP-279
URL: http://jira.codehaus.org/browse/MDEP-279
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.1, 2.0
Reporter: Torben Knerr
Assignee: Brian Fox
I have created a {{myapp-1.0-jar-with-dependencies.tar.gz}} file using the
maven-assembly-plugin:
{code}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
jar-with-dependencies
tar.gz
false
true
runtime
*:jar:*
{code}
Now I want to unpack {{myapp-1.0-jar-with-dependencies.tar.gz}} to another
maven project's target directory, but exclude some of the files in the .tar.gz
file:
{code}
maven-dependency-plugin
copy-to-shared-folder
generate-sources
unpack
my.group.id
myapp
1.0
jar-with-dependencies
tar.gz
**/*.*
**/bad-file.jar,**/some-stuff.log
${project.build.directory}/myapp-libs
true
true
{code}
*However, the {{}} and {{}} sections are completely
ignored here.*
I have noticed that for {{zip}} dependencies the include/exclude
filters are working as expected, but I would assume that it should for for
{{.tar.gz}} as well
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-220) Unable to access remote catalogs on HTTPS protocol, even with redirection
[
http://jira.codehaus.org/browse/ARCHETYPE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=213197#action_213197
]
Torben Knerr commented on ARCHETYPE-220:
with the https.patch applied you can use the following workaround:
{{... -DarchetypeCatalog=https://user:p...@acme.com/repo/archetype-catalog.xml
...}}
> Unable to access remote catalogs on HTTPS protocol, even with redirection
> -
>
> Key: ARCHETYPE-220
> URL: http://jira.codehaus.org/browse/ARCHETYPE-220
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 2.0-alpha-4
> Environment: Any (Windows, Linux)
>Reporter: Josep F. Barranco
>Priority: Minor
> Attachments: https.patch,
> org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch
>
>
> I use that test:
> 1 - Create an "archetype-catalog.xml" and set it on your apache "htdocs"
> directory
>Executing "mvn archetype:generate -DarchetypeCatalog=http://localhost";
> works fine.
> 2 - Configure your apache to use certificates and allow SSL (port 443) to
> access to same archetype catalog file
>Executing "mvn archetype:generate -DarchetypeCatalog=https://localhost";
> does not work. (it shows default catalog)
>It seems that stating with "https://"; does not match with allowed
> parameter values (local, internal, file:, http:)
> 3 - Anyway, try to redirect your working HTTP access to HTTPS (configure
> rewrite engine on Apache) as workaround to access you SSL catalog.
>Executing "mvn archetype:generate -DarchetypeCatalog=http://localhost";
> (same as step 1) IS NOT WORKING!!! (it shows empty catalog)
> There's no way to access an archetype-catalog.xml located on a SSL url ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-192) Property replacement for required properties
[
http://jira.codehaus.org/browse/ARCHETYPE-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206953#action_206953
]
Torben Knerr commented on ARCHETYPE-192:
When will 2.0-alpha-5 be deployed to repo1.maven.org? I have seen it is already
tagged in svn, so I guess it is already released, right?
> Property replacement for required properties
>
>
> Key: ARCHETYPE-192
> URL: http://jira.codehaus.org/browse/ARCHETYPE-192
> Project: Maven Archetype
> Issue Type: Improvement
>Affects Versions: 2.0-alpha-3
>Reporter: Will Gomes
> Fix For: 2.0-alpha-5
>
>
> It would be nice if one could define default values for required properties
> using other required properties.
> For example:
>
>
>
>
>org.foo.bar.${myModule}.${myApp}
>
>
> having resources
> src/main/java
> dao/MyDao.java
> Main.java
> would produce
> org.foo.bar.mymodule.myapp.dao.MyDao.java
> org.foo.bar.mymodule.myapp.Main.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206951#action_206951
]
Torben Knerr commented on ARCHETYPE-39:
---
+1 for adding Velocity Tools
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity configuration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206951#action_206951
]
Torben Knerr edited comment on ARCHETYPE-39 at 1/14/10 10:35 AM:
-
+1 vote for adding Velocity Tools
was (Author: tknerr):
+1 for adding Velocity Tools
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity configuration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206949#action_206949
]
Torben Knerr commented on MRELEASE-128:
---
+1 for fixing this bug.
The ticket says "Fix Version/s: 2.0.1". Is it now really fixed in 2.0.1?
Are you planning to release a fixed version soon? If it's fixed and tagged in
svn I would not bother to build it myself...
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
>Assignee: Emmanuel Venisse
>Priority: Critical
> Fix For: 2.0.1
>
> Attachments: after-release-perform-pom.xml,
> after-release-prepre-pom.xml, MNG-128-maven-release-manager.patch,
> MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch,
> original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
