[jira] (MNG-5181) New resolution from local repository is very confusing
[ https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300376#comment-300376 ] Eugene Dzhurinsky commented on MNG-5181: I would say that this feature makes maven3 unusable for most of maven2 users, and it definitely has to be configurable (and disabled or set to WARNING by default). And yes, I spent time of trying to understand why Maven doesn't use artifact available from local repository. It doesn't make any sense to me. > New resolution from local repository is very confusing > -- > > Key: MNG-5181 > URL: https://jira.codehaus.org/browse/MNG-5181 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3 >Reporter: Arnaud Heritier > > I just discover the change introduced in Maven 3.x to try to improve the > resolution mechanism and to avoid to use a local artifact which may not be > available in its remote repository : > https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository > Even if the feature is interesting it has several problems : > # When an artifact isn't accessible from its remote repository it isn't used > by maven which replies a classical "dependency not found error". It is really > annoying for a user with some Maven 2 skills which will have a look at his > local repo, will find the artifact and won't understand why Maven doesn't use > it. At least the error reported by Maven should be clear that even if the > dependency is available locally, it isn't used because it's remote repository > isn't available. > # This behavior cannot be configured to be only a warning for example. It is > really annoying because it doesn't take care of some context and constraints > we may have in a development team. Let's imagine that the remote artifact is > really removed. Cool Maven broke the build to warn us. But it brakes the > build of all the team whereas perhaps only one of them may try to solve the > issue (and it can be a long resolution). Thus having the ability to configure > if this control is blocker or warning may allow the team to configure it as > blocker on the CI server and as warning on the development environment. > # This behavior may introduce some bad practices for example when we are > using a staging feature on a repository manager. In our case my teams have a > dedicated profile to activate a staging repository when we are validating a > release. I recommend to not have this profile always activated but to do it > only on-demand to avoid them to DL staging stuffs they don't need. With this > new feature they need for all builds they run to activate this staging > profile while binaries are stored in it. When you have to do it 20 times per > day minimum let's imagine what the developer does : It adds it as an > alwaysActive profile and then forget to remove it when the release is ended. > For all these reason I would like we improve this feature to make it more > usable and before all bet understandable for ours users. -- 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] (MASSEMBLY-614) useTransitiveFiltering implemented contrarily
Joerg Schaible created MASSEMBLY-614:
Summary: useTransitiveFiltering implemented contrarily
Key: MASSEMBLY-614
URL: https://jira.codehaus.org/browse/MASSEMBLY-614
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Joerg Schaible
useTransitiveFiltering is implemented wrongly, it filters when set to false and
does not filter when set to true.
One of the declared dependencies in the project is this:
{code:xml}
com.sun.xml.ws
jaxws-rt
2.2.6
{code}
The assembly descriptor is:
{code:xml}
false
false
true
false
*:jaxws*
{code}
The result contains only the jar for jaxws-rt, but not its dependencies.
Setting useTransitiveFiltering to true, then all dependencies are included. It
works quite contrary to the documentation and the implicit property name.
--
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-5292) unable to import the file specified from the specified directory
Niranjan created MNG-5292: - Summary: unable to import the file specified from the specified directory Key: MNG-5292 URL: https://jira.codehaus.org/browse/MNG-5292 Project: Maven 2 & 3 Issue Type: Bug Components: Deployment Affects Versions: 3.0.4 Reporter: Niranjan Priority: Blocker while iam calling ANT build.xml file from my project which will inturn calls the "ant-sca-package.xml" file. The "ant-sca-package.xml" file internally imports "ant-sca-compile.xml", but iam getting error like this: C:\Oracle\Middleware\jdeveloper\bin\ant-sca-package.xml:18: Cannot find C:\Test_Maven\build\ant-sca-compile.xml imported from C:\Oracle\Middleware\jdeveloper\bin\ant-sca-package.xml my build.xml file is located here : C:\Test_Maven\build\build.xml -- 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] (MPLUGIN-172) The basedir property is not changed when called from an imported file.
[ https://jira.codehaus.org/browse/MPLUGIN-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300378#comment-300378 ] Niranjan commented on MPLUGIN-172: -- Hi, Any solution for this issue > The basedir property is not changed when called from an imported file. > --- > > Key: MPLUGIN-172 > URL: https://jira.codehaus.org/browse/MPLUGIN-172 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: maven-plugin-tools-ant > Environment: Windows XP professional edition >Reporter: Sander Rensen > Attachments: settings.xml, Temp.zip, test-auto-compile.zip > > > Dear Maven developers, > I want to call an ant script from maven using mojos. The issue I am facing is > that the basedir property does not change the moment this property is used > within an imported file. This needs to happen as the basedir from the > imported file is allocated in a different directory then the directory I am > calling the maven mojo from. Let me explain with an example I have attached. > 1. Please first extract the zip file test-auto-compile.zip. Install the mojo > plugin (mvn clean install). > 2. Make sure in the maven repository the settings xml file is changed. I have > attached this file separately. I have included a > test-auto-compile in the settings.xml file. > 3. Make sure the files ant-sca-package.xml and ant-sca-compile.xml are copied > in C:/Temp. For this please extract the zip file Temp.zip. > 4. run the test-auto-compile project typing: mvn testcompile:testcompile. > 5. The error is: Cannot find > D:\SopraGroup\Development\PoC\Mavin\test-auto-compile/ant-sca-compil > e.xml imported from C:\Temp\ant-sca-package.xml. > The file ant-sca-package.xml is imported from the build.xml file. This file > ant-sca-package.xml imports the ant-sca-compile file. This file is imported > using: > The basedir should be the directory from where the ant-sca-package is > imported. In this case c:/Temp. However it tries to find the > ant-sca-compile.xml file in the maven directory as his basedir. > When I am calling the same ant script directly from ant then the basedir > changes and the ant script is completed successfully. > The solution to this issue is very simple by changing the import statement in > the ant-sca-compile file. However I am not aloud to change this file!! > I hope you can assist with this bug. > Many Thanks > Sander Rensen -- 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] (MPLUGIN-172) The basedir property is not changed when called from an imported file.
[ https://jira.codehaus.org/browse/MPLUGIN-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300378#comment-300378 ] Niranjan edited comment on MPLUGIN-172 at 6/5/12 6:28 AM: -- Hi, if anyone have solution for this issue please update. was (Author: kann.niranjan): Hi, Any solution for this issue > The basedir property is not changed when called from an imported file. > --- > > Key: MPLUGIN-172 > URL: https://jira.codehaus.org/browse/MPLUGIN-172 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: maven-plugin-tools-ant > Environment: Windows XP professional edition >Reporter: Sander Rensen > Attachments: settings.xml, Temp.zip, test-auto-compile.zip > > > Dear Maven developers, > I want to call an ant script from maven using mojos. The issue I am facing is > that the basedir property does not change the moment this property is used > within an imported file. This needs to happen as the basedir from the > imported file is allocated in a different directory then the directory I am > calling the maven mojo from. Let me explain with an example I have attached. > 1. Please first extract the zip file test-auto-compile.zip. Install the mojo > plugin (mvn clean install). > 2. Make sure in the maven repository the settings xml file is changed. I have > attached this file separately. I have included a > test-auto-compile in the settings.xml file. > 3. Make sure the files ant-sca-package.xml and ant-sca-compile.xml are copied > in C:/Temp. For this please extract the zip file Temp.zip. > 4. run the test-auto-compile project typing: mvn testcompile:testcompile. > 5. The error is: Cannot find > D:\SopraGroup\Development\PoC\Mavin\test-auto-compile/ant-sca-compil > e.xml imported from C:\Temp\ant-sca-package.xml. > The file ant-sca-package.xml is imported from the build.xml file. This file > ant-sca-package.xml imports the ant-sca-compile file. This file is imported > using: > The basedir should be the directory from where the ant-sca-package is > imported. In this case c:/Temp. However it tries to find the > ant-sca-compile.xml file in the maven directory as his basedir. > When I am calling the same ant script directly from ant then the basedir > changes and the ant script is completed successfully. > The solution to this issue is very simple by changing the import statement in > the ant-sca-compile file. However I am not aloud to change this file!! > I hope you can assist with this bug. > Many Thanks > Sander Rensen -- 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] (MECLIPSE-643) java.lang.NullPointerException (EclipsePlugin.isAvailableAsAWorkspaceProject)
[
https://jira.codehaus.org/browse/MECLIPSE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300385#comment-300385
]
Endre Moen commented on MECLIPSE-643:
-
I am also getting this error. Running with -X option and it looks like other
projects are scanned too. Why is eclipse:eclipse scanning other projects when
current pom has no parents defined?
> java.lang.NullPointerException (EclipsePlugin.isAvailableAsAWorkspaceProject)
> -
>
> Key: MECLIPSE-643
> URL: https://jira.codehaus.org/browse/MECLIPSE-643
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Workspace settings
>Affects Versions: 2.7
> Environment: C:\Documents and
> Settings\catalrc\WorkspaceXYZ\FlexGN>mvn -v
> Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
> Java version: 1.6.0_16
> Java home: C:\Program Files\Java\jdk1.6.0_16\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Ricardo Catalfo
>Priority: Minor
>
> I found an issue when executing mvn eclipse:eclipse on my workspace. Below is
> the stack trace and the reason of it:
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'eclipse'.
> [INFO]
>
> [INFO] Building FlexGN
> [INFO]task-segment: [eclipse:eclipse]
> [INFO]
>
> [INFO] Preparing eclipse:eclipse
> [INFO] No goals needed for project - skipping
> [INFO] [eclipse:eclipse {execution: default-cli}]
> [INFO] Using Eclipse Workspace: C:\Documents and Settings\catalrc\WorkspaceXYZ
> [INFO] Adding default classpath container:
> org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.eclipse.EclipsePlugin.isAvailableAsAWorkspaceProject(EclipsePlugin.java:1889)
> at
> org.apache.maven.plugin.eclipse.EclipsePlugin.useProjectReference(EclipsePlugin.java:1932)
> at
> org.apache.maven.plugin.ide.AbstractIdeSupportMojo.doDependencyResolution(AbstractIdeSupportMojo.java:683)
> at
> org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:507)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Thu Mar 04 12:54:48 EST 2010
> [INFO] Final Memory: 7M/15M
> [INFO]
>
> ---
> The pom.xml for this project
[jira] (MRELEASE-768) Prepare wrongly reports snapshot dependencies existence for project's war module attachedClasses
Stevo Slavic created MRELEASE-768: - Summary: Prepare wrongly reports snapshot dependencies existence for project's war module attachedClasses Key: MRELEASE-768 URL: https://jira.codehaus.org/browse/MRELEASE-768 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3.1 Environment: maven 3.0.4 jdk 1.6 x64 update 32 Reporter: Stevo Slavic Priority: Minor P |--W (+A) |--J (depends on A) P is parent and aggregator module with two child modules W (war) and J (jar). W module has maven-war-plugin:2.2 configured to [attachClasses|http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses] resulting in additional artifact A with Ws classes attached to the build. A is declared as (provided) dependency of J. Problem is that P cannot be release prepared - snapshot dependencies check fails for J module on A dependency. It seems that maven release plugin isn't aware that the W will also produce A artifact. -- 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-643) it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
[ https://jira.codehaus.org/browse/MRELEASE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reopened MRELEASE-643: - > it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2 > > > Key: MRELEASE-643 > URL: https://jira.codehaus.org/browse/MRELEASE-643 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.1 > Environment: Win 7 64-bit > Maven 3.0.2 >Reporter: shane mills >Assignee: Robert Scholte > > We use Maven as project management tool. > For building releases we use maven-release-plugin. > Up until a few days ago we used Maven 2.2.1 but unfortunately we recognized > that for some reason when triggering "mvn release:prepare" on a project with > local modifications it would just prepare the release without saying anything > about it. > We actually just recognized this issue a few days ago so I started to track > down the problem with no result but the fact that with maven 3 it terminates > just as expected. So instead of tracking down the maven 2.2.1 issue i started > to check on maven 3 and if we could use it instead of maven 2.2.1. > Actually everything works just fine except of the site-plugin. I found out > that with maven 3.x you should use the site-plugin 3.x and so i tried to bend > dependencies so that the release-plugin uses the site-plugin 3.0-beta-3 > instead of site-plugin 2.0.1, but it just wont do so. > When triggering "mvn site:site" on the command line it works just fine, but > when triggering "mvn release:prepare" and afterwards "mvn release:perform" it > still uses the site-plugin 2.0.1 not as expected maven-site-plugin 3.0-beta-3. > I am using maven 3.0.2 with maven-release-plugin 2.0.1 > We are looking forward to switching to maven 3.x but at first we need to be > sure everything works at least as fine as with maven 2.2.1 :) -- 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-643) it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
[
https://jira.codehaus.org/browse/MRELEASE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-643.
---
Resolution: Not A Bug
This is not a ((maven-release-plugin}} bug, but a Maven-bug. Up to version
{{3.0.3}} the {{super-pom.xml}} contained a 2.x version of the
{{maven-site-plugin}}, which is incompatible with Maven3. This has been fix for
Maven-3.0.4
But... you shouldn't rely on the versions in the {{super-pom}}, because they
can be upgraded with every new release of Maven. It's a best practice to
include these plugins in your own pom with a locked version to keep the build
stable for ages.
> it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
>
>
> Key: MRELEASE-643
> URL: https://jira.codehaus.org/browse/MRELEASE-643
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.1
> Environment: Win 7 64-bit
> Maven 3.0.2
>Reporter: shane mills
>Assignee: Robert Scholte
>
> We use Maven as project management tool.
> For building releases we use maven-release-plugin.
> Up until a few days ago we used Maven 2.2.1 but unfortunately we recognized
> that for some reason when triggering "mvn release:prepare" on a project with
> local modifications it would just prepare the release without saying anything
> about it.
> We actually just recognized this issue a few days ago so I started to track
> down the problem with no result but the fact that with maven 3 it terminates
> just as expected. So instead of tracking down the maven 2.2.1 issue i started
> to check on maven 3 and if we could use it instead of maven 2.2.1.
> Actually everything works just fine except of the site-plugin. I found out
> that with maven 3.x you should use the site-plugin 3.x and so i tried to bend
> dependencies so that the release-plugin uses the site-plugin 3.0-beta-3
> instead of site-plugin 2.0.1, but it just wont do so.
> When triggering "mvn site:site" on the command line it works just fine, but
> when triggering "mvn release:prepare" and afterwards "mvn release:perform" it
> still uses the site-plugin 2.0.1 not as expected maven-site-plugin 3.0-beta-3.
> I am using maven 3.0.2 with maven-release-plugin 2.0.1
> We are looking forward to switching to maven 3.x but at first we need to be
> sure everything works at least as fine as with maven 2.2.1 :)
--
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-643) it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
[
https://jira.codehaus.org/browse/MRELEASE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300406#comment-300406
]
Robert Scholte edited comment on MRELEASE-643 at 6/5/12 11:07 AM:
--
This is not a {{maven-release-plugin}} bug, but a Maven-bug. Up to version
{{3.0.3}} the {{super-pom.xml}} contained a 2.x version of the
{{maven-site-plugin}}, which is incompatible with Maven3. This has been fix for
Maven-3.0.4
But... you shouldn't rely on the versions in the {{super-pom}}, because they
can be upgraded with every new release of Maven. It's a best practice to
include these plugins in your own pom with a locked version to keep the build
stable for ages.
was (Author: rfscholte):
This is not a ((maven-release-plugin}} bug, but a Maven-bug. Up to version
{{3.0.3}} the {{super-pom.xml}} contained a 2.x version of the
{{maven-site-plugin}}, which is incompatible with Maven3. This has been fix for
Maven-3.0.4
But... you shouldn't rely on the versions in the {{super-pom}}, because they
can be upgraded with every new release of Maven. It's a best practice to
include these plugins in your own pom with a locked version to keep the build
stable for ages.
> it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
>
>
> Key: MRELEASE-643
> URL: https://jira.codehaus.org/browse/MRELEASE-643
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.1
> Environment: Win 7 64-bit
> Maven 3.0.2
>Reporter: shane mills
>Assignee: Robert Scholte
>
> We use Maven as project management tool.
> For building releases we use maven-release-plugin.
> Up until a few days ago we used Maven 2.2.1 but unfortunately we recognized
> that for some reason when triggering "mvn release:prepare" on a project with
> local modifications it would just prepare the release without saying anything
> about it.
> We actually just recognized this issue a few days ago so I started to track
> down the problem with no result but the fact that with maven 3 it terminates
> just as expected. So instead of tracking down the maven 2.2.1 issue i started
> to check on maven 3 and if we could use it instead of maven 2.2.1.
> Actually everything works just fine except of the site-plugin. I found out
> that with maven 3.x you should use the site-plugin 3.x and so i tried to bend
> dependencies so that the release-plugin uses the site-plugin 3.0-beta-3
> instead of site-plugin 2.0.1, but it just wont do so.
> When triggering "mvn site:site" on the command line it works just fine, but
> when triggering "mvn release:prepare" and afterwards "mvn release:perform" it
> still uses the site-plugin 2.0.1 not as expected maven-site-plugin 3.0-beta-3.
> I am using maven 3.0.2 with maven-release-plugin 2.0.1
> We are looking forward to switching to maven 3.x but at first we need to be
> sure everything works at least as fine as with maven 2.2.1 :)
--
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-768) Prepare wrongly reports snapshot dependencies existence for project's war module attachedClasses
[ https://jira.codehaus.org/browse/MRELEASE-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic closed MRELEASE-768. - Resolution: Not A Bug Not a bug, works ok - just reference to A dependency was wrong. > Prepare wrongly reports snapshot dependencies existence for project's war > module attachedClasses > > > Key: MRELEASE-768 > URL: https://jira.codehaus.org/browse/MRELEASE-768 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.3.1 > Environment: maven 3.0.4 > jdk 1.6 x64 update 32 >Reporter: Stevo Slavic >Priority: Minor > > P > |--W (+A) > |--J (depends on A) > P is parent and aggregator module with two child modules W (war) and J (jar). > W module has maven-war-plugin:2.2 configured to > [attachClasses|http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses] > resulting in additional artifact A with Ws classes attached to the build. A > is declared as (provided) dependency of J. > Problem is that P cannot be release prepared - snapshot dependencies check > fails for J module on A dependency. It seems that maven release plugin isn't > aware that the W will also produce A artifact. -- 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-557) release:prepare does not update the version of a reactor plugin
[
https://jira.codehaus.org/browse/MRELEASE-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-557:
Component/s: (was: perform)
prepare
Description:
For example this pom.
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
example
example-parent
0.0.1-SNAPSHOT
pom
example
example-plugin
0.0.1-SNAPSHOT
example-plugin
{code:xml}
With "{{release:prepare}}", the version of the example-plugin in the build
section stays untouched.
BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error, if
I use SNAPSHOT versions in the {{pluginManagement}} section.
was:
For example this pom.
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
example
example-parent
0.0.1-SNAPSHOT
pom
example
example-plugin
0.0.1-SNAPSHOT
example-plugin
With "release:prepare", the version of the example-plugin in the build section
stays untouched.
BTW: Is the pluginManagement totally ignored? I even don't get an error, if I
use SNAPSHOT versions in the pluginManagement section.
> release:prepare does not update the version of a reactor plugin
> ---
>
> Key: MRELEASE-557
> URL: https://jira.codehaus.org/browse/MRELEASE-557
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
>Reporter: Frank Ressel
>
> For example this pom.
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> example
> example-parent
> 0.0.1-SNAPSHOT
> pom
>
>
>
>
> example
> example-plugin
> 0.0.1-SNAPSHOT
>
>
>
>
>
> example-plugin
>
>
> {code:xml}
> With "{{release:prepare}}", the version of the example-plugin in the build
> section stays untouched.
> BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error,
> if I use SNAPSHOT versions in the {{pluginManagement}} section.
--
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-557) release:prepare does not update the version of a reactor plugin
[
https://jira.codehaus.org/browse/MRELEASE-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-557:
Description:
For example this pom.
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
example
example-parent
0.0.1-SNAPSHOT
pom
example
example-plugin
0.0.1-SNAPSHOT
example-plugin
{code}
With "{{release:prepare}}", the version of the example-plugin in the build
section stays untouched.
BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error, if
I use SNAPSHOT versions in the {{pluginManagement}} section.
was:
For example this pom.
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
example
example-parent
0.0.1-SNAPSHOT
pom
example
example-plugin
0.0.1-SNAPSHOT
example-plugin
{code:xml}
With "{{release:prepare}}", the version of the example-plugin in the build
section stays untouched.
BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error, if
I use SNAPSHOT versions in the {{pluginManagement}} section.
> release:prepare does not update the version of a reactor plugin
> ---
>
> Key: MRELEASE-557
> URL: https://jira.codehaus.org/browse/MRELEASE-557
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
>Reporter: Frank Ressel
>
> For example this pom.
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> example
> example-parent
> 0.0.1-SNAPSHOT
> pom
>
>
>
>
> example
> example-plugin
> 0.0.1-SNAPSHOT
>
>
>
>
>
> example-plugin
>
>
> {code}
> With "{{release:prepare}}", the version of the example-plugin in the build
> section stays untouched.
> BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error,
> if I use SNAPSHOT versions in the {{pluginManagement}} section.
--
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] (ARCHETYPE-321) [regression] create-from-project results in FileNotFoundException
[
https://jira.codehaus.org/browse/ARCHETYPE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300455#comment-300455
]
Graham Leggett commented on ARCHETYPE-321:
--
FWIW, same problem here. 2.0-alpha-4 works, 2.0-alpha-5, 2.1 and 2.2 fail as
per the reported exception.
> [regression] create-from-project results in FileNotFoundException
> -
>
> Key: ARCHETYPE-321
> URL: https://jira.codehaus.org/browse/ARCHETYPE-321
> Project: Maven Archetype
> Issue Type: Bug
> Components: Creator
>Affects Versions: 2.0-alpha-5
> Environment: apache-maven-3.0-beta-1, OS X, Java 1.6
>Reporter: John Casey
>
> Using a clean project directory (mvn clean), I called:
> {code}
> mvn clean archetype:create-from-project -e
> {code}
> {noformat}
> /target/generated-sources/archetype/src/main/resources/archetype-resources/pom.xml
> (No such file or directory)
> at
> org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:206)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:133)
> {noformat}
> I checked, and the directory
> target/generated-sources/archetype/src/main/resources/ does exist, but the
> archetype-resources directory is missing.
> NOTE: When I run the same command with the previous version:
> {code}
> mvn clean
> org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-4:create-from-project
> -e
> {code}
> everything works fine.
--
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] (MNGSITE-137) Web page rendering issue on Maven in 5 Minutes
[ https://jira.codehaus.org/browse/MNGSITE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNGSITE-137. - Resolution: Not A Bug > Web page rendering issue on Maven in 5 Minutes > -- > > Key: MNGSITE-137 > URL: https://jira.codehaus.org/browse/MNGSITE-137 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Internet Explorer 7.0 >Reporter: Jacob Robertson > Attachments: maven-in-5-minutes-weird-spacing.PNG > > > Background: my organization is providing hands-on Continuous Integration > training courses, and as part of that, we bring up the Maven in 5 Minutes web > page > (http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html). > Every class so far there has been a little moment of "huh?" when students get > to a huge blank part of the guide they have to scroll down through (screen > shot attached). The problem only happens on non-wide-screen monitors, and > only in IE. However, as you see from the screenshot, it's pretty odd. -- 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] (MNGSITE-148) In pom reference, use full name for the Apache 2 license to be consistent with projects "in the wild"
[ https://jira.codehaus.org/browse/MNGSITE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNGSITE-148. - Resolution: Fixed Assignee: Herve Boutemy done in [r1346699|http://svn.apache.org/viewvc?rev=1346699&view=rev] thanks for the report > In pom reference, use full name for the Apache 2 license to be consistent > with projects "in the wild" > - > > Key: MNGSITE-148 > URL: https://jira.codehaus.org/browse/MNGSITE-148 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Roman Zenka >Assignee: Herve Boutemy >Priority: Trivial > > At http://maven.apache.org/pom.html#Licenses , the listed name for The Apache > Software License, Version 2.0 is "Apache 2". > Since people (like me) will copy&paste that snippet into their project, it > makes sense to use a more appropriate version that matches major projects > seen in the wild. > The proposed text is: > > The Apache Software License, Version 2.0 > http://www.apache.org/licenses/LICENSE-2.0.txt > repo > A business-friendly OSS license > -- 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] (MNGSITE-136) POM reference for is incomplete and misleading
[ https://jira.codehaus.org/browse/MNGSITE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNGSITE-136. - Resolution: Fixed Assignee: Herve Boutemy done in [r1346704|http://svn.apache.org/viewvc?rev=1346704&view=rev] > POM reference for is incomplete and misleading > --- > > Key: MNGSITE-136 > URL: https://jira.codehaus.org/browse/MNGSITE-136 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Maven 2.2.1; RHEL 6; Java 1.6.0_24 >Reporter: David Biesack >Assignee: Herve Boutemy >Priority: Minor > > See > http://jira.codehaus.org/browse/MJAVADOC-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264846#action_264846 > The POM reference at http://maven.apache.org/pom.html#Properties is > misleading - it does not document the syntax for but says "Maven > properties are value placeholder, like properties in Ant." so I mistakenly > assumed Ant syntax, and some examples on that page are in an > element which use > > mavenVersion > 2.0.3 > > syntax, but this is misleading > Apparently, uses the syntax > > some-property-value > another-property-value > > but the reference doc does not state this clearly, only showing > ... -- 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-643) it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
[ https://jira.codehaus.org/browse/MRELEASE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300469#comment-300469 ] shane mills commented on MRELEASE-643: -- Of course you are right about including such plugins in our own pom and I believe that is what we do since we switched to Maven 3. The time this Issue was created I tried Maven with some projekt we hadn't released for some time. If I recall correctly I actually tried to define the site plugin inside the projects pom. Anyways, it works just great and we allready upgraded almost all our projects to Maven 3. > it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2 > > > Key: MRELEASE-643 > URL: https://jira.codehaus.org/browse/MRELEASE-643 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.1 > Environment: Win 7 64-bit > Maven 3.0.2 >Reporter: shane mills >Assignee: Robert Scholte > > We use Maven as project management tool. > For building releases we use maven-release-plugin. > Up until a few days ago we used Maven 2.2.1 but unfortunately we recognized > that for some reason when triggering "mvn release:prepare" on a project with > local modifications it would just prepare the release without saying anything > about it. > We actually just recognized this issue a few days ago so I started to track > down the problem with no result but the fact that with maven 3 it terminates > just as expected. So instead of tracking down the maven 2.2.1 issue i started > to check on maven 3 and if we could use it instead of maven 2.2.1. > Actually everything works just fine except of the site-plugin. I found out > that with maven 3.x you should use the site-plugin 3.x and so i tried to bend > dependencies so that the release-plugin uses the site-plugin 3.0-beta-3 > instead of site-plugin 2.0.1, but it just wont do so. > When triggering "mvn site:site" on the command line it works just fine, but > when triggering "mvn release:prepare" and afterwards "mvn release:perform" it > still uses the site-plugin 2.0.1 not as expected maven-site-plugin 3.0-beta-3. > I am using maven 3.0.2 with maven-release-plugin 2.0.1 > We are looking forward to switching to maven 3.x but at first we need to be > sure everything works at least as fine as with maven 2.2.1 :) -- 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
