[jira] Created: (MRELEASE-490) Enable promotion process
Enable promotion process
Key: MRELEASE-490
URL: http://jira.codehaus.org/browse/MRELEASE-490
Project: Maven 2.x Release Plugin
Issue Type: New Feature
Reporter: Aziz Joumady
Priority: Minor
A new interesting feature would be useful for some projects.
The promotion process.
+First of all, what is a promotion ?+
The promotion is the process of validating a version as stabilized by changing
a version.
Promotion steps are SNAPSHOT --> alpha --> beta --> rc --> Main version.
+Use case+
Artifact : promotiontest-project
Version : 1.0-alpha-1-SNAPSHOT
Developers work on the SNAPSHOT from the trunk.
Once the SNAPSHOT pass the unit test, it is decided to release it (using
release plugin).
The version is then tagged and deployed to the repository as 1.0-alpha-1. The
next development version us the 1.0-alpha-2-SNAPSHOT
The assembly step aims at test the alpha version. If the version is validated,
We would like to promote it to beta.
Promoting the version to beta just change the version name from 1.0-alpha-1 to
1.0-beta-1, tag this new version, and deployed it to the repository.
The integration step aims at test the beta version. If the version is
validated, We would like to promote it to release candidate (rc).
Finally the version could be promoted as 1.0 version.
+Proposition+
{{mvn release:promote -DversionToPromote=1.0-alpha-1}}
The goal should work in a similar way as the branch goal, excepting it forces
the branch name using the versionToPromote name and it does not change the
local copy.
1/ By using release information, the plugin retrieves the scm tag of the
versionToPromote
2/ It checks out the version from the scm
3/ It changes the pom.xml versions and scm tags.
4/ It creates the new tag
5/ It checkout the new tag an perform the release (deploy to the repository)
--
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-491) Releasing publich nodes with mergeID, but this node only for internal use and not valid with XSD
Releasing publich nodes with mergeID, but this node only for internal use and not valid with XSD Key: MRELEASE-491 URL: http://jira.codehaus.org/browse/MRELEASE-491 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-9 Reporter: Hafga Attachments: poms.zip If you release a POM this plugin will add mergeId node. This node only allowed for internal use. But this version of POM will publish to repository: http://maven.apache.org/ref/2.1.0/maven-model/maven.html resource-0 src/main/resources resource-1 src/test/resources -- 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: (MCOMPILER-108) Overwriting configurations does not take affect in a POM child project
[
http://jira.codehaus.org/browse/MCOMPILER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MCOMPILER-108:
Attachment: MCOMPILER-108.zip
The attached demo project uses different source/target options in the parent
and child modules and works just fine.
> Overwriting configurations does not take affect in a POM child project
> ---
>
> Key: MCOMPILER-108
> URL: http://jira.codehaus.org/browse/MCOMPILER-108
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Thiago Leão Moreira
> Attachments: MCOMPILER-108.zip
>
>
> If you define a parent project with this compiler configuration
>
> maven-compiler-plugin
> true
>
> 1.3
> 1.3
>
>
> And a child project with this
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.3
> 1.1
> true
>
> -g:none
>
>
>
> ${settings.localRepository}/org/microemu/midpapi20/2.0.3/midpapi20-2.0.3.jar
>
>
>
>
> the configurations in the child project will not take affect!
--
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: (MSHARED-132) Add support for manifest attributes introduced with java.lang.instrument
[
http://jira.codehaus.org/browse/MSHARED-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194511#action_194511
]
Andreas Sewe commented on MSHARED-132:
--
I am aware of this possibility, which for {{Pre-Main-Class}} and
{{Agent-Class}} it works fine (just as it would for {{Main-Class}}, by the way
;-)); it simply changes the name of the XML element I have to use. Support for
the {{Class-Path}} manifest attribute, however, has some more smarts build in.
I thus wonder whether some of them might suit {{Boot-Class-Path}} as well.
There is, however, the issue that you would rarely want *all* dependencies to
show up in {{Boot-Class-Path}}; some of them should probably still end up in
the {{Class-Path}} entry. The question then is how to make this configurable.
Maybe one can distinguish by means of a classifier, as is possible with, e.g.,
the include and exclude directives of {{dependency:copy-dependencies}}.
That being said, I can live with explicit {{manifestEntries}}; it only causes
me to repeat myself whenever the {{Boot-Class-Path}} grows longer, as for each
of its entries I still have to have a {{provided}}-scoped dependency (to cause
Maven to compile my boot class path JARs automatically).
> Add support for manifest attributes introduced with java.lang.instrument
>
>
> Key: MSHARED-132
> URL: http://jira.codehaus.org/browse/MSHARED-132
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-2.4
>Reporter: Andreas Sewe
>Priority: Minor
>
> With J2SE 1.5 and the {{java.lang.instrument}} package, new manifest
> attributes have been introduced: {{Pre-Main-Class}}, {{Agent-Class}},
> {{Boot-Class-Path}}, etc. (see
> http://java.sun.com/javase/6/docs/api/java/lang/instrument/package-summary.html
> for a complete list). It would be great if the maven-archiver could support
> these as well as it supports the very similar {{Main-Class}} and
> {{Class-Path}} manifest attributes. (Note, however, that the attributes
> introduced require the use of JARs; they are not completely independent of
> the archive format, so maybe maven-archiver is not a perfect fit.)
--
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: (MCOMPILER-108) Overwriting configurations does not take affect in a POM child project
[
http://jira.codehaus.org/browse/MCOMPILER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MCOMPILER-108.
---
Resolution: Cannot Reproduce
Assignee: Benjamin Bentmann
Feel free to reopen when you can provide a reproducible test project that
exhibits the issue.
> Overwriting configurations does not take affect in a POM child project
> ---
>
> Key: MCOMPILER-108
> URL: http://jira.codehaus.org/browse/MCOMPILER-108
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Thiago Leão Moreira
>Assignee: Benjamin Bentmann
> Attachments: MCOMPILER-108.zip
>
>
> If you define a parent project with this compiler configuration
>
> maven-compiler-plugin
> true
>
> 1.3
> 1.3
>
>
> And a child project with this
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.3
> 1.1
> true
>
> -g:none
>
>
>
> ${settings.localRepository}/org/microemu/midpapi20/2.0.3/midpapi20-2.0.3.jar
>
>
>
>
> the configurations in the child project will not take affect!
--
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-491) Releasing publich nodes with mergeID, but this node only for internal use and not valid with XSD
[ http://jira.codehaus.org/browse/MRELEASE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194521#action_194521 ] Hafga commented on MRELEASE-491: This problem has started with version 2.0-beta-8 and is in 2.0-beta-9, too. In version 2.0-beta-7 no mergeId will be published > Releasing publich nodes with mergeID, but this node only for internal use and > not valid with XSD > > > Key: MRELEASE-491 > URL: http://jira.codehaus.org/browse/MRELEASE-491 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-9 >Reporter: Hafga > Attachments: poms.zip > > > If you release a POM this plugin will add mergeId node. This node only > allowed for internal use. But this version of POM will publish to repository: > http://maven.apache.org/ref/2.1.0/maven-model/maven.html > > > resource-0 > src/main/resources > > > > > resource-1 > src/test/resources > > -- 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: (MSHARED-40) Exported POM still has dependency version ranges
[ http://jira.codehaus.org/browse/MSHARED-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194524#action_194524 ] Thorsten Möller commented on MSHARED-40: My experience is that any occurrence of properties is not substituted in exported POMs. It seems to me that the original POM files are merely copied. Is this correct? Maybe the Maven experts on this board can shed a light whether this is (i) intended behavior and (ii) whether there can be harmful consequences caused by the fact that properties are not evaluated. > Exported POM still has dependency version ranges > > > Key: MSHARED-40 > URL: http://jira.codehaus.org/browse/MSHARED-40 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-archiver >Reporter: Matthew Beermann > > If you have a version range for one of your dependencies, then the exported > POM (the one that's placed in the repository and in the jar itself) will > still have a range there. This seems at odds with (one) point of exporting a > POM, which is to have all the information you need to reconstruct the state > of a build at a particular moment in time. Without knowing which version > number was chosen, you can't be sure you're reconstructing the same build > later. > It also seems to be at odds with the behavior elsewhere in this exported > artifact: the plugins section shows the actual version number used, and > active profiles are quietly merged into the main POM. -- 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: (MJAR-129) Already build test-jar for project which packaging is not jar
Already build test-jar for project which packaging is not jar - Key: MJAR-129 URL: http://jira.codehaus.org/browse/MJAR-129 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.2 Environment: java 1.6 mvn 2.2.1, mvn 2.0.9, mvn 2.1.0 Reporter: Christophe Lallement Attachments: test.zip The classic use case is when you use multi-module project. pomA (packaging pom) -> pomB (packaging jar) -> pomC (packaging jar) -> pomD (packaging pom) pomB,C,D inherit from pomA We define common plugin configuration into pomA, for example say to jar plugin to build test jar. but in some case it make not sense (for example when pom is type of 'pom') and in this case an empty jar is construct (then uploaded when we deploy) Maybe a check to detect zip file is empty could be sufficient or attache this plugin only on specific pom packaging (jar/war/ear ...) I have attached a sample, just unzip and run mvn package inside "test" directory. Regards Christophe -- 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-268) performance problem in AbstractJavadocMojo.getModulesLinks()
performance problem in AbstractJavadocMojo.getModulesLinks() Key: MJAVADOC-268 URL: http://jira.codehaus.org/browse/MJAVADOC-268 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.6 Environment: Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200) Java version: 1.6.0_13 Java home: /home/mkleint/javatools/jdk1.6.0_13/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.29.6-desktop-2mnb" arch: "i386" Family: "unix" Reporter: Milos Kleint Priority: Critical Attachments: javadoc.patch The getModulesLinks() method is unacceptably slow under certain conditions: 1. project's url is defined 2. one or more projects in reactor do not have any java sources and are not of "pom" packaging. For such projects the apidocs/ output folder is never created resulting in repeated invokation of a forked javadoc goal. It's more severe with high number of modules in reactor and high number of modules without any java sources. as an example checkout "hg clone https://hg.kenai.com/hg/forceten~src"; The immediate problem is in the apidocsFile.exists() condition that re-triggers the forked invokation. The attached patch fixes that. However it looks suspicitions that the method is being called repeatedly for each module at all. Maybe the aborting condition at the start of the method body is wrong (I was not able to decypher that) workaround is to use 2.5 or not to specify the url in pom.xml or set the detectOfflineLinks parameter to "false". -- 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: (MJAVADOC-268) performance problem in AbstractJavadocMojo.getModulesLinks()
[ http://jira.codehaus.org/browse/MJAVADOC-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194530#action_194530 ] Milos Kleint commented on MJAVADOC-268: --- originally reported at http://forums.netbeans.org/topic18558.html > performance problem in AbstractJavadocMojo.getModulesLinks() > > > Key: MJAVADOC-268 > URL: http://jira.codehaus.org/browse/MJAVADOC-268 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200) > Java version: 1.6.0_13 > Java home: /home/mkleint/javatools/jdk1.6.0_13/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.29.6-desktop-2mnb" arch: "i386" Family: "unix" >Reporter: Milos Kleint >Priority: Critical > Attachments: javadoc.patch > > > The getModulesLinks() method is unacceptably slow under certain conditions: > 1. project's url is defined > 2. one or more projects in reactor do not have any java sources and are not > of "pom" packaging. > For such projects the apidocs/ output folder is never created resulting in > repeated invokation of a forked javadoc goal. It's more severe with high > number of modules in reactor and high number of modules without any java > sources. > as an example checkout "hg clone https://hg.kenai.com/hg/forceten~src"; > The immediate problem is in the apidocsFile.exists() condition that > re-triggers the forked invokation. The attached patch fixes that. However it > looks suspicitions that the method is being called repeatedly for each module > at all. Maybe the aborting condition at the start of the method body is wrong > (I was not able to decypher that) > workaround is to use 2.5 or not to specify the url in pom.xml or set the > detectOfflineLinks parameter to "false". -- 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: (MJAVADOC-268) performance problem in AbstractJavadocMojo.getModulesLinks()
[ http://jira.codehaus.org/browse/MJAVADOC-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194532#action_194532 ] Fabrizio Giudici commented on MJAVADOC-268: --- I'm the author of forceten - please use "hg up -C 65db9b4e5077" to get a version with the 2.6, as I'm temporarily reverting the project to use 2.5. > performance problem in AbstractJavadocMojo.getModulesLinks() > > > Key: MJAVADOC-268 > URL: http://jira.codehaus.org/browse/MJAVADOC-268 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200) > Java version: 1.6.0_13 > Java home: /home/mkleint/javatools/jdk1.6.0_13/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.29.6-desktop-2mnb" arch: "i386" Family: "unix" >Reporter: Milos Kleint >Priority: Critical > Attachments: javadoc.patch > > > The getModulesLinks() method is unacceptably slow under certain conditions: > 1. project's url is defined > 2. one or more projects in reactor do not have any java sources and are not > of "pom" packaging. > For such projects the apidocs/ output folder is never created resulting in > repeated invokation of a forked javadoc goal. It's more severe with high > number of modules in reactor and high number of modules without any java > sources. > as an example checkout "hg clone https://hg.kenai.com/hg/forceten~src"; > The immediate problem is in the apidocsFile.exists() condition that > re-triggers the forked invokation. The attached patch fixes that. However it > looks suspicitions that the method is being called repeatedly for each module > at all. Maybe the aborting condition at the start of the method body is wrong > (I was not able to decypher that) > workaround is to use 2.5 or not to specify the url in pom.xml or set the > detectOfflineLinks parameter to "false". -- 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: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194533#action_194533 ] Mark Hobson commented on SUREFIRE-482: -- A good workaround is to add @Ignore to the class that shouldn't be run. > Surefire tries to run JUnit4 tests that contain no @Test annotations > > > Key: SUREFIRE-482 > URL: http://jira.codehaus.org/browse/SUREFIRE-482 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.4.2 >Reporter: Mark Hobson > Attachments: test.zip > > > Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that > contain no @Test annotations as tests, resulting in the exception: > java.lang.Exception: No runnable methods > at > org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) > at > org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) > at > org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) > at > org.junit.internal.runners.JUnit4ClassRunner.(JUnit4ClassRunner.java:27) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at > org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) > at > org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45) > at > org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) > at > org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) > at org.apache.maven.surefire.Surefire.run(Surefire.java:156) > 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:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) > Such classes should be ignored by Surefire. -- 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-447) Redefined scope is ignored for dependencies
Redefined scope is ignored for dependencies --- Key: MASSEMBLY-447 URL: http://jira.codehaus.org/browse/MASSEMBLY-447 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-4 Reporter: Eric Lewis I have a dependency which is defined with test. In another project, however, it is redefined to runtime. Now, when I get the runtime dependencies with true false runtime *:sources the dependency is not included. -- 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: (MNG-4391) DependencyManagement should allow to manage use of re-named, woven, instrumented or compatible artifacts
[
http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194540#action_194540
]
Neale commented on MNG-4391:
I think that's a rather personal point of view, if you don't mind me saying.
On that basis, none of us would make use of AspectJ or proxies.
It is _already_ the case that a child project configured to download X gets Y,
as that's what we're actually trying to do. The problem is that it doesn't
actually say "replace X with Y". It says: "don't download X".
You are mistaken in thinking that "when I look at the child POM, it says
download X" is relevant to what we as developers need. We can easily end up
with multiple versions of the same API on the classpath because the exclusions
weren't set on every child.
At some point in our project we want to say something like (as OSGi gives us):
_the implementation of org.apache.commons.logging that I want to use in my
build and runtime can be found in org.slf4j:slf4j:org.apache.commons.logging_,
or, if we want one that has been built as a valid OSGi bundle:
_org.slf4j:com.springsource.slf4j.org.apache.commons.logging_.
What we certainly *don't* want is to have to repeat the exclude on an ad-hoc
basis, and nor do we want the _meaning_ lost in separating out an exclusion
with a global inclusion (which is not always wanted either - e.g. for corporate
standards).
Can you please tell me how you propose to satisfy this use case, if you still
have your objections to my solution, please. It's all very well disagreeing,
but it would be useful to offer a better solution in it's place.
> DependencyManagement should allow to manage use of re-named,
> woven, instrumented or compatible artifacts
> --
>
> Key: MNG-4391
> URL: http://jira.codehaus.org/browse/MNG-4391
> Project: Maven 2
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 2.2.1
>Reporter: Neale
>
> [if only this was a later version of JIRA I'd have not lost all of what I
> just typed, as I could use Mylyn instead of the web UI. here goes again...]
> The challenge of using a different artifact instead of the one that is
> specified in a POM that you are consuming is not an easy one.
> Examples where this hits uses is:
> - the artifact name and packaging changes that Spring made at 2.5.6A (which
> was a big improvement)
> - wanting to use SLF4J instead of Apache commons logging (i.e. use something
> that provides the same API, but is an entirely different project)
> - wanting to use your own derivation of a public artifact
> - wanting to use a woven/instrumented version of a public artifact
> The current approach to replacing, say org.springframework : spring-beans
> with org.springframework : org.springframework.beans is to do ('scuse the
> shorthand):
> {code:xml}
>
>
>
> com.sun.jersey.contribs
> jersey-spring
>
>org.springframework : spring-beans
>
>
> ... repeat for every artifact that uses spring-beans, and then add more
> if adding another artifact
>
>
> {code}
> to exclude it, and then globally include the replacement using:
> {code:xml}
>
>
> org.springframework
> org.springframework.beans
> ${spring.version}
>
>
> {code}
> This is error prone, and could be made far easier by an extension to
> dependencies, which would remove the need to know what artifacts
> (jersey-spring in the above example) use the artifact that you are replacing.
> Here's how it would look:
> {code:xml}
>
>
>
>
> org.springframework
> org.springframework.beans
> ${spring.version}
>
>
>
> org.springframework
> spring-beans
>
>
> org.springframework
> org.springframework.beans
>
>
>
>
>
> {code}
> NOTE:
> - Nothing is specified in so no artifacts are globally added
> where they may not be needed. This means we can develop a project wide
> parent pom.xml.
> - Artifacts can have been split and merged
> - Derived artifacts, such as instrumented ones can easily be substituted, and
> could be selectively substituted using profiles.
--
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: (MNG-4391) DependencyManagement should allow to manage use of re-named, woven, instrumented or compatible artifacts
[
http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194540#action_194540
]
Neale edited comment on MNG-4391 at 10/13/09 8:30 AM:
--
I think that's a rather personal point of view, if you don't mind me saying.
On that basis, none of us would make use of AspectJ or proxies.
It is _already_ the case that a child project configured to download X gets Y,
as that's what we're actually trying to do. The problem is that it doesn't
actually say "replace X with Y". It says: "don't download X".
You are mistaken in thinking that "when I look at the child POM, it says
download X" is relevant to what we as developers need. We can easily end up
with multiple versions of the same API on the classpath because the exclusions
weren't set on every child.
At some point in our project we want to say something like (as OSGi gives us):
_the implementation of org.apache.commons.logging that I want to use in my
build and runtime can be found in org.slf4j:slf4j:org.apache.commons.logging_,
or, if we want one that has been built as a valid OSGi bundle:
_org.slf4j:com.springsource.slf4j.org.apache.commons.logging_.
What we certainly *don't* want is to have to repeat the exclude on an ad-hoc
basis, and nor do we want the _meaning_ lost in separating out an exclusion
with a global inclusion (which is not always wanted either - e.g. for corporate
standards).
Can you please tell me how you propose to satisfy this use case, if you still
have your objections to my solution. It's all very well disagreeing, but it
would be useful to offer a better solution in it's place.
was (Author: neale87):
I think that's a rather personal point of view, if you don't mind me
saying. On that basis, none of us would make use of AspectJ or proxies.
It is _already_ the case that a child project configured to download X gets Y,
as that's what we're actually trying to do. The problem is that it doesn't
actually say "replace X with Y". It says: "don't download X".
You are mistaken in thinking that "when I look at the child POM, it says
download X" is relevant to what we as developers need. We can easily end up
with multiple versions of the same API on the classpath because the exclusions
weren't set on every child.
At some point in our project we want to say something like (as OSGi gives us):
_the implementation of org.apache.commons.logging that I want to use in my
build and runtime can be found in org.slf4j:slf4j:org.apache.commons.logging_,
or, if we want one that has been built as a valid OSGi bundle:
_org.slf4j:com.springsource.slf4j.org.apache.commons.logging_.
What we certainly *don't* want is to have to repeat the exclude on an ad-hoc
basis, and nor do we want the _meaning_ lost in separating out an exclusion
with a global inclusion (which is not always wanted either - e.g. for corporate
standards).
Can you please tell me how you propose to satisfy this use case, if you still
have your objections to my solution, please. It's all very well disagreeing,
but it would be useful to offer a better solution in it's place.
> DependencyManagement should allow to manage use of re-named,
> woven, instrumented or compatible artifacts
> --
>
> Key: MNG-4391
> URL: http://jira.codehaus.org/browse/MNG-4391
> Project: Maven 2
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 2.2.1
>Reporter: Neale
>
> [if only this was a later version of JIRA I'd have not lost all of what I
> just typed, as I could use Mylyn instead of the web UI. here goes again...]
> The challenge of using a different artifact instead of the one that is
> specified in a POM that you are consuming is not an easy one.
> Examples where this hits uses is:
> - the artifact name and packaging changes that Spring made at 2.5.6A (which
> was a big improvement)
> - wanting to use SLF4J instead of Apache commons logging (i.e. use something
> that provides the same API, but is an entirely different project)
> - wanting to use your own derivation of a public artifact
> - wanting to use a woven/instrumented version of a public artifact
> The current approach to replacing, say org.springframework : spring-beans
> with org.springframework : org.springframework.beans is to do ('scuse the
> shorthand):
> {code:xml}
>
>
>
> com.sun.jersey.contribs
> jersey-spring
>
>org.springframework : spring-beans
>
>
> ... repeat for every artifact that uses spring-beans, and then add more
> if adding another artifact
>
>
> {code}
> to exclude it, and then globally include the replacement using:
> {code:xml}
>
>
> org.springframework
> org.s
[jira] Created: (MJAR-130) Sign goal fails on projects with maven-plugin packaging
Sign goal fails on projects with maven-plugin packaging
---
Key: MJAR-130
URL: http://jira.codehaus.org/browse/MJAR-130
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Edd Steel
If you run jar:sign on a project with maven-plugin packaging, jarsigner is run
with the argument '/-.maven-plugin' instead of
'/-.jar'.
A workaround is to add the configuration:
${project.build.directory}/${project.build.finalName}.jar
which is not very elegant.
--
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-4393) [regression] Parent POMs resolved from repository are parsed in strict mode
[regression] Parent POMs resolved from repository are parsed in strict mode --- Key: MNG-4393 URL: http://jira.codehaus.org/browse/MNG-4393 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 3.0-alpha-3 Reporter: Benjamin Bentmann When building the model for a project in the reactor, all parents POM resolved from the repos must be parsed in lenient mode to account for their potential bad contents. -- 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-492) The svn tag command failed
The svn tag command failed
--
Key: MRELEASE-492
URL: http://jira.codehaus.org/browse/MRELEASE-492
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-9
Environment: ubuntu 9.04 ,
Apache Maven 2.1.0 (r755702; 2009-03-19 00:40:27+0530)
Java version: 1.6.0_13
Java home: /usr/lib/jvm/java-6-sun-1.6.0.13/jre
Default locale: en_IN, platform encoding: UTF-8
OS name: "linux" version: "2.6.28-15-server" arch: "i386" Family: "unix"
Reporter: Sridher Jakku
when i run the mvn release:prepare this error comming
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.584 sec
[INFO] Running com.ipleanty.accure.module.orm.AppTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
[INFO]
[INFO] Results :
[INFO]
[INFO] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] [INFO] [antrun:run {execution: default}]
[INFO] [INFO] Executing tasks
[INFO] [echo]
[INFO] [echo] r2093 | js | 2009-10-13 20:02:29 +0530 (Tue, 13 Oct 2009)
[INFO] [echo]
[INFO] [echo] Your orm Revision number : 2073
[INFO] [INFO] Executed tasks
[INFO] [INFO] [jar:jar]
[INFO] [INFO] Building jar: /home/sridher/maven/svn/orm/target/orm-0.7.jar
[INFO] [INFO]
[INFO] [INFO] BUILD SUCCESSFUL
[INFO] [INFO]
[INFO] [INFO] Total time: 26 seconds
[INFO] [INFO] Finished at: Tue Oct 13 20:03:30 IST 2009
[INFO] [INFO] Final Memory: 25M/114M
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /home/sridher/maven/svn/orm && svn --username
js --password '*' --non-interactive commit --file
/tmp/maven-scm-327676631.commit --targets
/tmp/maven-scm-7485856893453511468-targets
[INFO] Working directory: /home/sridher/maven/svn/orm
[INFO] Tagging release with the label orm-0.7...
[INFO] Executing: /bin/sh -c cd /home/sridher/maven/svn/orm && svn --username
js --password '*' --non-interactive copy --file
/tmp/maven-scm-895863680.commit .
scm:svn:svn://192.168.1.10/Accure/orm/tags/orm-0.7
[INFO] Working directory: /home/sridher/maven/svn/orm
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Local, non-commit operations do not take a log message or revision
properties
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 41 seconds
[INFO] Finished at: Tue Oct 13 20:03:32 IST 2009
[INFO] Final Memory: 12M/119M
[INFO]
--
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: (MANT-61) Classpath generation should honour system-scope.
[
http://jira.codehaus.org/browse/MANT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Thomas updated MANT-61:
---
Attachment: MNT-61.patch
I've added a patch against the 2.2-release.
What does it do:
* for system scope artifacts, the corresponding dependency is looked up and the
systemPath is returned as path
* as the systemPath contains no more properties, each property value is
replaced by its key, e.g. {{C:\project\target\archiv.jar}} becomes
{{${${basedir}\target\archiv.jar}}}
* for system scope artifacts, no {{get-deps}}-entry is created
This allows for the generation of Ant files to be used in environments, where
no Maven repository is available.
> Classpath generation should honour system-scope.
>
>
> Key: MANT-61
> URL: http://jira.codehaus.org/browse/MANT-61
> Project: Maven 2.x Ant Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Michael Thomas
> Attachments: MNT-61.patch
>
>
> At the moment, dependencies are downloaded in the {{get-deps}}-target. For
> system dependencies, this is not necessary - the classpath-entries should
> directly reference the {{systemPath}}.
--
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: (MANT-61) Classpath generation should honour system-scope.
[
http://jira.codehaus.org/browse/MANT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194553#action_194553
]
Michael Thomas edited comment on MANT-61 at 10/13/09 9:44 AM:
--
I've added a patch against the 2.2-release.
What does it do:
* for system scope artifacts, the corresponding dependency is looked up and the
systemPath is returned as path
* as the systemPath contains no more properties, each property value is
replaced by its key, e.g. {{C:\project\target\archiv.jar}} becomes
{{${basedir}\target\archiv.jar}}}
* for system scope artifacts, no {{get-deps}}-entry is created
This allows for the generation of Ant files to be used in environments, where
no Maven repository is available.
was (Author: domi_digitus):
I've added a patch against the 2.2-release.
What does it do:
* for system scope artifacts, the corresponding dependency is looked up and the
systemPath is returned as path
* as the systemPath contains no more properties, each property value is
replaced by its key, e.g. {{C:\project\target\archiv.jar}} becomes
{{${${basedir}\target\archiv.jar}}}
* for system scope artifacts, no {{get-deps}}-entry is created
This allows for the generation of Ant files to be used in environments, where
no Maven repository is available.
> Classpath generation should honour system-scope.
>
>
> Key: MANT-61
> URL: http://jira.codehaus.org/browse/MANT-61
> Project: Maven 2.x Ant Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Michael Thomas
> Attachments: MNT-61.patch
>
>
> At the moment, dependencies are downloaded in the {{get-deps}}-target. For
> system dependencies, this is not necessary - the classpath-entries should
> directly reference the {{systemPath}}.
--
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: (MANT-61) Classpath generation should honour system-scope.
[
http://jira.codehaus.org/browse/MANT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194553#action_194553
]
Michael Thomas edited comment on MANT-61 at 10/13/09 9:44 AM:
--
I've added a patch against the 2.2-release.
What does it do:
* for system scope artifacts, the corresponding dependency is looked up and the
systemPath is returned as path
* as the systemPath contains no more properties, each property value is
replaced by its key, e.g. {{C:\project\target\archiv.jar}} becomes
{{${basedir}\target\archiv.jar}}
* for system scope artifacts, no {{get-deps}}-entry is created
This allows for the generation of Ant files to be used in environments, where
no Maven repository is available.
was (Author: domi_digitus):
I've added a patch against the 2.2-release.
What does it do:
* for system scope artifacts, the corresponding dependency is looked up and the
systemPath is returned as path
* as the systemPath contains no more properties, each property value is
replaced by its key, e.g. {{C:\project\target\archiv.jar}} becomes
{{${basedir}\target\archiv.jar}}}
* for system scope artifacts, no {{get-deps}}-entry is created
This allows for the generation of Ant files to be used in environments, where
no Maven repository is available.
> Classpath generation should honour system-scope.
>
>
> Key: MANT-61
> URL: http://jira.codehaus.org/browse/MANT-61
> Project: Maven 2.x Ant Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Michael Thomas
> Attachments: MNT-61.patch
>
>
> At the moment, dependencies are downloaded in the {{get-deps}}-target. For
> system dependencies, this is not necessary - the classpath-entries should
> directly reference the {{systemPath}}.
--
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-4393) [regression] Parent POMs resolved from repository are parsed in strict mode
[ http://jira.codehaus.org/browse/MNG-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4393. -- Resolution: Fixed Fix Version/s: 3.0-alpha-3 Assignee: Benjamin Bentmann Fixed in [r824842|http://svn.apache.org/viewvc?view=rev&revision=824842]. > [regression] Parent POMs resolved from repository are parsed in strict mode > --- > > Key: MNG-4393 > URL: http://jira.codehaus.org/browse/MNG-4393 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-3 > > > When building the model for a project in the reactor, all parents POM > resolved from the repos must be parsed in lenient mode to account for their > potential bad contents. -- 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: (MAVENUPLOAD-1538) xml-apis-1.2.01.jar
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194596#action_194596 ] Dennis Lundberg commented on MAVENUPLOAD-1538: -- Palanichamy Ramasamy: Why are you uploading PDF:s to this issue? They are copyrighted by IBM. I doubt that you have the right to distribute them. Even if you do they don't belong in an issue tracker. > xml-apis-1.2.01.jar > --- > > Key: MAVENUPLOAD-1538 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1538 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Michael Böckling >Assignee: Carlos Sanchez > Attachments: Introduction to Apache Maven 2.pdf, Introduction to > Apache Maven 2.pdf, pom.xml, xml-apis-1.2.01.jar > > > An older version of xml-apis. Needed by ICEFaces-1.5.3 which will follow > later on. POM is partially copied from > http://mirrors.ibiblio.org/pub/mirrors/maven2/xml-apis/xml-apis/1.3.04/xml-apis-1.3.04.pom. -- 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: (MCHANGES-178) Make the url parameter non-required
[ http://jira.codehaus.org/browse/MCHANGES-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-178. Resolution: Fixed Fix Version/s: 2.2 Assignee: Dennis Lundberg Fixed in [r824891|http://svn.apache.org/viewvc?view=rev&revision=824891]. > Make the url parameter non-required > --- > > Key: MCHANGES-178 > URL: http://jira.codehaus.org/browse/MCHANGES-178 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: announcement >Affects Versions: 2.1 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.2 > > > Currently the url parameter to the AnnouncementMojo is required. This is not > suitable for all projects. > As far as I can tell the url parameter is only used for two things: > # Act as a stand-in value for the introduction parameter, if that is not > supplied > # Forwarded to the Velocity template for use there > Our use case is that we have a project that doesn't have a url. We still want > to email an announcement when a new version is released. We are forced to > enter a dummy url in our plugin configuration to get around this. > I'd like to remove the @required annotation from AnnouncementMojo.url. Are > there any objections to this? > Projects already using the plugin will not be affected, because they already > have a url specified in their configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4391) DependencyManagement should allow to manage use of re-named, woven, instrumented or compatible artifacts
[
http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194601#action_194601
]
Paul Benedict commented on MNG-4391:
>> I think that's a rather personal point of view, if you don't mind me saying.
Of course it's a personal point of view.
>> It is already the case that a child project configured to download X gets Y
The use case is limited. X represents the artifact. You may configure different
versions of X for downloading, but it's still artifact X. Maven does provide
relocation support, but it's controlled by the publisher of the artifact. You
are expanding its use to give people the ability to relocate (temporarily) for
the current execution. Well, I don't think it's a good idea because it makes
the POM unclear what is going on.
> DependencyManagement should allow to manage use of re-named,
> woven, instrumented or compatible artifacts
> --
>
> Key: MNG-4391
> URL: http://jira.codehaus.org/browse/MNG-4391
> Project: Maven 2
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 2.2.1
>Reporter: Neale
>
> [if only this was a later version of JIRA I'd have not lost all of what I
> just typed, as I could use Mylyn instead of the web UI. here goes again...]
> The challenge of using a different artifact instead of the one that is
> specified in a POM that you are consuming is not an easy one.
> Examples where this hits uses is:
> - the artifact name and packaging changes that Spring made at 2.5.6A (which
> was a big improvement)
> - wanting to use SLF4J instead of Apache commons logging (i.e. use something
> that provides the same API, but is an entirely different project)
> - wanting to use your own derivation of a public artifact
> - wanting to use a woven/instrumented version of a public artifact
> The current approach to replacing, say org.springframework : spring-beans
> with org.springframework : org.springframework.beans is to do ('scuse the
> shorthand):
> {code:xml}
>
>
>
> com.sun.jersey.contribs
> jersey-spring
>
>org.springframework : spring-beans
>
>
> ... repeat for every artifact that uses spring-beans, and then add more
> if adding another artifact
>
>
> {code}
> to exclude it, and then globally include the replacement using:
> {code:xml}
>
>
> org.springframework
> org.springframework.beans
> ${spring.version}
>
>
> {code}
> This is error prone, and could be made far easier by an extension to
> dependencies, which would remove the need to know what artifacts
> (jersey-spring in the above example) use the artifact that you are replacing.
> Here's how it would look:
> {code:xml}
>
>
>
>
> org.springframework
> org.springframework.beans
> ${spring.version}
>
>
>
> org.springframework
> spring-beans
>
>
> org.springframework
> org.springframework.beans
>
>
>
>
>
> {code}
> NOTE:
> - Nothing is specified in so no artifacts are globally added
> where they may not be needed. This means we can develop a project wide
> parent pom.xml.
> - Artifacts can have been split and merged
> - Derived artifacts, such as instrumented ones can easily be substituted, and
> could be selectively substituted using profiles.
--
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: (MCHANGES-177) allow specify report columns
[ http://jira.codehaus.org/browse/MCHANGES-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-177. Resolution: Fixed Fix Version/s: 2.2 Assignee: Dennis Lundberg Patch applied in [r824902|http://svn.apache.org/viewvc?view=rev&revision=824902] with modifications. Thanks! > allow specify report columns > > > Key: MCHANGES-177 > URL: http://jira.codehaus.org/browse/MCHANGES-177 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: trac-report >Reporter: Tomas Vojtech >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: MCHANGES-177.patch > > > it would be nice if user could specify column names shown in the trac report. -- 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: (MJAR-130) Sign goal fails on projects with maven-plugin packaging
[
http://jira.codehaus.org/browse/MJAR-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194610#action_194610
]
Joerg Schaible commented on MJAR-130:
-
The jar:sign goal is deprecated, use the jarsigner plugin.
> Sign goal fails on projects with maven-plugin packaging
> ---
>
> Key: MJAR-130
> URL: http://jira.codehaus.org/browse/MJAR-130
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Edd Steel
>
> If you run jar:sign on a project with maven-plugin packaging, jarsigner is
> run with the argument '/-.maven-plugin'
> instead of '/-.jar'.
> A workaround is to add the configuration:
>
> ${project.build.directory}/${project.build.finalName}.jar
> which is not very elegant.
--
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: (MNG-4163) Deprecate all methods in MavenProject that relate to reporting.
[ http://jira.codehaus.org/browse/MNG-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-4163: --- Summary: Deprecate all methods in MavenProject that relate to reporting. (was: Remove all methods in MavenProject that relate to reporting.) > Deprecate all methods in MavenProject that relate to reporting. > --- > > Key: MNG-4163 > URL: http://jira.codehaus.org/browse/MNG-4163 > Project: Maven 2 > Issue Type: Sub-task >Affects Versions: 3.0-alpha-2 >Reporter: Jason van Zyl >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-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] Closed: (MNG-4163) Deprecate all methods in MavenProject that relate to reporting.
[ http://jira.codehaus.org/browse/MNG-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4163. -- Resolution: Fixed Deprecated methods in [r824941|http://svn.apache.org/viewvc?view=rev&revision=824941]. > Deprecate all methods in MavenProject that relate to reporting. > --- > > Key: MNG-4163 > URL: http://jira.codehaus.org/browse/MNG-4163 > Project: Maven 2 > Issue Type: Sub-task >Affects Versions: 3.0-alpha-2 >Reporter: Jason van Zyl >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-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: (MNG-4204) Remove support for legacy style repositories
[ http://jira.codehaus.org/browse/MNG-4204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194616#action_194616 ] Benjamin Bentmann commented on MNG-4204: [Related discussion on dev@|http://www.mail-archive.com/d...@maven.apache.org/msg81501.html]. > Remove support for legacy style repositories > > > Key: MNG-4204 > URL: http://jira.codehaus.org/browse/MNG-4204 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Minor > Fix For: 3.0-alpha-3 > > > Have been told M1 is long long ago so we shouldn't need the legacy repo > layout any more. -- 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: (MAVENUPLOAD-2628) Please upload javax.inject
Please upload javax.inject -- Key: MAVENUPLOAD-2628 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2628 Project: Maven Upload Requests Issue Type: Wish Reporter: Bob Lee I am the JSR lead: http://jcp.org/en/jsr/summary?id=330 -- 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: (MAVENUPLOAD-2628) Please upload javax.inject
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MAVENUPLOAD-2628. -- Resolution: Fixed Done. http://repo2.maven.org/maven2/javax/inject/javax.inject/1/ > Please upload javax.inject > -- > > Key: MAVENUPLOAD-2628 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2628 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Bob Lee >Assignee: Jason van Zyl > > I am the JSR lead: http://jcp.org/en/jsr/summary?id=330 -- 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] Question from a Maven NewBie. Can not run any mvn goal.
I am new to the Java, Maven, etc. I just downloaded and installed Maven. Followed all their instructions. I can not run any goal including mvn clean, or mvn anything. Pl. find the following stack trace. Any help will be greatly appreciated. My OS is XP (SP2). I tried 2 More newer versions of Maven. The same deal. Thanks. C:\>echo %M2_HOME% C:\java\apache-maven-2.0.9 C:\>echo %JAVA_HOME% C:\Sun\SDK\jdk C:\>echo %M2% C:\java\apache-maven-2.0.9\bin C:\>mvn -version Maven version: 2.0.9 Java version: 1.6.0_07 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" C:\>mvn -e clean + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [clean] [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean- plugin/2.2/maven-clean-plugin-2.2.jar [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that t he goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=mav en-clean-plugin -Dversion=2.2 -Dpackaging=maven-plugin -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins -DartifactId=maven -clean-plugin -Dversion=2.2 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl= [url] -DrepositoryId=[id] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.2 from the specified remote repositories: central (http://repo1.maven.org/maven2) org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.2 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.BuildFailureException: A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=mav en-clean-plugin -Dversion=2.2 -Dpackaging=maven-plugin -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins -DartifactId=maven -clean-plugin -Dversion=2.2 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl= [url] -DrepositoryId=[id] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.2 from the specified remote repositories: central (http://repo1.maven.org/maven2) org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.2 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:487) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginNotFoundException: Plugin could not be found - check that the goal name is correct: Unable to download the artifact fro m any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=mav en-clean-plugin -Dversion=2.2 -Dpackaging=maven-plugin -D
[jira] Reopened: (MCOMPILER-108) Overwriting configurations does not take affect in a POM child project
[
http://jira.codehaus.org/browse/MCOMPILER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago Leão Moreira reopened MCOMPILER-108:
---
Hi Benjamin,
I'm reopening the issue because I built a reproducible project.
> Overwriting configurations does not take affect in a POM child project
> ---
>
> Key: MCOMPILER-108
> URL: http://jira.codehaus.org/browse/MCOMPILER-108
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Thiago Leão Moreira
>Assignee: Benjamin Bentmann
> Attachments: MCOMPILER-108.zip
>
>
> If you define a parent project with this compiler configuration
>
> maven-compiler-plugin
> true
>
> 1.3
> 1.3
>
>
> And a child project with this
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.3
> 1.1
> true
>
> -g:none
>
>
>
> ${settings.localRepository}/org/microemu/midpapi20/2.0.3/midpapi20-2.0.3.jar
>
>
>
>
> the configurations in the child project will not take affect!
--
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: (MCOMPILER-108) Overwriting configurations does not take affect in a POM child project
[
http://jira.codehaus.org/browse/MCOMPILER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago Leão Moreira updated MCOMPILER-108:
--
Attachment: MCOMPILER-108-reproducible.zip
> Overwriting configurations does not take affect in a POM child project
> ---
>
> Key: MCOMPILER-108
> URL: http://jira.codehaus.org/browse/MCOMPILER-108
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Thiago Leão Moreira
>Assignee: Benjamin Bentmann
> Attachments: MCOMPILER-108-reproducible.zip, MCOMPILER-108.zip
>
>
> If you define a parent project with this compiler configuration
>
> maven-compiler-plugin
> true
>
> 1.3
> 1.3
>
>
> And a child project with this
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.3
> 1.1
> true
>
> -g:none
>
>
>
> ${settings.localRepository}/org/microemu/midpapi20/2.0.3/midpapi20-2.0.3.jar
>
>
>
>
> the configurations in the child project will not take affect!
--
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
