[jira] (MNG-5384) Declarative artifacts
Tuomas Kiviaho created MNG-5384:
---
Summary: Declarative artifacts
Key: MNG-5384
URL: https://jira.codehaus.org/browse/MNG-5384
Project: Maven 2 & 3
Issue Type: New Feature
Components: Artifacts and Repositories, POM, Reactor and workspace
Affects Versions: 3.0.4
Reporter: Tuomas Kiviaho
Currently there's no way to know what attachments a project is going to have
beforehand. Lack of this feature is currently patched inside Aether where
test-jar for instance has a special treatment prior packaging phase so that we
can get a file pointer to ${project.target.testOutputDirectory}.
Maven 2 had this hack embedded inside of it, but with Maven 3 the project
attachments list doesn't contain test-jar until it is actually added to the
project. I had to patch MBUILDHELPER-41 to be able attach this artifact prior
packaging phase and remove it at prepare-package so that the actual attachment
could be added to the project.
I propose that POM could have a section similar to {{build.finalName}} where
you'd list the attacments that the project is going to introduce. For backwards
compatibility this of course would not be required. Plugins such as jar,
sources and javadoc could kick in automatically when pom contains the
respective declarations (race conditions would arise between
maven-bundle-plugin and jar for instance).
--
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] (MNG-5353) Ignore pre-releases in exclusive upper bound [lw,up)
[ https://jira.codehaus.org/browse/MNG-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314184#comment-314184 ] Jason van Zyl commented on MNG-5353: With a DependencySelector it would not be subject to any calculation because it would be removed. It's really a matter of identifying how pre-releases are named so they can be removed. I chatted with Benjamin briefly and I believe it is more of a filter (DependencySelector). At any rate I think we can discuss this a little longer before pushing it in. I'd still like to get this release up for a vote on Friday. > Ignore pre-releases in exclusive upper bound [lw,up) > > > Key: MNG-5353 > URL: https://jira.codehaus.org/browse/MNG-5353 > Project: Maven 2 & 3 > Issue Type: Wish > Components: Dependencies >Affects Versions: 2.0.11, 2.2.1, 3.0.4 >Reporter: Jesse Long >Assignee: Jason van Zyl > Fix For: 3.1.1 > > > Please change the behaviour of exclusive upper bounds to the following: > In a version range, like [1.7.0,1.8.0), 1.8.0-alpha1 should not be included > in the range. 1.8.0* should not be included in the range. > This allows for us configure natural ranges for projects using semantic > versioning. > Please see: > http://markmail.org/message/4tubas4uok6ahbcp > http://markmail.org/message/s2ry2uru4ibub43q -- 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] (MANTRUN-78) Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ https://jira.codehaus.org/browse/MANTRUN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314191#comment-314191 ] Adrián Boimvaser commented on MANTRUN-78: - What if there were an optional boolean parameter for choosing not to create properties containing the paths to the dependencies? Some people might need those properties but many could still run their ant tasks without them. > Use of AntRun during clean phase fails multiproject with intermodule > dependencies > - > > Key: MANTRUN-78 > URL: https://jira.codehaus.org/browse/MANTRUN-78 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.1, 1.2 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_12 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Brian Jackson > Attachments: test.zip > > > Attaching the antrun plugin to the clean phase causes it to interfere with > local dependency resolution for sibling projects. > An example is attached. > The project consists of project 'test' with modules 'test-a' and test-b'. > 'test-a' depends on 'test-b'. > If you run "mvn clean" on the root POM, the clean succeeds. > If you run "mvn clean -Pbuild-failure" it fails. -- 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] (MARCHETYPES-42) Plugin archetype must include sample with it test (use of invoker plugin)
Olivier Lamy created MARCHETYPES-42: --- Summary: Plugin archetype must include sample with it test (use of invoker plugin) Key: MARCHETYPES-42 URL: https://jira.codehaus.org/browse/MARCHETYPES-42 Project: Maven Archetype Bundles Issue Type: Bug Components: Maven Plugin Archetype Reporter: Olivier Lamy -- 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] (MARCHETYPES-42) Plugin archetype must include sample with it test (use of invoker plugin)
[ https://jira.codehaus.org/browse/MARCHETYPES-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MARCHETYPES-42. --- Resolution: Fixed Fix Version/s: maven-archetype-plugin-1.2 Assignee: Olivier Lamy fixed. > Plugin archetype must include sample with it test (use of invoker plugin) > - > > Key: MARCHETYPES-42 > URL: https://jira.codehaus.org/browse/MARCHETYPES-42 > Project: Maven Archetype Bundles > Issue Type: Bug > Components: Maven Plugin Archetype >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: maven-archetype-plugin-1.2 > > -- 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] (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ https://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314195#comment-314195 ] Adrián Boimvaser commented on MNG-3283: --- Still no progress on this issue? > Plugins that require dependency resolution in early phases cause dependency > resolution issue > > > Key: MNG-3283 > URL: https://jira.codehaus.org/browse/MNG-3283 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle, Reactor and > workspace >Affects Versions: 2.0.7 >Reporter: Alfie Kirkpatrick > Fix For: Issues to be reviewed for 3.x > > Attachments: maven-dependency-bug.zip > > > What we're seeing is that some multi-project configurations succeed on > 'mvn package' but fail on 'mvn generate-sources'. They are failing when > one project in the reactor references another project in the reactor > which is not installed in the local repo. It seems that the referenced > project has not quite "made it" into the reactor this early in the phase > lifecycle. But it does work correctly if you target a later phase at the > outset which is really confusing. > The problem only occurs when a plugin binds itself to the > generate-sources phase and has @requiresDependencyResolution, presumably > because this is what triggers resolution of the referenced dependency > too early in the lifecycle, and hence the error. > We are seeing this problem when trying to run 'mvn eclipse:eclipse' > because this only executes the generate-sources phase by default and we > have other mojos which genuinely do generate source, such as java2wsdl. > A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. > Attached is a really simple project that exhibits this problem. -- 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] (MEAR-163) Weird result in multi-profile build
Wolfgang Grossinger created MEAR-163:
Summary: Weird result in multi-profile build
Key: MEAR-163
URL: https://jira.codehaus.org/browse/MEAR-163
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.8
Environment: Windows 7 64Bit; Java 6 / 32 Bit
Reporter: Wolfgang Grossinger
I configured my pom to create 2 separate EAR-files (with 2 different
classifiers) when a certain profile is active and get 2 weird things:
1.) I get a third 'normal' EAR-File too.
2.) I use true which has no effect, so at the end, I get 3
files with the same content and different names.
The config looks like:
org.apache.maven.plugins
maven-ear-plugin
web
package
ear
5
web-${zps.build.identifier}
true
ZPSWEB
at.gv.bmi
zps-gwt
/${zps.web.contextRoot}
at.gv.bmi
zps-integration
true
srv
package
ear
5
srv-${zps.build.identifier}
true
ZPSSRV
at.gv.bmi
zps-gwt
true
at.gv.bmi
zps-integration
/${zps.srv.contextRoot}
Regards,
Wolfgang
--
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] (MNG-5381) Restore MavenSession.getRepositoryCache()
[ https://jira.codehaus.org/browse/MNG-5381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314208#comment-314208 ] Olivier Lamy commented on MNG-5381: --- I don't see any commits related to this fix ? > Restore MavenSession.getRepositoryCache() > - > > Key: MNG-5381 > URL: https://jira.codehaus.org/browse/MNG-5381 > Project: Maven 2 & 3 > Issue Type: New Feature > Environment: >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.1.0 > > > Error when running stock Tycho 0.16.0 > Exception in thread "main" java.lang.NoSuchMethodError: > org.apache.maven.execution.MavenSession.getRepositoryCache()Lorg/apache/maven/artifact/repository/RepositoryCache; > This method was deprecated but it can be bridged to Aether code as this > screws up Tycho users unecessarily. Tycho can migrate off this method but > currently this breaks all Tycho users which is an unacceptable break. -- 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] (MNG-5385) Session overlayed by LegacyLocalRepositoryManager.overlay(...) returns different local repositories
Bernd Vogt created MNG-5385:
---
Summary: Session overlayed by
LegacyLocalRepositoryManager.overlay(...) returns different local repositories
Key: MNG-5385
URL: https://jira.codehaus.org/browse/MNG-5385
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0.4
Reporter: Bernd Vogt
Priority: Critical
Attachments: LegacyLocalRepositoryManager.java.patch,
LegacyLocalRepositoryManagerTest.java
To use a custom local repository during the resolution of an artifact, you have
to overlay the default repo session with the custom information. For that
LegacyLocalRepositoryManager.overlay(...) is intended. But after overlaying the
current session with a custom local repository the returend overlayed session
knows two local repositories:
{noformat}
RepositorySystemSession overlayed =
egacyLocalRepositoryManager.overlay(myLocalRepo, session, system);
overlayed.getLocalRepositoryManager().getRepository() // returns 'myLocalRepo'
overlayed.getLocalRepository() // should return 'myLocalRepo' but returns the
default local repositoy
{noformat}
This is a problem, because both methods are used to get the local repo during
artifact resolution, e.g.
{noformat}
class org.apache.maven.repository.internal.DefaultVersionResolver.Key
{
public Key( RepositorySystemSession session, VersionRequest request )
{
...
localRepo = session.getLocalRepository().getBasedir();
{noformat},
{noformat}
class org.sonatype.aether.impl.internal.DefaultMetadataResolver
{
private List resolve( RepositorySystemSession session,
Collection
requests )
{
...
LocalRepository localRepo =
session.getLocalRepositoryManager().getRepository();
{noformat}
(Critical because of our tooling to materialize artifacts to a specified folder
is broken since we migrated from Maven 2 to 3...)
--
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] (MSHADE-135) Add PluginTransformer
Robert Scholte created MSHADE-135: - Summary: Add PluginTransformer Key: MSHADE-135 URL: https://jira.codehaus.org/browse/MSHADE-135 Project: Maven 2.x Shade Plugin Issue Type: New Feature Affects Versions: 2.0 Reporter: Robert Scholte Priority: Critical When using doclet-tags for the Maven plugin we had to specify the shaded class as the role, since this String couldn't be recognized as a class. But now we have annotations as well, and here the role is a real class, so the trick above doesn't work anymore. Hence, we need a transformer for it. -- 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-803) Inner profile properties for artifact versions block release
Robert Scholte created MRELEASE-803:
---
Summary: Inner profile properties for artifact versions block
release
Key: MRELEASE-803
URL: https://jira.codehaus.org/browse/MRELEASE-803
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3.2
Reporter: Robert Scholte
>From {{maven-invoker-plugin-1.8-SNAPSHOT}}
{code:xml}
...
run-its
3.1
1.6
maven-invoker-plugin
${invokerPluginVersion}
true
${project.build.directory}/it
setup
verify
${project.build.directory}/local-repo
src/it/settings.xml
-Djava.io.tmpdir=${project.build.directory}
clean
initialize
{code}
The plugin discovers the invoker-plugin with a property-based version, but
can't find the property because it only collects the {{project.properties}}.
The plugin should at least add the properties of the declaring profile.
Workaround: move the property from profile-scope to project-scope.
--
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] (MEAR-164) support for useJvmChmod in archiver
Seth Rife created MEAR-164: -- Summary: support for useJvmChmod in archiver Key: MEAR-164 URL: https://jira.codehaus.org/browse/MEAR-164 Project: Maven 2.x Ear Plugin Issue Type: Improvement Reporter: Seth Rife Priority: Minor Add support for useJvmChmod in archiver. -- 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
