[jira] (MNG-5236) Make it possible to specify pluginRepository through CLI so that remote plugin consumers don't have to worry editing settings.xml file
Chethiya Abeysinghe created MNG-5236: Summary: Make it possible to specify pluginRepository through CLI so that remote plugin consumers don't have to worry editing settings.xml file Key: MNG-5236 URL: https://jira.codehaus.org/browse/MNG-5236 Project: Maven 2 & 3 Issue Type: Improvement Components: Plugins and Lifecycle Reporter: Chethiya Abeysinghe I wrote a maven plugin and expect it to be used by wide range of developers. At the moment my suggestion for them is to edit the user level settings.xml file to include to include the nexus remote repo of my plugin. Also that settings XML file include tag pointing to same repo too. It would be handy if it's possible to specify the plugin repository in the command line, e.g. mvn groupId:plugin-artifactId:goal -Dmaven.pluginRepositoryUrl=[url to the remote repo] That way I can ask plugin users to just copy-paste the command in the prompt without asking them to edit settings.xml. Of couse they also have the option of editing settings.xml file that is a one-time operation. Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-158) outputDirectory is marked as mandatory whereas it is not really mandatory
Jorg Heymans created MRESOURCES-158:
---
Summary: outputDirectory is marked as mandatory whereas it is not
really mandatory
Key: MRESOURCES-158
URL: https://jira.codehaus.org/browse/MRESOURCES-158
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.5
Reporter: Jorg Heymans
in the documentation and plugin descriptor the outputDirectory config element
is marked as mandatory. But since there is a default value of
${project.build.outputDirectory} this element is not really mandatory. Other
configuration elements with the same default value semantics are not marked as
mandatory so i think for outputDirectory the same semantics should be applied.
this is especially troublesome for ideas that try to assist in maven
configuration and rely on the plugin descriptor to figure out if elements are
mandatory or not. See http://youtrack.jetbrains.net/issue/IDEA-80626
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated MSITE-604:
-
Attachment: MSITE-604.tgz
We face the same problems. In our case we deploy the site documentation to our
intranet and depending on the environment the base URL is a file protocol with
different paths or scpexe. Therefore we have to use a property from
settings.xml.
The attached test project demonstrates the effect. Since our property contains
the protocol, we get this "{{Wagon protocol '' doesn't support directory
copying}}" error.
However, it seems that the usage of a parent located in the repository is part
of the problem.
You may test the project with the call
mvn -s settings.xml clean package site site:deploy
Have a look at the README.txt for simple preparation and alternate calls to
select the site-plugin version from command-line.
M3 fails with site-plugin 3.0, but succeeds with 3.0-beta-3 and will generate
no HTMLs for site-plugin version 2.x. M221 fails with site-plugin versions 3.0
and 2.3.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: 3.1
>
> Attachments: MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290463#comment-290463
]
Joerg Schaible edited comment on MSITE-604 at 2/1/12 5:23 AM:
--
We face the same problems. In our case we deploy the site documentation to our
intranet and depending on the environment the base URL is a file protocol with
different paths or scpexe. Therefore we have to use a property from
settings.xml.
The attached test project MSITE-604.tgz demonstrates the effect. Since our
property contains the protocol, we get this "{{Wagon protocol '' doesn't
support directory copying}}" error.
However, it seems that the usage of a parent located in the repository is part
of the problem.
You may test the project with the call
{noformat}
mvn -s settings.xml clean package site site:deploy
{noformat}
Have a look at the README.txt for simple preparation and alternate calls to
select the site-plugin version from command-line.
M3 fails with site-plugin 3.0, but succeeds with 3.0-beta-3 and will generate
no HTMLs for site-plugin version 2.x. M221 fails with site-plugin versions 3.0
and 2.3.
I've also linked this issue to MSITE-617, MSITE-585 and MSITE-501 that seem to
be related.
was (Author: joehni):
We face the same problems. In our case we deploy the site documentation to
our intranet and depending on the environment the base URL is a file protocol
with different paths or scpexe. Therefore we have to use a property from
settings.xml.
The attached test project MSITE-604.tgz demonstrates the effect. Since our
property contains the protocol, we get this "{{Wagon protocol '' doesn't
support directory copying}}" error.
However, it seems that the usage of a parent located in the repository is part
of the problem.
You may test the project with the call
{noformat}
mvn -s settings.xml clean package site site:deploy
{noformat}
Have a look at the README.txt for simple preparation and alternate calls to
select the site-plugin version from command-line.
M3 fails with site-plugin 3.0, but succeeds with 3.0-beta-3 and will generate
no HTMLs for site-plugin version 2.x. M221 fails with site-plugin versions 3.0
and 2.3.
I've also linked this issue to MNG-617, MNG-585 and MNG-501 that seem to be
related.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: 3.1
>
> Attachments: MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290463#comment-290463
]
Joerg Schaible edited comment on MSITE-604 at 2/1/12 5:23 AM:
--
We face the same problems. In our case we deploy the site documentation to our
intranet and depending on the environment the base URL is a file protocol with
different paths or scpexe. Therefore we have to use a property from
settings.xml.
The attached test project MSITE-604.tgz demonstrates the effect. Since our
property contains the protocol, we get this "{{Wagon protocol '' doesn't
support directory copying}}" error.
However, it seems that the usage of a parent located in the repository is part
of the problem.
You may test the project with the call
{noformat}
mvn -s settings.xml clean package site site:deploy
{noformat}
Have a look at the README.txt for simple preparation and alternate calls to
select the site-plugin version from command-line.
M3 fails with site-plugin 3.0, but succeeds with 3.0-beta-3 and will generate
no HTMLs for site-plugin version 2.x. M221 fails with site-plugin versions 3.0
and 2.3.
I've also linked this issue to MNG-617, MNG-585 and MNG-501 that seem to be
related.
was (Author: joehni):
We face the same problems. In our case we deploy the site documentation to
our intranet and depending on the environment the base URL is a file protocol
with different paths or scpexe. Therefore we have to use a property from
settings.xml.
The attached test project demonstrates the effect. Since our property contains
the protocol, we get this "{{Wagon protocol '' doesn't support directory
copying}}" error.
However, it seems that the usage of a parent located in the repository is part
of the problem.
You may test the project with the call
mvn -s settings.xml clean package site site:deploy
Have a look at the README.txt for simple preparation and alternate calls to
select the site-plugin version from command-line.
M3 fails with site-plugin 3.0, but succeeds with 3.0-beta-3 and will generate
no HTMLs for site-plugin version 2.x. M221 fails with site-plugin versions 3.0
and 2.3.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: 3.1
>
> Attachments: MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-734) When releaseVersion and developmentVersion are passed in command-line but are empty should be treated as not-defined
Dmitry Katsubo created MRELEASE-734:
---
Summary: When releaseVersion and developmentVersion are passed in
command-line but are empty should be treated as not-defined
Key: MRELEASE-734
URL: https://jira.codehaus.org/browse/MRELEASE-734
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Affects Versions: 2.2.2
Reporter: Dmitry Katsubo
In my case I would like to pass {{releaseVersion}} and {{developmentVersion}}
taken from user input, e.g. from [Hudson Release
Plugin|http://wiki.hudson-ci.org/display/HUDSON/Release+Plugin]:
{code}
release:prepare release:perform -DreleaseVersion=${RELEASE_VERSION}
-DdevelopmentVersion=${DEVELOPMENT_VERSION}
{code}
however if user leaves input fields empty it would be nice if
maven-release-plugin would treat empty values as non-defined and fallback to
default behaviour: inherit the next version from pom. Currently it breaks down
with message 'Unable to parse the version string ""'.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-826) maven-surefire-plugin does not add its own plugin dependencies to the classpath
René Zanner created SUREFIRE-826:
Summary: maven-surefire-plugin does not add its own plugin
dependencies to the classpath
Key: SUREFIRE-826
URL: https://jira.codehaus.org/browse/SUREFIRE-826
Project: Maven Surefire
Issue Type: Improvement
Components: classloading, Maven Surefire Plugin
Affects Versions: 2.11
Environment: Maven 3.0.3
Java 6
Reporter: René Zanner
Currently some JAR containing a RunListener for JUnit must be located in the
project's classpath (and pollutes the classpath with most likely unwanted
transitive dependencies).
An alternative is to use the 'additionalClasspathElements' configuration
element in the maven-surefire-plugin's configuration. Unfortunately this cannot
be used to specify another maven artifact directly - only JARs or class folders
in the file system.
It would be consistent to enable the usage of plugin dependencies
({{}} element in the {{}} section of the POM) to load
such classes:
{code:xml}
maven-surefire-plugin
listener
some.RunListener
some.group.id
some-artifact-id
${some.version}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-825) NPE in JUnit4TestChecker if org.junit.runner.RunWith class can't be loaded by testClassloader
[ https://jira.codehaus.org/browse/SUREFIRE-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290475#comment-290475 ] Jan Sievers commented on SUREFIRE-825: -- If you think this issue is valid, I am willing to spend time on writing a unit test which mocks the package-filtering OSGi classloader to reproduce the issue standalone. > NPE in JUnit4TestChecker if org.junit.runner.RunWith class can't be loaded by > testClassloader > - > > Key: SUREFIRE-825 > URL: https://jira.codehaus.org/browse/SUREFIRE-825 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.10 > Environment: tycho-surefire OSGi adapter >Reporter: Jan Sievers > Attachments: 0001-SUREFIRE-825-Add-null-check-for-runWith-field.patch > > > This is a follow up on tycho-surefire bug > https://bugs.eclipse.org/bugs/show_bug.cgi?id=369266 > If the class org.junit.runner.RunWith can't be loaded by the test > classloader, we get an NPE > org.apache.maven.surefire.util.SurefireReflectionException: > java.lang.reflect.InvocationTargetException; nested exception is > java.lang.reflect.InvocationTargetException: null > java.lang.reflect.InvocationTargetException > 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:123) > at > org.eclipse.tycho.surefire.osgibooter.OsgiSurefireBooter.run(OsgiSurefireBooter.java:84) > at > org.eclipse.tycho.surefire.osgibooter.HeadlessTestApplication.run(HeadlessTestApplication.java:21) > 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.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) > at > org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) > 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.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) > at org.eclipse.equinox.launcher.Main.run(Main.java:1410) > at org.eclipse.equinox.launcher.Main.main(Main.java:1386) > Caused by: java.lang.NullPointerException > at java.lang.Class.getAnnotation(Class.java:3027) > at > org.apache.maven.surefire.common.junit4.JUnit4TestChecker.isValidJUnit4Test(JUnit4TestChecker.java:63) > at > org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:52) > at > org.apache.maven.surefire.util.DefaultDirectoryScanner.locateTestClasses(DefaultDirectoryScanner.java:80) > at > org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:174) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:83) > ... 28 more > This can happen in an OSGi classloader environment where > classloading/visibility is controlled down to the package level. > A test OSGi bundle may well only import package org.junit (containing the > Test annotation, via MANIFEST header "Import-Package: org.junit"), but not > package org.junit.runner. > Thus org.junit.runner.RunWith can't be l
[jira] (MINDEXER-50) Logging of parsing exceptions should be handled consistently in org.apache.maven.index.creator.MavenPluginArtifactInfoIndexCreator
Peter Lynch created MINDEXER-50: --- Summary: Logging of parsing exceptions should be handled consistently in org.apache.maven.index.creator.MavenPluginArtifactInfoIndexCreator Key: MINDEXER-50 URL: https://jira.codehaus.org/browse/MINDEXER-50 Project: Maven Indexer Issue Type: Bug Reporter: Peter Lynch This patch makes the logging of artifact parsing exceptions consistent between org.apache.maven.index.creator.MavenPluginArtifactInfoIndexCreator and org.apache.maven.index.creator.MavenArchetypeArtifactInfoIndexCreator https://github.com/apache/maven-indexer/pull/2.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-50) Logging of parsing exceptions should be handled consistently in org.apache.maven.index.creator.MavenPluginArtifactInfoIndexCreator
[ https://jira.codehaus.org/browse/MINDEXER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Lynch updated MINDEXER-50: Affects Version/s: 4.1.2 > Logging of parsing exceptions should be handled consistently in > org.apache.maven.index.creator.MavenPluginArtifactInfoIndexCreator > -- > > Key: MINDEXER-50 > URL: https://jira.codehaus.org/browse/MINDEXER-50 > Project: Maven Indexer > Issue Type: Bug >Affects Versions: 4.1.2 >Reporter: Peter Lynch > > This patch makes the logging of artifact parsing exceptions consistent > between org.apache.maven.index.creator.MavenPluginArtifactInfoIndexCreator > and org.apache.maven.index.creator.MavenArchetypeArtifactInfoIndexCreator > https://github.com/apache/maven-indexer/pull/2.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJARSIGNER-14) Keystore password should be entered in an interactive way
[
https://jira.codehaus.org/browse/MJARSIGNER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290486#comment-290486
]
Eric TOURNIER commented on MJARSIGNER-14:
-
Here is a second patch which asks the user for both storepass and keypass
without echoing them.
> Keystore password should be entered in an interactive way
> -
>
> Key: MJARSIGNER-14
> URL: https://jira.codehaus.org/browse/MJARSIGNER-14
> Project: Maven 2.x Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Eric TOURNIER
>Priority: Minor
> Attachments: MJARSIGNER-14-maven-jarsigner-plugin.patch
>
>
> For security reasons, it could be useful not to configure keystore password
> in the {{pom.xml}} file. Then, when these informations are missing, the
> plugin should ask the user to enter this password in an interactive way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJARSIGNER-14) Keystore password should be entered in an interactive way
[
https://jira.codehaus.org/browse/MJARSIGNER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric TOURNIER updated MJARSIGNER-14:
Attachment: MJARSIGNER-14-maven-jarsigner-plugin.patch
> Keystore password should be entered in an interactive way
> -
>
> Key: MJARSIGNER-14
> URL: https://jira.codehaus.org/browse/MJARSIGNER-14
> Project: Maven 2.x Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Eric TOURNIER
>Priority: Minor
> Attachments: MJARSIGNER-14-maven-jarsigner-plugin.patch,
> MJARSIGNER-14-maven-jarsigner-plugin.patch
>
>
> For security reasons, it could be useful not to configure keystore password
> in the {{pom.xml}} file. Then, when these informations are missing, the
> plugin should ask the user to enter this password in an interactive way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-239) merge unpack to a single directory
[
https://jira.codehaus.org/browse/MDEP-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290490#comment-290490
]
Aaron Roller commented on MDEP-239:
---
I have a similar request to flatten the directory. Basically, I have a file in
the META-INF directory that I want to relocate to the root folder of a webapp.
Putting my request in terms of assembly plugin fileset terms:
{noformat}
META-INF
${project.build.outputDirectory}/${project.build.finalName}
*.html
{noformat}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_fileSet
> merge unpack to a single directory
> --
>
> Key: MDEP-239
> URL: https://jira.codehaus.org/browse/MDEP-239
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: unpack-dependencies
>Affects Versions: 2.0-alpha-4
>Reporter: Anders Kr. Andersen
>Assignee: Brian Fox
>Priority: Minor
>
> I would like an option to having the unpacked artifacts unpacked into the
> same directory root.
> This is usefull for my usecase, where I want to merge artifacts content. and
> use it further on in a merged context.
> Suggest flag: merge true/false
> Today a subdirectory with the artifact name is created under the
>
> I know that duplicate file will be possible. Here just the first/last wins.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-326) mvn dependency tree not working
[ https://jira.codehaus.org/browse/MDEP-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290508#comment-290508 ] Kamil Demecki commented on MDEP-326: I cannot agree with you Carlos. I think it is obvious case that maven dependency plugin (or some other maven tool) should show what dependency is not resolved - it is not obvious to find problem on 3rd or next level of dependencies. I see that pom cannot be found but I don't know which dependency refers it. > mvn dependency tree not working > --- > > Key: MDEP-326 > URL: https://jira.codehaus.org/browse/MDEP-326 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.3 > Environment: maven version i am using is > /usr/local/apache-maven-3.0/bin/mvn >Reporter: kapila >Assignee: Brian Fox > > While building a sub-project where I am trying to find the jar dependency > showing up in compliation which i am not able to locate in code/pom. > > Tried command ;- mvn dependency:tree > this doesnt show up the dependency tree > this jar doesnt exist on nexus even, so i wanna see where is this defined in > pom or dependency jar is calling it. > error is > Downloaded: > http://IP:8081/nexus/content/groups/public-snapshots/abc/abc-web-utils/1.1-SNAPSHOT/maven-metadata.xml > (351 B at 6.0 KB/sec) > Downloading: > http://IP:8081/nexus/content/groups/public/org/hibernate/ehcache/hibernate-core/3.3.1.GA/hibernate-core-3.3.1.GA.pom > > [WARNING] The POM for org.hibernate.ehcache:hibernate-core:jar:3.3.1.GA is > missing, no dependency information available > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.065s > [INFO] Finished at: Tue Sep 20 16:29:32 IST 2011 > [INFO] Final Memory: 8M/1009M > [INFO] > > [ERROR] Failed to execute goal on project com.abc.data.web: Could not resolve > dependencies for project com.abc:com.abc.data.web:war:3.0.0.M1: Could not > find artifact org.hibernate.ehcache:hibernate-core:jar:3.3.1.GA in abc > (http://IP:8081/nexus/content/groups/public) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException > > /home/kapilacvs/data-3.0/data-web/data-web > have made entry in pom also - > > org.apache.maven.plugins > > maven-dependency-plugin > 2.3 > > i have tried to run same command- mvn dependency:analyze-only on its parent > pom its runs fine for other sub-projects. but give issue in this specific > project. Doesn't give any dependency graph at all build gives build failure. > was trying to understand what harm can these make expect cleaner code- > [WARNING] Used undeclared dependencies found: > [WARNING] Unused declared dependencies found: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-158) outputDirectory is marked as mandatory whereas it is not really mandatory
[
https://jira.codehaus.org/browse/MRESOURCES-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290512#comment-290512
]
Robert Scholte commented on MRESOURCES-158:
---
Mandatory has nothing to do with default values. If you empty a mandatory
parameter, the build should fail.
> outputDirectory is marked as mandatory whereas it is not really mandatory
> -
>
> Key: MRESOURCES-158
> URL: https://jira.codehaus.org/browse/MRESOURCES-158
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Jorg Heymans
>
> in the documentation and plugin descriptor the outputDirectory config element
> is marked as mandatory. But since there is a default value of
> ${project.build.outputDirectory} this element is not really mandatory. Other
> configuration elements with the same default value semantics are not marked
> as mandatory so i think for outputDirectory the same semantics should be
> applied.
> this is especially troublesome for ideas that try to assist in maven
> configuration and rely on the plugin descriptor to figure out if elements are
> mandatory or not. See http://youtrack.jetbrains.net/issue/IDEA-80626
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-158) outputDirectory is marked as mandatory whereas it is not really mandatory
[
https://jira.codehaus.org/browse/MRESOURCES-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290520#comment-290520
]
Jorg Heymans commented on MRESOURCES-158:
-
There are different semantics IMO.
1) 'emptying' the parameter value as you say is this:
{code}
maven-resources-plugin
2.5
{code}
The value was in this case specified as null so a build error will be triggered
because it is mandatory. Does mandatory then mean a not-null not-empty string
or is this up to the plugin to interpret ?
2) Not specifying the parameter at all:
{code}
maven-resources-plugin
2.5
{code}
In this case the default value kicks in.
3) Specifying the parameter, the common case no problem there
{code}
maven-resources-plugin
2.5
mydir
{code}
Is this consistent for all maven plugins ? In that case an IDE should do an
extra check in case of a mandatory parameter, i.e. not-null check on the value
if the element is specified, and let it pass if the element is not specified
and has a default value. But this would break if there are plugins out there
that specify mandatory parameters without a default value. Do these exist ? And
where is the default value kept, it's not in the plugin descriptor AFAICT.
> outputDirectory is marked as mandatory whereas it is not really mandatory
> -
>
> Key: MRESOURCES-158
> URL: https://jira.codehaus.org/browse/MRESOURCES-158
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Jorg Heymans
>
> in the documentation and plugin descriptor the outputDirectory config element
> is marked as mandatory. But since there is a default value of
> ${project.build.outputDirectory} this element is not really mandatory. Other
> configuration elements with the same default value semantics are not marked
> as mandatory so i think for outputDirectory the same semantics should be
> applied.
> this is especially troublesome for ideas that try to assist in maven
> configuration and rely on the plugin descriptor to figure out if elements are
> mandatory or not. See http://youtrack.jetbrains.net/issue/IDEA-80626
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-629) Adding additional wagon provider as dependency does not work
[
https://jira.codehaus.org/browse/MSITE-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290524#comment-290524
]
Dennis Lundberg commented on MSITE-629:
---
I've tried this locally and was able to get past your error message, but ended
up with another error due to the fact that I don't have a local Nexus
installation. Can you try it and see if it works for you?
Add the following as an extra dependency to maven-site-plugin:
{code}
org.slf4j
slf4j-nop
1.5.3
runtime
{code}
> Adding additional wagon provider as dependency does not work
>
>
> Key: MSITE-629
> URL: https://jira.codehaus.org/browse/MSITE-629
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Mac OS 10.7.2, Apple Java 1.6.0_29, Maven 3.0.3/3.0.4
> Windows XP, SUN Java 1.6.0_24, Maven 3.0.4
>Reporter: Anders Hammar
> Attachments: console.txt, mvnsite-dav-dep-bug.zip
>
>
> According to
> http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deploy-protocol.html
> is should be possible to add additional wagon provider as a dependency to
> the site plugin. For a project deploying via dav, doing so using the
> wagon-webdav-jackrabbit makes Maven through a NoClassDefFoundError. Of adding
> the wagon as a global extension it works.
> Not sure if this is a maven-site-plugin issue though, or possible something
> in the specific wagon.
> I'm attaching a test project as well as the console output showing the error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-637) parsing of git urls fails on windows
[
https://jira.codehaus.org/browse/SCM-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290526#comment-290526
]
Robert Scholte commented on SCM-637:
{noformat}
private static final Pattern HOST_AND_PORT_EXTRACTOR =
Pattern.compile(
"([^:/~]*)(?::(\\d+))?(?::([^:/~]))?([/].*)?" );
// host ^---^
// separator ^
// port^^
// separator ^
// user^-^
{noformat}
At least Windows URL succeed, but the testGitDevURL fails :(
Anyone else wanna give it a try?
> parsing of git urls fails on windows
>
>
> Key: SCM-637
> URL: https://jira.codehaus.org/browse/SCM-637
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.5
>Reporter: Felix Simmendinger
>Priority: Blocker
>
> please fix this issue raised in the release plugin
> http://jira.codehaus.org/browse/MRELEASE-624
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-158) outputDirectory is marked as mandatory whereas it is not really mandatory
[
https://jira.codehaus.org/browse/MRESOURCES-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290536#comment-290536
]
Robert Scholte commented on MRESOURCES-158:
---
Here's an example of a help goal as specified in the META-INF/maven/plugin.xml:
{code:xml}
help
Display help information on maven-jar-plugin.
Call mvn jar:help -Ddetail=true
-Dgoal=<goal-name>
to display parameter
details.
false
false
false
false
false
true
org.apache.maven.plugin.jar.HelpMojo
java
per-lookup
once-per-session
true
detail
boolean
false
true
If true, display all settable
properties for each goal.
goal
java.lang.String
false
true
The name of the goal for which to show help. If
unspecified, all goals will be displayed.
indentSize
int
false
true
The number of spaces per indentation level, should be
positive.
lineLength
int
false
true
The maximum length of a display line, should be
positive.
${detail}
${goal}
${indentSize}
${lineLength}
{code}
The configuration-section contains these values.
Is it consistent? Probably not, but it should. Just like {{default-value}} and
{{expression}} they are often confused, but they are slightly different.
{quote}Does mandatory then mean a not-null not-empty string or is this up to
the plugin to interpret ?{quote}
This is verified by Plexus. As a plugin-developer you only have to say it is
{{@required}}.
> outputDirectory is marked as mandatory whereas it is not really mandatory
> -
>
> Key: MRESOURCES-158
> URL: https://jira.codehaus.org/browse/MRESOURCES-158
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Jorg Heymans
>
> in the documentation and plugin descriptor the outputDirectory config element
> is marked as mandatory. But since there is a default value of
> ${project.build.outputDirectory} this element is not really mandatory. Other
> configuration elements with the same default value semantics are not marked
> as mandatory so i think for outputDirectory the same semantics should be
> applied.
> this is especially troublesome for ideas that try to assist in maven
> configuration and rely on the plugin descriptor to figure out if elements are
> mandatory or not. See http://youtrack.jetbrains.net/issue/IDEA-80626
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
