[jira] Commented: (MRELEASE-310) ForkedMavenExecutor assumes mvn is on command-line path
[ http://jira.codehaus.org/browse/MRELEASE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133819#action_133819 ] Martin Jaeger commented on MRELEASE-310: After all it should be possible to define the executable on the commandline / with a plugin property. The execution of "mvn" as a fixed string is not appropriate for our system. Since we wrote a wrapper script to select the correct maven version for a defined project. > ForkedMavenExecutor assumes mvn is on command-line path > --- > > Key: MRELEASE-310 > URL: http://jira.codehaus.org/browse/MRELEASE-310 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 >Reporter: Brian Jackson > Attachments: ForkedMavenExecutor.patch > > > The ForkedMavenExecutor assumes the mvn executable is on the command-line > path. This will cause the release goals to fail if mvn is run from an > explicit path and the PATH environment variable has not be set to contain a > mvn executable. More dangerously though is the case where the release goal > is started with an explicit mvn executable of one version (for instance > 2.0.8) but a different version of the mvn executable is available on the > PATH. The forked processes will run a different version of Maven2 that the > parent process. -- 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-355) CVS provider with SSPI transport does not support port number in url
[ http://jira.codehaus.org/browse/SCM-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-355: - Fix Version/s: 1.1 Patch Submitted: [Yes] > CVS provider with SSPI transport does not support port number in url > > > Key: SCM-355 > URL: http://jira.codehaus.org/browse/SCM-355 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.0 > Environment: maven 2.0.7, CVSNT server configured non default port >Reporter: Siarhei Dudzin >Priority: Blocker > Fix For: 1.1 > > Attachments: SCM-355-documentation.patch, SCM-355.patch > > > Current implementation has checks on harcoded number of delimiters which is > for which doesn't allow to use port number in the url (which is happening > when the server is configured to use a different port number). Having port > number in the url tells SCM CVS that there are in fact 5 tokens which results > in an exception with the following message: > >mvn scm:checkout > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'scm'. > [INFO] > > [INFO] Building saar-main > [INFO]task-segment: [scm:checkout] (aggregator-style) > [INFO] > > [INFO] [scm:checkout] > [ERROR] The connection string contains an incorrect number of tokens (should > be four). > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Cannot run checkout command : > Embedded error: Can't load the scm provider. > The scm url is invalid. > The following format of developerConnection is used: > scm:cvs:sspi > If I remove the port number from the url it actually tries to checkout but > fails as there is no response on that port. If I try to use the same cvs > command maven is trying to issue (adding with the correct port number) - the > checkout works. -- 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-348) missing scm:bootstrap in overview
[ http://jira.codehaus.org/browse/SCM-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-348: - Priority: Trivial (was: Major) Fix Version/s: 1.1 > missing scm:bootstrap in overview > - > > Key: SCM-348 > URL: http://jira.codehaus.org/browse/SCM-348 > Project: Maven SCM > Issue Type: Improvement > Components: documentation >Reporter: Tomasz Pik >Priority: Trivial > Fix For: 1.1 > > > Overview on http://maven.apache.org/scm/plugins/index.html page lists most of > mojos but list do not include scm:bootstrap. > Please, add bootstrap to list. -- 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-354) [Patch] Allow attaching a Job to the Perforce changlist on check-in
[ http://jira.codehaus.org/browse/SCM-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-354: - Fix Version/s: 1.1 > [Patch] Allow attaching a Job to the Perforce changlist on check-in > --- > > Key: SCM-354 > URL: http://jira.codehaus.org/browse/SCM-354 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-perforce >Affects Versions: 1.x >Reporter: ajbanck > Fix For: 1.1 > > Attachments: p4jobs.patch > > > Many Perforce installation have a 'require job' rule/trigger turned on. > To allow check-in when such a rule is defined, the system property > maven.scm.jobs > can be set to specify a job that will be associated with the changelist on > check-in. > Handling of multiple jobs is currently not implemented. > Sample: -Dmaven.scm.jobs=JOB1234 -- 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-363) Perforce Provider ignores p4 errors from stderr
[ http://jira.codehaus.org/browse/SCM-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-363: - Fix Version/s: 1.1 > Perforce Provider ignores p4 errors from stderr > --- > > Key: SCM-363 > URL: http://jira.codehaus.org/browse/SCM-363 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Reporter: Brian Jackson > Fix For: 1.1 > > Attachments: stderrChecking.patch > > > All of the perforce commands are implemented to only check stdout for errors > when the errors are actually written to stderr. Attached is a patch for a > subset of the commands. -- 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-338) NullPointerException when using -DvssDirectory to set ss.exe path
[
http://jira.codehaus.org/browse/SCM-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated SCM-338:
-
Fix Version/s: 1.1
> NullPointerException when using -DvssDirectory to set ss.exe path
> -
>
> Key: SCM-338
> URL: http://jira.codehaus.org/browse/SCM-338
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-vss
>Affects Versions: 1.0
> Environment: Windows XP, JRE 1.4.2
>Reporter: Allan Lang
>Priority: Minor
> Fix For: 1.1
>
> Attachments: SCM-338-[02]-maven-scm-provider-vss.patch,
> SCM-338-maven-scm-provider-vss.patch, vssproviderbug.zip
>
>
> NullPointerException occurs with any SCM operation when there is no
> ~/.scm/vss-settings.xml file, and when the vssDirectory system property is
> set:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.scm.provider.vss.commands.VssCommandLineUtils.getSettings(VssCommandLineUtils.java:137)
> at
> org.apache.maven.scm.provider.vss.commands.VssCommandLineUtils.getSsDir(VssCommandLineUtils.java:145)
> at
> org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.buildCmdLine(VssHistoryCommand.java:91)
> at
> org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.executeChangeLogCommand(VssHistoryCommand.java:53)
> at
> org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:101)
> at
> org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:58)
> ... 21 more
> {code}
> This error is easily replicated using the attached project
> vssproviderbug.zip. Unzip the archive and run
> {code}
> mvn scm:changelog -DvssDirectory=something -e
> {code}
> Assuming the file ~/.scm/vss-settings.xml does not exist, you should see the
> above error in the stack traces. Note that you don't need VSS installed (or
> even to be on Windows) in order to replicate the error - Maven doesn't
> actually get as far as making a call to ss.exe.
--
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-359) scm:update goals link not working (update) on Overview -> Introduction
[ http://jira.codehaus.org/browse/SCM-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-359: - Priority: Trivial (was: Minor) Fix Version/s: 1.1 > scm:update goals link not working (update) on Overview -> Introduction > -- > > Key: SCM-359 > URL: http://jira.codehaus.org/browse/SCM-359 > Project: Maven SCM > Issue Type: Improvement > Components: documentation >Reporter: Ville Hartikainen >Priority: Trivial > Fix For: 1.1 > > > http://maven.apache.org/scm/plugins/index.html > Apparently should be: > http://maven.apache.org/scm/plugins/update-mojo > instead of current: > http://maven.apache.org/scm/plugins/index.html#update-mojo -- 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-322) SCM plug-in should tell at what revision the source is when it finishes
[
http://jira.codehaus.org/browse/SCM-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated SCM-322:
-
Fix Version/s: 1.1
> SCM plug-in should tell at what revision the source is when it finishes
> ---
>
> Key: SCM-322
> URL: http://jira.codehaus.org/browse/SCM-322
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-plugin
>Affects Versions: 1.0
>Reporter: Alex Mayorga Adame
>Priority: Trivial
> Fix For: 1.1
>
>
> As of now the output is like this:
> {noformat}
> ...
> [INFO] [scm:update]
> [INFO] Executing: svn --non-interactive update
> [INFO] Working directory: C:\archiva
> [INFO] Storing revision in 'scm.revision' project property.
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> ...
> {noformat}
> It would be nice to have something like this:
> {noformat}
> ...
> [INFO] [scm:update]
> [INFO] Executing: svn --non-interactive update
> [INFO] Working directory: C:\archiva
> [INFO] Project at revision XXX.
> [INFO] Storing revision in 'scm.revision' project property.
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> ...
> {noformat}
--
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-338) NullPointerException when using -DvssDirectory to set ss.exe path
[
http://jira.codehaus.org/browse/SCM-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated SCM-338:
-
Patch Submitted: [Yes]
> NullPointerException when using -DvssDirectory to set ss.exe path
> -
>
> Key: SCM-338
> URL: http://jira.codehaus.org/browse/SCM-338
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-vss
>Affects Versions: 1.0
> Environment: Windows XP, JRE 1.4.2
>Reporter: Allan Lang
>Priority: Minor
> Fix For: 1.1
>
> Attachments: SCM-338-[02]-maven-scm-provider-vss.patch,
> SCM-338-maven-scm-provider-vss.patch, vssproviderbug.zip
>
>
> NullPointerException occurs with any SCM operation when there is no
> ~/.scm/vss-settings.xml file, and when the vssDirectory system property is
> set:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.scm.provider.vss.commands.VssCommandLineUtils.getSettings(VssCommandLineUtils.java:137)
> at
> org.apache.maven.scm.provider.vss.commands.VssCommandLineUtils.getSsDir(VssCommandLineUtils.java:145)
> at
> org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.buildCmdLine(VssHistoryCommand.java:91)
> at
> org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.executeChangeLogCommand(VssHistoryCommand.java:53)
> at
> org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:101)
> at
> org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:58)
> ... 21 more
> {code}
> This error is easily replicated using the attached project
> vssproviderbug.zip. Unzip the archive and run
> {code}
> mvn scm:changelog -DvssDirectory=something -e
> {code}
> Assuming the file ~/.scm/vss-settings.xml does not exist, you should see the
> above error in the stack traces. Note that you don't need VSS installed (or
> even to be on Windows) in order to replicate the error - Maven doesn't
> actually get as far as making a call to ss.exe.
--
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-314) BazaarScmProviderRepository doesn't work with file URL on Windows
[
http://jira.codehaus.org/browse/SCM-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated SCM-314:
-
Fix Version/s: 1.1
> BazaarScmProviderRepository doesn't work with file URL on Windows
> -
>
> Key: SCM-314
> URL: http://jira.codehaus.org/browse/SCM-314
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-bazaar
>Affects Versions: 1.0-rc1
>Reporter: Kohsuke Kawaguchi
> Fix For: 1.1
>
>
> new BazaarScmProviderRepository("file:///c:/program
> files/cygwin/tmp/test").getURI() returns "file://c:\program
> files\cygwin\tmp\test", which Bazaar rejects as
> {noformat}
> bzr: ERROR: Invalid url supplied to transport: 'file://c:\\program
> files\\cygwin\\tmp\\test/': Win32 UNC path urls have form file://HOST/path
> {noformat}
> Any reason why getURI() method is not implemented as follows?
> {noformat}
> public String getURI()
> {
> return orgUrl;
> }
> {noformat}
--
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-331) bug found in StarteamUpdateCommand when doing a delete-local when a (view)label is used
[ http://jira.codehaus.org/browse/SCM-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-331: - Fix Version/s: 1.1 > bug found in StarteamUpdateCommand when doing a delete-local when a > (view)label is used > --- > > Key: SCM-331 > URL: http://jira.codehaus.org/browse/SCM-331 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-starteam >Affects Versions: 1.0-beta-3 >Reporter: Jan Edelbroek > Fix For: 1.1 > > > After a succesfull update the StarteamUpdateCommand fires a delete-local > command. > The command string that is created for the stcmd is wrong when a (view)label > is used. > stcmd delete-local -x -nologo -stop -p "[EMAIL > PROTECTED]:port/Project/View/path" -fp path-to-working-directory -is "-cfgl " > alpha-1-1 -filter N > As you can see, the -cfgl option is between quotes and there is also an > additional space character. > The problem is in the StarteamUpdateCommand class file (also in the trunk > version). > The following line in the createDeleteLocalCommand method > args.add( "-cfgl " ); > should be replaced with > args.add( "-cfgl" ); > thus leaving out the additional space character. > I can provide a patch when necessary. > See also SCM-309 in which i indicate that i have a patch ready to be able to > use promotion states instead of view labels -- 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-356) clearcase implementation does not allow id of more than 8 characters.
[ http://jira.codehaus.org/browse/SCM-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-356: - Fix Version/s: 1.1 Patch Submitted: [Yes] Maybe it would be better to move the USER command line pattern the the config file for backward compatibility > clearcase implementation does not allow id of more than 8 characters. > - > > Key: SCM-356 > URL: http://jira.codehaus.org/browse/SCM-356 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-clearcase >Affects Versions: 1.0 > Environment: OS : Windows and LInux Suse > Hardware : x86 >Reporter: Jean-Philippe Hautin >Priority: Critical > Fix For: 1.1 > > Attachments: maven-scm-provider-clearcase-SCM-356.patch > > > developer ID are not limited in clearcase. > So, we are used to use the standard pattern _ > But when using changelog report, we got an empty developer activity report. > Looking at the source code, I see that the the arguments of the cleartool > command generated force the maximum length of 8 characters. > In the class ClearCaseChangeLogCommand, line 114, we can see that the > cleartool argument is : > "USER:%-8.8u\\n" > I think it should be more like : > "USER:%u\\n" -- 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: (MARTIFACT-11) Do not use FileReader/FileWriter
[
http://jira.codehaus.org/browse/MARTIFACT-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MARTIFACT-11:
--
Fix Version/s: 3.0
> Do not use FileReader/FileWriter
>
>
> Key: MARTIFACT-11
> URL: http://jira.codehaus.org/browse/MARTIFACT-11
> Project: Maven Artifact
> Issue Type: Improvement
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Priority: Trivial
> Fix For: 3.0
>
> Attachments: avoid-platform-specific-encoding.patch
>
>
> Using {{FileReader}} or {{FileWriter}} makes code dependent on the platform's
> default encoding. For platform-independent behavior, the tests should use a
> fixed encoding.
--
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: (MARTIFACT-14) Use specific encoding for checksum files
[ http://jira.codehaus.org/browse/MARTIFACT-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MARTIFACT-14: -- Fix Version/s: 3.0 > Use specific encoding for checksum files > > > Key: MARTIFACT-14 > URL: http://jira.codehaus.org/browse/MARTIFACT-14 > Project: Maven Artifact > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Benjamin Bentmann >Priority: Minor > Fix For: 3.0 > > Attachments: checksum-file-encoding.patch > > > The checksum files are currently written/read using the JVM's default > encoding. Even though the ASCII characters constituting the checksums are > quite safe from being messed up, the principal possibility for such a problem > exists. Just assume somebody running with EBCDIC (like in MANTTASKS-14). See > also [Common Bugs|http://www.nabble.com/Re%3A-Common-Bugs-p15919795s177.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] Updated: (MARTIFACT-7) Clear separation of local versus remote concerns
[ http://jira.codehaus.org/browse/MARTIFACT-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MARTIFACT-7: - Fix Version/s: 3.0 > Clear separation of local versus remote concerns > > > Key: MARTIFACT-7 > URL: http://jira.codehaus.org/browse/MARTIFACT-7 > Project: Maven Artifact > Issue Type: Improvement >Reporter: Jason van Zyl > Fix For: 3.0 > > > The resolution very much couples local with remote repositories. For example > simply querying for all available versions requires some twiddling and faking > out the resolver because the local metadata is always used but I only want to > know about remote repositories. We just need to be able to query remote > repositories easily. Getting all the remote versions to prevent redeployment > is a perfect use case. -- 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: (MARTIFACT-12) [regression] ear dependencies are propagated transitively
[ http://jira.codehaus.org/browse/MARTIFACT-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MARTIFACT-12: -- Fix Version/s: 3.0-alpha-1 > [regression] ear dependencies are propagated transitively > - > > Key: MARTIFACT-12 > URL: http://jira.codehaus.org/browse/MARTIFACT-12 > Project: Maven Artifact > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Brett Porter > Fix For: 3.0-alpha-1 > > > In Maven 2.0.x, if you have a dependency on an EAR, the dependencies of the > EAR are not exposed as transitive dependencies since they are already packed > inside the EAR. > While alternate solutions for this (to solve both the Java EE scenarios, and > shading/uberjar/assembly type dependencies), no such solution is in place so > the previous functionality should be retained until deprecated and removed. -- 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: (MARTIFACT-5) non-handling of legacy repositories needs to be more graceful
[ http://jira.codehaus.org/browse/MARTIFACT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MARTIFACT-5: - Fix Version/s: 3.0-alpha-1 > non-handling of legacy repositories needs to be more graceful > - > > Key: MARTIFACT-5 > URL: http://jira.codehaus.org/browse/MARTIFACT-5 > Project: Maven Artifact > Issue Type: Bug >Reporter: Brett Porter > Fix For: 3.0-alpha-1 > > > legacy repository support was removed. > Currently, it appears to still partially handle it - using 2.1-SNAPHOT today > it requests groupId/types/artifactId-version.ext as before, but chokes on the > non-existence of a POM in the desired format. > If this support is to be removed, it should be removed completely, and legacy > repositories should be ignored in the repository list, with a warning > presented so that it sohuld either resolve from an alternate repository, or > present as an artifact not found exception. -- 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: (MARTIFACT-13) Make set of deployed checksums configurable
[
http://jira.codehaus.org/browse/MARTIFACT-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MARTIFACT-13:
--
Fix Version/s: 3.0
> Make set of deployed checksums configurable
> ---
>
> Key: MARTIFACT-13
> URL: http://jira.codehaus.org/browse/MARTIFACT-13
> Project: Maven Artifact
> Issue Type: New Feature
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
> Fix For: 3.0
>
>
> Nothing new, just an official ticket for
> {code:java}
> // TODO: configure these on the repository
> for ( int i = 0; i < CHECKSUM_IDS.length; i++ )
> {
> checksums.put( CHECKSUM_IDS[i], addChecksumObserver( wagon,
> CHECKSUM_ALGORITHMS[i] ) );
> }
> {code}
> from the
> {{[DefaultWagonManager|http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java?revision=647022&view=markup]}}.
> Since maven-artifact:3.0 is a major release, it might be a good time to add
> the required methods into the API.
> Number one use case is to entirely disable checksum files, e.g. to upload
> EARs directly into an app server's deployment directory via scp.
--
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: (MARTIFACT-9) Prefer LinkedHashMap over HashMap
[ http://jira.codehaus.org/browse/MARTIFACT-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MARTIFACT-9: - Fix Version/s: 3.0 > Prefer LinkedHashMap over HashMap > - > > Key: MARTIFACT-9 > URL: http://jira.codehaus.org/browse/MARTIFACT-9 > Project: Maven Artifact > Issue Type: Improvement >Reporter: Benjamin Bentmann >Priority: Trivial > Fix For: 3.0 > > Attachments: deterministic-map-ordering.patch > > > Sometimes order is important, Maven is learning that the hard way (MNG-1412, > MNG-3118, SUREFIRE-61, ...). Methods that don't know for sure that ordering > is irrelevant should follow "better safe than sorry" and keep the ordering of > input collections. -- 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: (MARTIFACT-16) DefaultArtifactVersion.hashCode() violates general contract
[
http://jira.codehaus.org/browse/MARTIFACT-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MARTIFACT-16:
--
Fix Version/s: 3.0
> DefaultArtifactVersion.hashCode() violates general contract
> ---
>
> Key: MARTIFACT-16
> URL: http://jira.codehaus.org/browse/MARTIFACT-16
> Project: Maven Artifact
> Issue Type: Bug
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
> Fix For: 3.0
>
> Attachments: default-artifact-version-hashcode.patch
>
>
> Compare
> [{{Object.hashCode()}}|http://java.sun.com/javase/6/docs/api/java/lang/Object.html#hashCode()]
> and [Effective Java, Chapter 3, "Methods Common to All
> Objects"|http://java.sun.com/docs/books/effective/chapters.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] Updated: (MARTIFACT-15) Clarify value of basedir property for ArtifactRepository
[
http://jira.codehaus.org/browse/MARTIFACT-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MARTIFACT-15:
--
Fix Version/s: 3.0
> Clarify value of basedir property for ArtifactRepository
>
>
> Key: MARTIFACT-15
> URL: http://jira.codehaus.org/browse/MARTIFACT-15
> Project: Maven Artifact
> Issue Type: Task
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
> Fix For: 3.0
>
>
> There seems to be some confusion what exactly the return value from
> {{ArtifactRepository.getBasedir()}} delivers:
> # always some part of a URL (i.e. a string that is subject to URL-encoding) or
> # something depending on the URL protocol (e.g. a normal file system path in
> case of {{file://}})
> The javadoc should be be extended to clearly express what contents callers of
> the method have to expect such that they can handle it properly.
--
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: (MARTIFACT-10) Fix error handling for system-scoped artifacts
[
http://jira.codehaus.org/browse/MARTIFACT-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MARTIFACT-10:
--
Fix Version/s: 3.0
> Fix error handling for system-scoped artifacts
> --
>
> Key: MARTIFACT-10
> URL: http://jira.codehaus.org/browse/MARTIFACT-10
> Project: Maven Artifact
> Issue Type: Improvement
>Reporter: Benjamin Bentmann
>Priority: Trivial
> Fix For: 3.0
>
> Attachments: file-error-handling.patch
>
>
> The current order of checking for error cases checks {{!File.isFile()}}
> before {{!File.exists()}}. However, {{!File.isFile()}} might also fail if the
> file does not exist at all, hence capturing the same case that is intended to
> be captured by the later check with {{!File.exists()}}. The order needs to be
> reversed to get the desired exception messages.
--
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: (MARTIFACT-8) Make wagon lookup case-insensitive with regard to protocol
[ http://jira.codehaus.org/browse/MARTIFACT-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MARTIFACT-8: - Fix Version/s: 3.0 > Make wagon lookup case-insensitive with regard to protocol > -- > > Key: MARTIFACT-8 > URL: http://jira.codehaus.org/browse/MARTIFACT-8 > Project: Maven Artifact > Issue Type: Bug > Environment: Maven 2.0.8 >Reporter: Benjamin Bentmann >Priority: Minor > Fix For: 3.0 > > Attachments: case-insensitive-lookup.patch > > > From [RFC 2396|http://www.ietf.org/rfc/rfc2396.txt], section 3.1, "Scheme > Component": > bq. [...] programs interpreting URI should treat upper case letters as > equivalent to lower case in scheme names (e.g., allow "HTTP" as well as > "http"). > Currently, the lookup of a wagon fails if the protocol is not completely > lower case which deviates from the RFC, the implementation of > java.net.URL/URI and everyday experience of users. The attached patch fixes > this by normalizing the protocol to lower case before lookup. Porting this > fix to other branches or WagonManagers is left to the reviewer. > Please note the implication of this patch for wagon providers: Any provider > that does not use an all lower case role-hint for the registration with > Plexus cannot be lookuped. As far as I can see, this is no problem with the > existing providers. -- 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-341) support release process that use a staging repository
support release process that use a staging repository - Key: MRELEASE-341 URL: http://jira.codehaus.org/browse/MRELEASE-341 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-8 Reporter: nicolas de loof Many release process (ex: geronimo) require the release candidate to be exposed in a staging repository for testing, then vote from the communiity, and finally copy the artifact in the public repository / web site. This requires to run the release:perform with the final version (not a "-rc*" one). When the vote fails, the release manager has to rollback the project to the previous SNAPSHOT version. As release:perform removes all the release-related files (including pom backups) the release:rollback goal cannot be used for this. Geronimo solution is to copy the trunk as a "savepoint" before staging a release. A far better option would be to have a dedicated goal for this "release:stage" : * same features as release:perform * don't remove release.properties and backups * requires a stagingRepository parameter, to be passed as -DaltRepoLocation to the deploy plugin * detect the site:deploy goal and replace it with site:stage-deploy -- 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] Reopened: (MINVOKER-22) Add feature to install plugin to a local repository.
[
http://jira.codehaus.org/browse/MINVOKER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann reopened MINVOKER-22:
---
I just had a look at the related goal
[{{shitty:install}}|http://mojo.codehaus.org/shitty-maven-plugin/install-mojo.html]
and believe we should follow its example and move the install feature into a
dedicated goal that can be run independently of the IT builds (e.g. in another
phase like {{pre-integration-test}}).
> Add feature to install plugin to a local repository.
>
>
> Key: MINVOKER-22
> URL: http://jira.codehaus.org/browse/MINVOKER-22
> Project: Maven 2.x Invoker Plugin
> Issue Type: New Feature
>Affects Versions: 1.1
>Reporter: Paul Gier
>Assignee: Paul Gier
> Fix For: 1.2
>
> Attachments: MINVOKER-22-install-artifacts.patch
>
>
> Currently if I want to test a maven plugin, I have to use the install plugin
> to install the jar into a temporary repository location. It would be helpful
> if there was a way that the invoker plugin could do this by itself instead of
> needing to use the install plugin.
--
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: (MINVOKER-22) Add feature to install plugin to a local repository.
[ http://jira.codehaus.org/browse/MINVOKER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133850#action_133850 ] Paul Gier commented on MINVOKER-22: --- Ok, that's fine with me. > Add feature to install plugin to a local repository. > > > Key: MINVOKER-22 > URL: http://jira.codehaus.org/browse/MINVOKER-22 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 1.2 > > Attachments: MINVOKER-22-install-artifacts.patch > > > Currently if I want to test a maven plugin, I have to use the install plugin > to install the jar into a temporary repository location. It would be helpful > if there was a way that the invoker plugin could do this by itself instead of > needing to use the install plugin. -- 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: (MRELEASE-341) support release process that use a staging repository
[ http://jira.codehaus.org/browse/MRELEASE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof closed MRELEASE-341. Assignee: nicolas de loof Resolution: Fixed Fix Version/s: 2.0-beta-8 new release:stage Mojo with documentation > support release process that use a staging repository > - > > Key: MRELEASE-341 > URL: http://jira.codehaus.org/browse/MRELEASE-341 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-8 >Reporter: nicolas de loof >Assignee: nicolas de loof > Fix For: 2.0-beta-8 > > > Many release process (ex: geronimo) require the release candidate to be > exposed in a staging repository for testing, then vote from the communiity, > and finally copy the artifact in the public repository / web site. This > requires to run the release:perform with the final version (not a "-rc*" one). > When the vote fails, the release manager has to rollback the project to the > previous SNAPSHOT version. As release:perform removes all the release-related > files (including pom backups) the release:rollback goal cannot be used for > this. > Geronimo solution is to copy the trunk as a "savepoint" before staging a > release. A far better option would be to have a dedicated goal for this > "release:stage" : > * same features as release:perform > * don't remove release.properties and backups > * requires a stagingRepository parameter, to be passed as -DaltRepoLocation > to the deploy plugin > * detect the site:deploy goal and replace it with site:stage-deploy -- 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-85) Use the members Name in the changelog.html
Use the members Name in the changelog.html -- Key: MCHANGELOG-85 URL: http://jira.codehaus.org/browse/MCHANGELOG-85 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: Maven 2.0.8 Reporter: Arnaud Priority: Minor Why doesn't replace the member ID in the changelog.html by the member Name when its possible (like it is in the dev-activity.html) Or if it's was not possible, juste add a link to team-list.html like this : team-list.html #IDnumber -- 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: (MPMD-80) maven-pmd-plugin should generate only one pmd.xml file
maven-pmd-plugin should generate only one pmd.xml file -- Key: MPMD-80 URL: http://jira.codehaus.org/browse/MPMD-80 Project: Maven 2.x PMD Plugin Issue Type: Improvement Components: PMD Affects Versions: 2.3 Reporter: Ulli Hafner Priority: Minor Currently the task mvn pmd:pmd generates two identical pmd.xml report files: one file is in target/pmd.xml, the other in target/site/pmd.xml. (findbugs and checkstyle just generate one file in the target folder). These two identical files hinder the processing by warning visualizations tools (like the Hudson CI server pmd-plugin) that use these m2 generated files as input. Normally, in Hudson one can just specify the file pattern **/pmd.xml to obtain the available files to process. (Of course the user might change the default pattern to **/target/pmd.xml, but it would be much smarter if this would not be a requirement. And using **/target/pmd.xml as default is also no possibility, since ant has no target folder...) See: https://hudson.dev.java.net/issues/show_bug.cgi?id=1647 -- 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-153) Multimodule archetype does not propagate the artifactId in module names.
[
http://jira.codehaus.org/browse/ARCHETYPE-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133889#action_133889
]
Foudil commented on ARCHETYPE-153:
--
Hi,
I tried to use the attached "archetype" (after adding the required snapshot
repository)
- I installed it.
- Then after running: mvn archetype:generate -DarchetypeCatalog=local i got
the same error as the one described in the issue description (with a build
failure at the end)
That is, it did not find the ressource ...myArtifact-api/pom.xml
However, when i typed 'proficio' as the the artifactId, the buid was
successful, but directories like '${rootArtifactId}-api'... where generated
it doesn't seem to resolve correctly the variable ${rootArtifactId} when
creating the directories !
Maybe the attached 'archetype' is not the right one ?
PS: i am using maven 2.0.9
Thanks
Regards,
---
Foudil
> Multimodule archetype does not propagate the artifactId in module names.
>
>
> Key: ARCHETYPE-153
> URL: http://jira.codehaus.org/browse/ARCHETYPE-153
> Project: Maven Archetype
> Issue Type: Bug
> Components: Creator, Generator
>Affects Versions: 2.0-alpha-2
>Reporter: Raphaël Piéroni
>Priority: Critical
> Fix For: 2.0-alpha-3
>
> Attachments: archetype.tgz, project.tgz
>
>
> Creating an archetype for a multimodule project,
> a test on the attached project creates the attached archetype
> using archetype:create-from-project.
> But when using the archetype, it raise an exception:
> mvn archetype:generate -DarchetypeCatalog=local
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO]
>
> [INFO] Building Maven Default Project
> [INFO]task-segment: [archetype:generate] (aggregator-style)
> [INFO]
>
> [INFO] Preparing archetype:generate
> [INFO] No goals needed for project - skipping
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [archetype:generate]
> Choose archetype:
> 1: local -> project (project)
> 2: local -> basic-multi-archetype (basic-multi-archetype)
> 3: local -> maven-integration-test-sample (maven-integration-test-sample)
> 4: local -> maven-integration-test-sample-archetype
> (maven-integration-test-sample-archetype)
> 5: local -> proficio (proficio)
> Choose a number: (1/2/3/4/5): 5
> Define value for groupId: : org.community
> Define value for artifactId: : pro
> Define value for version: : 2.0-SNAPSHOT
> Define value for package: : org.community.pro
> Confirm properties configuration:
> groupId: org.community
> artifactId: pro
> version: 2.0-SNAPSHOT
> package: org.community.pro
> Y: :
> [ERROR] ResourceManager : unable to find resource
> 'archetype-resources/pro-api/pom.xml' in any resource loader.
> [ERROR] org.apache.maven.archetype.exception.ArchetypeGenerationFailure:
> Error merging velocity templates: Unable to find resource
> 'archetype-resources/pro-api/pom.xml'
> org.apache.maven.archetype.exception.ArchetypeGenerationFailure:
> org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error
> merging velocity templates: Unable to find resource
> 'archetype-resources/pro-api/pom.xml'
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.generateArchetype(DefaultFilesetArchetypeGenerator.java:240)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.processFileSetArchetype(DefaultArchetypeGenerator.java:215)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype(DefaultArchetypeGenerator.java:130)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype(DefaultArchetypeGenerator.java:290)
> at
> org.apache.maven.archetype.DefaultArchetype.generateProjectFromArchetype(DefaultArchetype.java:75)
> at
> org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:165)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache
[jira] Commented: (MRELEASE-163) Dependencies in build.plugins section of pom do not have thier versions updated.
[ http://jira.codehaus.org/browse/MRELEASE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133893#action_133893 ] Michael Sell commented on MRELEASE-163: --- I run into this problem on my project as well, mine involving bringing in an ant task dependency into the ant-run plugin. > Dependencies in build.plugins section of pom do not have thier versions > updated. > > > Key: MRELEASE-163 > URL: http://jira.codehaus.org/browse/MRELEASE-163 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Linux/Maven v2.0.4 >Reporter: Baron Reznik > Attachments: MRELEASE-163-evaluation path.txt > > > Inside my parent pom of a multimodule project, I have something that looks > like: > > > > org.apache.maven.plugins > maven-checkstyle-plugin > > > mygroupId > build-resources > 1.0-SNAPSHOT > > ... > The snapshot dependencies inside the section are not resolved and > updated on release as other dependencies elsewhere in the pom are. In my > specific case, I am using the maven-checkstyle-plugin with a dependency that > includes a custom checkstyle checker xml file inside an artifact. So, I would > expect that on release, the snapshot dependency would be resolved and updated > like all others. If more information is needed to replicate, please let me > know. -- 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: (MNG-3568) site not reading properly with properties
site not reading properly with properties - Key: MNG-3568 URL: http://jira.codehaus.org/browse/MNG-3568 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Environment: Ubuntu 8.0.4, Windows XP, Sun JDK 1.6, Sun JDK 1.5 Reporter: Leon Priority: Critical Attachments: project.tgz The site goal does not read the correct properties from a parent pom if the properties are used to set the version of the artifact. For the attached project "mvn install" works but "mvn site" fails. -- 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: (MASSEMBLY-325) Pre-defined descriptor for appassembler goodness
Pre-defined descriptor for appassembler goodness Key: MASSEMBLY-325 URL: http://jira.codehaus.org/browse/MASSEMBLY-325 Project: Maven 2.x Assembly Plugin Issue Type: New Feature Reporter: Paul Smith Priority: Minor The predefined assembly descriptors are nice. I'd love to have a built in one that matched the output of the appassembler plugin, something like: tar.gz README* LICENSE* NOTICE* target/appassembler -- 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: (MJAVADOC-186) Multimodule javadoc aggregate fails when submodule depeneds on generate-sources phase being executed
Multimodule javadoc aggregate fails when submodule depeneds on generate-sources phase being executed Key: MJAVADOC-186 URL: http://jira.codehaus.org/browse/MJAVADOC-186 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: James William Dumay Multimodule javadoc aggregate fails when submodule depeneds on generate-sources phase being executed. Take the following multimodule example: POM A -->POM B POM B generates java source files on generate-sources phase. When javadoc aggregate is executed on top level project, javadoc fails because those classes have not been generated. -- 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: (ARCHETYPE-145) Allow archetype:crawl to crawl only a specific part of the local repository
[ http://jira.codehaus.org/browse/ARCHETYPE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gert Vanthienen closed ARCHETYPE-145. - Resolution: Not A Bug It already works, so no need to do anything about it I guess... > Allow archetype:crawl to crawl only a specific part of the local repository > --- > > Key: ARCHETYPE-145 > URL: http://jira.codehaus.org/browse/ARCHETYPE-145 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 2.0-alpha-2 >Reporter: Gert Vanthienen >Priority: Minor > > The use case for this feature request would be to create a project-specific > archetype catalog. > Cfr. > http://www.nabble.com/Tool-for-generating-an-archetype-catalog-to15799921s177.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
