[jira] Created: (CONTINUUM-1686) In the group view provide an option to display only failed builds
In the group view provide an option to display only failed builds - Key: CONTINUUM-1686 URL: http://jira.codehaus.org/browse/CONTINUUM-1686 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1 Reporter: Vincent Massol Priority: Minor When you have 100+ modules listed it's hard to find the failing ones quickly. -- 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-469) test environment is not share between dependent modules
test environment is not share between dependent modules --- Key: SUREFIRE-469 URL: http://jira.codehaus.org/browse/SUREFIRE-469 Project: Maven Surefire Issue Type: Bug Components: plugin Affects Versions: 2.3 Environment: Windows XP Maven version: 2.0.7 Java version: 1.5.0_12 OS name: "windows xp" version: "5.1" arch: "x86" Reporter: Bogdan Serban I have to dependent modules which have some special dependencies for testing. 1. Let say the first one has a JDBC driver specified 2. When i test the second the test fails because the test dependency from the first module is not included. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1680) Add functionality to remove/recreate a working copy
[ http://jira.codehaus.org/browse/CONTINUUM-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126420 ] Nick Stolwijk commented on CONTINUUM-1680: -- I know of that option, after the little discussion on the maillinglist. However, it would be nice if there was just one button to recreate it. I'd rather not to have to schedule a build with a recreate. > Add functionality to remove/recreate a working copy > --- > > Key: CONTINUUM-1680 > URL: http://jira.codehaus.org/browse/CONTINUUM-1680 > Project: Continuum > Issue Type: New Feature > Components: SCM, Web - UI >Reporter: Nick Stolwijk >Priority: Minor > > Sometimes a subversion working copy gets corrupted and can not be repaired > through the user interface. This is possible when you have a strange build > which overwrites directories or conflicting commits/build(*). It would be > nice if the User interface offered a possibility to recreate the working copy > (remove and new checkout for example). > (*) We had a directory called etc. In a few commits someone removed that > directory, another one added build code to create a file in that directory > and another person added this folder again in SVN. Continuum (or rather the > SVN under it) was a little confused and could not update. -- 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: (MDEPLOY-45) Classifier not supported by deploy:deploy
[
http://jira.codehaus.org/browse/MDEPLOY-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Schulz updated MDEPLOY-45:
-
Attachment: mdeploy-45-test.zip
The attached mdeploy-45-test.zip contains a sample web project: The war plugin
is configured with a *classifier*. For simplicity, the deploy plugin is
configured with *altDeploymentRepository* pointing to the target directory.
1. To reproduce the MDEPLOY-45 bug, call:
{{%> mvn deploy}}
2. To compare with non-classifier behaviour, call:
{{%> mvn -Dmdp45.artifact.classifier= deploy}}
I hope it helps.
> Classifier not supported by deploy:deploy
> -
>
> Key: MDEPLOY-45
> URL: http://jira.codehaus.org/browse/MDEPLOY-45
> Project: Maven 2.x Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Fabian Bauschulte
>Priority: Critical
> Fix For: 2.4
>
> Attachments: MDEPLOY-45-maven-deploy-plugin.patch, mdeploy-45-test.zip
>
>
> I am using classifieres in some projects (jar, war, ear) and installing the
> artefacts works fine. I am getting an Exception during the deployment of the
> artifacts.
--
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-146) Archetype Resources not being processed on Windows.
[
http://jira.codehaus.org/browse/ARCHETYPE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126419
]
Rob Evans commented on ARCHETYPE-146:
-
I can't seem to get a patch created but here's a fix. Look for the comment //
START FIX
public class DefaultArchetype
extends AbstractLogEnabled
implements Archetype
{
...
private void zipper( ZipOutputStream zos,
int offset,
File currentSourceDirectory )
throws IOException
{
File[] files = currentSourceDirectory.listFiles();
for ( int i = 0; i < files.length; i++ )
{
if ( files[i].isDirectory() )
{
zipper( zos, offset, files[i] );
}
else
{
String fileName = files[i].getAbsolutePath().substring( offset
+ 1 );
// START FIX
if(files[i].separatorChar != '/'){
fileName = fileName.replace('\\', '/');
}
// END FIX
ZipEntry e = new ZipEntry( fileName );
zos.putNextEntry( e );
FileInputStream is = new FileInputStream( files[i] );
byte[] buf = new byte[4096];
int n;
while ( ( n = is.read( buf ) ) > 0 )
{
zos.write( buf, 0, n );
}
is.close();
zos.flush();
zos.closeEntry();
}
}
}
...
}
> Archetype Resources not being processed on Windows.
>
>
> Key: ARCHETYPE-146
> URL: http://jira.codehaus.org/browse/ARCHETYPE-146
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 2.0-alpha-2
> Environment: Windows XP
>Reporter: Rob Evans
>
> We created an archetype, built and installed it on a windows machine. When we
> used it on the same machine, the project was created but did not have the
> src/ directory. When we built it on a unix system and ran it on a windows box
> it worked properly.
> Looks like a problem processing the resources. Maybe a path issue?
> $ mvn --version
> Maven version: 2.0.7
> Java version: 1.6.0_02
> OS name: "windows xp" version: "5.1" arch: "x86"
> Define value for package: : d
> Confirm properties configuration:
> groupId: d
> artifactId: d
> version: d
> package: d
> Y: :
> [DEBUG] OldArchetype generation configuration confirmed
> [DEBUG] archetype.cci.struts: using locally installed snapshot
> [DEBUG] archetype.cci.struts: using locally installed snapshot
> [DEBUG] No found META-INF/maven/archetype-metadata.xml retrying with windows
> path
> [DEBUG] archetype.cci.struts: using locally installed snapshot
> [DEBUG] No found META-INF/maven/archetype-metadata.xml retrying with windows
> path
> [DEBUG] Found resource archetype-resources\pom.xml
> [DEBUG] Found resource archetype-resources\src\main\webapp\index.jsp
> [DEBUG] Found resource archetype-resources\src\main\webapp\WEB-INF\web.xml
> [DEBUG] Not resource META-INF\maven\archetype-metadata.xml
> [DEBUG] Not resource META-INF\maven\archetype.xml
> [DEBUG] Processing complete archetype app
> [DEBUG] Processing d
> [DEBUG] Processing pom C:\DOCUME~1\robevans\NX73F8~1\temp\d\pom.xml
> [DEBUG] Prosessing template archetype-resources\pom.xml
> [DEBUG] Merging into C:\DOCUME~1\robevans\NX73F8~1\temp\d\pom.xml
> [DEBUG] Processing filesets
> [DEBUG] Processing fileset src/main/webapp (Filtered-Flat) [**/*.jsp,
> **/*.xml -- ]
> []
> [archetype-resources\pom.xml, archetype-resources\src\main\webapp\index.jsp,
> archetype-resources\src\main\webapp\WEB-INF\web.xml]
> [DEBUG] Processed 0 files
> [DEBUG] Processed d
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 11 seconds
> [INFO] Finished at: Thu Mar 06 21:05:31 GMT-02:00 2008
> [INFO] Final Memory: 7M/13M
> [INFO]
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-396) No association between Maven 2 dependencies source possible
No association between Maven 2 dependencies source possible --- Key: MECLIPSE-396 URL: http://jira.codehaus.org/browse/MECLIPSE-396 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: M2Eclipse support Environment: Version: 3.2.2 (Build id: M20070212-1330), Windows XP, M2Eclipse 0.0.12.20071107-2300 Reporter: Karl Heinz Marbaise Priority: Minor I can not associate as source code zip file with an Maven dependency. Via the UI i can do the steps to make the associatation but it seemed that the information is not stored in any way. If i go through the step a second time the information is lost. -- 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: (MDEP-154) dependency:copy always creates new timestamp, when copying from Repository to local filesystem
dependency:copy always creates new timestamp, when copying from Repository to local filesystem -- Key: MDEP-154 URL: http://jira.codehaus.org/browse/MDEP-154 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: copy, copy-dependencies Affects Versions: 2.1 Environment: Windows XP 2.0-alpha-5-20080115.230021-25 Reporter: Torsten Reinhard Assignee: Brian Fox Priority: Minor From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2008 7:00 AM To: [EMAIL PROTECTED] Subject: dependency:copy always creates new timestamp Hi, to create the delivery version of our whole system, I use "dependency:copy" and "dependency:copy-dependencies" to copy the jars, ears, wars and so on from our internal repository into a defined directory structure. Install Module-A xyz.war Module-B xyz.ear Documentation *.doc Every time I start the "delivery build", the copied artifacts get new timestamps - although the version hasn´t changed in between. I couldn´t find any property "keep original timestamp" to set for the goals "copy" or "copy-dependencies". Is there a way? Thanx, Torsten -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126426
]
Damien Lecan commented on MJAVADOC-116:
---
Antonio, same problem as me with classifiers.
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>Assignee: Vincent Siveton
> Fix For: 2.4
>
> Attachments: clean javadoc-plugin-test-case with classifier use.zip,
> javadoc-plugin-test-case with classifier use.zip,
> javadoc-plugin-test-case.zip, log.txt, tiles-log.txt
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1955) upload xSocket 2.0-beta-1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126428 ] greg commented on MAVENUPLOAD-1955: --- OK, please see attached the required sync information > upload xSocket 2.0-beta-1 > - > > Key: MAVENUPLOAD-1955 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1955 > Project: maven-upload-requests > Issue Type: Wish >Reporter: greg > Attachments: info.txt > > > please also upload the xSocket extensions > http://xsocket.sourceforge.net/download/xSocket-http-2.0-alpha-3-bundle.jar > http://xsocket.sourceforge.net/download/xSocket-multiplexed-2.0-alpha-3-bundle.jar > Thank you very much > Greg -- 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: (MAVENUPLOAD-1955) upload xSocket 2.0-beta-1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] greg updated MAVENUPLOAD-1955: -- Attachment: info.txt > upload xSocket 2.0-beta-1 > - > > Key: MAVENUPLOAD-1955 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1955 > Project: maven-upload-requests > Issue Type: Wish >Reporter: greg > Attachments: info.txt > > > please also upload the xSocket extensions > http://xsocket.sourceforge.net/download/xSocket-http-2.0-alpha-3-bundle.jar > http://xsocket.sourceforge.net/download/xSocket-multiplexed-2.0-alpha-3-bundle.jar > Thank you very much > Greg -- 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-397) Eclipse project set as dependency + test-jar dependency i sincluded twice in .classpath
Eclipse project set as dependency + test-jar dependency i sincluded twice in .classpath --- Key: MECLIPSE-397 URL: http://jira.codehaus.org/browse/MECLIPSE-397 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Workspace settings Affects Versions: 2.5 Environment: maven 2.0.8, eclipse plugin version 2.5-20080218.113139-24 Reporter: nicolas de loof My maven project depends on A-util.jar for compile and A-util-tests.jar for tests : ... A-util ... ... A-util ... test-jar test I have the "A-util" project in my eclipse workspace Running mvn eclipse:eclipse creates an invalid .classpath where the eclipse A project is included twice : -- 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-397) Eclipse project set as dependency + test-jar dependency is included twice in .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof updated MECLIPSE-397: - Summary: Eclipse project set as dependency + test-jar dependency is included twice in .classpath (was: Eclipse project set as dependency + test-jar dependency i sincluded twice in .classpath) > Eclipse project set as dependency + test-jar dependency is included twice in > .classpath > --- > > Key: MECLIPSE-397 > URL: http://jira.codehaus.org/browse/MECLIPSE-397 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 > Environment: maven 2.0.8, eclipse plugin version > 2.5-20080218.113139-24 >Reporter: nicolas de loof > > My maven project depends on A-util.jar for compile and A-util-tests.jar for > tests : > > ... > A-util > ... > > > ... > A-util > ... > test-jar > test > > I have the "A-util" project in my eclipse workspace > Running mvn eclipse:eclipse creates an invalid .classpath where the eclipse A > project is included twice : > > -- 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-397) Eclipse project set as dependency + test-jar dependency is included twice in .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof updated MECLIPSE-397: - Description: My maven project depends on A-util.jar for compile and A-util-tests.jar for tests : ... A-util ... ... A-util ... test-jar test I have the "A-util" project in my eclipse workspace Running mvn eclipse:eclipse creates an invalid .classpath where the eclipse A project is included twice : .. and invalid .project with twice references : A-util A-util was: My maven project depends on A-util.jar for compile and A-util-tests.jar for tests : ... A-util ... ... A-util ... test-jar test I have the "A-util" project in my eclipse workspace Running mvn eclipse:eclipse creates an invalid .classpath where the eclipse A project is included twice : > Eclipse project set as dependency + test-jar dependency is included twice in > .classpath > --- > > Key: MECLIPSE-397 > URL: http://jira.codehaus.org/browse/MECLIPSE-397 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 > Environment: maven 2.0.8, eclipse plugin version > 2.5-20080218.113139-24 >Reporter: nicolas de loof > > My maven project depends on A-util.jar for compile and A-util-tests.jar for > tests : > > ... > A-util > ... > > > ... > A-util > ... > test-jar > test > > I have the "A-util" project in my eclipse workspace > Running mvn eclipse:eclipse creates an invalid .classpath where the eclipse A > project is included twice : > > > .. and invalid .project with twice references : > A-util > A-util -- 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: (DOXIA-204) Add generic parameters support to Figure and Link events
[ http://jira.codehaus.org/browse/DOXIA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-204. --- Assignee: Lukas Theussl Resolution: Fixed I committed a first version in r634662, please review and feel free to adjust and improve. :) > Add generic parameters support to Figure and Link events > > > Key: DOXIA-204 > URL: http://jira.codehaus.org/browse/DOXIA-204 > Project: Maven Doxia > Issue Type: Improvement > Components: Sink API >Affects Versions: 1.0-alpha-10 >Reporter: Vincent Massol >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > > For example XWiki has the following syntax for image macros and links: > * image: http://code.xwiki.org/xwiki/bin/view/Macros/ImageMacro > * links: http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HLinks > For the image macro there are the "document" and "fromincludingdoc" which are > specific to XWiki and thus cannot be put as standard parameters. > Same for links. > Thus I propose to allow parsers to pass a Map of properties (pair/values) to > the Sink API so that sinks can be written to understand them (the XWiki sink > would understand them for example). -- 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: (DOXIA-227) [regression] attributes stripped from img tags
[ http://jira.codehaus.org/browse/DOXIA-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-227. --- Assignee: Lukas Theussl Resolution: Fixed Fixed with DOXIA-204. > [regression] attributes stripped from img tags > -- > > Key: DOXIA-227 > URL: http://jira.codehaus.org/browse/DOXIA-227 > Project: Maven Doxia > Issue Type: Bug > Components: Core, Module - Xdoc, Module - Xhtml, Modules, Sink API >Affects Versions: 1.0-alpha-9 >Reporter: Brett Porter >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > > previous versions didn't do this, but it is happening on trunk. For an > example, run it on the Archiva site and compare outputs with the last release. -- 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: (DOXIA-78) Doxia XDOC parser and XHTML renderer ignore "rowspan" and "colspan" attributes for tables
[ http://jira.codehaus.org/browse/DOXIA-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-78. -- Resolution: Fixed Fixed with DOXIA-204. > Doxia XDOC parser and XHTML renderer ignore "rowspan" and "colspan" > attributes for tables > - > > Key: DOXIA-78 > URL: http://jira.codehaus.org/browse/DOXIA-78 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Xdoc, Module - Xhtml, Sink API >Affects Versions: 1.0-alpha-8 >Reporter: Henning Schmiedehausen >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: doxia.patch > > > The xdoc parser ignores rowspan and colspan attributes for and > cells (even though the DTD says that these are legal) and the XHTML renderer > subsequently does not render out these attributes. > As the Sink-API offers methods for generating table-cells with a defined > width, this is easy to implement (see attached patch), but the rowspan > attribute would require new methods in the (very unflexible) API that take > both height and width. > The attached patch fixes the colspan problem for the xdoc parser and the > xhtml renderer. -- 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-397) Eclipse project set as dependency + test-jar dependency is included twice in .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126450 ] nicolas de loof commented on MECLIPSE-397: -- Issue is a little more complex. When eclipse .classpath make reference to project A-util, it only includes default build directory (target/classes), so will never include the target/test-classes that matches the A-util-tests.jar. I don't know if this is possible to specify build directory in target project in the .classpath XML format. The UI editor doesn't provides this option. > Eclipse project set as dependency + test-jar dependency is included twice in > .classpath > --- > > Key: MECLIPSE-397 > URL: http://jira.codehaus.org/browse/MECLIPSE-397 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 > Environment: maven 2.0.8, eclipse plugin version > 2.5-20080218.113139-24 >Reporter: nicolas de loof > > My maven project depends on A-util.jar for compile and A-util-tests.jar for > tests : > > ... > A-util > ... > > > ... > A-util > ... > test-jar > test > > I have the "A-util" project in my eclipse workspace > Running mvn eclipse:eclipse creates an invalid .classpath where the eclipse A > project is included twice : > > > .. and invalid .project with twice references : > A-util > A-util -- 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: (DOXIA-38) Independent row parsing
[
http://jira.codehaus.org/browse/DOXIA-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated DOXIA-38:
---
Fix Version/s: (was: 1.0-beta-1)
1.0-beta-2
With DOXIA-204 this is now possible in principle, we just need to make the
AptParser emit the appropriate attributes. Scheduling for a later release...
> Independent row parsing
> ---
>
> Key: DOXIA-38
> URL: http://jira.codehaus.org/browse/DOXIA-38
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Anuerin Diaz
>Priority: Minor
> Fix For: 1.0-beta-2
>
>
> Currently the table rendered formats each column depending on the definition
> of the first row. This is a problem when the text justification of the header
> row is different from the rest of the table (e.g. the header row is centered,
> but the rest of the table rows are left-aligned). Take this example fo
> instance:
> {noformat}
> *---*--*
> |<> |<>
> |
> *---+--+
> |generate-sources |generate any source code for inclusion in compilation.
>|
> *---+--+
> |generate-resources |generate resources for inclusion in the package.
>|
> *---+--+
> |compile |compile the source code of the project.
> |
> *---+--+
> |test |run tests using a suitable unit testing framework.
> These tests|
> | |should not require the code be packaged or deployed.
> |
> *---+--+
> |package |take the compiled code and package it in its
> distributable format,|
> | |such as JAR.
> |
> *---+--+
> |install |install the package into the local repository, for use
> as a |
> | |dependency in other projects locally.
> |
> *---+--+
> {noformat}
>
--
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: (DOXIA-63) Add CSS style class to XHTML tags
[ http://jira.codehaus.org/browse/DOXIA-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-63. -- Assignee: Lukas Theussl Resolution: Won't Fix Fix Version/s: (was: 1.0) More general solution implemented at DOXIA-204. > Add CSS style class to XHTML tags > - > > Key: DOXIA-63 > URL: http://jira.codehaus.org/browse/DOXIA-63 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Vance Karimi >Assignee: Lukas Theussl >Priority: Minor > Attachments: doxia-1.0-alpha-8-core-patch.txt, > doxia-1.0-alpha-8-sink-api-patch.txt > > > Add support for CSS style formatting with a class property on tags. > Previously filed http://jira.codehaus.org/browse/MNG-545. > Patches for core and sink-api for doxia-1.0-alpha-8 attached. > It provides the following fixes: > 1. class property on list and numbered list tag > 2. class property on paragraph tag > 3. class property on link tag > 4. target property on link tag > 5. class property on table cells > 6. class property on table header cells > 7. class property on anchors > Is this an acceptable request or have people achieved CSS style differently > when generating XHTML using Doxia? > Thanks -- 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-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126458 ] George Gastaldi commented on MSITE-211: --- When will this be fixed ? > Can't deploy site using site:deploy due to a ProxyHTTP error > > > Key: MSITE-211 > URL: http://jira.codehaus.org/browse/MSITE-211 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-5 > Environment: linux ubuntu dapper drake >Reporter: Elid OR >Priority: Blocker > Attachments: MSITE-211.patch > > > When I execute the site deployment (with version that comes with maven 2.0.5) > "mvn site:deploy " I got an error see log en debug mode below. This used to > work correctly with maven version 2.04 (so maybe site plugin version > 2.0-beta-4 : > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy > error: Forbidden > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: org.apache.maven.wagon.authentication.AuthenticationException: > Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: > Forbidden > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) > ... 18 more > Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: > proxy error: Forbidden > at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) > ... 20 more > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007 > [INFO] Final Memory: 3M/7M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1934) gnu-hylafax 1.0.0-b2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126464 ] Steven Jardine commented on MAVENUPLOAD-1934: - I am the admin of the GNU-HylaFAX project. I have setup a repository located at scp://shell.sourceforge.net/home/groups/g/gn/gnu-hylafax/m2repo Would you mind adding it to the automatic sync. Thanks! > gnu-hylafax 1.0.0-b2 > > > Key: MAVENUPLOAD-1934 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1934 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina >Assignee: Carlos Sanchez > > the release is made up by 4 artifacts (4 upload bundles below) + 1 parent pom: > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-core-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-inet-ftp-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-pool-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-utils-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-1.0.0-b2.pom > Note that gnu-hylafax uses maven 2 to build, so these are official poms. > Groupid is "gnu-hylafax", which is not so good accorting maven convention, > but this is how artifacts are officially released. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1957) GNU-HylaFAX
GNU-HylaFAX --- Key: MAVENUPLOAD-1957 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1957 Project: maven-upload-requests Issue Type: Task Reporter: Steven Jardine I would like to add GNU-HylaFAX to the maven repository. I have set up a repository on the sourceforge server. It is located at scp://shell.sourceforge.net/home/groups/g/gn/gnu-hylafax/m2repo Please add us to the automatic sync list. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1934) gnu-hylafax 1.0.0-b2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126483 ] Carlos Sanchez commented on MAVENUPLOAD-1934: - please read the instructions and provide all the info asked there http://maven.apache.org/guides/mini/guide-central-repository-upload.html > gnu-hylafax 1.0.0-b2 > > > Key: MAVENUPLOAD-1934 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1934 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina >Assignee: Carlos Sanchez > > the release is made up by 4 artifacts (4 upload bundles below) + 1 parent pom: > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-core-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-inet-ftp-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-pool-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-utils-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-1.0.0-b2.pom > Note that gnu-hylafax uses maven 2 to build, so these are official poms. > Groupid is "gnu-hylafax", which is not so good accorting maven convention, > but this is how artifacts are officially released. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1946) Upload ImageInfo 1.9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126486 ] Michael Osipov commented on MAVENUPLOAD-1946: - What are you trying to tell me? Do you want me to upload it? > Upload ImageInfo 1.9 > > > Key: MAVENUPLOAD-1946 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1946 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Michael Osipov > > Version 1.9 contains important fixes. Upload is appreciated! -- 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-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126489
]
Vincent Massol commented on MNG-3438:
-
You'll need to defined the xwiki remote repos in your settings.xml to build the
module. See
http://dev.xwiki.org/xwiki/bin/view/Community/Building#HInstallingMaven
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Vincent Massol
> Fix For: 2.0.9
>
>
> This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Platform - Applications - Selenium
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
> [INFO] [remote-resources:process {execution: xwiki-license-resources}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] Attempting to build MavenProject instance for Artifact
> (com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
> type: maven-plugin; constructing POM artifact instead.
> [INFO] [xwiki-xar:xar]
> [INFO] Generating package.xml descriptor at
> [/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
> [FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
> (java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
> urls[0] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
> urls[3] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
> urls[4] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
> urls[5] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
> urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
> urls[7] =
> file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> [FATAL ERROR] Container realm = plexus.core
> urls[0] =
> file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.IncompatibleClassChangeError
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
> at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(Defaul
[jira] Created: (MNG-3448) Infinite Loop When Using project.version in Modules Build
Infinite Loop When Using project.version in Modules Build
-
Key: MNG-3448
URL: http://jira.codehaus.org/browse/MNG-3448
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.8
Reporter: Hilco Wijbenga
I have the following setup:
org.example.pom/pom.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/xsd/maven-4.0.0.xsd";
>
4.0.0
org.example
pom
pom
1
POM
${project.version}
and org.example.jar/pom.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/xsd/maven-4.0.0.xsd";
>
4.0.0
org.example
pom
1
../org.example.pom/pom.xml
org.example
jar
jar
${webapp.version}
JAR
Running "mvn clean" in org.example.jar yields just
[INFO] Scanning for projects...
and then Maven hangs. Replacing "${project.version}" with a simple "0.1" allows
things to work properly.
My environment:
Maven version: 2.0.8
Java version: 1.5.0_14
OS name: "linux" version: "2.6.24-gentoo-r2" arch: "i386" Family: "unix"
--
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-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126493
]
Brian Fox commented on MNG-3438:
I'm getting more info when it crashes:
{noformat}
[INFO] [xwiki-xar:xar]
[INFO] Generating package.xml descriptor at
[D:\svn\xwiki\target\classes\package.xml]
[FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
(java.lang.IncompatibleClassChangeError) a
nd may be out-of-date. Check the realms:
[FATAL ERROR] Plugin realm =
app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
urls[0] =
file:/d:/mavenRepo/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.
jar
urls[1] =
file:/d:/mavenRepo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
urls[2] =
file:/d:/mavenRepo/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
urls[3] =
file:/d:/mavenRepo/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
urls[4] =
file:/d:/mavenRepo/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
urls[5] =
file:/d:/mavenRepo/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
urls[6] = file:/d:/mavenRepo/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
urls[7] = file:/d:/mavenRepo/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
[FATAL ERROR] Container realm = plexus.core
urls[0] = file:/c:/Program Files/maven2/bin/../lib/maven-2.0.9-SNAPSHOT-uber.jar
urls[1] =
file:/d:/mavenRepo/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHO
T.jar
urls[2] =
file:/d:/mavenRepo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Class org.codehaus.plexus.logging.console.ConsoleLogger does not
implement the requested interface org.codehaus.p
lexus.logging.Logger
[INFO]
[INFO] Trace
java.lang.IncompatibleClassChangeError: Class
org.codehaus.plexus.logging.console.ConsoleLogger does not implement the r
equested interface org.codehaus.plexus.logging.Logger
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:50
7)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
a:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:331)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:124)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:285)
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: 14 seconds
[INFO] Finished at: Fri Mar 07 14:02:55 EST 2008
[INFO] Final Memory: 8M/15M
[INFO]
{noformat}
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Version
[jira] Commented: (MNG-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126494
]
Brian Fox commented on MNG-3438:
This seems to be caused by the XarMojo trying to use some old plexus dependency
that causes conflicts in the logging impl.
It works in 2.1 because there plugins are completely isolated from the core. If
you can identify which jar is causing the conflict, we might be able to figure
out what can be done to restore compatibility.
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Vincent Massol
> Fix For: 2.0.9
>
>
> This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Platform - Applications - Selenium
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
> [INFO] [remote-resources:process {execution: xwiki-license-resources}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] Attempting to build MavenProject instance for Artifact
> (com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
> type: maven-plugin; constructing POM artifact instead.
> [INFO] [xwiki-xar:xar]
> [INFO] Generating package.xml descriptor at
> [/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
> [FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
> (java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
> urls[0] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
> urls[3] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
> urls[4] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
> urls[5] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
> urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
> urls[7] =
> file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> [FATAL ERROR] Container realm = plexus.core
> urls[0] =
> file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.IncompatibleClassChangeError
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
> at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.Defaul
[jira] Commented: (MNG-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126496
]
John Casey commented on MNG-3438:
-
looks like plexus-archiver could use an exclusion on plexus-component-api,
probably, but not sure. The incompatible class is almost certainly the Logger
defined in plexus-component-api.
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Vincent Massol
> Fix For: 2.0.9
>
>
> This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Platform - Applications - Selenium
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
> [INFO] [remote-resources:process {execution: xwiki-license-resources}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] Attempting to build MavenProject instance for Artifact
> (com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
> type: maven-plugin; constructing POM artifact instead.
> [INFO] [xwiki-xar:xar]
> [INFO] Generating package.xml descriptor at
> [/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
> [FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
> (java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
> urls[0] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
> urls[3] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
> urls[4] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
> urls[5] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
> urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
> urls[7] =
> file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> [FATAL ERROR] Container realm = plexus.core
> urls[0] =
> file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.IncompatibleClassChangeError
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
> at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.e
[jira] Commented: (MNG-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126497
]
John Casey commented on MNG-3438:
-
the xar plugin could define an exclusion on
org.codehaus.plexus:plexus-component-api in its dependency on plexus-archiver
to achieve this.
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Vincent Massol
> Fix For: 2.0.9
>
>
> This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Platform - Applications - Selenium
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
> [INFO] [remote-resources:process {execution: xwiki-license-resources}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] Attempting to build MavenProject instance for Artifact
> (com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
> type: maven-plugin; constructing POM artifact instead.
> [INFO] [xwiki-xar:xar]
> [INFO] Generating package.xml descriptor at
> [/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
> [FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
> (java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
> urls[0] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
> urls[3] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
> urls[4] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
> urls[5] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
> urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
> urls[7] =
> file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> [FATAL ERROR] Container realm = plexus.core
> urls[0] =
> file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.IncompatibleClassChangeError
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
> at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
>
[jira] Commented: (MNG-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126499
]
Brian Fox commented on MNG-3438:
The enforcer plugin can be used to detect these issues. I updated the pom like
below and it works (note i removed checkstyle because it wasn't building):
{noformat}
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
com.xpn.xwiki.platform.tools
xwiki-tools
8-SNAPSHOT
xwiki-xar-plugin
XWiki Platform - Tools - XAR Plugin
1.10-SNAPSHOT
maven-plugin
XWiki Platform - Tools - XAR Plugin
org.apache.maven
maven-plugin-api
2.0
org.apache.maven
maven-project
2.0.4
org.codehaus.plexus
plexus-archiver
1.0-alpha-9
org.codehaus.plexus
plexus-container-default
org.codehaus.plexus
plexus-component-api
org.codehaus.plexus
plexus-io
1.0-alpha-2
org.apache.maven
maven-model
2.0.4
org.apache.maven
maven-artifact
2.0
dom4j
dom4j
1.6.1
maven-enforcer-plugin
enforce
ensure-no-container-api
org.codehaus.plexus:plexus-component-api
The new containers are not
supported. You probably added a dependency that is missing the
exclusions.
true
{noformat}
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Vincent Massol
> Fix For: 2.0.9
>
>
> This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Platform - Applications - Selenium
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
> [INFO] [remote-resources:process {execution: xwiki-license-resources}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] Attempting to build MavenProject instance for Artifact
> (com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
> type: maven-plugin; constructing POM artifact instead.
> [INFO] [xwiki-xar:xar]
> [INFO] Generating package.xml descriptor at
> [/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
> [FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
> (java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
> urls[0] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
> urls[3] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
> urls[4] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
> urls[5] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
> urls[6] = file
[jira] Closed: (MNG-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MNG-3438.
--
Assignee: Vincent Massol
Resolution: Won't Fix
Fix Version/s: (was: 2.0.9)
This is an issue with the plexus archiver bringing in the wrong plexus
container dependencies
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Vincent Massol
>Assignee: Vincent Massol
>
> This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Platform - Applications - Selenium
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
> [INFO] [remote-resources:process {execution: xwiki-license-resources}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] Attempting to build MavenProject instance for Artifact
> (com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
> type: maven-plugin; constructing POM artifact instead.
> [INFO] [xwiki-xar:xar]
> [INFO] Generating package.xml descriptor at
> [/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
> [FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
> (java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
> urls[0] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
> urls[3] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
> urls[4] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
> urls[5] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
> urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
> urls[7] =
> file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> [FATAL ERROR] Container realm = plexus.core
> urls[0] =
> file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.IncompatibleClassChangeError
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
> at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLife
[jira] Created: (MARTIFACT-10) Fix error handling for system-scoped artifacts
Fix error handling for system-scoped artifacts
--
Key: MARTIFACT-10
URL: http://jira.codehaus.org/browse/MARTIFACT-10
Project: Maven Artifact
Issue Type: Improvement
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: file-error-handling.patch
The current order of checking for error cases checks {{!File.isFile()}} before
{{!File.exists()}}. However, {{!File.isFile()}} might also fail if the file
does not exist at all, hence capturing the same case that is intended to be
captured by the later check with {{!File.exists()}}. The order needs to be
reversed to get the desired exception messages.
--
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-3394) Plugin versions inherited via cannot be overriden by . section of sub modules
[ http://jira.codehaus.org/browse/MNG-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3394. --- Resolution: Fixed Fixed, and IT is in place to keep it from coming back. > Plugin versions inherited via cannot be overriden by > . section of sub modules > > > Key: MNG-3394 > URL: http://jira.codehaus.org/browse/MNG-3394 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Assignee: John Casey >Priority: Critical > Fix For: 2.0.9 > > Attachments: plugin-management-version.zip > > > See the comments in the module POM of the attached demo project for more > explanation. -- 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: (DOXIA-229) Snippet macro works in SQL files
Snippet macro works in SQL files Key: DOXIA-229 URL: http://jira.codehaus.org/browse/DOXIA-229 Project: Maven Doxia Issue Type: Improvement Reporter: Manfred Moser Priority: Minor I just wanted to highlight that the snippet macro work in a SQL file like that -- START SNIPPET: projectid select * from project -- END SNIPPET: projectid It might be nice to have that added in terms of test coverage and documentation. http://maven.apache.org/doxia/macros/index.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] Closed: (MNG-2881) Improve logging when downloading snapshots in offline mode
[ http://jira.codehaus.org/browse/MNG-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2881. -- Resolution: Cannot Reproduce Everything seems ok with 2.0.9-SNAPSHOT in offline mode. > Improve logging when downloading snapshots in offline mode > -- > > Key: MNG-2881 > URL: http://jira.codehaus.org/browse/MNG-2881 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Jason van Zyl >Priority: Minor > Fix For: 2.0.9 > > > Even though the network is not touched we get logging output like this: > --->8--- > [INFO] snapshot > org.codehaus.plexus:plexus-appserver-maven-plugin:2.0-alpha-8-SNAPSHOT: > checking for updates from apache.snapshots > [DEBUG] System is offline. Cannot resolve metadata: > Repository Metadata > -- > GroupId: org.codehaus.plexus > ArtifactId: plexus-appserver-maven-plugin > Metadata Type: > org.apache.maven.artifact.repository.metadata.SnapshotArtifactRepositoryMetadata > --->8--- -- 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-3395) Default core plugin versions in the superpom.
[ http://jira.codehaus.org/browse/MNG-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126509 ] Brian Fox commented on MNG-3395: initial revision committed. Waiting for javadoc release before making this final. > Default core plugin versions in the superpom. > - > > Key: MNG-3395 > URL: http://jira.codehaus.org/browse/MNG-3395 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.9 > > > We should define the plugin versions for core and other common plugins (the > apache plugins is a good place to start) in the super pom in 2.0.x to help > with stability. > See here for more info. > http://www.nabble.com/Plugin-Versions-in-the-Super-pom-to15367074s177.html#a15367074 -- 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] Work started: (MNG-3395) Default core plugin versions in the superpom.
[ http://jira.codehaus.org/browse/MNG-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3395 started by Brian Fox. > Default core plugin versions in the superpom. > - > > Key: MNG-3395 > URL: http://jira.codehaus.org/browse/MNG-3395 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.9 > > > We should define the plugin versions for core and other common plugins (the > apache plugins is a good place to start) in the super pom in 2.0.x to help > with stability. > See here for more info. > http://www.nabble.com/Plugin-Versions-in-the-Super-pom-to15367074s177.html#a15367074 -- 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: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126511 ] gotama commented on MIDEA-102: -- http://cygwin.com/setup.exe ... just click through 'next' on everything and get the basic install. quick easy setup... beats the windows prompt for those on the corporate XP system! :) > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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] Reopened: (MNG-2881) Improve logging when downloading snapshots in offline mode
[ http://jira.codehaus.org/browse/MNG-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-2881: --- Assignee: Brett Porter > Improve logging when downloading snapshots in offline mode > -- > > Key: MNG-2881 > URL: http://jira.codehaus.org/browse/MNG-2881 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Jason van Zyl >Assignee: Brett Porter >Priority: Minor > Fix For: 2.0.9 > > > Even though the network is not touched we get logging output like this: > --->8--- > [INFO] snapshot > org.codehaus.plexus:plexus-appserver-maven-plugin:2.0-alpha-8-SNAPSHOT: > checking for updates from apache.snapshots > [DEBUG] System is offline. Cannot resolve metadata: > Repository Metadata > -- > GroupId: org.codehaus.plexus > ArtifactId: plexus-appserver-maven-plugin > Metadata Type: > org.apache.maven.artifact.repository.metadata.SnapshotArtifactRepositoryMetadata > --->8--- -- 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-2881) Improve logging when downloading snapshots in offline mode
[ http://jira.codehaus.org/browse/MNG-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2881. - Resolution: Fixed actually I fixed this as part of my recent changes to the metadata handling > Improve logging when downloading snapshots in offline mode > -- > > Key: MNG-2881 > URL: http://jira.codehaus.org/browse/MNG-2881 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Jason van Zyl >Assignee: Brett Porter >Priority: Minor > Fix For: 2.0.9 > > > Even though the network is not touched we get logging output like this: > --->8--- > [INFO] snapshot > org.codehaus.plexus:plexus-appserver-maven-plugin:2.0-alpha-8-SNAPSHOT: > checking for updates from apache.snapshots > [DEBUG] System is offline. Cannot resolve metadata: > Repository Metadata > -- > GroupId: org.codehaus.plexus > ArtifactId: plexus-appserver-maven-plugin > Metadata Type: > org.apache.maven.artifact.repository.metadata.SnapshotArtifactRepositoryMetadata > --->8--- -- 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: (DOXIA-144) Review signature methods
[ http://jira.codehaus.org/browse/DOXIA-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126522 ] Lukas Theussl commented on DOXIA-144: - I did a first clean-up in r634855, please check if there's anything specific left, otherwise I'd like to close this as 'too generic'. > Review signature methods > > > Key: DOXIA-144 > URL: http://jira.codehaus.org/browse/DOXIA-144 > Project: Maven Doxia > Issue Type: Improvement > Components: Core, Modules >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Siveton > Fix For: 1.0-beta-1 > > > Severals methods are public instead of private -- 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: (DOXIA-229) Snippet macro works in SQL files
[ http://jira.codehaus.org/browse/DOXIA-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-229. --- Assignee: Lukas Theussl Resolution: Won't Fix Thanks for pointing this out, however, the snippet macro actually works independently of the file type, you can use it on any type of file. All you have to do is put the start/end demarcators into a comment specific to the file. The current documentation in svn trunk explains this better than the published site (http://svn.apache.org/viewvc/maven/doxia/site/src/site/apt/macros/index.apt?view=log), I don't think it's necessary to document/test every specific case. > Snippet macro works in SQL files > > > Key: DOXIA-229 > URL: http://jira.codehaus.org/browse/DOXIA-229 > Project: Maven Doxia > Issue Type: Improvement >Reporter: Manfred Moser >Assignee: Lukas Theussl >Priority: Minor > > I just wanted to highlight that the snippet macro work in a SQL file like that > -- START SNIPPET: projectid > select * from project > -- END SNIPPET: projectid > It might be nice to have that added in terms of test coverage and > documentation. > http://maven.apache.org/doxia/macros/index.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: (MNG-3449) direct invocation of plugin after lifecycle calls that build it causes lifecycle-planning problem
direct invocation of plugin after lifecycle calls that build it causes lifecycle-planning problem - Key: MNG-3449 URL: http://jira.codehaus.org/browse/MNG-3449 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.1-alpha-1 Reporter: John Casey Attachments: maven-find-local-repo-plugin.zip When you run a plugin build using something like: maven-foo-plugin$ mvn clean install foo:bar Maven fails to construct a build plan for this build, since it cannot resolve the prefix for the 'foo' plugin. We need to allow this to fail during build-planning, then do another late-bound approach to resolve the prefix and run the mojo. I'm attaching a test plugin for this. -- 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-3450) build planning may fail to find forked executions on late-bound plugins
build planning may fail to find forked executions on late-bound plugins --- Key: MNG-3450 URL: http://jira.codehaus.org/browse/MNG-3450 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.1-alpha-1 Reporter: John Casey When a plugin cannot be located during the build-planning part of the build (which happens before any of the plugins execute), that plugin's resolution is deferred until the first time it's run in the build. Right before the plugin is scheduled to run, a special internal state-management mojo is executed to retry plugin resolution. If that fails, the build fails. However, we need to be sure that plugins that are late-bound in this way and that specify forked executions of one type or another have their forked executions included in the build. This would be the first case of a mojo modifying the build plan in which it is executing (to inject a forked execution ahead of the next mojo to run, which is the one that was late-bound). -- 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-3450) build planning may fail to find forked executions on late-bound plugins
[ http://jira.codehaus.org/browse/MNG-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126530 ] John Casey commented on MNG-3450: - steps to reproduce: 1. create a basic plugin using archetype 2. Make sure the mojo in this plugin specifies '@execute phase="site"' or something similar, such that its maximum phase will not be satisfied yet by 'clean install' 3. make sure that plugin doesn't exist in any way in the repositories (either local or remote) 4. execute the following (making sure the last mojo invocation is fully qualified): mvn clean install org.plugin:my-maven-plugin:1.0-SNAPSHOT:touch Since the plugin isn't resolvable from any repository, the build planner should assign the last task to a late-bound state-management mojo, which will run second-to-last in the build order. Before the test mojo runs, the site phase should be executed, making it possible to check for some basic site files in the target directory, and fail the build if they are missing. I'll write a test plugin for this when I get a chance, but these steps should show the potential problem, if it exists. > build planning may fail to find forked executions on late-bound plugins > --- > > Key: MNG-3450 > URL: http://jira.codehaus.org/browse/MNG-3450 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 >Reporter: John Casey > > When a plugin cannot be located during the build-planning part of the build > (which happens before any of the plugins execute), that plugin's resolution > is deferred until the first time it's run in the build. Right before the > plugin is scheduled to run, a special internal state-management mojo is > executed to retry plugin resolution. If that fails, the build fails. > However, we need to be sure that plugins that are late-bound in this way and > that specify forked executions of one type or another have their forked > executions included in the build. This would be the first case of a mojo > modifying the build plan in which it is executing (to inject a forked > execution ahead of the next mojo to run, which is the one that was > late-bound). -- 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-2861) NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions.
[ http://jira.codehaus.org/browse/MNG-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2861: --- Fix Version/s: (was: 2.0.x) 2.0.9 putting this to 2.0.9 so I remember to look again. > NullPointerException in DefaultArtifactCollector for relocated > resolvedArtifacts with different version ranges and available versions. > -- > > Key: MNG-2861 > URL: http://jira.codehaus.org/browse/MNG-2861 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Micah Whitacre > Fix For: 2.0.9 > > Attachments: MNG-2861-maven-project.patch, MNG-2861.tar.gz, > MNG-2861_broken.zip > > > In a remoteRepository that I am populating I have a project. Previously I > was deploying artifacts with an old groupId and then decided to switch to > having a new more descriptive groupId. For the old groupId I have deployed > versions 1.0 and 1.1. For the new groupId I have deployed 1.2 and 2.0. I > deployed a relocation POM to the old groupId for the 1.2 version. I also > updated the metadata.xml files to include 1.2 as an available version. This > way projects using version ranges [1,2) will be able to pick up the newest > version. So in the repository I now have: > oldgroupId:project:1.0 > oldgroupId:project:1.1 > oldgroupId:project:1.2 - redirecting to newgroupId:project:1.2 > newgroupId:project:1.2 > newgroupId:project:2.0 > The oldgroupId's metadata lists the available versions as [1.0,1.1,1.2]. The > newgroupId's metadata lists the available versions has [1,2]. > I have 3 additional projects A, B, C. A depends on B and C. B depends on > oldgroupId:project:[1,2). Project B has also finished development and been > released so we are avoiding rereleasing it for the groupId change. C > depends on newgroupId:project:[2,3). When I try to build project A, Maven > dies and gives me the following stack trace. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [DEBUG] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:168) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1142) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:374) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds
[jira] Updated: (MNG-2010) Add new lifecycle phases for IT
[ http://jira.codehaus.org/browse/MNG-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2010: --- Fix Version/s: (was: 2.0.x) 2.1 I think we've decided in the past not to add new phases, i'm tempted to close this but at a minimum it should go to 2.1 > Add new lifecycle phases for IT > --- > > Key: MNG-2010 > URL: http://jira.codehaus.org/browse/MNG-2010 > Project: Maven 2 > Issue Type: Task > Components: integration tests, Plugins and Lifecycle >Reporter: Vincent Massol > Fix For: 2.1 > > Attachments: MNG-2010-maven-lifecycle.patch, MNG-2010-site.patch > > > Namely: > * generate-integration-test-sources > * process-integration-test-sources > * generate-integration-test-resources > * process-integration-test-resources > * integration-test-compile > and possibly a: > * integration-test-package -- 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-2570) Maven needs to support multiple logging levels
[ http://jira.codehaus.org/browse/MNG-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2570: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 > Maven needs to support multiple logging levels > -- > > Key: MNG-2570 > URL: http://jira.codehaus.org/browse/MNG-2570 > Project: Maven 2 > Issue Type: Improvement > Components: Logging >Affects Versions: 2.0.4 >Reporter: Brian Fox > Fix For: 2.1 > > > The current logging levels are essentially verbose (default) and debug (-X). > We need a slightly less verbose output so that things like compiler warnings > and other output is actually visable to the developer. Currently it gets > buried in all the noise. -- 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-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[
http://jira.codehaus.org/browse/MNG-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126536
]
Brian Fox commented on MNG-2456:
Can someone produce an IT for this?
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Barrie Treloar
>Assignee: Kenney Westerhof
> Fix For: 2.0.x
>
> Attachments: MNG-2456-maxb.patch, MNG-2456-patch.txt,
> MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
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-2431) Make it possible to specify that version should be the LATEST STABLE available
[ http://jira.codehaus.org/browse/MNG-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2431. -- Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) We don't really recommend even using LATEST or RELEASE as they introduce enough instability to prevent true reproducibility. The lastest stable is impossible to define. > Make it possible to specify that version should be the LATEST STABLE available > -- > > Key: MNG-2431 > URL: http://jira.codehaus.org/browse/MNG-2431 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Jimisola Laursen > > Hi! > I've been looking for a way to specify that the latest STABLE version of a > library (dependency) should be used automatically. However, I can't seem to > find any information on this. Is this not possible? The "Dependency Version > Ranges" doesn't solve the problem for me since it sets with the lowest > version satisfying the range. > This guy had the same question about a year ago, but it doesn't look > promising: > http://www.nabble.com/newbie-ques%3A-downloading-latest-stable-jars-t74577.html#a202750 > I asked the same question is this thread: > http://www.nabble.com/How-to-get-the-latest-STABLE-version-of-a-library-dependency-automatical-tf1851718.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] Updated: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[
http://jira.codehaus.org/browse/MNG-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2456:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.0.x
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Barrie Treloar
>Assignee: Kenney Westerhof
> Fix For: 2.0.x
>
> Attachments: MNG-2456-maxb.patch, MNG-2456-patch.txt,
> MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
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-2742) Using a version range in a plugin dependency causes "failure to resolve artifact" error
[ http://jira.codehaus.org/browse/MNG-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2742: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 > Using a version range in a plugin dependency causes "failure to resolve > artifact" error > --- > > Key: MNG-2742 > URL: http://jira.codehaus.org/browse/MNG-2742 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: Windows XP SP2, java version "1.5.0_08" >Reporter: Matthew Adams > Fix For: 2.1 > > Attachments: mvn.txt, pom.xml > > > If I declare a dependency in a plugin using an exact version, Maven correctly > resolves the artifact. If, however, I change the dependency's version to a > version range, Maven no longer resolves the artifact. I'm using the very > same artifact and version range in my project's dependencies and everything > works ok. See my attached pom.xml file for details, in particular, the > comments "" and "". > I am using the "major.minor.revision-buildNumber" version string syntax as > described on the wiki. -- 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-2694) property in plugin dependency's systemPath is not resolved and causes "system-scoped dependency must specify an absolute path systemPath."
[
http://jira.codehaus.org/browse/MNG-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2694:
---
Affects Version/s: 2.0.11
> property in plugin dependency's systemPath is not resolved and causes
> "system-scoped dependency must specify an absolute path systemPath."
> --
>
> Key: MNG-2694
> URL: http://jira.codehaus.org/browse/MNG-2694
> Project: Maven 2
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 2.0.4, 2.0.5
>Reporter: Willie Vu
> Fix For: 2.0.11
>
>
> In a plugin pom.xml,
>
> weblogic
> weblogic
> [9.0,)
> system
> ${wl.home}/server/lib/weblogic.jar
>
> In ~/.m2/setting.xml,
>
>
>
> weblogicConfig
>
>
>
>
> c:/java/bea-9.2/weblogic92
>
>
>
>
> weblogicConfig
>
>
> When build the plugin, it works fine.
> In a project that uses this plugin, when build, it causes the following error:
> Project ID: org.codehaus.mojo:weblogic-maven-plugin
> POM Location: Artifact
> [org.codehaus.mojo:weblogic-maven-plugin:pom:2.9.0-SNAPSHOT]
> Validation Messages:
> [0] For dependency Dependency {groupId=weblogic, artifactId=weblogic,
> version=[9.0,), type=jar}: system-scoped dependency must specify an absolute
> path systemPath.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2694) property in plugin dependency's systemPath is not resolved and causes "system-scoped dependency must specify an absolute path systemPath."
[
http://jira.codehaus.org/browse/MNG-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2694:
---
Affects Version/s: (was: 2.0.11)
2.0.5
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.0.11
> property in plugin dependency's systemPath is not resolved and causes
> "system-scoped dependency must specify an absolute path systemPath."
> --
>
> Key: MNG-2694
> URL: http://jira.codehaus.org/browse/MNG-2694
> Project: Maven 2
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 2.0.4, 2.0.5
>Reporter: Willie Vu
> Fix For: 2.0.11
>
>
> In a plugin pom.xml,
>
> weblogic
> weblogic
> [9.0,)
> system
> ${wl.home}/server/lib/weblogic.jar
>
> In ~/.m2/setting.xml,
>
>
>
> weblogicConfig
>
>
>
>
> c:/java/bea-9.2/weblogic92
>
>
>
>
> weblogicConfig
>
>
> When build the plugin, it works fine.
> In a project that uses this plugin, when build, it causes the following error:
> Project ID: org.codehaus.mojo:weblogic-maven-plugin
> POM Location: Artifact
> [org.codehaus.mojo:weblogic-maven-plugin:pom:2.9.0-SNAPSHOT]
> Validation Messages:
> [0] For dependency Dependency {groupId=weblogic, artifactId=weblogic,
> version=[9.0,), type=jar}: system-scoped dependency must specify an absolute
> path systemPath.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2640) Expressions in POMs are not modified when the Maven Project is updated
[
http://jira.codehaus.org/browse/MNG-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2640:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1
> Expressions in POMs are not modified when the Maven Project is updated
> --
>
> Key: MNG-2640
> URL: http://jira.codehaus.org/browse/MNG-2640
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Vincent Massol
> Fix For: 2.1
>
> Attachments: MNG-2640.diff
>
>
> In the Clover plugin I'm modifying the finalName with:
> {code:java}
> getProject().getBuild().setFinalName( getProject().getArtifactId() + "-" +
> getProject().getVersion() + "-clover" );
> {code}
> This works fine and all subsequent plugins using the MavenProject object do
> work fine. However if the user uses, say, the AntRun plugin and uses the
> ${project.build.fineName} expression in his POM it'll return the original
> value and not the one modified by the Clover plugin. For example if the user
> is using the AntRun plugin combined with xdoclet Ant tasks to generate files,
> they won't be put in the correct target directories when used with the Clover
> plugin and the build will fail...
> See http://jira.codehaus.org/browse/MCLOVER-59 for an issue filed against the
> Clover plugin on this.
> I think we need a way for reevaluating interpolated expressions when the
> model is changed.
> Thanks
> -Vincent
--
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-2485) Profile compiler plugin configuration not inherited
[ http://jira.codehaus.org/browse/MNG-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2485. -- Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) A parent's profiles are not inherited, however the effect of activating that profile is inherited. There are some proposals for 2.1 to make this behavior more flexible. > Profile compiler plugin configuration not inherited > --- > > Key: MNG-2485 > URL: http://jira.codehaus.org/browse/MNG-2485 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.4 > Environment: Windows XP, 2K >Reporter: Olivier Pichon > > Compiler plugin configuration in parent pom profile is ignored by child pom. > Parent pom includes a profile which sets the compiler plugin's source and > target settings to 1.5: > > ... > > > test > > > test > true > > > > > > true > org.apache.maven.plugins > maven-compiler-plugin > > 1.5 > 1.5 > > > > > > > > When running the test-compile phase on a child pom, the profile is ignored. > Maven complains about annotations not being allowed with -source=1.3. > This occurs when the profile is activated eitherwith the -Ptest or with the > -Dtest=true CLI parameters. > The above configuration works perfectly well when the element is > copied/pasted to the child pom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2398) attached artifacts (such as assemblies) are not resolved in the workspace when running 'package' phase
[ http://jira.codehaus.org/browse/MNG-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2398: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.11 > attached artifacts (such as assemblies) are not resolved in the workspace > when running 'package' phase > -- > > Key: MNG-2398 > URL: http://jira.codehaus.org/browse/MNG-2398 > Project: Maven 2 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0.4 > Environment: Running of Mac OSX 10.4 >Reporter: Matt Brozowski >Priority: Blocker > Fix For: 2.0.11 > > Attachments: attached-artifact-bug.tar.gz, > maven-project-2.0.4-patch.txt > > > I have attached a sample project. > submoduleA creates an attached artifact (a tar.gz assembly) which submoduleB > depends on. > When running: > mvn package > The attached artifact cannot be resolved from the workspace but tries the > repos instead, yet when running: > > This problems makes using attached artifacts very 'risky' because it could be > running 'old' 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: (MNG-3042) Extending a Mojo Class and used in a new Mojo Project, parameter fields in the parent mojo are not set, this disables reuse of existing mojo project.
[ http://jira.codehaus.org/browse/MNG-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3042: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 inheriting mojos across plugins is not currently supported. We should consider for 2.1 > Extending a Mojo Class and used in a new Mojo Project, parameter fields in > the parent mojo are not set, this disables reuse of existing mojo project. > - > > Key: MNG-3042 > URL: http://jira.codehaus.org/browse/MNG-3042 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API >Reporter: Leopoldo Agdeppa III > Fix For: 2.1 > > > I have an Existing maven-plugin-a and I want to extend its functionality and > put it in maven-plugin-b, so what i did is I put the the maven-plugin-a as a > dependecy in maven-plugin-b and extended the mojo class from A, the issue on > this is that paramter fields from A is not set, when I used plugin-B, I think > this disables reusing and extending of mojos -- 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-2626) System scope dependencies in parent POM cause validation warnings for most plugins and errors in assembly plugin
[
http://jira.codehaus.org/browse/MNG-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2626:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.0.11
> System scope dependencies in parent POM cause validation warnings for most
> plugins and errors in assembly plugin
>
>
> Key: MNG-2626
> URL: http://jira.codehaus.org/browse/MNG-2626
> Project: Maven 2
> Issue Type: Bug
> Components: Errors
>Affects Versions: 2.0-alpha-1
>Reporter: Brian Topping
>Assignee: Jason van Zyl
>Priority: Blocker
> Fix For: 2.0.11
>
> Attachments: interpolation-good.patch, interpolation.patch,
> MNG-2626it.tgz
>
>
> When system scope dependencies are in a parent POM and the systemPath for
> those variables contain a variable to be interpolated as a root path, maven
> throws off a lot of spurious warnings that the POM does not validate because
> system paths need to be absolute. An example of this in a parent POM (where
> ${jboss.home} is defined in ~/.m2/settings.xml):
> {code:xml}
>
> jboss
> activation
> 4.0.4.GA
> system
>
> ${jboss.home}/server/default/lib/activation.jar
>
> {code}
> In discussing this with John and Jason online, both apparently have generic
> implementations that can go in at some point, but this is something I would
> like to get into 2.0.5. The patch is ~25 lines of new code with one
> replaced.
> It's marked as blocker because we use the assembly plugin, which fails the
> build on the validation problem where most other plugins just enumerate every
> system scope dependency. For now, I will distribute the patched version
> around the company though :-)
> thanks
--
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-2972) Ignores version of plugin dependency specified in my pom
[ http://jira.codehaus.org/browse/MNG-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2972: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.9 I think this was fixed already. Check in 2.0.9 > Ignores version of plugin dependency specified in my pom > > > Key: MNG-2972 > URL: http://jira.codehaus.org/browse/MNG-2972 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: maven 2.0.6, java version "1.5.0_07" >Reporter: Derek Alexander >Priority: Critical > Fix For: 2.0.9 > > > xmlbeans-maven-plugin declares a dependency on xmlbeans-2.0.0 > I want to use xmlbeans-2.2.0 > So in my pom I put: > > org.codehaus.mojo > xmlbeans-maven-plugin > > > > xmlbeans > > > > > ... > > > > xmlbeans > xbean > 2.2.0 > > >But it still downloads 2.0.0. (as well as 2.2.0). Haven't got a clue which it > is using as it doesn't seem to output stuff like that. Couldn't see a verbose > or debug switch mentioned in the docs. Anyway I think it is still using 2.0.0. > Seems like I'm not the first to experience this: > http://www.nabble.com/Override-plugin-dependency-version-tf2357806s177.html#a6568092 > Apparently this should be possible: http://maven.apache.org/pom.html#plugins > "dependencies: Dependencies are seen a lot within the POM, and are an element > under all plugins element blocks. The dependencies have the same structure > and function as under that base build. The major difference in this case is > that instead of applying as dependencies of the project, they now apply as > dependencies of the plugin that they are under. The power of this is to alter > the dependency list of a plugin, perhaps by removing an unused runtime > dependency via exclusions, or by altering the version of a required > dpendency. See above under Dependencies for more information." -- 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-2562) expose current time as a property for POM interpolation
[ http://jira.codehaus.org/browse/MNG-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2562: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 > expose current time as a property for POM interpolation > --- > > Key: MNG-2562 > URL: http://jira.codehaus.org/browse/MNG-2562 > Project: Maven 2 > Issue Type: New Feature > Components: Inheritance and Interpolation >Reporter: Brett Porter > Fix For: 2.0.10 > > > it is useful to have the current time, for example to write out a manifest > entry for the build time or to filter into another file. > I'm not sure of the best way to make the format of the time configurable - > perhaps another POM element/property. > See the related issue for a current example of how this can be done, but it > would be nice to have a built-in. -- 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-3033) DependencyManagement override version if declared in child
[ http://jira.codehaus.org/browse/MNG-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3033: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 > DependencyManagement override version if declared in child > -- > > Key: MNG-3033 > URL: http://jira.codehaus.org/browse/MNG-3033 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.5, 2.0.6 >Reporter: hugo lassiege > Fix For: 2.0.10 > > > Hi, > I'm currently in maven 2.0.5 but I tried in 2.0.6 > If I declare a dependency in a father pom within a dependencyManagement like > this : > > A > A > 1.0 > > and if I want to override the version in the child : > > A > A > 1.1 > > I get the version 1.0. It seems it was already reported in this issue : > http://jira.codehaus.org/browse/MNG-1577 but was not the main purpose and was > not fixed. > Regards. -- 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-2366) child-level transitive dependency builds (http://www.mail-archive.com/[EMAIL PROTECTED]/msg32502.html)
[ http://jira.codehaus.org/browse/MNG-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2366. -- Resolution: Duplicate Fix Version/s: (was: Reviewed Pending Version Assignment) > child-level transitive dependency builds (http://www.mail-archive.com/[EMAIL > PROTECTED]/msg32502.html) > --- > > Key: MNG-2366 > URL: http://jira.codehaus.org/browse/MNG-2366 > Project: Maven 2 > Issue Type: Wish > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Hung Le >Priority: Minor > > I did not a JIRA for this. > My wish list: Maven will implement what being outline in this discussion: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg32502.html > -- > [m2] child-level transitive dependency builds? > Christopher Cobb > Tue, 10 Jan 2006 08:15:54 -0800 > Is it expected/preferred that (all?) builds are normally be done from the > top level? It doesn't seem that this works very well for situations where I > have a specific plugin which should only be used for certain children. Even > if I configure the plugin at the top level, it may not make sense/not work > to invoke it on all the children. So I have been changing into the > appropriate child directories to invoke some plugins, which leads to also > doing iterative builds in those child directories. > > If it is expected that we will occasionally/frequently change into child > project to invoke parts of the build (like I do now), then it seems like > child-level builds should do transitive build dependency resolution. So if > I am doing a build in P1, and P1 has some dependencies on P4, and something > in P4 has changed, then P4 should also get built/installed when I am > building P1. It seems like this could be done by adding something like a > tag within each for which you would > like build-time transitive dependency resolution. Or, I suppose it could > also be figured out by navigating to the parent pom and examining the > children. Then you could figure out which dependencies are actually > "project siblings" and should be "transitively built". > > It looks like sometimes/frequently you need to do child-level builds, and > you may want/need dependent "project siblings" to be build when you do so. > > Is there a way to handle this now? Is this an enhancement request? > -- -- 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-3038) Transitive DepMan not working (per MNG-1577) [use case attached]
[
http://jira.codehaus.org/browse/MNG-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3038:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1-alpha-1
Component/s: (was: Dependencies)
Artifacts and Repositories
> Transitive DepMan not working (per MNG-1577) [use case attached]
>
>
> Key: MNG-3038
> URL: http://jira.codehaus.org/browse/MNG-3038
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.5, 2.0.6
>Reporter: Joakim Erdfelt
>Assignee: Patrick Schneider
> Fix For: 2.1-alpha-1
>
> Attachments: carlos_transitive_version.tar.gz
>
>
> When working with the example use case described by Carlos on the MNG-1577
> thread.
> http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html
> {noformat}
> What about this use case for transitive dependencyManagement? has been tested?
> A -> B -> C -> D
> C depends on D 1.0
> B has D 2.0 in dependencyManagement, no D in dependencies
> A should get D 2.0
> {noformat}
> It was discovered that this does not work.
> Sample Project / Use Case is attached. (655 bytes)
--
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-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[ http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2962: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 > (False) transitive dependencies don't appear on the compiler classpath in > some windows environments since m2.0.6. > - > > Key: MNG-2962 > URL: http://jira.codehaus.org/browse/MNG-2962 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: windows >Reporter: Geoffrey De Smet > Fix For: 2.0.10 > > Attachments: m2.0.6-failing-compile-machineC.log, > m2.0.6-working-compile-machineB.log > > > Since m2.0.6 builds that work perfectly on linux machine A and sometimes even > on a windows machine B, breaks on another windows machine C. > We have some "false transitive dependencies": transitive dependencies that > should be direct dependencies. > (We currently do this to avoid having to duplicate the version number as the > different projects don't have a common superpom.) > Making those dependencies direct dependencies fixes the problem with windows > machine C, but the real problem is that the guy on linux machine A should get > the problems too, before committing. > The compiler plugin version is locked down to 2.0.2, but are using maven > 2.0.6. This did not occur in maven 2.0.5. > Attached you'll find the "mvn -X install" logs of the 2 windows machines. > The log of machine C is specifically interesting, as it shows > "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the > classpath in the compiler plugin: > [DEBUG] Adding managed depedendencies for unknown:atlas-spring > ... > [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile > ... > [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes > .. (no org.springframework:spring-beans:jar:2.0.2) > Machine B instead has instead this at the classpath log part: > [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes > ... > C:\Documents and > Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.jar -- 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-2888) Written pom doesn't conserve element attributes
[ http://jira.codehaus.org/browse/MNG-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2888. -- Resolution: Cannot Reproduce Fix Version/s: (was: Reviewed Pending Version Assignment) pretty sure this was fixed eons ago. > Written pom doesn't conserve element attributes > --- > > Key: MNG-2888 > URL: http://jira.codehaus.org/browse/MNG-2888 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.0-alpha-1 > Environment: Maven 2 Eclipse plugin 0.0.11 (latest from SVN, revision > 230) using the following jars: > lucene-core-2.0.0.jar > maven-embedder-2.1.0.v20070302-2248-dep.jar >Reporter: Arnaud Daroussin > > MavenEmbedder writeModel method rewrite pom without element attributes. > It appears that the error is due to MavenJDOMWriter. > The case happen when I use maven-antrun-plugin because ant tasks required > often attributes, and when I add a dependency, Maven 2 Eclipse plugin rewrite > pom file using this annoying writeModel method... -- 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-2815) Parent POM defined profile dependencyManagement dependency version overrides child pom explicit dependency
[ http://jira.codehaus.org/browse/MNG-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2815. -- Resolution: Cannot Reproduce Fix Version/s: (was: Reviewed Pending Version Assignment) > Parent POM defined profile dependencyManagement dependency version overrides > child pom explicit dependency > -- > > Key: MNG-2815 > URL: http://jira.codehaus.org/browse/MNG-2815 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.4 > Environment: jdk 1.6 > mvn 2.0.4 > windows 2000 >Reporter: Peter Lynch > > 1. Create parent pom with a profile activated on the jdk you are running > maven with > Inside the profile define a dependencyManagement/dependency to a jar > explicitly stating a version. Assume in this example it is version 1.0 > 2. Create a child pom defining parent in step 1 as parent. In this child, > define an explicit dependencies/dependency with the same artifactId and > groupId as that profile/dependencyManagement/dependency defined in parent > pom. Only difference being that in the child, the dependency version is set > to 2.0. > 3. Run mvn site and look at teh dependency report. The dependency report > indicates the version of the dependency to be 1.0 ( the one defined in the > parent pom profile. > Expected behavior is that the explicit dependency defined in child should > take precedence. -- 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-3377) Build reactor from toplevel pom
[ http://jira.codehaus.org/browse/MNG-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3377. -- Resolution: Duplicate > Build reactor from toplevel pom > --- > > Key: MNG-3377 > URL: http://jira.codehaus.org/browse/MNG-3377 > Project: Maven 2 > Issue Type: Improvement >Reporter: Jörg Hohwiller > > The following is all about multi-project environments. > For many maven calls the result differs if you perform you mvn command on the > toplevel project > or in a specific module. In the latter case the related modules of the > projects are not included in the reactor > causing the result to be invalid or the build to fail. > There should be a way that I can call maven within a particular module > causing the reactor > to be build from the toplevel pom while walking the relativePath (defaults to > ../pom.xml) upwards > until a pom is reached, that has no parent. From that pom the reactor should > be build, > while the actual build should work on the module where maven was invoked. > A typical example use-case would be the command "mvn eclipse:eclipse". > Right now it does not create project-internal dependencies if it is called > within the module. This is especially nasty when you have a local sandbox > module that should not (yet) be committed. Then you always need to add it > as extra module to your parent pom, call eclipse:eclipse and then revert the > changed pom. > Additional use-cases are that you want to build a specific module rather than > the entire project. Right now you need to enter the module, give "mvn > install" a try. > If it fails, you will see which dependency is missing. Then you go there > before > and try "mvn install" there. This process is iterated until the first "mvn > install" completes. > This is very inconvenient. However fixing such problems as well would > cause that not only the modules are added to the reactor but that the actual > mvn call > is also applied to the dependend modules that are in the reactor. > This specific issue might need some extra discussion... > For reasons of compatibility the suggested improvement could/should be > activated by a specific commandline option (somehow the opposite of "-N"). > A suggestion would be "-R" for reactor and recursive. -- 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-3301) is there any problems with proxy i tried every thing with settings.xml i dont why it happening like this we have to fix this issue
[ http://jira.codehaus.org/browse/MNG-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126541 ] Brian Fox commented on MNG-3301: please make a sample project we can use to test this. > is there any problems with proxy i tried every thing with settings.xml i dont > why it happening like this we have to fix this issue > -- > > Key: MNG-3301 > URL: http://jira.codehaus.org/browse/MNG-3301 > Project: Maven 2 > Issue Type: Task > Components: Command Line >Affects Versions: 2.0.7 >Reporter: vamsikrishna > Fix For: Reviewed Pending Version Assignment > > > org.apache.maven.lifecycle.LifecycleExecutionException: Missing: > -- > 1) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.wagon > -DartifactId=wagon-webdav \ > -Dversion=1.0-beta-2 -Dpackaging=jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=org.apache.maven.wagon > -DartifactId=wagon-webdav \ > -Dversion=1.0-beta-2 -Dpackaging=jar -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.intralinks.qa:qc-super-pom:pom:1.2-SNAPSHOT > 2) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 -- 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-3301) is there any problems with proxy i tried every thing with settings.xml i dont why it happening like this we have to fix this issue
[ http://jira.codehaus.org/browse/MNG-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3301: --- Fix Version/s: Reviewed Pending Version Assignment > is there any problems with proxy i tried every thing with settings.xml i dont > why it happening like this we have to fix this issue > -- > > Key: MNG-3301 > URL: http://jira.codehaus.org/browse/MNG-3301 > Project: Maven 2 > Issue Type: Task > Components: Command Line >Affects Versions: 2.0.7 >Reporter: vamsikrishna > Fix For: Reviewed Pending Version Assignment > > > org.apache.maven.lifecycle.LifecycleExecutionException: Missing: > -- > 1) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.wagon > -DartifactId=wagon-webdav \ > -Dversion=1.0-beta-2 -Dpackaging=jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=org.apache.maven.wagon > -DartifactId=wagon-webdav \ > -Dversion=1.0-beta-2 -Dpackaging=jar -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.intralinks.qa:qc-super-pom:pom:1.2-SNAPSHOT > 2) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 -- 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-3196) Allow exclusion of a certain transitive dependency across all direct dependencies.
[ http://jira.codehaus.org/browse/MNG-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3196: --- Fix Version/s: 2.1 > Allow exclusion of a certain transitive dependency across all direct > dependencies. > -- > > Key: MNG-3196 > URL: http://jira.codehaus.org/browse/MNG-3196 > Project: Maven 2 > Issue Type: New Feature > Components: Dependencies >Affects Versions: 2.0.7 >Reporter: Paul Gier >Assignee: Brett Porter > Fix For: 2.1 > > > I would like to be able to put exludes at the top level of dependencies so > that it can easily be excluded from all transitive dependencies, instead of > just excluding it from a single dependency at a time. For example assume > that project1 and project2 both have transitive dependencies on different > versions of project-trans: > > > > com.stuff > project-trans > > > > com.stuff > project1 > 1.0 > > > com.stuff > project2 > 1.0 > > > In this example, the "project-trans" dependency would be exluded from both > project1 and project2. It can be difficult to find all the locations of a > transitively included dependency for a large project that has a large number > of frequently changing dependencies. -- 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-3383) Downloaded plugin dependencies influence project dependencies
[
http://jira.codehaus.org/browse/MNG-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3383:
---
Fix Version/s: 2.0.10
> Downloaded plugin dependencies influence project dependencies
> -
>
> Key: MNG-3383
> URL: http://jira.codehaus.org/browse/MNG-3383
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies, Plugins and
> Lifecycle
>Affects Versions: 2.0.8
>Reporter: Stefan Seidel
> Fix For: 2.0.10
>
> Attachments: pom.xml
>
>
> Currently, a plugin may define additional pluginRepositories, which are used
> to resolve dependencies of that plugin.
> This leads to the fact that a plugin might resolve a dependency which would
> normally not be available to the project.
> When it does that, it seems to write a metadata-central (although on the
> central repo this artifact does not exist) and thus, the project will use
> that dependency, too.
> How to reproduce:
> 1. remove xstream from local repo:
> {code}rm -Rf ~/.m2/repository/com/thoughtworks/xstream{code}
> 2. run mvn clean install on the attached pom.xml
> -> the build should fail because the version 1.3.0-SNAPSHOT is not available
> at repo1.maven.org
> 3. edit the pom.xml, uncomment the plugin definition (jspc used for
> demonstration purposes only)
> 3. run mvn clean install again
> -> the build succeeds and the 1.3.0-SNAPSHOT is being built into the
> artifact, which is wrong.
--
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-3368) Printing version (-v argument) should not stop lifecycle execution
[ http://jira.codehaus.org/browse/MNG-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3368: --- Fix Version/s: 2.0.10 > Printing version (-v argument) should not stop lifecycle execution > -- > > Key: MNG-3368 > URL: http://jira.codehaus.org/browse/MNG-3368 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build, Command Line >Affects Versions: 2.0.8 >Reporter: Paul Benedict > Fix For: 2.0.10 > > > I wanted to always print the Maven version when I build, but unfortunately > Maven immediately quits after outputting the version. This option should not > quit when a lifecycle is also specified. Example: mvn -v install -- 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-3384) Repos defined in plugin are used to download dependencies
[ http://jira.codehaus.org/browse/MNG-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3384: --- Fix Version/s: 2.0.10 > Repos defined in plugin are used to download dependencies > - > > Key: MNG-3384 > URL: http://jira.codehaus.org/browse/MNG-3384 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Affects Versions: 2.0.8 >Reporter: Stefan Seidel > Fix For: 2.0.10 > > > When a plugin defines a repository, the dependencies declared to and by this > plugin are being resolved within these repositories. While this might be > easier, it introduces a number of problems, including the fact that it cannot > be controlled which repos are being used, security concerns (internal > artifact names might be sent to a remote repository, a malicious plugin could > define a fake repo with malicious "more recent" versions of almost anything). > If there is no intention to change the current behaviour, there should be at > least an option to disable it. > More unspecifically, I think the situation got worse in 2.1-SNAPSHOT (I use > the m2eclipse plugin), because I see lookups of SNAPSHOT versions of > dependencies occur much more often than with 2.0.8. -- 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-3385) PluginManagement does not work for report-plugins
[ http://jira.codehaus.org/browse/MNG-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3385: --- Fix Version/s: 2.1 > PluginManagement does not work for report-plugins > - > > Key: MNG-3385 > URL: http://jira.codehaus.org/browse/MNG-3385 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.8 >Reporter: Andreas Höhmann > Fix For: 2.1 > > > >... > > > org.apache.maven.plugins > maven-pmd-plugin > 2.2 > > > >... > > > > > maven-pmd-plugin > > > > mvn site ... use pmd-2.4-SNAPSHOT instead of the defined 2.2 ... why? -- 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-3326) Profile Deactivation
[ http://jira.codehaus.org/browse/MNG-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3326: --- Fix Version/s: 2.1 > Profile Deactivation > > > Key: MNG-3326 > URL: http://jira.codehaus.org/browse/MNG-3326 > Project: Maven 2 > Issue Type: New Feature > Components: Profiles >Affects Versions: 2.0.8 >Reporter: Paul Gier > Fix For: 2.1 > > > Profile definitions should have a way to add deactivation configuration > similar to the activation configuration. So you could have a profile > definition similar to this: > > my-profile > > > all.profiles.on > > > > > all.profiles.off > > 1.6 > > -- 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-3399) Maven shows fake network error until the next updatePolicy period
[ http://jira.codehaus.org/browse/MNG-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3399. -- Resolution: Duplicate > Maven shows fake network error until the next updatePolicy period > - > > Key: MNG-3399 > URL: http://jira.codehaus.org/browse/MNG-3399 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.8 >Reporter: Jonas Fagundes > > Hi, > The default updatePolicy is daily. > If it has any problems in updating it marks that plugin as checked and > keeping showing the same error message without trying to hit the server again. > At my work they changed the proxy configuration making the build fail, we > started to have the following message: > The plugin 'org.apache.maven.plugins:maven-clean-plugin' does not exist or no > valid version could be found. > Even after they rollback the network configuration, maven still showing the > same error. > To solve the problem I had to put this lines > > > always > > > false > > central > Maven Plugin Repository > http://repo1.maven.org/maven2 > > as the first pluginRepository and run for every developer just to force the > update. > This workaround works fine but until I realized that this is the behavior of > maven it generated a lot problems trying setup the network configuration (it > was not trying to hit the network, but it still showing the same error, so > all configuration attempts were worthless). > Show a network error that was not checked against the current configuration > is a bug. > My suggestion for an easy solution is to update timestamp of the latest hit > in the repository *after* it has a success, if it fails does not update the > timestamp and updatePolicy will make it keep trying for every execution until > it finally hit with success. This way you don't need to verify any extra > condition to see if the previous try resulted in an error. This way will make > the debug of network problems much easier for the users that have the same > problem. > I didn't look your sources, so maybe this solution is not practical in your > architecture. Feel free to use another route to solve this bug. > Thanks for your excellent work in maven (it is first bug in years), > Jonas Fagundes -- 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: (MJAVADOC-162) javadocExecutable unusable
[
http://jira.codehaus.org/browse/MJAVADOC-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak updated MJAVADOC-162:
-
Fix Version/s: (was: 2.4)
> javadocExecutable unusable
> --
>
> Key: MJAVADOC-162
> URL: http://jira.codehaus.org/browse/MJAVADOC-162
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows XP and non-Windows
>Reporter: Greg Thompson
>
> AbstractJavadocMojo tries to be smart by seeing if the file indicated by
> javadocExecutable exists, but this is actually quite problematic. If you put
> the following in your config:
> blahblahblah${file.separator}javadoc
> then you'll get an error on Windows since the file is actually javadoc.exe,
> which is a pain since it's perfectly acceptable to omit the .exe when
> executing a command.
> If you put .exe in the config, then it won't work on non-Windows platforms
> since the files doesn't have .exe.
> Forcing users to add hackery to their POMs to add .exe in some cases and
> leave it off in others is onerous.
> Methinks it's much preferable to simply use the path provided by the config.
> If it doesn't exist, let CommandLineUtils.executeCommandLine (or something
> else) throw an exception.
--
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: (MJAVADOC-119) Aggregate does not work for multiple module project when doing install.
[ http://jira.codehaus.org/browse/MJAVADOC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MJAVADOC-119: - Fix Version/s: (was: 2.4) > Aggregate does not work for multiple module project when doing install. > --- > > Key: MJAVADOC-119 > URL: http://jira.codehaus.org/browse/MJAVADOC-119 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Fedora Linux, Maven 2.0.6 >Reporter: Paul Gier > > If have a multi-module project, the javadoc aggregate does not find > inter-module dependencies: > pom.xml > |-->module1 > |-->module2 > module 1 depends on module 2 > The javadoc plugin is added to the build lifecycle attached to the install > phase. When I run "mvn install" I get a "Failed to resolve artifact." error > message looking for module 2. -- 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: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak updated MJAVADOC-116:
-
Fix Version/s: (was: 2.4)
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>Assignee: Vincent Siveton
> Attachments: clean javadoc-plugin-test-case with classifier use.zip,
> javadoc-plugin-test-case with classifier use.zip,
> javadoc-plugin-test-case.zip, log.txt, tiles-log.txt
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
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-3415) Transfer errors cause junk metadata in the local repo
[ http://jira.codehaus.org/browse/MNG-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126548 ] John Casey commented on MNG-3415: - I have the fix in place on my localhost, but I'm still trying to nail down the integration tests and make them work in both 2.0.9 and 2.1. It'll be Monday before I get this sorted out. > Transfer errors cause junk metadata in the local repo > - > > Key: MNG-3415 > URL: http://jira.codehaus.org/browse/MNG-3415 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Brian Fox >Assignee: John Casey > Fix For: 2.0.9 > > Attachments: MNG-3415.diff > > > I see this all the time and I swear there was an issue for it, but now I > can't find it. Sometimes there is metadata in the repo, usually after an > offline build or a build where something went wrong downloading artifacts. > Maven will apparently decide based on the metadata that the file can never be > found and will simply fail on a missing artifact. You can tell this has > happened because no attempt has actually been made to download the artifact > from a repository. Subsequent clearing of (portions) the localrepo fixes the > issue. This is terribly confusing to new users...and annoying to everyone. -- 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-3447) Enterprise Repository Architecture and Release Process
[ http://jira.codehaus.org/browse/MNG-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MNG-3447. Assignee: Wendy Smoak Resolution: Incomplete Please ask questions on the users list instead. You can find subscription info here: http://maven.apache.org/mail-lists.html > Enterprise Repository Architecture and Release Process > -- > > Key: MNG-3447 > URL: http://jira.codehaus.org/browse/MNG-3447 > Project: Maven 2 > Issue Type: Wish > Components: Design, Patterns & Best Practices >Reporter: sachin kamdar >Assignee: Wendy Smoak >Priority: Minor > > We implemented Maven last year in our Organization, overall we are satisfied > with the tool however, as we migrate more and more applications to Maven we > are facing some daunting challenges. We have roughly 500 maven projects for > 150 odd applications (ears), using the concept of Super POMS and Dependency > Management to create a layer of abstraction for commonly used artifacts, > plugins and properties > > However, despite of this abstraction we still have fairly deep dependency > graph. And since we have component base Application Architecture the impact > of a change in common, low level component which is not managed from Super > Pom is huge. A change in the low level pom means we have to change entire pom > hierarchies. In some cases it means changing upto 400 pom files. This issue > has now become so contentious that we have created a Project to re-structure > and re-architect Maven. > > As far as our Release Cycle goes, we release in test environment from which > we go through the bug fixing cycle, once all the bugs are fixed then the > artifacts are pushed into pre-prod and prod. Now because the artifact is > released into Test envt, any code change for bug fixes will force a pom > version change. This will trigger a change in the entire project hierarchy > from core->ejb->war->ear. As a result our release cycles have become really > slow. We are looking at options to reduce a) the impact of change in the low > level artifact and b) ability to release quickly. > > We looked at version ranges as an options but it would only partly solved the > problem, as we still get pinned versions into manifest files. Other > alternative was to release snapshots into Test Environment. Only pitfall with > this option is that once the bug fixing cycle is over we'll have to release > and build again. This, at present is against our company policy but > personally I don't see any fuss with it > > I was wondering if anyone has any recommendations for, > > 1. What is the recommended Maven Repository Architecture for Organizations > with Application Architecture such as ours > 2. Is there a 'best practice' for Releasing Maven Enterprise projects. (from > dev->test->pre->prod->prod) > 3. Is there a Dependency Graph type of tool (not like site - dependencies > report) which can display 'what depends on me' for each and every artifact in > the hierarchy? > > We use WebSphere on Linux and most of our projects have > ear-->wars-->ejbs-->cores type of structure. We also have whole heap of > business services deployed as ear-->ejb-->core, which gets used by other > application. -- 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
