[jira] Created: (MSITE-456) [regression] Site navigation not generated
[regression] Site navigation not generated -- Key: MSITE-456 URL: http://jira.codehaus.org/browse/MSITE-456 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Paul Benedict Priority: Critical My corporate POM locks down the maven-site-plugin to version 2.1. The site of the corporate POM generates just fine. However, when a child project inherits from it, that project's site contains no left-hand navigation. Reverting to 2.0.1 is my workaround. Attached project demonstrates problem. -- 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: (MSITE-456) [regression] Site navigation not generated
[ http://jira.codehaus.org/browse/MSITE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MSITE-456: Attachment: MSITE-456.zip Attached project can reproduce problem. First generate parent site and verify it is normal; then install parent. Next, generate child's site and verify missing navigation. > [regression] Site navigation not generated > -- > > Key: MSITE-456 > URL: http://jira.codehaus.org/browse/MSITE-456 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Paul Benedict >Priority: Critical > Attachments: MSITE-456.zip > > > My corporate POM locks down the maven-site-plugin to version 2.1. The site of > the corporate POM generates just fine. However, when a child project inherits > from it, that project's site contains no left-hand navigation. Reverting to > 2.0.1 is my workaround. > Attached project demonstrates problem. -- 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: (MSITE-456) [regression] Site navigation not generated
[ http://jira.codehaus.org/browse/MSITE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MSITE-456: Description: My corporate POM locks down the maven-site-plugin to version 2.1. The site of the corporate POM generates just fine. However, when a child project inherits from it, that project's site contains no left-hand navigation. Reverting to 2.0.1 is my workaround. (was: My corporate POM locks down the maven-site-plugin to version 2.1. The site of the corporate POM generates just fine. However, when a child project inherits from it, that project's site contains no left-hand navigation. Reverting to 2.0.1 is my workaround. Attached project demonstrates problem. ) Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) Java version: 1.6.0_16 Java home: d:\jdk1.6.0_16\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > [regression] Site navigation not generated > -- > > Key: MSITE-456 > URL: http://jira.codehaus.org/browse/MSITE-456 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) > Java version: 1.6.0_16 > Java home: d:\jdk1.6.0_16\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Paul Benedict >Priority: Critical > Attachments: MSITE-456.zip > > > My corporate POM locks down the maven-site-plugin to version 2.1. The site of > the corporate POM generates just fine. However, when a child project inherits > from it, that project's site contains no left-hand navigation. Reverting to > 2.0.1 is my workaround. -- 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-4514) Loading resource from plugin dependency using Plexus ResourceManager fails with leading slash
Loading resource from plugin dependency using Plexus ResourceManager fails with
leading slash
-
Key: MNG-4514
URL: http://jira.codehaus.org/browse/MNG-4514
Project: Maven 2 & 3
Issue Type: Bug
Components: Class Loading, Dependencies, Plugins and Lifecycle
Affects Versions: 3.0-alpha-5
Reporter: Peter Lynch
When a maven plugin tries to load a resource(file) from a plugin dependency
defined in a project pom file and the path to that resource begins with 'slash'
/ then the resource is not found. The code uses the Plexus ResourceManagers
Example code that works in 2.2.1 and earlier and fails in Maven 3.0-alpha-5. If
resource is in root of jar and configFile begins with forward slash then we get
ResourceNotFoundException.
{code:java}
/**
* ResourceManager for getting a resource from a dependency jar
*
* @component
* @required
* @readonly
*/
private ResourceManager locator;
...
protected void loadResource(String configFile) throws
ResourceNotFoundException
{
InputStream inStream = null;
if (configFile != null)
{
try
{
inStream =
locator.getResourceAsInputStream(configFile);
} finally
{
if (inStream != null)
{
try
{
inStream.close();
} catch (IOException ex)
{
throw new RuntimeException(
"Should not have happended", ex);
}
}
}
}
}
{code}
Will attach IT test.
--
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-4514) Loading resource from plugin dependency using Plexus ResourceManager fails with leading slash
[
http://jira.codehaus.org/browse/MNG-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204942#action_204942
]
Peter Lynch commented on MNG-4514:
--
Added integration test for mng-4514 that passes Maven 2.2.1 and below but fails
with Maven 3.0-alpha-5
> Loading resource from plugin dependency using Plexus ResourceManager fails
> with leading slash
> -
>
> Key: MNG-4514
> URL: http://jira.codehaus.org/browse/MNG-4514
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
>Affects Versions: 3.0-alpha-5
>Reporter: Peter Lynch
> Attachments: mng-4514-IT.zip
>
>
> When a maven plugin tries to load a resource(file) from a plugin dependency
> defined in a project pom file and the path to that resource begins with
> 'slash' / then the resource is not found. The code uses the Plexus
> ResourceManagers
> Example code that works in 2.2.1 and earlier and fails in Maven 3.0-alpha-5.
> If resource is in root of jar and configFile begins with forward slash then
> we get ResourceNotFoundException.
> {code:java}
> /**
> * ResourceManager for getting a resource from a dependency jar
> *
> * @component
> * @required
> * @readonly
> */
> private ResourceManager locator;
> ...
> protected void loadResource(String configFile) throws
> ResourceNotFoundException
> {
> InputStream inStream = null;
> if (configFile != null)
> {
> try
> {
> inStream =
> locator.getResourceAsInputStream(configFile);
> } finally
> {
> if (inStream != null)
> {
> try
> {
> inStream.close();
> } catch (IOException ex)
> {
> throw new RuntimeException(
> "Should not have happended", ex);
> }
> }
> }
> }
> }
> {code}
> Will attach IT test.
--
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-4514) Loading resource from plugin dependency using Plexus ResourceManager fails with leading slash
[
http://jira.codehaus.org/browse/MNG-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Lynch updated MNG-4514:
-
Attachment: mng-4514-IT.zip
> Loading resource from plugin dependency using Plexus ResourceManager fails
> with leading slash
> -
>
> Key: MNG-4514
> URL: http://jira.codehaus.org/browse/MNG-4514
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
>Affects Versions: 3.0-alpha-5
>Reporter: Peter Lynch
> Attachments: mng-4514-IT.zip
>
>
> When a maven plugin tries to load a resource(file) from a plugin dependency
> defined in a project pom file and the path to that resource begins with
> 'slash' / then the resource is not found. The code uses the Plexus
> ResourceManagers
> Example code that works in 2.2.1 and earlier and fails in Maven 3.0-alpha-5.
> If resource is in root of jar and configFile begins with forward slash then
> we get ResourceNotFoundException.
> {code:java}
> /**
> * ResourceManager for getting a resource from a dependency jar
> *
> * @component
> * @required
> * @readonly
> */
> private ResourceManager locator;
> ...
> protected void loadResource(String configFile) throws
> ResourceNotFoundException
> {
> InputStream inStream = null;
> if (configFile != null)
> {
> try
> {
> inStream =
> locator.getResourceAsInputStream(configFile);
> } finally
> {
> if (inStream != null)
> {
> try
> {
> inStream.close();
> } catch (IOException ex)
> {
> throw new RuntimeException(
> "Should not have happended", ex);
> }
> }
> }
> }
> }
> {code}
> Will attach IT test.
--
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-4514) Loading resource from plugin dependency using Plexus ResourceManager fails with leading slash
[
http://jira.codehaus.org/browse/MNG-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Lynch updated MNG-4514:
-
Testcase included: yes
> Loading resource from plugin dependency using Plexus ResourceManager fails
> with leading slash
> -
>
> Key: MNG-4514
> URL: http://jira.codehaus.org/browse/MNG-4514
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
>Affects Versions: 3.0-alpha-5
>Reporter: Peter Lynch
> Attachments: mng-4514-IT.zip
>
>
> When a maven plugin tries to load a resource(file) from a plugin dependency
> defined in a project pom file and the path to that resource begins with
> 'slash' / then the resource is not found. The code uses the Plexus
> ResourceManagers
> Example code that works in 2.2.1 and earlier and fails in Maven 3.0-alpha-5.
> If resource is in root of jar and configFile begins with forward slash then
> we get ResourceNotFoundException.
> {code:java}
> /**
> * ResourceManager for getting a resource from a dependency jar
> *
> * @component
> * @required
> * @readonly
> */
> private ResourceManager locator;
> ...
> protected void loadResource(String configFile) throws
> ResourceNotFoundException
> {
> InputStream inStream = null;
> if (configFile != null)
> {
> try
> {
> inStream =
> locator.getResourceAsInputStream(configFile);
> } finally
> {
> if (inStream != null)
> {
> try
> {
> inStream.close();
> } catch (IOException ex)
> {
> throw new RuntimeException(
> "Should not have happended", ex);
> }
> }
> }
> }
> }
> {code}
> Will attach IT test.
--
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: (MECLIPSE-601) to-maven mojo install source plugins as ordinay plugins. It should install the source plugins as classified as 'sources'
[ http://jira.codehaus.org/browse/MECLIPSE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204947#action_204947 ] Peter Lynch commented on MECLIPSE-601: -- Providing the integration tests is next in my queue. Hopefully after that it will get applied soon. > to-maven mojo install source plugins as ordinay plugins. It should install > the source plugins as classified as 'sources' > > > Key: MECLIPSE-601 > URL: http://jira.codehaus.org/browse/MECLIPSE-601 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.7 > Environment: N/A >Reporter: Hasan Ceylan >Assignee: Peter Lynch > Attachments: source-plugin.patch, source-plugin.patch, > source-plugin.patch > > > to-maven mojo install source plugins as ordinay plugins. It should install > the source plugins as classified as 'sources' > Say you have the source plugins along with your plugins. ie: here's what you > would get: > [hcey...@ceylan ~]$ ll > /home/hceylan/.m2/repository/org/eclipse/core/runtime/3.5.100-v20090629/ > -rw-rw-r-- 1 hceylan hceylan 69652 2009-09-10 22:12 > runtime-3.5.100-v20090629.jar > -rw-rw-r-- 1 hceylan hceylan 1741 2009-09-10 22:12 > runtime-3.5.100-v20090629.pom > drw-rw-r-- 1 hceylan hceylan 86072 2009-09-10 22:12 source > Instead you should get the following: > [hcey...@ceylan ~]$ ll > /home/hceylan/.m2/repository/org/eclipse/core/runtime/3.5.100-v20090629/ > -rw-rw-r-- 1 hceylan hceylan 69652 2009-09-10 22:12 > runtime-3.5.100-v20090629.jar > -rw-rw-r-- 1 hceylan hceylan 1741 2009-09-10 22:12 > runtime-3.5.100-v20090629.pom > -rw-rw-r-- 1 hceylan hceylan 86072 2009-09-10 22:12 > runtime-3.5.100-v20090629-sources.jar > Attached patch resolves that issue. -- 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: (MECLIPSE-601) to-maven mojo install source plugins as ordinay plugins. It should install the source plugins as classified as 'sources'
[ http://jira.codehaus.org/browse/MECLIPSE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204947#action_204947 ] Peter Lynch edited comment on MECLIPSE-601 at 1/3/10 3:57 AM: -- Providing the integration tests is next in my queue. Hopefully after that it will get applied soon. Part of the delay was grokking in what format the integration tests need to be created. Getting back into the swing of things I am discovering each plugin rolls its own style. was (Author: plynch): Providing the integration tests is next in my queue. Hopefully after that it will get applied soon. > to-maven mojo install source plugins as ordinay plugins. It should install > the source plugins as classified as 'sources' > > > Key: MECLIPSE-601 > URL: http://jira.codehaus.org/browse/MECLIPSE-601 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.7 > Environment: N/A >Reporter: Hasan Ceylan >Assignee: Peter Lynch > Attachments: source-plugin.patch, source-plugin.patch, > source-plugin.patch > > > to-maven mojo install source plugins as ordinay plugins. It should install > the source plugins as classified as 'sources' > Say you have the source plugins along with your plugins. ie: here's what you > would get: > [hcey...@ceylan ~]$ ll > /home/hceylan/.m2/repository/org/eclipse/core/runtime/3.5.100-v20090629/ > -rw-rw-r-- 1 hceylan hceylan 69652 2009-09-10 22:12 > runtime-3.5.100-v20090629.jar > -rw-rw-r-- 1 hceylan hceylan 1741 2009-09-10 22:12 > runtime-3.5.100-v20090629.pom > drw-rw-r-- 1 hceylan hceylan 86072 2009-09-10 22:12 source > Instead you should get the following: > [hcey...@ceylan ~]$ ll > /home/hceylan/.m2/repository/org/eclipse/core/runtime/3.5.100-v20090629/ > -rw-rw-r-- 1 hceylan hceylan 69652 2009-09-10 22:12 > runtime-3.5.100-v20090629.jar > -rw-rw-r-- 1 hceylan hceylan 1741 2009-09-10 22:12 > runtime-3.5.100-v20090629.pom > -rw-rw-r-- 1 hceylan hceylan 86072 2009-09-10 22:12 > runtime-3.5.100-v20090629-sources.jar > Attached patch resolves that issue. -- 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-4514) Loading resource from plugin dependency using Plexus ResourceManager fails with leading slash
[
http://jira.codehaus.org/browse/MNG-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4514.
--
Resolution: Not A Bug
Assignee: Benjamin Bentmann
This is a bug in the plexus-resources component (cf.
[r8418|http://fisheye.codehaus.org/changelog/plexus/plexus-components/trunk/plexus-resources?cs=8418]),
not Maven. Calling {{ClassLoader.getResource()}} when the resource name has a
leading slash only works in Maven 2.x due to buggy/non-standard classloaders of
ClassWorlds. Try this with a regular URLClassLoader and see it fail.
> Loading resource from plugin dependency using Plexus ResourceManager fails
> with leading slash
> -
>
> Key: MNG-4514
> URL: http://jira.codehaus.org/browse/MNG-4514
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
>Affects Versions: 3.0-alpha-5
>Reporter: Peter Lynch
>Assignee: Benjamin Bentmann
> Attachments: mng-4514-IT.zip
>
>
> When a maven plugin tries to load a resource(file) from a plugin dependency
> defined in a project pom file and the path to that resource begins with
> 'slash' / then the resource is not found. The code uses the Plexus
> ResourceManagers
> Example code that works in 2.2.1 and earlier and fails in Maven 3.0-alpha-5.
> If resource is in root of jar and configFile begins with forward slash then
> we get ResourceNotFoundException.
> {code:java}
> /**
> * ResourceManager for getting a resource from a dependency jar
> *
> * @component
> * @required
> * @readonly
> */
> private ResourceManager locator;
> ...
> protected void loadResource(String configFile) throws
> ResourceNotFoundException
> {
> InputStream inStream = null;
> if (configFile != null)
> {
> try
> {
> inStream =
> locator.getResourceAsInputStream(configFile);
> } finally
> {
> if (inStream != null)
> {
> try
> {
> inStream.close();
> } catch (IOException ex)
> {
> throw new RuntimeException(
> "Should not have happended", ex);
> }
> }
> }
> }
> }
> {code}
> Will attach IT test.
--
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: (MCHANGES-172) Bump to Doxia 1.1.2
[ http://jira.codehaus.org/browse/MCHANGES-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MCHANGES-172: --- Description: Quick patch to upgrade to latest Doxia. However this assumes that the plugin will require maven 2.1 (and site-plugin 2.1). If we want to stay compatible with maven 2.0.x we have to add some shading, see http://maven.apache.org/doxia/developers/maven-integration.html. Patch Submitted: [Yes] Attachment: MCHANGES-172.patch Summary: Bump to Doxia 1.1.2 (was: Bump to Doxia 1.1.1) > Bump to Doxia 1.1.2 > --- > > Key: MCHANGES-172 > URL: http://jira.codehaus.org/browse/MCHANGES-172 > Project: Maven 2.x Changes Plugin > Issue Type: Task >Reporter: Vincent Siveton > Attachments: MCHANGES-172.patch > > > Quick patch to upgrade to latest Doxia. However this assumes that the plugin > will require maven 2.1 (and site-plugin 2.1). If we want to stay compatible > with maven 2.0.x we have to add some shading, see > http://maven.apache.org/doxia/developers/maven-integration.html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-584) Integration tests do not work during a release
Integration tests do not work during a release -- Key: SUREFIRE-584 URL: http://jira.codehaus.org/browse/SUREFIRE-584 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.5 Reporter: Stephen Connolly Priority: Blocker The integration tests fail when running a release. They need to be refactored to work with staged versions of the dependencies from the build -- 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-4515) NoSuchArchiverException: No such archiver: 'jar'
NoSuchArchiverException: No such archiver: 'jar'
Key: MNG-4515
URL: http://jira.codehaus.org/browse/MNG-4515
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0-alpha-5
Reporter: Olivier Bazoud
In my own plugin, i use an ArchiverManager to get an UnArchiver object.
{noformat}
...
/**
* To look up Archiver/UnArchiver implementations
*
* @parameter
expression="${component.org.codehaus.plexus.archiver.manager.ArchiverManager}"
* @required
*/
private ArchiverManager archiverManager;
...
private void unpack(File file, File location) throws
MojoExecutionException, NoSuchArchiverException {
try {
// Log
if (getLog().isDebugEnabled()) {
getLog().debug("Unpack component " + file + " to " + location);
}
UnArchiver unArchiver = archiverManager.getUnArchiver("jar");
unArchiver.setSourceFile(file);
unArchiver.setDestDirectory(location);
unArchiver.extract();
} catch (ArchiverException e) {
throw new MojoExecutionException("Error unpacking file: " + file +
" to: " + location, e);
}
}
{noformat}
When i use maven 3.0 alpha 5, i got this exception on a war projet but it works
fine with maven 2.2.1 with the same projet.
{noformat}
org.codehaus.plexus.archiver.manager.NoSuchArchiverException: No such archiver:
'jar'.
at
org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getUnArchiver(DefaultArchiverManager.java:77)
at com.mycompagny...unpack(...)
...
{noformat}
Any idea ?
--
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-4515) NoSuchArchiverException: No such archiver: 'jar'
[
http://jira.codehaus.org/browse/MNG-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204967#action_204967
]
Benjamin Bentmann commented on MNG-4515:
bq. Any idea ?
Any test project or POMs? Any debug logs?
> NoSuchArchiverException: No such archiver: 'jar'
>
>
> Key: MNG-4515
> URL: http://jira.codehaus.org/browse/MNG-4515
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0-alpha-5
>Reporter: Olivier Bazoud
>
> In my own plugin, i use an ArchiverManager to get an UnArchiver object.
> {noformat}
> ...
> /**
> * To look up Archiver/UnArchiver implementations
> *
> * @parameter
> expression="${component.org.codehaus.plexus.archiver.manager.ArchiverManager}"
> * @required
> */
> private ArchiverManager archiverManager;
> ...
> private void unpack(File file, File location) throws
> MojoExecutionException, NoSuchArchiverException {
> try {
> // Log
> if (getLog().isDebugEnabled()) {
> getLog().debug("Unpack component " + file + " to " +
> location);
> }
> UnArchiver unArchiver = archiverManager.getUnArchiver("jar");
> unArchiver.setSourceFile(file);
> unArchiver.setDestDirectory(location);
> unArchiver.extract();
> } catch (ArchiverException e) {
> throw new MojoExecutionException("Error unpacking file: " + file
> + " to: " + location, e);
> }
> }
> {noformat}
> When i use maven 3.0 alpha 5, i got this exception on a war projet but it
> works fine with maven 2.2.1 with the same projet.
> {noformat}
> org.codehaus.plexus.archiver.manager.NoSuchArchiverException: No such
> archiver: 'jar'.
> at
> org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getUnArchiver(DefaultArchiverManager.java:77)
> at com.mycompagny...unpack(...)
> ...
> {noformat}
> Any idea ?
--
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-4514) Loading resource from plugin dependency using Plexus ResourceManager fails with leading slash
[
http://jira.codehaus.org/browse/MNG-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204968#action_204968
]
Peter Lynch commented on MNG-4514:
--
I will add then that a user of Maven who upgrades to Maven 3.x and happens to
use a plugin ( for example maven-eclipse-plugin ) that works with resources
with a leading slash will have to change their pom to remove the leading slash
in order to avoid the ResourceNotFoundException.
To a regular user, they will think this is a regression and blame Maven 3 since
the only thing they will change is using Maven 3.
I'll add a comment in the Maven 3.x compatibility notes for user's benefit.
> Loading resource from plugin dependency using Plexus ResourceManager fails
> with leading slash
> -
>
> Key: MNG-4514
> URL: http://jira.codehaus.org/browse/MNG-4514
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
>Affects Versions: 3.0-alpha-5
>Reporter: Peter Lynch
>Assignee: Benjamin Bentmann
> Attachments: mng-4514-IT.zip
>
>
> When a maven plugin tries to load a resource(file) from a plugin dependency
> defined in a project pom file and the path to that resource begins with
> 'slash' / then the resource is not found. The code uses the Plexus
> ResourceManagers
> Example code that works in 2.2.1 and earlier and fails in Maven 3.0-alpha-5.
> If resource is in root of jar and configFile begins with forward slash then
> we get ResourceNotFoundException.
> {code:java}
> /**
> * ResourceManager for getting a resource from a dependency jar
> *
> * @component
> * @required
> * @readonly
> */
> private ResourceManager locator;
> ...
> protected void loadResource(String configFile) throws
> ResourceNotFoundException
> {
> InputStream inStream = null;
> if (configFile != null)
> {
> try
> {
> inStream =
> locator.getResourceAsInputStream(configFile);
> } finally
> {
> if (inStream != null)
> {
> try
> {
> inStream.close();
> } catch (IOException ex)
> {
> throw new RuntimeException(
> "Should not have happended", ex);
> }
> }
> }
> }
> }
> {code}
> Will attach IT test.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204969#action_204969 ] luke w patterson commented on ARCHETYPE-273: > Here is a new patch ... > New mojo has been renamed to ImportMojo ... > since it now supports importing not only all archetypes > but also importing just single fully specified archetype Thanks Stevo, I applied the patch locally and tested it. I only ran into one issue: org.apache.maven.archetype.source.ArchetypeDataSourceException: Error parsing archetype catalog. at org.apache.maven.archetype.source.CatalogArchetypeDataSource.readCatalog(CatalogArchetypeDataSource.java:202) at org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.getArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:114) at org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java:210) at org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java:201) at org.apache.maven.archetype.mojos.ImportMojo.execute(ImportMojo.java:153) You'll get that error if the remote repo's archetype-catalog.xml file is missing or empty. At first I thought it was just an ordering issue in ImportMojo.execute, where the single import stuff should be done first, but as I dig deeper it looks like there are some more checks around the archetype entry's existence in archetype-catalog.xml. > add goal to import remote archetype catalog into local catalog > -- > > Key: ARCHETYPE-273 > URL: http://jira.codehaus.org/browse/ARCHETYPE-273 > Project: Maven Archetype > Issue Type: New Feature > Components: Archetypes >Affects Versions: 2.0-alpha-4 >Reporter: Dan Allen > Attachments: > org.apache.maven.archetype.maven-archetype-ARCHETYPE-220_&_273_interactive_combo.patch, > org.apache.maven.archetype.maven-archetype-ARCHETYPE-273_&_220_combo.patch > > > If I've just published a new archetype, I need to be able to provide the > developer with a command that allows them to "educate" their local catalog > about the new archetypes that area available. Currently, it's possible to > specify an archetype catalog for a single run of the generate goal: > mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 > But the catalog is transient. Those entries are not "remembered". The next > time I run the generate goal... > mvn archetype:generate > ...the archetypes in the catalog provided in the previous command are not > offered as options. > This is especially problematic when using an IDE to create a new Maven > project, because the mechanism for providing an archetype catalog differs in > each IDE. We want them to be in the local repository. Simply point, it's too > much information for the developer to have to reconcile, especially since > using an archetype is likely the developer's first exposure to your project. > It needs to be simple. > What I'm looking for is a command that I can give the developer to import the > entries from a remote archetype catalog. A discovery mechanism so to speak. > I envision the following sequence to work: > mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 > mvn archetype:generate > At this point, the developer would see options for the imported archetypes. > The import goal could even download the archetype JAR files at the same time. -- 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-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204971#action_204971 ] Dennis Lundberg commented on MRELEASE-261: -- Eric, I tried to have a look at the sample project you supplied, but all I find in the archive is something that looks like a file for Eclipse. Do you have a Maven project that can be used to reproduce your problems? > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0-beta-10 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, MRELEASE-261-with-its-v3.patch, > MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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-449) Parent snapshot version is not rewritten to resolved non-snapshot version during release:prepare
[
http://jira.codehaus.org/browse/MRELEASE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204972#action_204972
]
Dennis Lundberg commented on MRELEASE-449:
--
I can confirm that the sample project fails in the way that is described in
this issue.
What I can't understand is, how doing a release in this way could work outside
a dry run. You can't release a parent from a child can you?
Also parent 1.0 must be deployed prior to child 1.1 (specifying parent-1.0 as
parent) being released.
> Parent snapshot version is not rewritten to resolved non-snapshot version
> during release:prepare
>
>
> Key: MRELEASE-449
> URL: http://jira.codehaus.org/browse/MRELEASE-449
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
>Reporter: Steve Gilbert
>Priority: Critical
> Fix For: 2.0-beta-10
>
> Attachments: maven-release-rewrite-parent-bug.patch,
> parent_version_rewrite_bug.zip
>
>
> When a pom has a parent specified with a snapshot version, when "mvn
> release:prepare" is executed, the version entered by the user when prompted
> to resolve the parent version is not used when the pom is rewritten. The
> parent version remains at the snapshot version in the rewritten pom.
> This happens in dry run mode and normal mode.
> I will attach a zip file with a simple example/test case that shows the bug.
> The steps to reproduce using the zip file:
> 1. cd to parent
> 2. execute "mvn install"
> 3. cd to ../child
> 4. execute "mvn -DdryRun=true release:prepare" answering "yes" to the first
>"resolve dependencies?" question and then answering with the default to
>all the other questions
> 5. cat pom.xml.tag noticing the parent SNAPSHOT version has not been replaced
> The cause of this appears to be in AbstractRewritePomsPhase.rewriteParent.
> This method only consults the mappedVersions Map, however when the release
> plugin is executed from the command line and the user enters the version
> number to resolve the snapshot dependency (even using the default provided by
> the release plugin) the values are stored in the resolvedSnapshotDependencies
> Map only.
> I've modified the code to consult both Maps which is what other methods in
> the class do when rewriting dependency snapshot revisions. I have provided a
> patch with the modified code. The patch also contains a new test method in
> RewritePomsForReleasePhaseTest that will fail without the patch and pass with
> it.
> The patch was taken from maven-release 2.0-beta-9 and can be applied with
> {code}
> patch -p0 < ~/maven-release-rewrite-parent-bug.patch
> {code}
--
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: (MRELEASE-261) release:prepare should support flat directory multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRELEASE-261: - Summary: release:prepare should support flat directory multi-module projects (was: release:prepare shouls support flat directory multimodule projects) > release:prepare should support flat directory multi-module projects > --- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0-beta-10 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, MRELEASE-261-with-its-v3.patch, > MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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: (MRELEASE-450) release:perform should not call test:test as release:prepare already did
[ http://jira.codehaus.org/browse/MRELEASE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRELEASE-450: - Summary: release:perform should not call test:test as release:prepare already did (was: release:perform shoult not call test:test as release:prepare already did) > release:perform should not call test:test as release:prepare already did > > > Key: MRELEASE-450 > URL: http://jira.codehaus.org/browse/MRELEASE-450 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform >Affects Versions: 2.0-beta-9 > Environment: linux >Reporter: Christian Hammers >Assignee: Olivier Lamy >Priority: Minor > Fix For: 2.0-beta-10 > > > Hello > When doing a "mvn release:prepare" and then "mvn release:perform" the > complete test suite is run twice. As it takes a couple of minutes it feels > annoying. Also I don't really see the necessarity of running the test:test > goal in release:perform as release:prepare already does so and afterwards tag > the source code so that the perform cannot be made on a non-tested code, or? > bye, > -christian- -- 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: (MSITE-456) [regression] Site navigation not generated
[ http://jira.codehaus.org/browse/MSITE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204973#action_204973 ] Dennis Lundberg commented on MSITE-456: --- Confirmed. > [regression] Site navigation not generated > -- > > Key: MSITE-456 > URL: http://jira.codehaus.org/browse/MSITE-456 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) > Java version: 1.6.0_16 > Java home: d:\jdk1.6.0_16\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Paul Benedict >Priority: Critical > Attachments: MSITE-456.zip > > > My corporate POM locks down the maven-site-plugin to version 2.1. The site of > the corporate POM generates just fine. However, when a child project inherits > from it, that project's site contains no left-hand navigation. Reverting to > 2.0.1 is my workaround. -- 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-450) release:perform should not call test:test as release:prepare already did
[ http://jira.codehaus.org/browse/MRELEASE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204974#action_204974 ] Paul Benedict commented on MRELEASE-450: Performing the release is supposed to do a "clean room" build. Skipping the tests might be useful (speedier for sure), but it also is a way to release artifacts with failing tests. I say mark this as Won't Fix. > release:perform should not call test:test as release:prepare already did > > > Key: MRELEASE-450 > URL: http://jira.codehaus.org/browse/MRELEASE-450 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform >Affects Versions: 2.0-beta-9 > Environment: linux >Reporter: Christian Hammers >Assignee: Olivier Lamy >Priority: Minor > Fix For: 2.0-beta-10 > > > Hello > When doing a "mvn release:prepare" and then "mvn release:perform" the > complete test suite is run twice. As it takes a couple of minutes it feels > annoying. Also I don't really see the necessarity of running the test:test > goal in release:perform as release:prepare already does so and afterwards tag > the source code so that the perform cannot be made on a non-tested code, or? > bye, > -christian- -- 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-450) release:perform should not call test:test as release:prepare already did
[ http://jira.codehaus.org/browse/MRELEASE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204975#action_204975 ] Olivier Lamy commented on MRELEASE-450: --- agree on won't fix too. Users can configure test skipping if they prefer not executing tests. > release:perform should not call test:test as release:prepare already did > > > Key: MRELEASE-450 > URL: http://jira.codehaus.org/browse/MRELEASE-450 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform >Affects Versions: 2.0-beta-9 > Environment: linux >Reporter: Christian Hammers >Assignee: Olivier Lamy >Priority: Minor > Fix For: 2.0-beta-10 > > > Hello > When doing a "mvn release:prepare" and then "mvn release:perform" the > complete test suite is run twice. As it takes a couple of minutes it feels > annoying. Also I don't really see the necessarity of running the test:test > goal in release:perform as release:prepare already does so and afterwards tag > the source code so that the perform cannot be made on a non-tested code, or? > bye, > -christian- -- 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-261) release:prepare should support flat directory multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204976#action_204976 ] Eric Miles commented on MRELEASE-261: - The file I've attached has 3 subdirectories, each with a pom in it. I have re-downloaded the archive attached to this JIRA and it works fine. It is in tar.gz format, make sure you are downloading the maven-release-issue.tar.gz file. > release:prepare should support flat directory multi-module projects > --- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0-beta-10 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, MRELEASE-261-with-its-v3.patch, > MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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: (MECLIPSE-631) [Maven 3] Inegration test project-44 fails with Unable to resolve resource location: /checkstyle-config.xml
[Maven 3] Inegration test project-44 fails with Unable to resolve resource location: /checkstyle-config.xml --- Key: MECLIPSE-631 URL: http://jira.codehaus.org/browse/MECLIPSE-631 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Environment: Using Java version: 1.6 Apache Maven 3.0-alpha-5 (r883378; 2009-11-23 10:53:41-0500) Java version: 1.6.0_17 Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" Reporter: Peter Lynch project-44 integration test fails due to MNG-4514 when using Maven 3.0-alpha-5 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.309s [INFO] Finished at: Sun Jan 03 19:19:58 EST 2010 [INFO] Final Memory: 4M/264M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) on project maven-eclipse-plugin-test-project-44: Unable to resolve resource location: /checkstyle-config.xml -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) on project maven-eclipse-plugin-test-project-44: Unable to resolve resource location: /checkstyle-config.xml at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:570) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:245) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:102) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:423) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:158) at org.apache.maven.cli.MavenCli.main(MavenCli.java:123) 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to resolve resource location: /checkstyle-config.xml at org.apache.maven.plugin.eclipse.EclipsePlugin.writeAdditionalConfig(EclipsePlugin.java:1200) at org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1141) at org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:562) ... 14 more [ERROR] -- 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: (MECLIPSE-631) [Maven 3] Integration test project-44 fails with Unable to resolve resource location: /checkstyle-config.xml
[ http://jira.codehaus.org/browse/MECLIPSE-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Lynch updated MECLIPSE-631: - Summary: [Maven 3] Integration test project-44 fails with Unable to resolve resource location: /checkstyle-config.xml (was: [Maven 3] Inegration test project-44 fails with Unable to resolve resource location: /checkstyle-config.xml) > [Maven 3] Integration test project-44 fails with Unable to resolve resource > location: /checkstyle-config.xml > > > Key: MECLIPSE-631 > URL: http://jira.codehaus.org/browse/MECLIPSE-631 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: Using Java version: 1.6 > Apache Maven 3.0-alpha-5 (r883378; 2009-11-23 10:53:41-0500) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" >Reporter: Peter Lynch > > project-44 integration test fails due to MNG-4514 when using Maven 3.0-alpha-5 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 1.309s > [INFO] Finished at: Sun Jan 03 19:19:58 EST 2010 > [INFO] Final Memory: 4M/264M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) on > project maven-eclipse-plugin-test-project-44: Unable to resolve resource > location: /checkstyle-config.xml -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) > on project maven-eclipse-plugin-test-project-44: Unable to resolve resource > location: /checkstyle-config.xml > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:570) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:245) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:102) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:423) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:158) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:123) > 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to resolve > resource location: /checkstyle-config.xml > at > org.apache.maven.plugin.eclipse.EclipsePlugin.writeAdditionalConfig(EclipsePlugin.java:1200) > at > org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1141) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:562) > ... 14 more > [ERROR] -- 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: (MECLIPSE-631) [Maven 3] Integration test project-44 fails with Unable to resolve resource location: /checkstyle-config.xml
[ http://jira.codehaus.org/browse/MECLIPSE-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Lynch updated MECLIPSE-631: - Attachment: MECLIPSE-631.patch > [Maven 3] Integration test project-44 fails with Unable to resolve resource > location: /checkstyle-config.xml > > > Key: MECLIPSE-631 > URL: http://jira.codehaus.org/browse/MECLIPSE-631 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: Using Java version: 1.6 > Apache Maven 3.0-alpha-5 (r883378; 2009-11-23 10:53:41-0500) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" >Reporter: Peter Lynch > Attachments: MECLIPSE-631.patch > > > project-44 integration test fails due to MNG-4514 when using Maven 3.0-alpha-5 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 1.309s > [INFO] Finished at: Sun Jan 03 19:19:58 EST 2010 > [INFO] Final Memory: 4M/264M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) on > project maven-eclipse-plugin-test-project-44: Unable to resolve resource > location: /checkstyle-config.xml -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) > on project maven-eclipse-plugin-test-project-44: Unable to resolve resource > location: /checkstyle-config.xml > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:570) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:245) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:102) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:423) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:158) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:123) > 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to resolve > resource location: /checkstyle-config.xml > at > org.apache.maven.plugin.eclipse.EclipsePlugin.writeAdditionalConfig(EclipsePlugin.java:1200) > at > org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1141) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:562) > ... 14 more > [ERROR] -- 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: (MECLIPSE-631) [Maven 3] Integration test project-44 fails with Unable to resolve resource location: /checkstyle-config.xml
[ http://jira.codehaus.org/browse/MECLIPSE-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Lynch updated MECLIPSE-631: - Patch Submitted: [Yes] > [Maven 3] Integration test project-44 fails with Unable to resolve resource > location: /checkstyle-config.xml > > > Key: MECLIPSE-631 > URL: http://jira.codehaus.org/browse/MECLIPSE-631 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: Using Java version: 1.6 > Apache Maven 3.0-alpha-5 (r883378; 2009-11-23 10:53:41-0500) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" >Reporter: Peter Lynch > Attachments: MECLIPSE-631.patch > > > project-44 integration test fails due to MNG-4514 when using Maven 3.0-alpha-5 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 1.309s > [INFO] Finished at: Sun Jan 03 19:19:58 EST 2010 > [INFO] Final Memory: 4M/264M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) on > project maven-eclipse-plugin-test-project-44: Unable to resolve resource > location: /checkstyle-config.xml -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) > on project maven-eclipse-plugin-test-project-44: Unable to resolve resource > location: /checkstyle-config.xml > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:570) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:245) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:102) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:423) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:158) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:123) > 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to resolve > resource location: /checkstyle-config.xml > at > org.apache.maven.plugin.eclipse.EclipsePlugin.writeAdditionalConfig(EclipsePlugin.java:1200) > at > org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1141) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:562) > ... 14 more > [ERROR] -- 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: (MECLIPSE-631) [Maven 3] Integration test project-44 fails with Unable to resolve resource location: /checkstyle-config.xml
[ http://jira.codehaus.org/browse/MECLIPSE-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204977#action_204977 ] Peter Lynch commented on MECLIPSE-631: -- Patch attached that resolves the integration test failure. Any user trying to load resources with leading slash may need to modify their pom. > [Maven 3] Integration test project-44 fails with Unable to resolve resource > location: /checkstyle-config.xml > > > Key: MECLIPSE-631 > URL: http://jira.codehaus.org/browse/MECLIPSE-631 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: Using Java version: 1.6 > Apache Maven 3.0-alpha-5 (r883378; 2009-11-23 10:53:41-0500) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" >Reporter: Peter Lynch > Attachments: MECLIPSE-631.patch > > > project-44 integration test fails due to MNG-4514 when using Maven 3.0-alpha-5 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 1.309s > [INFO] Finished at: Sun Jan 03 19:19:58 EST 2010 > [INFO] Final Memory: 4M/264M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) on > project maven-eclipse-plugin-test-project-44: Unable to resolve resource > location: /checkstyle-config.xml -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) > on project maven-eclipse-plugin-test-project-44: Unable to resolve resource > location: /checkstyle-config.xml > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:570) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:245) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:102) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:423) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:158) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:123) > 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to resolve > resource location: /checkstyle-config.xml > at > org.apache.maven.plugin.eclipse.EclipsePlugin.writeAdditionalConfig(EclipsePlugin.java:1200) > at > org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1141) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:562) > ... 14 more > [ERROR] -- 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: (MECLIPSE-632) Add markers in the generated project files that can identify them as being created by the maven-eclipse-plugin
Add markers in the generated project files that can identify them as being created by the maven-eclipse-plugin -- Key: MECLIPSE-632 URL: http://jira.codehaus.org/browse/MECLIPSE-632 Project: Maven 2.x Eclipse Plugin Issue Type: Task Components: M2Eclipse support Reporter: Jason van Zyl M2Eclipse as of the 1.0 release will not support project files generated with the maven-eclipse-plugin. We receive too many support questions and there is too much user confusion over what works and what doesn't. If users choose to employ the maven-eclipse-plugin then they will not be able to use M2Eclipse 1.0. -- 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-505) Upgrade to scm 1.3
[ http://jira.codehaus.org/browse/MRELEASE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204982#action_204982 ] Subir S commented on MRELEASE-505: -- Yes, please. Since [SCM-505|http://jira.codehaus.org/browse/SCM-505] and [SCM-261|http://jira.codehaus.org/browse/SCM-261] are some critical fixes in maven-scm-snergy provider. Without which release cannot be done. Hence if release plugin is to be used then this should also be updated. > Upgrade to scm 1.3 > -- > > Key: MRELEASE-505 > URL: http://jira.codehaus.org/browse/MRELEASE-505 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Reporter: Olivier Lamy > Fix For: 2.0-beta-10 > > -- 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
