[jira] Updated: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic updated ARCHETYPE-273: --- Attachment: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch Attaching proposed patch to archetype trunk r892601 ([^org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch]) with new ImportRemoteCatalogMojo (archetype:import-catalog goal, mandatory repository parameter with no default value, and optional repositoryId parameter defaulting to archetype value). When run import mojo will: - load remote archetype catalog from %repository%/archetype-catalog.xml URL; - load local archetype catalog from %localRepository%/archetype-catalog.xml; - loop through archetypes listed in remote archetype catalog and for each check: -- if remote archetype is not listed in local archetype catalog import mojo will download archetype artifact into local repository and update local archetype catalog; - and finally save local archetype catalog to %localRepository%/archetype-catalog.xml. This patch also contains my patch for ARCHETYPE-220, adding support for archetypeRepositoryId parameter to archetype:generate goal. Will look into separating the two if possible. Existing tests pass. No new tests have been added yet. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- 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] Closed: (MNG-4503) Project building exception : Cannot find parent
[
http://jira.codehaus.org/browse/MNG-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4503.
--
Resolution: Not A Bug
Assignee: Benjamin Bentmann
bq. If maven-parent is not available at relative path it should download it
from the central.
And it does:
{noformat}
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
Unable to download the artifact from any repository
org.apache.maven:maven-parent:pom:11
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
{noformat}
As this POM is available from
[central|http://repo2.maven.org/maven2/org/apache/maven/maven-parent/11/], this
indicates you have a network/proxy problem. Please use the [user mailing
list|http://maven.apache.org/mail-lists.html] to solve your environment issue.
Project building exception : Cannot find parent
---
Key: MNG-4503
URL: http://jira.codehaus.org/browse/MNG-4503
Project: Maven 2 3
Issue Type: Bug
Components: POM
Affects Versions: 2.1.0
Environment: Windows
Reporter: amaresh mourya
Assignee: Benjamin Bentmann
Attachments: apache-maven-2.2.0.rar
I ran the org.apache.maven.project.MavenProject build() method from
DeafultMavenProjectBuilder for maven-artifact's pom.xml (A) to build Maven
Project for maven-artifact, but since it is derived from
org.apache.maven:maven:2.2.0 's pom.xml which has parent entry like shown
below (B), and maven-parent is not located at relative path is gives me the
following error (C):
If maven-parent is not available at relative path it should download it from
the central.
1. I haven't touched my local repo.
2. my setting.xml resides at \apache-maven-2.1.0\conf\settings.xml and have
just proxy information
3. I have attached my test case with setting.xml
A: part of maven-artifact's pom.xml
parent
groupIdorg.apache.maven/groupId
artifactIdmaven/artifactId
version2.2.0/version
/parent
artifactIdmaven-artifact/artifactId
B:part of maven's pom.xml
parent
groupIdorg.apache.maven/groupId
artifactIdmaven-parent/artifactId
version11/version
relativePath../pom/maven/pom.xml/relativePath
/parent
artifactIdmaven/artifactId
version2.2.0/version
packagingpom/packaging
C:Error thrown
org.apache.maven.project.ProjectBuildingException: Cannot find parent:
org.apache.maven:maven-parent for project: null:maven:pom:2.2.0 for project
null:maven:pom:2.2.0
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1398)
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1415)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:823)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:508)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:217)
at
oracle.jdeveloper.maven.node.POMNode.getFullMavenProject(POMNode.java:322)
at
oracle.jdevimpl.wizard.project.MavenProjectImportWorker.loadPOM(MavenProjectImportWorker.java:215)
at
oracle.jdevimpl.wizard.project.MavenProjectImportWorker.generate(MavenProjectImportWorker.java:163)
at
oracle.jdevimpl.wizard.project.MavenProjectImportWorker.runGen(MavenProjectImportWorker.java:136)
at
oracle.jdevimpl.wizard.project.MavenProjectImportWorker.callImport(MavenProjectImportWorker.java:114)
at
oracle.jdevimpl.wizard.project.MavenProjectImportWorker.run(MavenProjectImportWorker.java:91)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.apache.maven.project.ProjectBuildingException: POM
'org.apache.maven:maven-parent' not found in repository: Unable to download
the artifact from any repository
org.apache.maven:maven-parent:pom:11
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
for project org.apache.maven:maven-parent
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:605)
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1394)
... 11 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
Unable to download the artifact from any repository
org.apache.maven:maven-parent:pom:11
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:228)
at
[jira] Created: (SCM-516) git provider doesn't respect username in settings.xml
git provider doesn't respect username in settings.xml - Key: SCM-516 URL: http://jira.codehaus.org/browse/SCM-516 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.1 Reporter: Marat Radchenko git provider doesn't respect username in settings.xml (it always uses current user name). So currently the only way to specify git username is via scm url. This doesn't work in case of multiple developers. -- 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: (MECLIPSE-629) Eclipse doesn't accept absolute path in output property of the .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203655#action_203655 ] Vincent ASTRUC commented on MECLIPSE-629: - The linked resources for output directories in the class EclipseProjectWritter isn't managed Eclipse doesn't accept absolute path in output property of the .classpath - Key: MECLIPSE-629 URL: http://jira.codehaus.org/browse/MECLIPSE-629 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : .project, Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.7 Reporter: Vincent ASTRUC When the outputDirectory of the pom.xml is an absolute path, meclispe would have generate linked resource in .projet and use this link in .classpath. -- 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] Created: (SCM-517) Putting SVN password in settings.xml doesn't support password encryption
Putting SVN password in settings.xml doesn't support password encryption Key: SCM-517 URL: http://jira.codehaus.org/browse/SCM-517 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Reporter: Julien HENRY I'm using maven-release-plugin-2.0-beta-8 and I have encrypted all the password in settings.xml as described here: http://maven.apache.org/guides/mini/guide-encryption.html It works for deployment servers but not for SVN servers (the functionality was provided by SCM-85). I had to revert back to clear passwords for SVN server credentials in settings.xml. -- 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: (MWAR-211) Ability to rename a dependency's jar when putting it on the lib folder
[ http://jira.codehaus.org/browse/MWAR-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203690#action_203690 ] Johan Sjöberg commented on MWAR-211: Simply put, when using archiveClassestrue/archiveClasses to archive classes into a jar-file it would be necessary to be able to name the produced file to something other thanartefactId-version.jar, as identified by Paulo. The new tag could be something similar to archiveNamea name/archiveName. Ability to rename a dependency's jar when putting it on the lib folder -- Key: MWAR-211 URL: http://jira.codehaus.org/browse/MWAR-211 Project: Maven 2.x WAR Plugin Issue Type: New Feature Reporter: Magno Machado Paulo Attachments: TestMaven.rar Maven put on my 'lib' folder the jars of my project's dependencies named like artefactId-version.jar This is a problem when we need to reference the jar filename from sourcecode, because if we change the dependency version, we have to track all source code references to it and correct them. This is the case when importing a taglib into a jsp page It would be better if Maven put only artefactId.jar on the lib folder. And even better if it let us use any custom name we want for the dependencies. If no name is specified, then it could use the current pattern. -- 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: (MWAR-211) Ability to rename a dependency's jar when putting it on the lib folder
[ http://jira.codehaus.org/browse/MWAR-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203690#action_203690 ] Johan Sjöberg edited comment on MWAR-211 at 12/21/09 11:35 AM: --- If File Name Mapping renames TLDs etc. as well, perhaps a tag like archiveNamemyname.jar/archiveName would be great to complement archiveClassestrue/archiveClasses; to be able to replace the default artefactId-version.jar with myname.jar. was (Author: draenor): Simply put, when using archiveClassestrue/archiveClasses to archive classes into a jar-file it would be necessary to be able to name the produced file to something other thanartefactId-version.jar, as identified by Paulo. The new tag could be something similar to archiveNamea name/archiveName. Ability to rename a dependency's jar when putting it on the lib folder -- Key: MWAR-211 URL: http://jira.codehaus.org/browse/MWAR-211 Project: Maven 2.x WAR Plugin Issue Type: New Feature Reporter: Magno Machado Paulo Attachments: TestMaven.rar Maven put on my 'lib' folder the jars of my project's dependencies named like artefactId-version.jar This is a problem when we need to reference the jar filename from sourcecode, because if we change the dependency version, we have to track all source code references to it and correct them. This is the case when importing a taglib into a jsp page It would be better if Maven put only artefactId.jar on the lib folder. And even better if it let us use any custom name we want for the dependencies. If no name is specified, then it could use the current pattern. -- 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] Closed: (SCM-516) git provider doesn't respect username in settings.xml
[ http://jira.codehaus.org/browse/SCM-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed SCM-516. - Resolution: Fixed Fix Version/s: 1.3 Assignee: Mark Struberg this has already been implemented and will be available with scm-1.3 git provider doesn't respect username in settings.xml - Key: SCM-516 URL: http://jira.codehaus.org/browse/SCM-516 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.1 Reporter: Marat Radchenko Assignee: Mark Struberg Fix For: 1.3 git provider doesn't respect username in settings.xml (it always uses current user name). So currently the only way to specify git username is via scm url. This doesn't work in case of multiple developers. -- 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] Created: (MPIR-179) Dependency File Details and Dependency Repository Locations tables have a border when rendered with maven-site-plugin 2.1
Dependency File Details and Dependency Repository Locations tables have a border when rendered with maven-site-plugin 2.1 - Key: MPIR-179 URL: http://jira.codehaus.org/browse/MPIR-179 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1.2 Reporter: Herve Boutemy Priority: Minor see http://www.mail-archive.com/d...@maven.apache.org/msg83269.html -- 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] Closed: (MPIR-179) Dependency File Details and Dependency Repository Locations tables have a border when rendered with maven-site-plugin 2.1
[ http://jira.codehaus.org/browse/MPIR-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPIR-179. -- Resolution: Fixed Fix Version/s: 2.2 Assignee: Herve Boutemy fixed in r892918 Dependency File Details and Dependency Repository Locations tables have a border when rendered with maven-site-plugin 2.1 - Key: MPIR-179 URL: http://jira.codehaus.org/browse/MPIR-179 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1.2 Reporter: Herve Boutemy Assignee: Herve Boutemy Priority: Minor Fix For: 2.2 see http://www.mail-archive.com/d...@maven.apache.org/msg83269.html -- 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-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203709#action_203709 ] Dan Allen commented on ARCHETYPE-273: - Overall, I think you have suggested a nice solution. However, I think the repository parameter should be named catalog. That's consistent with the archetype:generate command. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- 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] Created: (ARCHETYPE-276) Allow archetypes to declare minimum version of maven-archetype-plugin they need
Allow archetypes to declare minimum version of maven-archetype-plugin they need
---
Key: ARCHETYPE-276
URL: http://jira.codehaus.org/browse/ARCHETYPE-276
Project: Maven Archetype
Issue Type: Improvement
Reporter: luke w patterson
In my archetype, I want to specify the minimum version of
maven-archetype-plugin which I expect/need.
e.g. if I want to use features enabled in ARCHETYPE-192, stuff like this:
requiredProperty key=myModule /
requiredProperty key=package
defaultValueorg.foo.bar.${myModule}.${myApp}/defaultValue
If my archetype assumes that replacement functionality is in place, and it
ends up not being in place, I'll have directories named ${myModule} and
${myApp}.
--
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-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203713#action_203713 ] Stevo Slavic commented on ARCHETYPE-273: repository parameter is inline with archetype:generate's archetypeRepository parameter; in both cases it is any repository URL, which is used by mojos to construct repository (usually with default repositoryId, and if explicitly provided with given repository id which is handy for authentication) for retrieving repository archetype catalog and artifacts. In archetype:generate catalog can be local, remote, internal, http:// or file://, neither of which is flexible, powerful, nor simple as just any repository URL requirement (so including https://, maybe even dav:// will work, as long as there is appropriate wagon provider available). add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- 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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203270#action_203270
]
Eric Miles edited comment on MRELEASE-261 at 12/21/09 2:04 PM:
---
I'm not 100% sure this is fixed. I setup a project to use the beta-10-SNAPSHOT
plugin and it is still not working, I'm getting the following error while
trying to prepare the release:
{code}
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd
/Users/emiles/Projects/release-workspace/release-parent svn
--non-interactive commit --file
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit
--targets
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets
[INFO] Working directory:
/Users/emiles/Projects/release-workspace/release-parent
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: '/Users/emiles/Projects/release-workspace' is not a working copy
{code}
I have confirmed that I am using the beta 10 release as well as I have
confirmed the beta 10 release in Apache snapshots contained the v3.patch
identified in one of the previous comments. I'm attaching my sample project,
maven-release-issue.tar.gz. I'm hoping this can be used as a test case and/or
someone can tell me if I've set the project up incorrectly.
This work is being performed in a Mac OS X environment with JDK 1.5 and SVN
1.6.6.
An update...I have completely removed the release plugin and am only using the
svn binary on my box. I still get the same issue, issuing a similar command
{code}
emiles-macbook:~ emiles$ svn --non-interactive commit --file /tmp/svn-msg
--targets /tmp/targets
svn: '/Users/emiles/Projects/release-workspace' is not a working copy
{code}
Here's a cat of svn-msg:
{code}
emiles-macbook:~ emiles$ cat /tmp/svn-msg
[maven-release-plugin] prepare release release-parent-0.0.1emiles-macbook:~
emiles$
{code}
And a cat of targets:
{code}
emiles$ cat /tmp/targets
/Users/emiles/Projects/release-workspace/release-parent/pom.xml
/Users/emiles/Projects/release-workspace/release-module1/pom.xml
/Users/emiles/Projects/release-workspace/release-module2/pom.xml
{code}
So that this point, I'm beginning to wonder if it's the svn binary causing an
issue, at this point we have completely circumvented the release plugin. Or
maybe it's the way the release plugin is attempting to use SVN?
was (Author: bigehokie):
I'm not 100% sure this is fixed. I setup a project to use the
beta-10-SNAPSHOT plugin and it is still not working, I'm getting the following
error while trying to prepare the release:
{code}
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd
/Users/emiles/Projects/release-workspace/release-parent svn
--non-interactive commit --file
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit
--targets
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets
[INFO] Working directory:
/Users/emiles/Projects/release-workspace/release-parent
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: '/Users/emiles/Projects/release-workspace' is not a working copy
{code}
I have confirmed that I am using the beta 10 release as well as I have
confirmed the beta 10 release in Apache snapshots contained the v3.patch
identified in one of the previous comments. I'm attaching my sample project,
maven-release-issue.tar.gz. I'm hoping this can be used as a test case and/or
someone can tell me if I've set the project up incorrectly.
This work is being performed in a Mac OS X environment with JDK 1.5 and SVN
1.6.6.
release:prepare shouls support flat directory multimodule projects
--
Key: MRELEASE-261
URL: http://jira.codehaus.org/browse/MRELEASE-261
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: prepare
Environment: linux / maven2 / svn
Reporter: paul.whe...@gmail.com
Assignee: Maria Odea Ching
Fix For: 2.0-beta-10
Attachments: flatProject.main.patch, flatProject.test.patch,
maven-release-issue.tar.gz, MRELEASE-261-with-its-v3.patch,
[jira] Commented: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203721#action_203721 ] Dan Allen commented on ARCHETYPE-273: - Ah, in that case, it does make sense. I didn't know what the archetypeRepository parameter was for since there is absolutely no documentation for it on this page: http://maven.apache.org/plugins/maven-archetype-plugin/generate-mojo.html#archetypeRepository Also, I meant to say archetypeCatalog where I said catalog. For consistency, perhaps both archetypeRepository and archetypeCatalog should be supported. Or are you saying that archetypeCatalog should be deprecated? That's fine with me as long as the preferred parameter is supported by both goals. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- 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: (MCHANGES-190) HTML in changes.xml stopped working
[ http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203725#action_203725 ] Dennis Lundberg commented on MCHANGES-190: -- I think we need to have a configuration parameter for this. Some people, like me, wants to use the issue text for both the announcement and the report and can't have html code in the changes.xml file. Others, like yourself, wants to enhance their issue text with html code and only use it for the report. Now we only need to figure out a characteristic name for the parameter and a good default value. The parameter will go into the changes-report goal. How about allowHtml with a default value of false? HTML in changes.xml stopped working --- Key: MCHANGES-190 URL: http://jira.codehaus.org/browse/MCHANGES-190 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes-report Affects Versions: 2.3 Environment: Maven version: 2.0.10 Java version: 1.5.0_17 OS name: linux version: 2.6.32-686 arch: i386 Family: unix Reporter: Christian Schulte Priority: Critical Attachments: changes.xml, changes.xml, MCHANGES-190.zip The fix for MCHANGES-189 does not seem to be correct. A changes.xml file containing HTML-Tags got rendered correctly using version 2.2. Starting with version 2.3, HTML-Tags will be encoded using HTML entities for the '' and '' characters leading to the actual tags getting shown in the report. See the attached example changes.xml file containing HTML no longer working with version 2.3. -- 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] Created: (MCHANGELOG-106) NoSuchElementException During Site generation
NoSuchElementException During Site generation - Key: MCHANGELOG-106 URL: http://jira.codehaus.org/browse/MCHANGELOG-106 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.1 Environment: * Windows XP, SVN 1.5.4, MVN 2.2.1 java version 1.6.0 Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode) * Linux, Hudson 1.326, MVN 2.0.9, Java 1.6-SUN Reporter: Karl Heinz Marbaise I have configured to use maven-changelog-plugin as follows in my reporting part: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changelog-plugin/artifactId version2.1/version /plugin During the site generation i get the following message: java.util.NoSuchElementException at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) at org.apache.maven.plugin.changelog.ChangeLogReport.getAbsolutePath(ChangeLogReport.java:1344) at org.apache.maven.plugin.changelog.ChangeLogReport.generateLinks(ChangeLogReport.java:1266) at org.apache.maven.plugin.changelog.ChangeLogReport.generateLinks(ChangeLogReport.java:1208) at org.apache.maven.plugin.changelog.FileActivityReport.doRows(FileActivityReport.java:189) at org.apache.maven.plugin.changelog.FileActivityReport.doChangedSets(FileActivityReport.java:160) at org.apache.maven.plugin.changelog.FileActivityReport.doGenerateReport(FileActivityReport.java:125) at org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:303) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) 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) -- 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-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203726#action_203726 ] Stevo Slavic commented on ARCHETYPE-273: archetypeRepository (repository) and archetypeCatalog (catalog) are somewhat overlapping. Yes, docs are scarce, even in the [Maven book|http://www.sonatype.com/books/maven-book]. Luckily it's FOSS. I agree that either both parameters should be supported or just one, consistently. As proof of concept in my import-catalog mojo patch I implemented support just for one (repository). If there's no special reason to support both I'd prefer if it was just one that is left, maybe even just archetypeCatalog/catalog, it would make things more clear. Of course decision is up to plugin maintainers. IMO, in any case, repositoryId should be supported - repository URL (in form of repository or catalog) and repositoryId should go as a pair, just like in deploy:deploy-file mojo. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- 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: (MCHANGES-190) HTML in changes.xml stopped working
[ http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203728#action_203728 ] Lukas Theussl commented on MCHANGES-190: According to the current changes.xsd schema, the action element in changes.xml has text content only, ie no markup is allowed inside action. So I think the current behavior is actually correct. However, wrt to backward compatibility and functionality, this is not very satisfactory. Note that in maven 1, the action element could contain arbitrary xdoc markup, for the announcement only the text content was extracted. I think the proper solution would be to mimic this behavior, ie generalize the xsd schema and process the content of changes.xml according to where the output goes. A configuration parameter seems unnecessary to me, at least you would have to make it consistent with the xsd. HTML in changes.xml stopped working --- Key: MCHANGES-190 URL: http://jira.codehaus.org/browse/MCHANGES-190 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes-report Affects Versions: 2.3 Environment: Maven version: 2.0.10 Java version: 1.5.0_17 OS name: linux version: 2.6.32-686 arch: i386 Family: unix Reporter: Christian Schulte Priority: Critical Attachments: changes.xml, changes.xml, MCHANGES-190.zip The fix for MCHANGES-189 does not seem to be correct. A changes.xml file containing HTML-Tags got rendered correctly using version 2.2. Starting with version 2.3, HTML-Tags will be encoded using HTML entities for the '' and '' characters leading to the actual tags getting shown in the report. See the attached example changes.xml file containing HTML no longer working with version 2.3. -- 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-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203731#action_203731 ] luke w patterson commented on ARCHETYPE-273: Dan, I was looking over your patch to see if it could be augmented to include what I consider to be a necessary goal: import-archetype import-archetype would simply import one archetype from a repo (local or remote) into the local catalog Does your patch provide any foundation code for for an import-archetype goal? I'll keep reading through it. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- 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] Created: (MRELEASE-507) Execute tests before tagging
Execute tests before tagging Key: MRELEASE-507 URL: http://jira.codehaus.org/browse/MRELEASE-507 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-9 Reporter: Paul Benedict Preparing a release waits to execute tests until after the tag. If the tagging succeeds but the tests fail, the commit created a tag with failing tests, and the build fails altogether. I recommend the test phase should run before the tag... yes, in addition (or as a replacement) after the tagging phase. -- 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-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203743#action_203743 ] Dan Allen commented on ARCHETYPE-273: - Luke, the patch was created by Stevo Slavic. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- 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-507) Execute tests before tagging
[ http://jira.codehaus.org/browse/MRELEASE-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203746#action_203746 ] Dan Tran commented on MRELEASE-507: --- i am -1 on this since it makes the build to run run test twice. The worse case user can always revert the release after tag build fails the test. Execute tests before tagging Key: MRELEASE-507 URL: http://jira.codehaus.org/browse/MRELEASE-507 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-9 Reporter: Paul Benedict Preparing a release waits to execute tests until after the tag. If the tagging succeeds but the tests fail, the commit created a tag with failing tests, and the build fails altogether. I recommend the test phase should run before the tag... yes, in addition (or as a replacement) after the tagging phase. -- 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] Created: (SUREFIRE-583) When forking and specifying a JVM, that JVM's security policy's JCE providers are not loaded, JAVA_HOME's are
When forking and specifying a JVM, that JVM's security policy's JCE providers are not loaded, JAVA_HOME's are - Key: SUREFIRE-583 URL: http://jira.codehaus.org/browse/SUREFIRE-583 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.4.2 Environment: Windows, JAVA_HOME is Sun JDK 1.6.0u16, forked JVM is IBM JDK for WAS 6.1 Reporter: Justin Searls Premise: My test needs to run on the IBM JDK to work, but for other reasons I need to actually build on the Sun JVM. My application's tests are relying on libraries that use a message digest (SHA, not SHA1) that I can only find support for in the BouncyCastle JCE provider. Setup: 1. So I've identified in my plugin configuration something like jvm/path/to/ibm/jdk/jre/bin/javaw.exe/jvm 2. Added BouncyCastle JCE provider jar to /path/to/ibm/jdk/jre/lib/ext 3. Setup BouncyCastle as the sole JCE provider in /path/to/ibm/jdk/jre/lib/security/java.security Expected Result: Designated IBM JVM would look for its java.security file and load its jre/lib/ext JARs when executing tests Actual Result: No such effect. After going through the same setup on my Sun JDK (which I'm running Maven with), that did have the effect of actually providing that provider and getting past the error I was experiencing. It seems to me that if you fork to a different JVM, that JVM's security policy should be used. Given the complexity of this API, however, I wouldn't be surprised to hear that there's a major technical hurdle in implementing this, however. -- 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-507) Execute tests before tagging
[ http://jira.codehaus.org/browse/MRELEASE-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203757#action_203757 ] Paul Benedict commented on MRELEASE-507: Dan, the worse case is too easily allowed. The tests don't have to be run twice; you could skip them second time around. Execute tests before tagging Key: MRELEASE-507 URL: http://jira.codehaus.org/browse/MRELEASE-507 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-9 Reporter: Paul Benedict Preparing a release waits to execute tests until after the tag. If the tagging succeeds but the tests fail, the commit created a tag with failing tests, and the build fails altogether. I recommend the test phase should run before the tag... yes, in addition (or as a replacement) after the tagging phase. -- 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-507) Execute tests before tagging
[ http://jira.codehaus.org/browse/MRELEASE-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203760#action_203760 ] Dan Tran commented on MRELEASE-507: --- you are right there, we can configure release:perform to skip the test. However, running a long test before tag can be very long, i dont know what is impact when other people check into the release/branch/trunk while the test is going on. Also, since this change the behavior of plugin, it should be added as an option Execute tests before tagging Key: MRELEASE-507 URL: http://jira.codehaus.org/browse/MRELEASE-507 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-9 Reporter: Paul Benedict Preparing a release waits to execute tests until after the tag. If the tagging succeeds but the tests fail, the commit created a tag with failing tests, and the build fails altogether. I recommend the test phase should run before the tag... yes, in addition (or as a replacement) after the tagging phase. -- 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: (SCM-261) Synergy provider assumes instance of 1 for projects... won't work for distributed CM (and some other scenarios)
[
http://jira.codehaus.org/browse/SCM-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203772#action_203772
]
Subir S commented on SCM-261:
-
Body Mass,
My assumption about DCM in step b.) above was wrong. I noticed that instance of
a project (generically object) need not be same as the local database. It can
be that of the remote database also. Secondly even in DB where there is no DCM
in use instance need not be default 1. It can also change.
So i fixed this as per your suggestion. Such that in the SCM URL the last or
6th parameter is an optional (instance). If specified then its used, else
default value of '1' is used, so that current users do not get affected.
It works fine with Windows environment. With Linux testing is not possible due
to a plexus-util issue. However that is not related to this case. I have
checked that construction of the argument is fine with Linux also.
I will submit a patch soon, so that this can be included to SCM 1.3
Thanks for your valuable comments.
Synergy provider assumes instance of 1 for projects... won't work for
distributed CM (and some other scenarios)
---
Key: SCM-261
URL: http://jira.codehaus.org/browse/SCM-261
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-synergy
Affects Versions: 1.0-beta-4
Environment: All Synergy environments
Reporter: Body Mass
Fix For: future
We've started testing and hit our first snag:
A unique locator in synergy is: name~version:type:instance
The new snergy provider appears to assume thie instance is 1, and cannot find
projects whose instance is not 1. This is not a valid for a Distributed CM
install, for example, where 1 cannot be the instance number as Synergy will
not allow it. This instance can be any string, and should be specified in the
SCM URL or some other appropriate configuration mechanism.
For example following is a query that works against my developer workspace.
This same funkiness for DCM also applies to task names, but I can't get that
far in testing due to the project problem.
ccm query -u
is_task_in_folder_of(is_folder_in_rp_of('Arc_Workspace~k1gmd00:project:arc#1'))
arc#6602 completed k1gmd00 task void arc void
arc#6607 completed k1gmd00 task void arc void
arc#6619 completed k1jcs01 task void arc void
arc#6620 completed k1jcs01 task void arc void
arc#6630 completed k1gmd00 task void arc void
arc#6632 completed k1gmd00 task void arc void
arc#6634 completed k1jcs01 task void arc void
arc#6637 completed k1gmd00 task void arc void
arc#6638 completed k1gmd00 task void arc void
arc#6644 completed k1jcs01 task void arc void
arc#6645 completed k1jcs01 task void arc void
arc#6646 completed k1gmd00 task void arc void
arc#6647 completed k1jcs01 task void arc void
arc#6648 completed k1gmd00 task void arc void
arc#6649 completed k1jcs01 task void arc void
arc#6652 completed k1gmd00 task void arc void
arc#6656 completed k1gmd00 task void arc void
arc#6657 completed k1jcs01 task void arc void
--
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] Updated: (SCM-261) Synergy provider assumes instance of 1 for projects... won't work for distributed CM (and some other scenarios)
[
http://jira.codehaus.org/browse/SCM-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Subir S updated SCM-261:
Attachment: SCM-261-maven-scm.patch
Patch for this issue.
Tested with Windows and Linux. Works fine with Windows. Testing in Linux not
possible due to [SCM-514|http://jira.codehaus.org/browse/SCM-514]
However that case is related to Quotes in arguments.
Synergy provider assumes instance of 1 for projects... won't work for
distributed CM (and some other scenarios)
---
Key: SCM-261
URL: http://jira.codehaus.org/browse/SCM-261
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-synergy
Affects Versions: 1.0-beta-4
Environment: All Synergy environments
Reporter: Body Mass
Fix For: future
Attachments: SCM-261-maven-scm.patch
We've started testing and hit our first snag:
A unique locator in synergy is: name~version:type:instance
The new snergy provider appears to assume thie instance is 1, and cannot find
projects whose instance is not 1. This is not a valid for a Distributed CM
install, for example, where 1 cannot be the instance number as Synergy will
not allow it. This instance can be any string, and should be specified in the
SCM URL or some other appropriate configuration mechanism.
For example following is a query that works against my developer workspace.
This same funkiness for DCM also applies to task names, but I can't get that
far in testing due to the project problem.
ccm query -u
is_task_in_folder_of(is_folder_in_rp_of('Arc_Workspace~k1gmd00:project:arc#1'))
arc#6602 completed k1gmd00 task void arc void
arc#6607 completed k1gmd00 task void arc void
arc#6619 completed k1jcs01 task void arc void
arc#6620 completed k1jcs01 task void arc void
arc#6630 completed k1gmd00 task void arc void
arc#6632 completed k1gmd00 task void arc void
arc#6634 completed k1jcs01 task void arc void
arc#6637 completed k1gmd00 task void arc void
arc#6638 completed k1gmd00 task void arc void
arc#6644 completed k1jcs01 task void arc void
arc#6645 completed k1jcs01 task void arc void
arc#6646 completed k1gmd00 task void arc void
arc#6647 completed k1jcs01 task void arc void
arc#6648 completed k1gmd00 task void arc void
arc#6649 completed k1jcs01 task void arc void
arc#6652 completed k1gmd00 task void arc void
arc#6656 completed k1gmd00 task void arc void
arc#6657 completed k1jcs01 task void arc void
--
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: (SCM-514) Quotes in CommandLine is causing failure to scm:update
[
http://jira.codehaus.org/browse/SCM-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203776#action_203776
]
Subir S commented on SCM-514:
-
Created a issue with plexus-utils
[PLXUTILS-122|http://jira.codehaus.org/browse/PLXUTILS-122]
Quotes in CommandLine is causing failure to scm:update
--
Key: SCM-514
URL: http://jira.codehaus.org/browse/SCM-514
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-synergy
Affects Versions: 1.3
Environment: Platform OS: RHEL 5
Java: 1.6.0_17
Maven: 2.1.0
Maven SCM: 1.3-SNAPSHOT
SCM: CM/Synergy 7.0
Reporter: Subir S
Priority: Critical
While executing scm:update command in 'Linux', there is a single quote which
appears in the start and end of the argument. This causes the already
existing arguments to have wrong syntax.
mvn scm:update -Dusername=user -Dpassword=pass -X shows the following output:
[DEBUG] STDERR :
[DEBUG] Synergy : Entering getWorkingProject method
[DEBUG] Executing: /bin/sh -c ccm query -u -f %objectname {color:red}
-- additonal start single quote '{color}
owner='user' and status='working' and type='project' and
has_predecessor('sm-3.3:project:inhytest#1')' {color:red}
-- Additional end single quote{color}
[DEBUG] Exit code :1
[DEBUG] STDOUT : unavailable
[DEBUG] STDERR :Warning: Syntax error in query request: owner=user and
status=working and type=project and
has_predecessor(sm-3.3:project:inhytest#1) {color:red}
-- Note that now the single quotes after interpretation by the shell are
removed.{color}
This works fine in 'Windows' platform.
Correct output should be: /bin/sh -c ccm query -u -f %objectname
owner='user' and status='working' and type='project' and
has_predecessor('sm-3.3:project:inhytest#1') {color:red}
--No single quotes, but double quotes and inner single quotes not modified
then.{color}
How to get this working? I have seens some changes to plexus-utils on these
quotes, but could not understand how to workaround this. Please help.
--
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-507) Execute tests before tagging
[ http://jira.codehaus.org/browse/MRELEASE-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203778#action_203778 ] Mark Struberg commented on MRELEASE-507: since when does the tests run _after_ the tagging? I remember they always got fired _before_! And I also see no reason why (in the mvn release:prepare stage) they should run after tagging. They will get fired on mvn release:perform anyway, and this has a very good reason. Execute tests before tagging Key: MRELEASE-507 URL: http://jira.codehaus.org/browse/MRELEASE-507 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-9 Reporter: Paul Benedict Preparing a release waits to execute tests until after the tag. If the tagging succeeds but the tests fail, the commit created a tag with failing tests, and the build fails altogether. I recommend the test phase should run before the tag... yes, in addition (or as a replacement) after the tagging phase. -- 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
