[jira] Closed: (MEJB-19) clientExclude(s) does not work
[ http://jira.codehaus.org/browse/MEJB-19?page=all ] Dennis Lundberg closed MEJB-19. --- Resolution: Fixed Fix Version/s: 2.1 Closing. > clientExclude(s) does not work > -- > > Key: MEJB-19 > URL: http://jira.codehaus.org/browse/MEJB-19 > Project: Maven 2.x Ejb Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Maven 2.0.4 >Reporter: Stefan Seidel > Fix For: 2.1 > > > I've tried each and every configuration of and > to control what is being put into the ejb-client JAR, but > nothing really works. I expect the configuration > > ** > > to produce an empty JAR - but it doesn't. > What I really need to do is to exclude ejb-jar.xml and jboss.xml from the > client jar because JBoss 4 will still (try to) deploy the JAR file because > these XMLs are in it, even if it is given as java module in the > application.xml. Leaving these files there leads the whole idea of a client > JAR ad adsurdum. -- 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-1244) jt400-full-5.2-bundle
jt400-full-5.2-bundle - Key: MAVENUPLOAD-1244 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1244 Project: maven-upload-requests Issue Type: Task Reporter: M.H. Avegaart https://sourceforge.net/projects/jt400 http://jt400.sourceforge.net/ http://jt400.sourceforge.net/team.html The IBM Toolbox for Java is a library of Java classes supporting the client/server and internet programming models to a system running OS/400 or i5/OS. The classes can be used by Java applets, servlets, and applications to easily access OS/400 and i5/OS data and resources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-232) Archiva trunk does not build
Archiva trunk does not build Key: MRM-232 URL: http://jira.codehaus.org/browse/MRM-232 Project: Archiva Issue Type: Bug Reporter: Max Bowsher Since the Archiva website "Getting Started" page tells people to build from trunk, it is bad for trunk to not build. Trunk is currently broken because the MRM-231 changes have already been committed, but they are dependent on very recent changes to plexus-security-rbac-profile which have not yet been deployed to the codehaus snapshot repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1241) JWebUnit 1.4 RC1 available.
JWebUnit 1.4 RC1 available. --- Key: MAVENUPLOAD-1241 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1241 Project: maven-upload-requests Issue Type: New Feature Reporter: Julien HENRY Hi, Please sync from http://jwebunit.sourceforge.net/m2-repo to get the JWebUnit 1.4 RC1 release. Thanks Julien -- 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: (MCHANGES-61) Provide DTD/XSD for changes.xml
[ http://jira.codehaus.org/browse/MCHANGES-61?page=comments#action_80591 ] Dennis Lundberg commented on MCHANGES-61: - Please note that the Maven 2 version of the plugin does not yet have all the features of the Maven 1 plugin. Work has been done by Denis Cabasson in MCHANGES-47 to try to use a Modello model in the changes plugin. With this in place it would be easy to generate an xsd for changes.xml. I've been working a bit on Modello to apply patches that are required by Denis' patch for the changes plugin. > Provide DTD/XSD for changes.xml > --- > > Key: MCHANGES-61 > URL: http://jira.codehaus.org/browse/MCHANGES-61 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-2 >Reporter: Mark Hobson > > A DTD/XSD for changes.xml would be extremely useful for IDE auto-completion. > It should be hosted on the apache site. -- 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-103) Simple test case where compile succeeds but javadoc fails
[ http://jira.codehaus.org/browse/MJAVADOC-103?page=comments#action_80649 ] Stephane Nicoll commented on MJAVADOC-103: -- It seems that agregation does not take the classpath of the child when building the documentation. > Simple test case where compile succeeds but javadoc fails > - > > Key: MJAVADOC-103 > URL: http://jira.codehaus.org/browse/MJAVADOC-103 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Adam Lally > Attachments: maven-javadoc-test.zip > > > The attached project has a parent POM with one module. The module has just > one simple Java class in it, but it has dependencies on some 3rd party > artifacts (available from a shared repository). > When I run "mvn install" for the parent, it succeeds. > If I run "mvn javadoc:javadoc" from the module, it succeeds. > If I run "mvn javadoc:javadoc" from the parent, it fails: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation. > Embedded error: Exit code: 1 - > C:/alally/dev/maven-javadoc-test/test-module/src/ > main/java/Test.java:3: package org.eclipse.jdt.ui does not exist > import org.eclipse.jdt.ui.ISharedImages; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:4: > package > org.eclipse.jdt.ui does not exist > import org.eclipse.jdt.ui.JavaUI; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:5: > package > org.eclipse.swt.graphics does not exist > import org.eclipse.swt.graphics.Image; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : class Image > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(IShare > dImages.IMG_OBJS_CLASS); > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : variable ISharedImages > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(ISharedImages.IMG_OBJS_CLASS); > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : variable JavaUI > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(ISharedImages.IMG_OBJS_CLASS); -- 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-61) Adding custom source paths to javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-61?page=comments#action_80635 ]
Julien HENRY commented on MJAVADOC-61:
--
I have a similar issue with source generated with antrun plugin.
I have a multimodule project, and when I run mvn package -DperformRelease=true,
the Javadoc of my generated source is generated and packaged, but when I run
mvn site, I don't have the Javadoc of my generated class. Perhaps there is a
problem with aggregate=true ?
> Adding custom source paths to javadoc
> -
>
> Key: MJAVADOC-61
> URL: http://jira.codehaus.org/browse/MJAVADOC-61
> Project: Maven 2.x Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.0-beta-3
> Environment: FedoreCore 4 kernel 2.6.10-1.760_FC3smp #1
>Reporter: Erik van Zijst
> Assigned To: Vincent Siveton
> Fix For: 2.1
>
>
> I have a code generator that creates sources during the compile stage. These
> sources end up in a custom directory
> (${project.build.directory}/generated-sources/main/java). The problem is that
> javadoc skips these files when it generates the documentation. What I'm
> looking for is a way to manipulate javadoc's sourcefilenames argument.
> I have already tried adding
> ${project.build.directory}/generated-sources/main/java
> to the code generation step, but it didn't affect javadoc.
--
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: (MCLEAN-22) Possibility to ignore deletion failures
[ http://jira.codehaus.org/browse/MCLEAN-22?page=all ] Carlos Sanchez updated MCLEAN-22: - Fix Version/s: (was: 2.1.1) 2.2 > Possibility to ignore deletion failures > --- > > Key: MCLEAN-22 > URL: http://jira.codehaus.org/browse/MCLEAN-22 > Project: Maven 2.x Clean Plugin > Issue Type: Improvement >Affects Versions: 2.1, 2.1.1 > Environment: WinXP SP2 >Reporter: Bugittaa Pahasti > Fix For: 2.2 > > > If deletion of the output directories during clean fails, the build will > fail. It would be good to have a configuration option, so that the plugin > would just print a warning and continue cleaning with the rest of the > directories. -- 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-1236) JHLabs filters version 2.0.235
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1236?page=comments#action_80656 ] Carlos Sanchez commented on MAVENUPLOAD-1236: - no, the requirement is fine > JHLabs filters version 2.0.235 > -- > > Key: MAVENUPLOAD-1236 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1236 > Project: maven-upload-requests > Issue Type: Task >Reporter: Wim Deblauwe > Assigned To: Carlos Sanchez > > http://users.fulladsl.be/spb2291/jhlabs/filters-2.0.235-bundle.jar > http://www.jhlabs.com/ > http://www.jhlabs.com/ > JHLabs Image Processing Filters: A collection of image processing filters. -- 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: (MPIR-58) The sandbox component Jar has been renamed to JarAnalyzer
[ http://jira.codehaus.org/browse/MPIR-58?page=all ] Joakim Erdfelt closed MPIR-58. -- Assignee: Joakim Erdfelt Resolution: Fixed Fix Version/s: 2.1 Work performed before this jira was filed. Update your subversion. > The sandbox component Jar has been renamed to JarAnalyzer > - > > Key: MPIR-58 > URL: http://jira.codehaus.org/browse/MPIR-58 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3 > Environment: ALl >Reporter: Hermod Opstvedt > Assigned To: Joakim Erdfelt > Fix For: 2.1 > > Attachments: projectreport.patch > > > The sandbox component Jar has been renamed to JarAnalyzer. Attached is a > patch for this. There is one prerequisite for this patch, which is a patch > for the JarAnalyzer. The method setFile was had accessor protected, but needs > to be public. -- 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: (MRM-233) Add 'Edit user info' link in the side navigation
Add 'Edit user info' link in the side navigation Key: MRM-233 URL: http://jira.codehaus.org/browse/MRM-233 Project: Archiva Issue Type: Improvement Components: web application Environment: Linux FC4, JDK 1.5, Maven 2.0.4 Reporter: Napoleon Esmundo C. Ramirez Priority: Minor Add 'Edit user info' link similar to that of continuum. -- 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-1244) jt400-full-5.2-bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1244?page=all ] M.H. Avegaart updated MAVENUPLOAD-1244: --- Attachment: jt400-full-5.1.1-bundle.jar > jt400-full-5.2-bundle > - > > Key: MAVENUPLOAD-1244 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1244 > Project: maven-upload-requests > Issue Type: Task >Reporter: M.H. Avegaart > Attachments: jt400-full-5.0-bundle.jar, jt400-full-5.1.1-bundle.jar, > jt400-full-5.2-bundle.jar > > > https://sourceforge.net/projects/jt400 > http://jt400.sourceforge.net/ > http://jt400.sourceforge.net/team.html > The IBM Toolbox for Java is a library of Java classes supporting the > client/server and internet programming models to a system running OS/400 or > i5/OS. The classes can be used by Java applets, servlets, and applications to > easily access OS/400 and i5/OS data and resources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-1244) jt400-full-5.2-bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1244?page=all ] M.H. Avegaart updated MAVENUPLOAD-1244: --- Attachment: jt400-full-5.0-bundle.jar > jt400-full-5.2-bundle > - > > Key: MAVENUPLOAD-1244 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1244 > Project: maven-upload-requests > Issue Type: Task >Reporter: M.H. Avegaart > Attachments: jt400-full-5.0-bundle.jar, jt400-full-5.1.1-bundle.jar, > jt400-full-5.2-bundle.jar > > > https://sourceforge.net/projects/jt400 > http://jt400.sourceforge.net/ > http://jt400.sourceforge.net/team.html > The IBM Toolbox for Java is a library of Java classes supporting the > client/server and internet programming models to a system running OS/400 or > i5/OS. The classes can be used by Java applets, servlets, and applications to > easily access OS/400 and i5/OS data and resources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-78) create eclipse projects which are m2eclipse ready
[ http://jira.codehaus.org/browse/MECLIPSE-78?page=all ] Rob Baily updated MECLIPSE-78: -- Attachment: MECLIPSE-78.patch I've attached a new version of the patch. Sorry about the last one as I did it with Eclipse and it used my entire directory structure rather than just going from the project base. Also for anyone interested I'm attaching another patch file which is used during the eclipse:add-maven-repo goal to set the Eclipse plugin setting for the repository. I wasn't sure if the change should include any kind of flag to activate it so I left that out and it is always set. > create eclipse projects which are m2eclipse ready > - > > Key: MECLIPSE-78 > URL: http://jira.codehaus.org/browse/MECLIPSE-78 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Environment: Fedora Core 3, Sun JDK 1.5.0.06, Eclipse 3.1.1, Maven > 2.0.2 >Reporter: Joshua Nichols > Attachments: m2eclipse-add-repo.patch, m2eclipse.patch, > m2eclipse.patch, m2eclipse.patch, m2eclipse.patch, MECLIPSE-78.patch > > > WIth the recent development of the m2eclipse plugin, I believe it is useful > to create eclipse projects via mvn eclipse:eclipse that use m2eclipse from > the start. One of the advantages of using m2eclipse is that you don't have to > rerun eclipse:eclipse when you update any dependencies. > A few things are necessary to accomplish this, in terms of changes to > .classpath and .project. > .project needs a new nature and builder added. For the builder: > > org.maven.ide.eclipse.maven2Builder > > > For the nature: > org.maven.ide.eclipse.maven2Nature > In the .classpath, we need to add: >path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> > In .classpath, you also don't want entries path="M2_REPO/blah/blah/x.y.z/blah-x.y.z.jar"/>, because they would conflict > with m2eclipse setting up the classpath. -- 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-78) create eclipse projects which are m2eclipse ready
[ http://jira.codehaus.org/browse/MECLIPSE-78?page=all ] Rob Baily updated MECLIPSE-78: -- Attachment: m2eclipse-add-repo.patch > create eclipse projects which are m2eclipse ready > - > > Key: MECLIPSE-78 > URL: http://jira.codehaus.org/browse/MECLIPSE-78 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Environment: Fedora Core 3, Sun JDK 1.5.0.06, Eclipse 3.1.1, Maven > 2.0.2 >Reporter: Joshua Nichols > Attachments: m2eclipse-add-repo.patch, m2eclipse.patch, > m2eclipse.patch, m2eclipse.patch, m2eclipse.patch, MECLIPSE-78.patch > > > WIth the recent development of the m2eclipse plugin, I believe it is useful > to create eclipse projects via mvn eclipse:eclipse that use m2eclipse from > the start. One of the advantages of using m2eclipse is that you don't have to > rerun eclipse:eclipse when you update any dependencies. > A few things are necessary to accomplish this, in terms of changes to > .classpath and .project. > .project needs a new nature and builder added. For the builder: > > org.maven.ide.eclipse.maven2Builder > > > For the nature: > org.maven.ide.eclipse.maven2Nature > In the .classpath, we need to add: >path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> > In .classpath, you also don't want entries path="M2_REPO/blah/blah/x.y.z/blah-x.y.z.jar"/>, because they would conflict > with m2eclipse setting up the classpath. -- 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-193) The new 'additionalConfig' configuration doesn't create sub-directories
The new 'additionalConfig' configuration doesn't create sub-directories --- Key: MECLIPSE-193 URL: http://jira.codehaus.org/browse/MECLIPSE-193 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Maurice Zeijen Fix For: 2.3, 2.4 The new configuration option 'additionalConfig' throws an exception when I set a non existing sub-directory in the 'file' node. It would be better if the subdirectory would be created if it doesn't exists. Example: A lot of eclipse configuration files are written in the '.settings' directory. .settings/org.eclipse.jdt.core.prefs The plugin should create the subdirectory '.settings' if it doesn't exist. -- 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: (MSUREFIRE-170) Classpath in XML report is wrong
[ http://jira.codehaus.org/browse/MSUREFIRE-170?page=comments#action_80626 ] J-C Walmetz commented on MSUREFIRE-170: --- Properties written in the XML report are just a dump of the System.getProperties() executed after tests. It does not used the classloader used for tests. I can provide a patch for that. Do you prefer a patch over the trunk or over last release ? > Classpath in XML report is wrong > > > Key: MSUREFIRE-170 > URL: http://jira.codehaus.org/browse/MSUREFIRE-170 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug > Components: xml generation >Reporter: Joerg Schaible >Priority: Minor > > The XML report contains in the property java.class.path Maven's classpath, > but not the class path used to execute the tests. -- 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-2672) Wrong dependency handling when having dependencies to artifacts in different versions
[ http://jira.codehaus.org/browse/MNG-2672?page=all ] Carlos Sanchez closed MNG-2672. --- Assignee: Carlos Sanchez Resolution: Won't Fix Works as expected, check http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html i've just improved the docs and will be available soon # Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree it's not defined which one will win. * "nearest definition" means that the version used will be the closest one to your project in the tree of dependencies, eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0 > Wrong dependency handling when having dependencies to artifacts in different > versions > - > > Key: MNG-2672 > URL: http://jira.codehaus.org/browse/MNG-2672 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: Windows XP, JDK 1.4.2_12 >Reporter: Fabian Christ > Assigned To: Carlos Sanchez > > Hi, > let's take a look at the following situation. There is a project A which has > dependencies to B and C. Now both B and C have a dependency to D but in > different versions. B requires version D-1.0 and C version D-2.0. > Now in different situations is one time D-1.0 used and the next time D-2.0. > There is no chance to configure which version will be used. Notice the > restriction that I can't change the configured dependencies in B oder C - > they are given.Here is a list of different configurations and their results: > Base configuration: > A: > > org.test > B > 1.0-SNAPSHOT > compile > > > org.test > C > 1.0-SNAPSHOT > compile > > B: > > org.test > D > 1.0 > compile > > C: > > org.test > D > 2.0 > compile > > Debug: > [DEBUG] org.test:A:jar:1.0 (selected for null) > [DEBUG] org.test:B:jar:1.0-SNAPSHOT:compile (selected for compile) > [DEBUG] org.test:D:jar:1.0:compile (selected for compile) > [DEBUG] org.test:C:jar:1.0-SNAPSHOT:compile (selected for compile) > [DEBUG] org.test:D:jar:2.0:compile (removed - nearer found: 1.0) > => so D-1.0.jar is used > Config 2: > Exclude artifact D from dependency on B in A: > > org.test > B > 1.0-SNAPSHOT > compile > > > org.test > D > > > > Debug: > [DEBUG] org.test:A:jar:1.0 (selected for null) > [DEBUG] org.test:B:jar:1.0-SNAPSHOT:compile (selected for compile) > [DEBUG] org.test:C:jar:1.0-SNAPSHOT:compile (selected for compile) > ==> So D is never used (!) and so not on the classpath. Expected was to use > D-2.0. The exclude seems not to work correct here as it excludes the artifact > from the whole build. > Config 3: > No exclusions. > Change dependency of A to B-1.0-SNAPSHOT to B-1.0 > Debug: > [DEBUG] org.test:A:jar:1.0 (selected for null) > [DEBUG] org.test:C:jar:1.0-SNAPSHOT:compile (selected for compile) > [DEBUG] org.test:D:jar:2.0:compile (selected for compile) > [DEBUG] org.test:B:jar:1.0:compile (selected for compile) > [DEBUG] org.test:D:jar:1.0:compile (removed - nearer found: 2.0) > ==> so D-2.0.jar is used (!). Why is version 2.0 nearer now than 1.0? In the > base configuration above version 1.0 was nearer. > Config 4: > Change dependency of A to B-1.0-SNAPSHOT to B-1.0 > Change dependency of A to C-1.0-SNAPSHOT to C-1.0 > Debug: > [DEBUG] org.test:A:jar:1.0 (selected for null) > [DEBUG] org.test:C:jar:1.0:compile (selected for compile) > [DEBUG] org.test:D:jar:2.0:compile (selected for compile) > [DEBUG] org.test:B:jar:1.0:compile (selected for compile) > [DEBUG] org.test:D:jar:1.0:compile (removed - nearer found: 2.0) > ==> so D-2.0.jar is used. Same result as with config 3. > So what would be the correct behavior here? At the moment it is not > configurable which version of D will be used during compile. > - Fabian -- 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: (MRM-233) Add 'Edit user info' link in the side navigation
[ http://jira.codehaus.org/browse/MRM-233?page=all ] Napoleon Esmundo C. Ramirez updated MRM-233: Attachment: MRM-233-archiva-webapp.patch This patch adds the 'Edit user info' link in the side navigation menu. > Add 'Edit user info' link in the side navigation > > > Key: MRM-233 > URL: http://jira.codehaus.org/browse/MRM-233 > Project: Archiva > Issue Type: Improvement > Components: web application > Environment: Linux FC4, JDK 1.5, Maven 2.0.4 >Reporter: Napoleon Esmundo C. Ramirez >Priority: Minor > Attachments: MRM-233-archiva-webapp.patch > > > Add 'Edit user info' link similar to that of continuum. -- 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-2664) Add native support for webdav
[ http://jira.codehaus.org/browse/MNG-2664?page=comments#action_80678 ] Joakim Erdfelt commented on MNG-2664: - what's not working with the webdav wagon provider? we use it regularly. /me checks the WAGON jira ... > Add native support for webdav > - > > Key: MNG-2664 > URL: http://jira.codehaus.org/browse/MNG-2664 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Arnaud Heritier > Fix For: 2.0.5 > > Attachments: MNG-2664.patch > > > Actually with maven 2.0.4 we can't use the deploy:deploy-file goal to add an > artifact on a remote repository with webdav. > This is really annoying for archiva which supports webdav for uploads. -- 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-2673) Change accessor of setFile in JarAnalyzer of maven-shared-jar
[ http://jira.codehaus.org/browse/MNG-2673?page=all ] Joakim Erdfelt closed MNG-2673. --- Resolution: Duplicate > Change accessor of setFile in JarAnalyzer of maven-shared-jar > - > > Key: MNG-2673 > URL: http://jira.codehaus.org/browse/MNG-2673 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Hermod Opstvedt > Assigned To: Joakim Erdfelt > Attachments: jaranalyzer.patch > > > When renaming the Jar to JarAnalyzer, the accessor of setFile changed. The > maven-project-info-reports-plugin uses this method to the the jarfile to > analyze, so it need to be public. Attached is patch for it. -- 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: (CONTINUUM-529) Modules (child) scm connection URLs are not constructed correctly
[ http://jira.codehaus.org/browse/CONTINUUM-529?page=all ]
Emmanuel Venisse closed CONTINUUM-529.
--
Assignee: Emmanuel Venisse
Resolution: Fixed
Fixed.
> Modules (child) scm connection URLs are not constructed correctly
> -
>
> Key: CONTINUUM-529
> URL: http://jira.codehaus.org/browse/CONTINUUM-529
> Project: Continuum
> Issue Type: Bug
> Components: Core system, SCM
>Affects Versions: 1.0.2
>Reporter: Grégory Joseph
> Assigned To: Emmanuel Venisse
> Fix For: 1.1
>
>
> It *seems* to me that, when adding a parent pom to continuum, which has
> defined, but the scm url only defined in the parent, it gets and
> parses the child poms correctly, but their scm URLs are build as
> ${parentScmUrl}/${childArtifactId} , while I think they should rather be
> ${parentScmUrl}/${modulePath}
> Maybe this is a maven inheritance issue, though ?
--
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: (MRM-234) Moving files between repos through webdav doesn't work
Moving files between repos through webdav doesn't work -- Key: MRM-234 URL: http://jira.codehaus.org/browse/MRM-234 Project: Archiva Issue Type: Bug Components: repository interface Affects Versions: 1.0-beta-1 Reporter: Carlos Sanchez The goal is to move files from one repo to another through the webdav interface, using a webdav client, like Windows My Network Places or BitKinex Two repos where created and accessed with username/password http://localhost:8092/repository/repo1 http://localhost:8092/repository/repo2 Copying from one to another fails. Copying from any other webdav server to them works Copying from them to any other webdav server works Copying from local to them and from them to local of course works I tried with latest svn code from could.it which includes this MOVE improvement http://issues.apache.org/jira/browse/HADOOP-505 that makes a real move and not a copy+delete -- 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: (MRM-234) Moving files between repos through webdav doesn't work
[ http://jira.codehaus.org/browse/MRM-234?page=comments#action_80707 ] Carlos Sanchez commented on MRM-234: The code I tested from could.it is http://could.it/repo/webdav/head rev# 262 > Moving files between repos through webdav doesn't work > -- > > Key: MRM-234 > URL: http://jira.codehaus.org/browse/MRM-234 > Project: Archiva > Issue Type: Bug > Components: repository interface >Affects Versions: 1.0-beta-1 >Reporter: Carlos Sanchez > > The goal is to move files from one repo to another through the webdav > interface, using a webdav client, like Windows My Network Places or BitKinex > Two repos where created and accessed with username/password > http://localhost:8092/repository/repo1 > http://localhost:8092/repository/repo2 > Copying from one to another fails. > Copying from any other webdav server to them works > Copying from them to any other webdav server works > Copying from local to them and from them to local of course works > I tried with latest svn code from could.it which includes this MOVE > improvement http://issues.apache.org/jira/browse/HADOOP-505 that makes a real > move and not a copy+delete -- 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-1236) JHLabs filters version 2.0.235
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1236?page=comments#action_80627 ] Wim Deblauwe commented on MAVENUPLOAD-1236: --- Thanks for uploading. Should I file a bug that the maven plugin demands an scm connection to be in there? > JHLabs filters version 2.0.235 > -- > > Key: MAVENUPLOAD-1236 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1236 > Project: maven-upload-requests > Issue Type: Task >Reporter: Wim Deblauwe > Assigned To: Carlos Sanchez > > http://users.fulladsl.be/spb2291/jhlabs/filters-2.0.235-bundle.jar > http://www.jhlabs.com/ > http://www.jhlabs.com/ > JHLabs Image Processing Filters: A collection of image processing filters. -- 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: (MJAVADOC-103) Simple test case where compile succeeds but javadoc fails
[ http://jira.codehaus.org/browse/MJAVADOC-103?page=all ] Vincent Siveton closed MJAVADOC-103. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 Already fixed > Simple test case where compile succeeds but javadoc fails > - > > Key: MJAVADOC-103 > URL: http://jira.codehaus.org/browse/MJAVADOC-103 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Adam Lally > Assigned To: Vincent Siveton > Fix For: 2.1 > > Attachments: maven-javadoc-test.zip > > > The attached project has a parent POM with one module. The module has just > one simple Java class in it, but it has dependencies on some 3rd party > artifacts (available from a shared repository). > When I run "mvn install" for the parent, it succeeds. > If I run "mvn javadoc:javadoc" from the module, it succeeds. > If I run "mvn javadoc:javadoc" from the parent, it fails: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation. > Embedded error: Exit code: 1 - > C:/alally/dev/maven-javadoc-test/test-module/src/ > main/java/Test.java:3: package org.eclipse.jdt.ui does not exist > import org.eclipse.jdt.ui.ISharedImages; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:4: > package > org.eclipse.jdt.ui does not exist > import org.eclipse.jdt.ui.JavaUI; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:5: > package > org.eclipse.swt.graphics does not exist > import org.eclipse.swt.graphics.Image; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : class Image > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(IShare > dImages.IMG_OBJS_CLASS); > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : variable ISharedImages > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(ISharedImages.IMG_OBJS_CLASS); > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : variable JavaUI > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(ISharedImages.IMG_OBJS_CLASS); -- 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: (MJAVADOC-102) Error in multimodule project gives very misleading error messages
[ http://jira.codehaus.org/browse/MJAVADOC-102?page=all ]
Vincent Siveton closed MJAVADOC-102.
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 2.1
Already fixed
> Error in multimodule project gives very misleading error messages
> -
>
> Key: MJAVADOC-102
> URL: http://jira.codehaus.org/browse/MJAVADOC-102
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows XP
> Sun Java 1.5.0_07
>Reporter: Adam Lally
> Assigned To: Vincent Siveton
>Priority: Minor
> Fix For: 2.1
>
> Attachments: maven-javadoc-bug.zip
>
>
> The attached zip has a multimodule project with 2 modules. module 2 has an
> invalid package.html file.
> In the parent directory, run "mvn install". This should work fine.
> Then run "mvn javadoc:javadoc". When I do this, I get:
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error has occurred in JavaDocs report generation.
> Embedded error: Exit code: 1 -
> C:/alally/dev/maven-javadoc-bug/module1/src/main/java/test/module1/Test.java:3:
> package org.eclipse.emf.common.util does not exist
> import org.eclipse.emf.common.util.EList;
>^
> C:/alally/dev/maven-javadoc-bug/module1/src/main/java/test/module1/Test.java:6:
> cannot find symbol
> symbol : class EList
> location: class test.module1.Test
> public static void foo(EList bar) {}
> ^
> C:\alally\dev\maven-javadoc-bug\module2\src\main\java\test\module2\package.html:
> error - Body tag missing from HTML
> ---
> In addition to the correct error message about the missing body tag, you can
> see I'm also getting a bogus "cannot find symbol" error.
> In my real project, I was getting *hundreds* of "cannot find symbol" errors,
> making it very difficult to see what the real problem is. This caused me to
> waste a few hours trying to figure out why my dependencies weren't being
> resolved.
--
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: (MRM-234) Moving files between repos through webdav doesn't work
[ http://jira.codehaus.org/browse/MRM-234?page=all ] Carlos Sanchez updated MRM-234: --- Attachment: server.log client.log Client and server logs > Moving files between repos through webdav doesn't work > -- > > Key: MRM-234 > URL: http://jira.codehaus.org/browse/MRM-234 > Project: Archiva > Issue Type: Bug > Components: repository interface >Affects Versions: 1.0-beta-1 >Reporter: Carlos Sanchez > Attachments: client.log, server.log > > > The goal is to move files from one repo to another through the webdav > interface, using a webdav client, like Windows My Network Places or BitKinex > Two repos where created and accessed with username/password > http://localhost:8092/repository/repo1 > http://localhost:8092/repository/repo2 > Copying from one to another fails. > Copying from any other webdav server to them works > Copying from them to any other webdav server works > Copying from local to them and from them to local of course works > I tried with latest svn code from could.it which includes this MOVE > improvement http://issues.apache.org/jira/browse/HADOOP-505 that makes a real > move and not a copy+delete -- 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-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=comments#action_80660 ] Kay Grosskop commented on MSITE-159: Moreover the current behaviour of the site generation leads to the following annoying issue: pom: https://bla.mycomp.nl scp://mycomp.nl/home/groups/bla/htdocs/site (where the project url is mapped to the htdocs directory) site.xml: https://bla.mycomp.nl/docs"/> In this case, the it will create a relative link to href="docs". but since my site gets deployed in subdirectory ./site it will point erroneously to ./site/docs Now you can argue that the project-url is meant to point to the root of the site deployment location. But in my opinion absolute paths should stay absolute. Isn't that the reason why you define them absolute, because you want to overrule the relation with the deployment url? > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-180) Rewritten poms loose comments
[ http://jira.codehaus.org/browse/MRELEASE-180?page=comments#action_80594 ] Wendy Smoak commented on MRELEASE-180: -- The same thing happened to the commons-parent pom recently. http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL PROTECTED] Brett said, "That is a bug in the release plugin if you have new lines in the root element. I think it's fixed in trunk." > Rewritten poms loose comments > -- > > Key: MRELEASE-180 > URL: http://jira.codehaus.org/browse/MRELEASE-180 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Guillaume Nodet > > When releasing ServiceMix, the following file was used before running the > release plugin: > > http://svn.apache.org/viewvc/incubator/servicemix/branches/servicemix-3.0/pom.xml?revision=470027&view=markup > But when actually releasing, the modified pom has lost the comments: > > http://svn.apache.org/viewvc/incubator/servicemix/branches/servicemix-3.0/pom.xml?revision=470031&view=markup > -- 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: (SCM-254) Add command should accept a message
Add command should accept a message --- Key: SCM-254 URL: http://jira.codehaus.org/browse/SCM-254 Project: Maven SCM Issue Type: Bug Components: maven-scm-api Environment: xp, linux , starteam Reporter: Dan Tran Fix For: 1.0 We need an additional Add interface to accept a message ieAddScmResult add( ScmRepository repository, ScmFileSet fileSet , String message ) throws ScmException; for cvs/svn and similar system should ignore the message -- 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: (SCM-254) Add command should accept a message
[ http://jira.codehaus.org/browse/SCM-254?page=all ] Dan Tran updated SCM-254: - Affects Version/s: 1.0-beta-3 Fix Version/s: 1.0 > Add command should accept a message > --- > > Key: SCM-254 > URL: http://jira.codehaus.org/browse/SCM-254 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api >Affects Versions: 1.0-beta-3 > Environment: xp, linux , starteam >Reporter: Dan Tran > Fix For: 1.0 > > > We need an additional Add interface to accept a message > ieAddScmResult add( ScmRepository repository, ScmFileSet fileSet , String > message ) throws ScmException; > for cvs/svn and similar system should ignore the message -- 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: (MPH-14) Add a mojo to print the dependency tree
[ http://jira.codehaus.org/browse/MPH-14?page=all ] Mark Hobson updated MPH-14: --- Attachment: MPH-14-patch.txt Attaching patch against r477616 that uses maven-dependency-tree, thanks! > Add a mojo to print the dependency tree > --- > > Key: MPH-14 > URL: http://jira.codehaus.org/browse/MPH-14 > Project: Maven 2.x Help Plugin > Issue Type: New Feature >Reporter: Kenney Westerhof >Priority: Minor > Attachments: MPH-14-patch.txt > > > This mojo should print a tree like is now on the dependencies report > generated by the site plugin. > This is more user-friendly than having to run with -X and grepping through > the huge amount of debug output. -- 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: (MRM-234) Moving files between repos through webdav doesn't work
[ http://jira.codehaus.org/browse/MRM-234?page=all ] Carlos Sanchez updated MRM-234: --- Attachment: webdav-0.5-dev.jar Built version of http://could.it/repo/webdav/head rev# 262 > Moving files between repos through webdav doesn't work > -- > > Key: MRM-234 > URL: http://jira.codehaus.org/browse/MRM-234 > Project: Archiva > Issue Type: Bug > Components: repository interface >Affects Versions: 1.0-beta-1 >Reporter: Carlos Sanchez > Attachments: client.log, server.log, webdav-0.5-dev.jar > > > The goal is to move files from one repo to another through the webdav > interface, using a webdav client, like Windows My Network Places or BitKinex > Two repos where created and accessed with username/password > http://localhost:8092/repository/repo1 > http://localhost:8092/repository/repo2 > Copying from one to another fails. > Copying from any other webdav server to them works > Copying from them to any other webdav server works > Copying from local to them and from them to local of course works > I tried with latest svn code from could.it which includes this MOVE > improvement http://issues.apache.org/jira/browse/HADOOP-505 that makes a real > move and not a copy+delete -- 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-102) Error in multimodule project gives very misleading error messages
[ http://jira.codehaus.org/browse/MJAVADOC-102?page=comments#action_80661 ]
Vincent Siveton commented on MJAVADOC-102:
--
It works here with javadoc plugin version 2.1. The only pb is
"\module2\src\main\java\test\module2\package.html: error - Body tag missing
from HTML"
Try to bump to 2.1.
Waiting for your feedback.
> Error in multimodule project gives very misleading error messages
> -
>
> Key: MJAVADOC-102
> URL: http://jira.codehaus.org/browse/MJAVADOC-102
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows XP
> Sun Java 1.5.0_07
>Reporter: Adam Lally
>Priority: Minor
> Attachments: maven-javadoc-bug.zip
>
>
> The attached zip has a multimodule project with 2 modules. module 2 has an
> invalid package.html file.
> In the parent directory, run "mvn install". This should work fine.
> Then run "mvn javadoc:javadoc". When I do this, I get:
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error has occurred in JavaDocs report generation.
> Embedded error: Exit code: 1 -
> C:/alally/dev/maven-javadoc-bug/module1/src/main/java/test/module1/Test.java:3:
> package org.eclipse.emf.common.util does not exist
> import org.eclipse.emf.common.util.EList;
>^
> C:/alally/dev/maven-javadoc-bug/module1/src/main/java/test/module1/Test.java:6:
> cannot find symbol
> symbol : class EList
> location: class test.module1.Test
> public static void foo(EList bar) {}
> ^
> C:\alally\dev\maven-javadoc-bug\module2\src\main\java\test\module2\package.html:
> error - Body tag missing from HTML
> ---
> In addition to the correct error message about the missing body tag, you can
> see I'm also getting a bogus "cannot find symbol" error.
> In my real project, I was getting *hundreds* of "cannot find symbol" errors,
> making it very difficult to see what the real problem is. This caused me to
> waste a few hours trying to figure out why my dependencies weren't being
> resolved.
--
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: (MNGECLIPSE-212) Installation Fails
[ http://jira.codehaus.org/browse/MNGECLIPSE-212?page=all ] Eugene Kuleshov closed MNGECLIPSE-212. -- Resolution: Duplicate > Installation Fails > -- > > Key: MNGECLIPSE-212 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-212 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.9 > Environment: Linux, fresh install of eclipse 3.2.1, JDK 1.5.08 >Reporter: Robert Smol > > Hello, thanks for this product, however I am having issue start using it. > I've installed version 0.0.9 as other plugins and everything seemed to be ok. > Restarted IDE and tried to right click on project Maven2->Enable and dialog > Information appears: > The chosen operation is not currently available. > Also in Windows->Preferences->Maven2 I get error dialog Preference Page > Creation Problems: > Reason: > Plug-in org.maven.ide.eclipse. was unable to load class > org.maven.ide.eclipse.preferences.Mave2PreferencePage. > I've installed Maven2Plugin into /opt/eclipse: > czcholdnoc01 ~ # ll /opt/eclipse/* > /opt/eclipse/features: > total 0 > drwxr-xr-x 2 rsmol users 80 2006-11-21 15:10 > org.maven.ide.eclipse.feature_0.0.9 > /opt/eclipse/plugins: > total 9421 > -rw-r--r-- 1 rsmol users 9635764 2006-11-21 15:10 > org.maven.ide.eclipse_0.0.9.jar > Any idea what am I doing wrong? Other plugins works, so I believe location is > not the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-52) XML Reports include testcases from previous tests
[ http://jira.codehaus.org/browse/SUREFIRE-52?page=comments#action_80595 ]
Mirko Nasato commented on SUREFIRE-52:
--
I'd suggest raising the Priority from Minor to Major.
It may be just a presentation issue, but frankly it's quite annoying to see all
the HTML reports incorrect, even for all the Maven plugins themselves
http://maven.apache.org/plugins/maven-install-plugin/surefire-report.html
http://maven.apache.org/plugins/maven-resources-plugin/surefire-report.html
http://maven.apache.org/plugins/maven-ear-plugin/surefire-report.html
...
> XML Reports include testcases from previous tests
> -
>
> Key: SUREFIRE-52
> URL: http://jira.codehaus.org/browse/SUREFIRE-52
> Project: surefire
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: bin zhu
>Priority: Minor
> Fix For: 2.1
>
> Attachments: patch.txt
>
>
> to reproduce
> 1. create the following JUnit tests:
> public class TestA extends TestCase {
>public void test1() {
>}
> }
> public class TestB extends TestCase {
>public void test2() {
> }
> 2. run 'mvn clean install'
> note that in TEST-TestB.xml includes testcase results from test1 and test2,
> even though TestB only has test2()
> name="TestB">
> ...
>
>
>
--
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-1240) Please upload new version of xmlenc
Please upload new version of xmlenc --- Key: MAVENUPLOAD-1240 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1240 Project: maven-upload-requests Issue Type: Task Reporter: Anthony Goubard Attachments: pom.xml Note that xmlenc is already known in Maven2 repository (but it wasn't me who put it). If you have any questions, contact me at [EMAIL PROTECTED] -- 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-103) Simple test case where compile succeeds but javadoc fails
[ http://jira.codehaus.org/browse/MJAVADOC-103?page=comments#action_80663 ] Vincent Siveton commented on MJAVADOC-103: -- Seems to be the same that MJAVADOC-102. Try to bump to 2.1. > Simple test case where compile succeeds but javadoc fails > - > > Key: MJAVADOC-103 > URL: http://jira.codehaus.org/browse/MJAVADOC-103 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Adam Lally > Attachments: maven-javadoc-test.zip > > > The attached project has a parent POM with one module. The module has just > one simple Java class in it, but it has dependencies on some 3rd party > artifacts (available from a shared repository). > When I run "mvn install" for the parent, it succeeds. > If I run "mvn javadoc:javadoc" from the module, it succeeds. > If I run "mvn javadoc:javadoc" from the parent, it fails: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation. > Embedded error: Exit code: 1 - > C:/alally/dev/maven-javadoc-test/test-module/src/ > main/java/Test.java:3: package org.eclipse.jdt.ui does not exist > import org.eclipse.jdt.ui.ISharedImages; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:4: > package > org.eclipse.jdt.ui does not exist > import org.eclipse.jdt.ui.JavaUI; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:5: > package > org.eclipse.swt.graphics does not exist > import org.eclipse.swt.graphics.Image; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : class Image > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(IShare > dImages.IMG_OBJS_CLASS); > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : variable ISharedImages > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(ISharedImages.IMG_OBJS_CLASS); > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : variable JavaUI > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(ISharedImages.IMG_OBJS_CLASS); -- 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: (MSUREFIRE-170) Classpath in XML report is wrong
[ http://jira.codehaus.org/browse/MSUREFIRE-170?page=comments#action_80682 ] Joerg Schaible commented on MSUREFIRE-170: -- If the trunk can be used together with upcoming Maven 2.0.5 ... ;-) > Classpath in XML report is wrong > > > Key: MSUREFIRE-170 > URL: http://jira.codehaus.org/browse/MSUREFIRE-170 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug > Components: xml generation >Reporter: Joerg Schaible >Priority: Minor > > The XML report contains in the property java.class.path Maven's classpath, > but not the class path used to execute the tests. -- 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-1245) Hessian 3.0.8
Hessian 3.0.8 - Key: MAVENUPLOAD-1245 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1245 Project: maven-upload-requests Issue Type: Task Reporter: Simone Bordet Attachments: hessian-3.0.8-bundle.jar Please upload Hessian 3.0.8, used to convert MX4J to Maven2. -- 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-2664) Add native support for webdav
[ http://jira.codehaus.org/browse/MNG-2664?page=comments#action_80691 ] Arnaud Heritier commented on MNG-2664: -- Trygve, I agree but the the best is the enemy of good. I we can't fix the deploy plugin before the 2.0.5 release, I think that it can be a temporary workaround. It's very annoying to have to modify the original distribution for each user who want to upload artifacts using webdav. WDYT ? > Add native support for webdav > - > > Key: MNG-2664 > URL: http://jira.codehaus.org/browse/MNG-2664 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Arnaud Heritier > Fix For: 2.0.5 > > Attachments: MNG-2664.patch > > > Actually with maven 2.0.4 we can't use the deploy:deploy-file goal to add an > artifact on a remote repository with webdav. > This is really annoying for archiva which supports webdav for uploads. -- 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: (MPIR-58) The sandbox component Jar has been renamed to JarAnalyzer
The sandbox component Jar has been renamed to JarAnalyzer - Key: MPIR-58 URL: http://jira.codehaus.org/browse/MPIR-58 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Affects Versions: 2.0-beta-3 Environment: ALl Reporter: Hermod Opstvedt Attachments: projectreport.patch The sandbox component Jar has been renamed to JarAnalyzer. Attached is a patch for this. There is one prerequisite for this patch, which is a patch for the JarAnalyzer. The method setFile was had accessor protected, but needs to be public. -- 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: (MEAR-43) add ability to do filtering (i.e. template var replacement) for files in src/main/application/
[ http://jira.codehaus.org/browse/MEAR-43?page=comments#action_80693 ] Stephane Nicoll commented on MEAR-43: - Actually we do this with resourcesDir and it's being deprecated :) Let's do it that way. I'll implement something for 2.4 Now decreasing the priority. > add ability to do filtering (i.e. template var replacement) for files in > src/main/application/ > -- > > Key: MEAR-43 > URL: http://jira.codehaus.org/browse/MEAR-43 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Ian Springer > Assigned To: Stephane Nicoll > Fix For: 2.4 > > > I need to do some template var replacements in files in > src/main/application/. It would be great if the ear plugin could provide a > filtering configuration in a similar manner to the war plugin. That is, > something along the lines of: > > ... > > true > -- 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: (MEAR-43) add ability to do filtering (i.e. template var replacement) for files in src/main/application/
[ http://jira.codehaus.org/browse/MEAR-43?page=all ] Stephane Nicoll updated MEAR-43: Priority: Minor (was: Major) > add ability to do filtering (i.e. template var replacement) for files in > src/main/application/ > -- > > Key: MEAR-43 > URL: http://jira.codehaus.org/browse/MEAR-43 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Ian Springer > Assigned To: Stephane Nicoll >Priority: Minor > Fix For: 2.4 > > > I need to do some template var replacements in files in > src/main/application/. It would be great if the ear plugin could provide a > filtering configuration in a similar manner to the war plugin. That is, > something along the lines of: > > ... > > true > -- 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: (CONTINUUM-1004) Continuum Log File rotation
[ http://jira.codehaus.org/browse/CONTINUUM-1004?page=all ] Emmanuel Venisse closed CONTINUUM-1004. --- Resolution: Fixed Fix Version/s: 1.1 Applied but I kept the threshold to INFO > Continuum Log File rotation > --- > > Key: CONTINUUM-1004 > URL: http://jira.codehaus.org/browse/CONTINUUM-1004 > Project: Continuum > Issue Type: Improvement >Reporter: Allan Ramirez > Assigned To: Allan Ramirez > Fix For: 1.1 > > Attachments: CONTINUUM-1004-continuum-webapp.patch > > > Continuum should have log file rotation similar to Archiva. > Each day Archiva starts with a new log file without stopping and starting. -- 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-2662) SettingsBuilder internally converts network paths to local paths and is therefore preventing the use of network profiles
[ http://jira.codehaus.org/browse/MNG-2662?page=all ] Daniel Bechler updated MNG-2662: Attachment: maven-settings-patch-PROPER.diff Ups, sorry. The first patch was not created properly. Please use the attached version (maven-settings-patch-PROPER.diff) instead. > SettingsBuilder internally converts network paths to local paths and is > therefore preventing the use of network profiles > > > Key: MNG-2662 > URL: http://jira.codehaus.org/browse/MNG-2662 > Project: Maven 2 > Issue Type: Bug > Components: Settings >Affects Versions: 2.0.4 > Environment: Windows XP, Domain-Environment, Network User-Profile >Reporter: Daniel Bechler >Priority: Minor > Attachments: maven-settings-patch-PROPER.diff, patch.diff > > > I'm not sure if this is a bug or intended but the DefaultMavenSettingsBuilder > converts paths like "\\server\username\.m2\settings.xml" to " Drive>:\server\username\.m2\settings.xml". This prevented us from using the > default user.home because our userprofiles are located on another server and > are referenced by "\\" network paths. It would've been quite complicated to > change the user.home system property for all developers, so we fixed the > problem by removing a regular expression that replaced double backslashes by > only one, followed by calling "new File(path).getAbsolutePath()" which added > the current drive letter to the path and converted it to a local path this > way. > I don't know the reason for removing double backslashes from the beginning > but at least i didn't recognize any problems with my changes yet. It would be > nice if somebody could tell me what the regexp was intended for. I attached a > patch to this posting and hope it helps! -- 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-189) Coordinate the efforts of several users to write a Dashboard Plugin for Maven 2
[ http://jira.codehaus.org/browse/MSITE-189?page=comments#action_80669 ] Kay Grosskop commented on MSITE-189: Hoi we have also made our proprietary Dashboard plugin. I hope to convince my manager soon to be able to contribute to a common effort. I think it does not make sense to invent this many times. I havn't had time yet to investigate the qalab & radar functionality and source in depth. By the time we wrote our plugin the state of the project was unclear. Anyhow our plugin features: - aggregation of a number of results from submodules in a multi-module project. (findbugs,checkstyle,junit,cobertura,ncss) - history charts on the collected data. I think the issue 188 is not really to the point here. The problem is, as far as I understand, that on multimodule projects the maven engine wil go through the reporting fases of the submodules and there is no hook to do a data aggregation and chart generation step afterwards. It seems to be a feature of the maven build lifecyle. the workaround for us was not to define the dashboard-plugin as a report plugin at all, but to run it after the site generation. like mvn site dashboard-plugin:collect site:deploy I also see the aggregation and history as two conceptually different tasks. The first should be resolved on a more generic level in a way that makes it easier for plugin writers to aggregate their data on multimodule builds (currently it seems that only javadoc en ncss knew to hack their way ) The history collection and chart generation should be the core of concern of a dashboard/history plugin. what do you think. > Coordinate the efforts of several users to write a Dashboard Plugin for Maven > 2 > --- > > Key: MSITE-189 > URL: http://jira.codehaus.org/browse/MSITE-189 > Project: Maven 2.x Site Plugin > Issue Type: Task >Reporter: Gisbert Amm > Attachments: screenshot-1.jpg > > > Coordinate the efforts of several users to write a Dashboard Plugin for Maven > 2 > Several people started their own Dashboard plugins (see > http://jira.codehaus.org/browse/MSITE-188 and discussions on the users > mailing list). It would be better, if one of those implementations would be > adopted by the Maven team and the various development efforts would be > coordinated and focused to that one. -- 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: (MANTRUN-63) ant classpath resolves incorrectly if project is invoked as part of multi-project builds
ant classpath resolves incorrectly if project is invoked as part of
multi-project builds
Key: MANTRUN-63
URL: http://jira.codehaus.org/browse/MANTRUN-63
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Environment: maven-2.0.4, java 5, XP and linux
Reporter: Binyan
I have the following pom definition:
maven-antrun-plugin
package
MPC: ${mpc}
run
ant
ant-nodeps
1.6.5
with the output being:
[INFO] Executing tasks
[echo] MPC: C:\Documents and
Settings\binyan\.m2\repository\ant\ant-nodeps\1.6.5\ant-nodeps-1.6.5.jar;C:\Documents
and Settings\binyan\.m2\repository\ant\ant\1.6.5\ant-1.6.5.jar;C:\Documents
and
Settings\binyan\.m2\repository\ant\ant-launcher\1.6.5\ant-launcher-1.6.5.jar;E:\maven\lib\maven-project-2.0.4.jar;E:\maven\lib\maven-plugin-api-2.0.4.jar
... [ sucessful build performed] ...
Everything works fine if I build the project standalone, however, if the
project is part of a maven multi-project build and invoked by the top level
project then I get the following output:
[INFO] Executing tasks
[echo] MPC: C:\Documents and
Settings\binyan\.m2\repository\ant\ant\1.6.5\ant-1.6.5.jar;C:\Documents and
Settings\binyan\.m2\repository\ant\ant-launcher\1.6.5\ant-launcher-1.6.5.jar;E:\maven\lib\maven-project-2.0.4.jar;E:\maven\lib\maven-plugin-api-2.0.4.jar
init:
[mkdir] Created dir:
E:\dev\workspace-eclipse\MX\installs\target\installer-staging\mxscripts
[mkdir] Created dir:
E:\dev\workspace-eclipse\MX\installs\target\installer-staging\wars
build-staging:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: The following error occurred while executing this line:
E:\dev\workspace-eclipse\MX\installs\build.xml:23: Could not create type
regexpmapper due to No supported regular expression matcher found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant
tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
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.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 executing ant
tasks
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:114)
at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
... 16 more
Caused by: The following error occurred while executing this line:
E:\dev\workspace-eclipse\MX\installs\build.xml:23: Could not create type
regexpmapper due to No supported regular expression matcher found
at
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:539)
at org.apache.tools.ant.taskdefs.Ant.execute(An
[jira] Created: (MNG-2673) Change accessor of setFile in JarAnalyzer of maven-shared-jar
Change accessor of setFile in JarAnalyzer of maven-shared-jar - Key: MNG-2673 URL: http://jira.codehaus.org/browse/MNG-2673 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Reporter: Hermod Opstvedt Attachments: jaranalyzer.patch When renaming the Jar to JarAnalyzer, the accessor of setFile changed. The maven-project-info-reports-plugin uses this method to the the jarfile to analyze, so it need to be public. Attached is patch for it. -- 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-1240) Please upload new version of xmlenc
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1240?page=comments#action_80614 ] Carlos Sanchez commented on MAVENUPLOAD-1240: - Read http://maven.apache.org/guides/mini/guide-ibiblio-upload.html for instructions > Please upload new version of xmlenc > --- > > Key: MAVENUPLOAD-1240 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1240 > Project: maven-upload-requests > Issue Type: Task >Reporter: Anthony Goubard > Attachments: pom.xml > > > Note that xmlenc is already known in Maven2 repository (but it wasn't me who > put it). > If you have any questions, contact me at [EMAIL PROTECTED] -- 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: (SCM-253) AbstractCvsRemoveCommand must ignore "message" argument
AbstractCvsRemoveCommand must ignore "message" argument --- Key: SCM-253 URL: http://jira.codehaus.org/browse/SCM-253 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0-beta-3 Environment: xp, linux Reporter: Dan Tran I am writing a test suites which use maven-scm-api to read/write to multiple scm types ( cvs, svn, and starteam) Remove command fails since it generates -m option which is illegal in CVS. We should completely ignore the message argument for CVS provider Here is the message [INFO] Working directory: /opt/proj/dtran/dev//integration/replay/replay-cvstest/target/replay-test/working-copy [INFO] Executing: cvs -z3 -f -d /opt/proj/dtran/dev//integration/replay/replay-cvstest/target/replay-test/repository -q remove -f -l -m '"remove Foo.java"' src/main/java/Foo.java Provider message -- The cvs command failed. -- -- Command output -- remove: invalid option -- m Usage: cvs remove [-flR] [files...] -f Delete the file before removing it. -l Process this directory only (not recursive). -R Process directories recursively. (Specify the --help global option for a list of other help options) -- 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] Moved: (SCM-250) executing mvn test twice fails
[ http://jira.codehaus.org/browse/SCM-250?page=all ] Lukas Theussl moved MPSCM-91 to SCM-250: Affects Version/s: (was: 1.6) Complexity: Intermediate Workflow: Maven New (was: jira) Key: SCM-250 (was: MPSCM-91) Project: Maven SCM (was: maven-scm-plugin) > executing mvn test twice fails > -- > > Key: SCM-250 > URL: http://jira.codehaus.org/browse/SCM-250 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin >Reporter: Franz Allan Valencia See >Priority: Minor > > TagMojoTest fails when doing a second mvn test because one of its tests > asserts if a file does not exist, and if it does not, it proceeds with the > checkout and checks if that file now exists. > However, since that file is not cleaned up, doing a second mvn test will > fail, unless an mvn clean is executed first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1238) Please upload speculoos 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1238?page=all ] Carlos Sanchez closed MAVENUPLOAD-1238. --- Assignee: Carlos Sanchez Resolution: Fixed > Please upload speculoos 1.0 > --- > > Key: MAVENUPLOAD-1238 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1238 > Project: maven-upload-requests > Issue Type: Task >Reporter: Thomas Recloux > Assigned To: Carlos Sanchez > > http://speculoos.sourceforge.net/mvn-central-upload/speculoos-rt-1.0-bundle.jar > http://speculoos.sourceforge.net/mvn-central-upload/speculoos-gen-1.0-bundle.jar > http://speculoos.sourceforge.net/mvn-central-upload/speculoos-jndi-rt-1.0-bundle.jar > http://speculoos.sourceforge.net/mvn-central-upload/speculoos-jndi-gen-1.0-bundle.jar > http://speculoos.sourceforge.net/mvn-central-upload/speculoos-commons-1.0-bundle.jar > http://speculoos.sourceforge.net/mvn-central-upload/speculoos-all-bundle-1.0.jar > http://speculoos.sourceforge.net/ > http://speculoos.sourceforge.net/team-list.html > A tool for generating objects that allow easy mapping from java to jndi/ldap > data storage and integration of different data sources in a transparent data > access layer. > 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: (MECLIPSE-178) symbolic links need to able to be specified in the pom
[ http://jira.codehaus.org/browse/MECLIPSE-178?page=comments#action_80684 ] Maurice Zeijen commented on MECLIPSE-178: - It would really be great if you could create absolute symbolic links from the project root. For example a 'shortcut' link to the src/main/webapp directory. > symbolic links need to able to be specified in the pom > -- > > Key: MECLIPSE-178 > URL: http://jira.codehaus.org/browse/MECLIPSE-178 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: Jim Sellers > Fix For: 2.4 > > > In eclipse, you can make a symbolic link to a file. > create new file -> advanced -> "link to file in the system". > This will create a part in the .project file like this: > > > src/test/resources/oracle-ds.xml > 1 > > C://jboss/server/default/deploy/oracle-ds.xml > > > When you run "mvn eclipse:eclipse" this gets wipped out. It would be great > if this soft link didn't have to be re-created someone runs the command. -- 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: (MRM-231) Repository roles are not removed when a repository is removed
Repository roles are not removed when a repository is removed - Key: MRM-231 URL: http://jira.codehaus.org/browse/MRM-231 Project: Archiva Issue Type: Bug Reporter: Maria Odea Ching -- 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: (MANTRUN-62) line.separator property not passed properly to ant
line.separator property not passed properly to ant
--
Key: MANTRUN-62
URL: http://jira.codehaus.org/browse/MANTRUN-62
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Environment: maven 2.0.4
Reporter: Corporate Gadfly
Attachments: build.xml, pom.xml
line.separator does not resolve properly inside an ant task (using
maven-antrun-plugin).
E.g., using the 2 attached files, running
{code}ant{code} produces the following output {code}Buildfile: build.xml
echo:
[echo]
[echo] line.separator: --
[echo] --
[echo] os.name: --Linux--
[echo]
BUILD SUCCESSFUL
Total time: 0 seconds{code}
which is all okay, so far (new line is being shown on the echo line).
However, when using {code}mvn initialize{code}, we get the following output
{code}[INFO] Scanning for projects...
[INFO]
[INFO] Building Maven Echo
[INFO]task-segment: [initialize]
[INFO]
[INFO] [antrun:run {execution: echo-no-properties}]
[INFO] Executing tasks
echo:
[echo]
[echo] line.separator: --${line.separator}--
[echo] os.name: --${os.name}--
[echo]
[INFO] Executed tasks
[INFO] [antrun:run {execution: echo-with-properties}]
[INFO] Executing tasks
echo:
[echo]
[echo] line.separator: -- --
[echo] os.name: --Linux--
[echo]
[INFO] Executed tasks
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Tue Nov 21 15:26:55 EST 2006
[INFO] Final Memory: 3M/508M
[INFO]
{code}
I have two questions:
# Why do I have to specify all the properties one-by-one while calling the
target?
# Why is the output for line.separator not what is expected?
--
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-2672) Wrong dependency handling when having dependencies to artifacts in different versions
Wrong dependency handling when having dependencies to artifacts in different versions - Key: MNG-2672 URL: http://jira.codehaus.org/browse/MNG-2672 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: Windows XP, JDK 1.4.2_12 Reporter: Fabian Christ Hi, let's take a look at the following situation. There is a project A which has dependencies to B and C. Now both B and C have a dependency to D but in different versions. B requires version D-1.0 and C version D-2.0. Now in different situations is one time D-1.0 used and the next time D-2.0. There is no chance to configure which version will be used. Notice the restriction that I can't change the configured dependencies in B oder C - they are given.Here is a list of different configurations and their results: Base configuration: A: org.test B 1.0-SNAPSHOT compile org.test C 1.0-SNAPSHOT compile B: org.test D 1.0 compile C: org.test D 2.0 compile Debug: [DEBUG] org.test:A:jar:1.0 (selected for null) [DEBUG] org.test:B:jar:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] org.test:D:jar:1.0:compile (selected for compile) [DEBUG] org.test:C:jar:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] org.test:D:jar:2.0:compile (removed - nearer found: 1.0) => so D-1.0.jar is used Config 2: Exclude artifact D from dependency on B in A: org.test B 1.0-SNAPSHOT compile org.test D Debug: [DEBUG] org.test:A:jar:1.0 (selected for null) [DEBUG] org.test:B:jar:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] org.test:C:jar:1.0-SNAPSHOT:compile (selected for compile) ==> So D is never used (!) and so not on the classpath. Expected was to use D-2.0. The exclude seems not to work correct here as it excludes the artifact from the whole build. Config 3: No exclusions. Change dependency of A to B-1.0-SNAPSHOT to B-1.0 Debug: [DEBUG] org.test:A:jar:1.0 (selected for null) [DEBUG] org.test:C:jar:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] org.test:D:jar:2.0:compile (selected for compile) [DEBUG] org.test:B:jar:1.0:compile (selected for compile) [DEBUG] org.test:D:jar:1.0:compile (removed - nearer found: 2.0) ==> so D-2.0.jar is used (!). Why is version 2.0 nearer now than 1.0? In the base configuration above version 1.0 was nearer. Config 4: Change dependency of A to B-1.0-SNAPSHOT to B-1.0 Change dependency of A to C-1.0-SNAPSHOT to C-1.0 Debug: [DEBUG] org.test:A:jar:1.0 (selected for null) [DEBUG] org.test:C:jar:1.0:compile (selected for compile) [DEBUG] org.test:D:jar:2.0:compile (selected for compile) [DEBUG] org.test:B:jar:1.0:compile (selected for compile) [DEBUG] org.test:D:jar:1.0:compile (removed - nearer found: 2.0) ==> so D-2.0.jar is used. Same result as with config 3. So what would be the correct behavior here? At the moment it is not configurable which version of D will be used during compile. - Fabian -- 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-103) Simple test case where compile succeeds but javadoc fails
[ http://jira.codehaus.org/browse/MJAVADOC-103?page=comments#action_80653 ] Adam Lally commented on MJAVADOC-103: - However, it does not seem to *always* ignore the classpath of the child. I have a multimodule build where most of the modules work fine. There seems to be something special about this test case, maybe having to do with these particular dependent artifacts. It's possible there is some problem with transitive dependencies? But I'm just guessing. Also see http://jira.codehaus.org/browse/MJAVADOC-102, which I reported recently. Because of that bug, the error messages we're seeing here could be misleading side-effects that hide that root cause of the problem. > Simple test case where compile succeeds but javadoc fails > - > > Key: MJAVADOC-103 > URL: http://jira.codehaus.org/browse/MJAVADOC-103 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Adam Lally > Attachments: maven-javadoc-test.zip > > > The attached project has a parent POM with one module. The module has just > one simple Java class in it, but it has dependencies on some 3rd party > artifacts (available from a shared repository). > When I run "mvn install" for the parent, it succeeds. > If I run "mvn javadoc:javadoc" from the module, it succeeds. > If I run "mvn javadoc:javadoc" from the parent, it fails: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation. > Embedded error: Exit code: 1 - > C:/alally/dev/maven-javadoc-test/test-module/src/ > main/java/Test.java:3: package org.eclipse.jdt.ui does not exist > import org.eclipse.jdt.ui.ISharedImages; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:4: > package > org.eclipse.jdt.ui does not exist > import org.eclipse.jdt.ui.JavaUI; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:5: > package > org.eclipse.swt.graphics does not exist > import org.eclipse.swt.graphics.Image; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : class Image > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(IShare > dImages.IMG_OBJS_CLASS); > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : variable ISharedImages > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(ISharedImages.IMG_OBJS_CLASS); > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : variable JavaUI > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(ISharedImages.IMG_OBJS_CLASS); -- 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: (MEAR-47) since resourcesDir property is deprecated anyway, please make it optional and do not attempt to copy resources from it if is not explicitly set
[ http://jira.codehaus.org/browse/MEAR-47?page=all ]
Ian Springer reopened MEAR-47:
--
Oops. In the patch I submitted, when removing the default value for the
resourceDir field, I accidentally removed the @parameter Javadoc tag
altogether. Please make the following mod:
/**
* The directory to get the resources from.
*
* @parameter
* @deprecated
*/
private File resourcesDir;
That is, add back the @parameter tag, just without a default value.
> since resourcesDir property is deprecated anyway, please make it optional and
> do not attempt to copy resources from it if is not explicitly set
> ---
>
> Key: MEAR-47
> URL: http://jira.codehaus.org/browse/MEAR-47
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Ian Springer
> Assigned To: Stephane Nicoll
> Fix For: 2.3
>
> Attachments: make-resourcesDir-optional.patch,
> skip-resources-copy-if-resourceDir-equals-workDirectory.patch
>
>
> The deprecated resourcesDir property recently caused me quite a bit of grief.
> In our build environment we use a profile called "dev" that allows artifacts
> to be built directly to their test deploy locations, rather than to
> target/classes (or target/my.ear in the case of the ear plugin). To make this
> magic happen, I had to write a simple M2 plugin that allows you to override
> the value of project.build.directory and/or project.build.outputDirectory. So
> for our ear, the dev profile sets the ear plugin's workDirectory prop to
> /deploy/my.ear. It also sets project.build.outputDirectory to
> /deploy/my.ear in the pre-clean phase, so that the clean phase
> will delete /deploy/my.ear.
> The problem that I hit was that if I ran "mvn clean install",
> project.build.outputDirectory would still be set to
> "/deploy/my.ear" when mvn got to the default lifecycle, and
> since the ear plugin's resourcesDir property defaults to
> "${project.build.outputDirectory}", the ear plugin ends up trying to copy the
> contents of "/deploy/my.ear" over top of themselves, which
> causes all of the files in the ear to get zeroed out.
> Anyway, I know my use case is a bit unusual, but making the property optional
> and not doing anything if it's not explicitly set would save me from having
> to do an additional hack to reset project.build.outputDirectory at the
> beginning of the default lifecycle.
> Another acceptable alternative would be if the resource copying was skipped
> if resourceDir equals workDirectory.
> I've attached patches for both of the alternatives.
--
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: (MRM-231) Repository roles are not removed when a repository is removed
[ http://jira.codehaus.org/browse/MRM-231?page=all ] Maria Odea Ching updated MRM-231: - Due Date: 21/Nov/06 Remaining Estimate: 7 hours Original Estimate: 7 hours > Repository roles are not removed when a repository is removed > - > > Key: MRM-231 > URL: http://jira.codehaus.org/browse/MRM-231 > Project: Archiva > Issue Type: Bug >Reporter: Maria Odea Ching > Assigned To: Maria Odea Ching > Original Estimate: 7 hours > Remaining Estimate: 7 hours > -- 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: (MRM-231) Repository roles are not removed when a repository is removed
[ http://jira.codehaus.org/browse/MRM-231?page=comments#action_80643 ] Maria Odea Ching commented on MRM-231: -- Aside from the changes I made in DeleteRepositoryAction and AbstractDeleteRepositoryAction, I also submitted a patch in plexus security that is needed for this issue. Please refer to http://jira.codehaus.org/browse/PLX-296. Thanks! :) > Repository roles are not removed when a repository is removed > - > > Key: MRM-231 > URL: http://jira.codehaus.org/browse/MRM-231 > Project: Archiva > Issue Type: Bug >Reporter: Maria Odea Ching > Assigned To: Maria Odea Ching > Original Estimate: 7 hours > Time Spent: 7 hours > Remaining Estimate: 0 minutes > -- 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: (MSUREFIREREP-24) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MSUREFIREREP-24?page=all ] Carlos Sanchez updated MSUREFIREREP-24: --- Fix Version/s: 2.1 > Review Plugin Documentation > --- > > Key: MSUREFIREREP-24 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-24 > Project: Maven 2.x Surefire report Plugin > Issue Type: Task >Reporter: Allan Ramirez > Assigned To: Allan Ramirez > Fix For: 2.1 > > Attachments: MSUREFIREREP-24-maven-surefire-report-plugin.patch > > Original Estimate: 16 hours > Time Spent: 17 hours > Remaining Estimate: 0 minutes > -- 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: (MNGECLIPSE-212) Installation Fails
Installation Fails -- Key: MNGECLIPSE-212 URL: http://jira.codehaus.org/browse/MNGECLIPSE-212 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Affects Versions: 0.0.9 Environment: Linux, fresh install of eclipse 3.2.1, JDK 1.5.08 Reporter: Robert Smol Hello, thanks for this product, however I am having issue start using it. I've installed version 0.0.9 as other plugins and everything seemed to be ok. Restarted IDE and tried to right click on project Maven2->Enable and dialog Information appears: The chosen operation is not currently available. Also in Windows->Preferences->Maven2 I get error dialog Preference Page Creation Problems: Reason: Plug-in org.maven.ide.eclipse. was unable to load class org.maven.ide.eclipse.preferences.Mave2PreferencePage. I've installed Maven2Plugin into /opt/eclipse: czcholdnoc01 ~ # ll /opt/eclipse/* /opt/eclipse/features: total 0 drwxr-xr-x 2 rsmol users 80 2006-11-21 15:10 org.maven.ide.eclipse.feature_0.0.9 /opt/eclipse/plugins: total 9421 -rw-r--r-- 1 rsmol users 9635764 2006-11-21 15:10 org.maven.ide.eclipse_0.0.9.jar Any idea what am I doing wrong? Other plugins works, so I believe location is not the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-179) Create a branch instead of a tag
Create a branch instead of a tag Key: MRELEASE-179 URL: http://jira.codehaus.org/browse/MRELEASE-179 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Environment: Debian JDK 1.5 Reporter: Franck HUGOT When I release I first create a branch instead of a tag. Can you add this feature? I would like to choose when I prepare a release. Thanks in advance. -- 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: (MSUREFIREREP-22) Aggragated surefire report from modules
[ http://jira.codehaus.org/browse/MSUREFIREREP-22?page=all ] J-C Walmetz updated MSUREFIREREP-22: Attachment: patch2.patch First proposed patched does not works when I have more than 2 levels of modules. Patch2 corrects that issue > Aggragated surefire report from modules > --- > > Key: MSUREFIREREP-22 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-22 > Project: Maven 2.x Surefire report Plugin > Issue Type: New Feature >Affects Versions: 2.0 > Environment: all >Reporter: Bugittaa Pahasti > Attachments: patch.patch, patch2.patch, report.JPG > > > Aggregated surefire report from child modules. I think this has been > discussed in the mailing lists, but seemed not to be on Jira yet. -- 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: (MEAR-47) since resourcesDir property is deprecated anyway, please make it optional and do not attempt to copy resources from it if is not explicitly set
[ http://jira.codehaus.org/browse/MEAR-47?page=comments#action_80575 ]
Stephane Nicoll commented on MEAR-47:
-
This is good. First time I apply a patch without writing a test case first. My
bad, I shouldn't have applied it.
Thanks for the bug hunting :)
> since resourcesDir property is deprecated anyway, please make it optional and
> do not attempt to copy resources from it if is not explicitly set
> ---
>
> Key: MEAR-47
> URL: http://jira.codehaus.org/browse/MEAR-47
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Ian Springer
> Assigned To: Stephane Nicoll
> Fix For: 2.3
>
> Attachments: make-resourcesDir-optional.patch,
> skip-resources-copy-if-resourceDir-equals-workDirectory.patch
>
>
> The deprecated resourcesDir property recently caused me quite a bit of grief.
> In our build environment we use a profile called "dev" that allows artifacts
> to be built directly to their test deploy locations, rather than to
> target/classes (or target/my.ear in the case of the ear plugin). To make this
> magic happen, I had to write a simple M2 plugin that allows you to override
> the value of project.build.directory and/or project.build.outputDirectory. So
> for our ear, the dev profile sets the ear plugin's workDirectory prop to
> /deploy/my.ear. It also sets project.build.outputDirectory to
> /deploy/my.ear in the pre-clean phase, so that the clean phase
> will delete /deploy/my.ear.
> The problem that I hit was that if I ran "mvn clean install",
> project.build.outputDirectory would still be set to
> "/deploy/my.ear" when mvn got to the default lifecycle, and
> since the ear plugin's resourcesDir property defaults to
> "${project.build.outputDirectory}", the ear plugin ends up trying to copy the
> contents of "/deploy/my.ear" over top of themselves, which
> causes all of the files in the ear to get zeroed out.
> Anyway, I know my use case is a bit unusual, but making the property optional
> and not doing anything if it's not explicitly set would save me from having
> to do an additional hack to reset project.build.outputDirectory at the
> beginning of the default lifecycle.
> Another acceptable alternative would be if the resource copying was skipped
> if resourceDir equals workDirectory.
> I've attached patches for both of the alternatives.
--
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: (SCM-252) ClearCaseUpdateConsumer for I18N
ClearCaseUpdateConsumer for I18N
-
Key: SCM-252
URL: http://jira.codehaus.org/browse/SCM-252
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-clearcase
Affects Versions: 1.0-beta-3
Environment: does not dependency
Reporter: komusubi
It can't get updateFiles list way of indexOf("Loading") method because I use
Japanese version.
It might use ResourceBundle ??
I have to need fix it because use with continuum, so I can give you a patch,
but how should I do?
--
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-1242) JFreeChart 1.0.3
JFreeChart 1.0.3 Key: MAVENUPLOAD-1242 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1242 Project: maven-upload-requests Issue Type: Task Reporter: Takayoshi Kimura http://www.jfree.org/jfreechart/ -- 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: (MCHANGES-61) Provide DTD/XSD for changes.xml
[ http://jira.codehaus.org/browse/MCHANGES-61?page=comments#action_80577 ] Lukas Theussl commented on MCHANGES-61: --- The m1 plugin has an xsd already: http://svn.apache.org/viewvc/maven/maven-1/plugins/trunk/changes/src/plugin-resources/xsd/changes.xsd?revision=354742&view=markup > Provide DTD/XSD for changes.xml > --- > > Key: MCHANGES-61 > URL: http://jira.codehaus.org/browse/MCHANGES-61 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-2 >Reporter: Mark Hobson > > A DTD/XSD for changes.xml would be extremely useful for IDE auto-completion. > It should be hosted on the apache site. -- 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-1243) JCommon 1.0.6
JCommon 1.0.6 - Key: MAVENUPLOAD-1243 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1243 Project: maven-upload-requests Issue Type: Task Reporter: Takayoshi Kimura Attachments: jcommon-1.0.6-bundle.jar http://www.jfree.org/jcommon/ -- 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: (MCHANGES-61) Provide DTD/XSD for changes.xml
[ http://jira.codehaus.org/browse/MCHANGES-61?page=comments#action_80578 ] Mark Hobson commented on MCHANGES-61: - Cool, any chance of hosting this somewhere convenient? We would also ideally need a namespace. > Provide DTD/XSD for changes.xml > --- > > Key: MCHANGES-61 > URL: http://jira.codehaus.org/browse/MCHANGES-61 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-2 >Reporter: Mark Hobson > > A DTD/XSD for changes.xml would be extremely useful for IDE auto-completion. > It should be hosted on the apache site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-6) Multiproject Release: No check in
[ http://jira.codehaus.org/browse/MRELEASE-6?page=comments#action_80562 ] Wouter Boers commented on MRELEASE-6: - Just zoomin in on the eclipse problem. There is an easy workaround for the flat project layout. Do not use the src specification in the .classpath file but use the 'link' functionality which is stored in the .project file. > Multiproject Release: No check in > - > > Key: MRELEASE-6 > URL: http://jira.codehaus.org/browse/MRELEASE-6 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Windows XP, Eclipse Workspace >Reporter: Bernd Mau > Assigned To: Jason van Zyl >Priority: Critical > Fix For: 2.0-beta-5 > > > I tried to release a multiproject with 5 modules (on a Branch). Well, > the POMs of all modules are changed and there are some dependencies > which have been updated correctly. But only the master has been checked > in correctly. > I'm changed the recommended layout, to fit in an eclipse workspace. I > have one master at the same level as the other modules. > The module section of the master pom.xml: > > ../hhla.library.pom > ../hhla.library.site > ../hhla.lang > ../hhla.common.log4jx > -- 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-2671) Parent/modules relative file path compression
Parent/modules relative file path compression - Key: MNG-2671 URL: http://jira.codehaus.org/browse/MNG-2671 Project: Maven 2 Issue Type: Improvement Components: Inheritence and Interpolation Affects Versions: 2.0.4 Environment: Windows XP Reporter: Vincent Beretti Priority: Minor Sometimes a problem appears in M2 with parent and module structure due to the OS limitation in filepath length. For example Windows file path can not exceed 255 characters. But in complex maven 2 structure of parent/modules we can encounter a problem with that. In Eclipse, one has to put children projects in a flat structure. Example : in my filesystem my projects are : C:/ |-- parentProject/ |-- childprojectA/ |-- childProjectB/ But in maven the structure is as following : parentProject |-- childProjectA |-- childProjectB So in childProjectX poms, I have to references parent project like this : ../parentProject and the same for modules in parent as ../parentProject On a very complex structure, I have a path longer than 255 but in fact i could be compressed to remove .. for example when maven deletes target dir, it does like this : delete C:/parentProject/../childProjectA/target instead it could do delete C:/childProjectA. This would reduce the path length in very complex structures. See the post at : http://www.nabble.com/Parent-modules-File-path-compression-tf2628075s177.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] Commented: (MEAR-49) if an artifact in the list of ear modules already exists in the ear, the ear mojo will copy it on top of itself, zeroing out the file
[ http://jira.codehaus.org/browse/MEAR-49?page=comments#action_80561 ] Stephane Nicoll commented on MEAR-49: - How do we reproduce this unusual case? > if an artifact in the list of ear modules already exists in the ear, the ear > mojo will copy it on top of itself, zeroing out the file > - > > Key: MEAR-49 > URL: http://jira.codehaus.org/browse/MEAR-49 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ian Springer > Fix For: 2.3 > > Attachments: skip-already-deployed-module.patch > > > The ear plugin doesn't check for artifacts that are already deployed within > the ear, and so ends up redundantly copying such artifacts, e.g.: > copy C:/appserver/deploy/my.ear/lib/my.jar > C:/appserver/deploy/my.ear/lib/my.jar > and when you copy a file onto itself using the Plexus copy util method, it > zeros out the file (a bug in itself IMO but that's beside the point :). > A check should be added, so the ear plugin intelligently handles this, albeit > unusual, case. -- 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: (MEAR-49) if an artifact in the list of ear modules already exists in the ear, the ear mojo will copy it on top of itself, zeroing out the file
[ http://jira.codehaus.org/browse/MEAR-49?page=all ] Stephane Nicoll updated MEAR-49: Fix Version/s: 2.3 > if an artifact in the list of ear modules already exists in the ear, the ear > mojo will copy it on top of itself, zeroing out the file > - > > Key: MEAR-49 > URL: http://jira.codehaus.org/browse/MEAR-49 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ian Springer > Fix For: 2.3 > > Attachments: skip-already-deployed-module.patch > > > The ear plugin doesn't check for artifacts that are already deployed within > the ear, and so ends up redundantly copying such artifacts, e.g.: > copy C:/appserver/deploy/my.ear/lib/my.jar > C:/appserver/deploy/my.ear/lib/my.jar > and when you copy a file onto itself using the Plexus copy util method, it > zeros out the file (a bug in itself IMO but that's beside the point :). > A check should be added, so the ear plugin intelligently handles this, albeit > unusual, case. -- 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: (CONTINUUM-1005) A standard error message should display anytime an incorrect User ID or password is entered
[ http://jira.codehaus.org/browse/CONTINUUM-1005?page=all ] Maria Odea Ching updated CONTINUUM-1005: Attachment: CONTINUUM-1005-plexus-security.patch > A standard error message should display anytime an incorrect User ID or > password is entered > --- > > Key: CONTINUUM-1005 > URL: http://jira.codehaus.org/browse/CONTINUUM-1005 > Project: Continuum > Issue Type: Task >Reporter: Maria Odea Ching > Assigned To: Maria Odea Ching > Attachments: CONTINUUM-1005-plexus-security.patch > > > The error message should be: > "You have entered an incorrect username and/or password" -- 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-107) Dependency Version Incorrectly Taken from DependencyManagement
[ http://jira.codehaus.org/browse/MECLIPSE-107?page=comments#action_80581 ] Damien Lecan commented on MECLIPSE-107: --- I have the same problem, which is very annoying for me. Someone could work on that ? > Dependency Version Incorrectly Taken from DependencyManagement > -- > > Key: MECLIPSE-107 > URL: http://jira.codehaus.org/browse/MECLIPSE-107 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.2 >Reporter: Stephen Duncan Jr >Priority: Critical > Attachments: dmtest.zip > > > The version used when generating .classpath is taken from > dependencyManagement even though the child pom sets the dependency version, > which should override what is in dependencyManagement. This is a regression > from the correct behaviour in 2.1. > The attached project demonstrates the problem. The .classpath file generated > for the "child" project should specify log4j-1.2.13, but instead specifies > 1.28. -- 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: (CONTINUUM-1005) A standard error message should display anytime an incorrect User ID or password is entered
[ http://jira.codehaus.org/browse/CONTINUUM-1005?page=all ] Maria Odea Ching updated CONTINUUM-1005: Attachment: (was: CONTINUUM-1005-plexus-security.patch) > A standard error message should display anytime an incorrect User ID or > password is entered > --- > > Key: CONTINUUM-1005 > URL: http://jira.codehaus.org/browse/CONTINUUM-1005 > Project: Continuum > Issue Type: Task >Reporter: Maria Odea Ching > Assigned To: Maria Odea Ching > Attachments: CONTINUUM-1005-plexus-security.patch > > > The error message should be: > "You have entered an incorrect username and/or password" -- 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: (MPJETTY-2) Cannot compile jsp pages
[ http://jira.codehaus.org/browse/MPJETTY-2?page=comments#action_80539 ] john book commented on MPJETTY-2: - http://www.cisco21.kokoom.com/keydo500.html http://www.cisco21.kokoom.com/keydo452.html http://www.cisco21.kokoom.com/keydo244.html http://www.cisco21.kokoom.com/keydo304.html http://www.cisco21.kokoom.com/keydo303.html http://www.cisco21.kokoom.com/keydo254.html http://www.cisco21.kokoom.com/keydo266.html http://www.cisco21.kokoom.com/keydo267.html http://www.cisco21.kokoom.com/keydo245.html http://www.cisco21.kokoom.com/keydo288.html http://www.cisco21.kokoom.com/keydo268.html http://www.cisco21.kokoom.com/keydo286.html http://www.cisco21.kokoom.com/keydo289.html http://www.cisco21.kokoom.com/keydo287.html http://www.cisco21.kokoom.com/keydo247.html http://www.cisco21.kokoom.com/keydo251.html http://www.cisco21.kokoom.com/keydo256.html http://www.cisco21.kokoom.com/keydo258.html http://www.cisco21.kokoom.com/keydo248.html http://www.cisco21.kokoom.com/keydo262.html http://www.cisco21.kokoom.com/keydo252.html http://www.cisco21.kokoom.com/keydo249.html http://www.cisco21.kokoom.com/keydo246.html http://www.cisco21.kokoom.com/keydo269.html http://www.cisco21.kokoom.com/keydo250.html http://www.cisco21.kokoom.com/keydo253.html http://www.cisco21.kokoom.com/keydo277.html http://www.cisco21.kokoom.com/keydo255.html http://www.cisco21.kokoom.com/keydo280.html http://www.cisco21.kokoom.com/keydo283.html http://www.cisco21.kokoom.com/keydo284.html http://www.cisco21.kokoom.com/keydo259.html http://www.cisco21.kokoom.com/keydo263.html http://www.cisco21.kokoom.com/keydo265.html http://www.cisco21.kokoom.com/keydo257.html http://www.cisco21.kokoom.com/keydo260.html http://www.cisco21.kokoom.com/keydo261.html http://www.cisco21.kokoom.com/keydo290.html http://www.cisco21.kokoom.com/keydo264.html http://www.cisco21.kokoom.com/keydo292.html http://www.cisco21.kokoom.com/keydo272.html http://www.cisco21.kokoom.com/keydo294.html http://www.cisco21.kokoom.com/keydo296.html http://www.cisco21.kokoom.com/keydo270.html http://www.cisco21.kokoom.com/keydo271.html http://www.cisco21.kokoom.com/keydo273.html http://www.cisco21.kokoom.com/keydo274.html http://www.cisco21.kokoom.com/keydo275.html http://www.cisco21.kokoom.com/keydo276.html http://www.cisco21.kokoom.com/keydo278.html http://www.cisco21.kokoom.com/keydo281.html http://www.cisco21.kokoom.com/keydo297.html http://www.cisco21.kokoom.com/keydo298.html http://www.cisco21.kokoom.com/keydo299.html http://www.cisco21.kokoom.com/keydo285.html http://www.cisco21.kokoom.com/keydo300.html http://www.cisco21.kokoom.com/keydo301.html http://www.cisco21.kokoom.com/keydo169.html http://www.cisco21.kokoom.com/keydo302.html http://www.cisco21.kokoom.com/keydo279.html http://www.cisco21.kokoom.com/keydo47.html http://www.cisco21.kokoom.com/keydo282.html http://www.cisco21.kokoom.com/keydo206.html http://www.cisco21.kokoom.com/keydo291.html http://www.cisco21.kokoom.com/keydo293.html http://www.cisco21.kokoom.com/keydo295.html http://www.cisco21.kokoom.com/keydo456.html http://www.cisco21.kokoom.com/keydo157.html http://www.cisco21.kokoom.com/keydo449.html http://www.cisco21.kokoom.com/keydo24.html http://www.cisco21.kokoom.com/keydo363.html http://www.cisco21.kokoom.com/keydo409.html http://www.cisco21.kokoom.com/keydo432.html http://www.cisco21.kokoom.com/keydo108.html http://www.cisco21.kokoom.com/keydo431.html http://www.cisco21.kokoom.com/keydo238.html http://www.cisco21.kokoom.com/keydo412.html http://www.cisco21.kokoom.com/keydo415.html http://www.cisco21.kokoom.com/keydo418.html http://www.cisco21.kokoom.com/keydo312.html http://www.cisco21.kokoom.com/keydo413.html http://www.cisco21.kokoom.com/keydo438.html http://www.cisco21.kokoom.com/keydo416.html http://www.cisco21.kokoom.com/keydo419.html http://www.cisco21.kokoom.com/keydo414.html http://www.cisco21.kokoom.com/keydo311.html http://www.cisco21.kokoom.com/keydo408.html http://www.cisco21.kokoom.com/keydo410.html http://www.cisco21.kokoom.com/keydo344.html http://www.cisco21.kokoom.com/keydo411.html http://www.cisco21.kokoom.com/keydo417.html http://www.cisco21.kokoom.com/keydo234.html http://www.cisco21.kokoom.com/keydo65.html http://www.cisco21.kokoom.com/keydo497.html http://www.cisco21.kokoom.com/keydo46.html http://www.cisco21.kokoom.com/keydo231.html http://www.cisco21.kokoom.com/keydo186.html http://www.cisco21.kokoom.com/keydo314.html http://www.cisco21.kokoom.com/keydo195.html http://www.cisco21.kokoom.com/keydo183.html http://www.cisco21.kokoom.com/keydo490.html http://www.cisco21.kokoom.com/keydo347.html http://www.cisco21.kokoom.com/keydo203.html http://www.cisco21.kokoom.com/keydo306.html http://www.cisco21.kokoom.com/index.html http://www.cisco21.kokoom.com/keydo69.html http://www.cisco21.kokoom.com/keydo67.html http://www.cisco21.kokoom.com/keydo422.html http://www.cisco21.kokoom.com/keydo23.html http://www.cisco21.kokoom.com/keydo51.html http://www
[jira] Created: (SCM-251) Missing remove method in StarteamScmProvider class
Missing remove method in StarteamScmProvider class -- Key: SCM-251 URL: http://jira.codehaus.org/browse/SCM-251 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-starteam Affects Versions: 1.0-beta-3 Reporter: Dan Tran -- 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: (SCM-251) Missing remove method in StarteamScmProvider class
[ http://jira.codehaus.org/browse/SCM-251?page=all ] Dan Tran closed SCM-251. Assignee: Dan Tran Resolution: Fixed add the missing method in revision: 477352 > Missing remove method in StarteamScmProvider class > -- > > Key: SCM-251 > URL: http://jira.codehaus.org/browse/SCM-251 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-starteam >Affects Versions: 1.0-beta-3 >Reporter: Dan Tran > Assigned To: Dan Tran > -- 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-107) Dependency Version Incorrectly Taken from DependencyManagement
[ http://jira.codehaus.org/browse/MECLIPSE-107?page=comments#action_80585 ]
Damien Lecan commented on MECLIPSE-107:
---
I have looked at the code and this bad resolution comes from theses lines of
code :
{code:title=AbstractIdeSupportMojo.java, rev474384|borderStyle=solid}
Map managedVersions = createManagedVersionMap( getArtifactFactory(),
project.getId(),
project.getDependencyManagement() );
...
artifactResolutionResult = artifactCollector.collect(
getProjectArtifacts(), project.getArtifact(),
managedVersions, localRepo, project.getRemoteArtifactRepositories(),
getArtifactMetadataSource(), null, listeners );
{code}
The list of artifacts to add in .classpath is filtered by managed dependencies.
I don't understand why managed dependency have to be taken into account to
build .classpath ? This file may be build with just real dependencies ?
> Dependency Version Incorrectly Taken from DependencyManagement
> --
>
> Key: MECLIPSE-107
> URL: http://jira.codehaus.org/browse/MECLIPSE-107
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: dependency resolution
>Affects Versions: 2.2
>Reporter: Stephen Duncan Jr
>Priority: Critical
> Attachments: dmtest.zip
>
>
> The version used when generating .classpath is taken from
> dependencyManagement even though the child pom sets the dependency version,
> which should override what is in dependencyManagement. This is a regression
> from the correct behaviour in 2.1.
> The attached project demonstrates the problem. The .classpath file generated
> for the "child" project should specify log4j-1.2.13, but instead specifies
> 1.28.
--
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: (MEAR-49) if an artifact in the list of ear modules already exists in the ear, the ear mojo will copy it on top of itself, zeroing out the file
[ http://jira.codehaus.org/browse/MEAR-49?page=comments#action_80566 ] Ian Springer commented on MEAR-49: -- It happens when the "dev" profile I mentioned in an earlier issue is enabled. When dev mode is enabled, things get build directly to the test deployment location, rather than somewhere under target (this is done by using a custom plugin that allows project.build.directory and/or project.build.outputDirectory to be overridden). In this case, we have a couple of jars which are part of our reactor build. When dev mode is enabled, these jars will get built directly to /.../myjboss/.../deploy/my.ear/lib/ rather than to target/ (because project.build.directory has been overridden). When the ear pom in the same reactor is reached later in the build, the "file" fields of the in-memory ActiveProjectArtifacts that represent the two afore-mentioned jars are set to /.../myjboss/.../deploy/my.ear/lib/xxx.jar. And the destination path that the ear plugin computes will also end up pointing to /.../myjboss/.../deploy/my.ear/lib/xxx.jar. So the jar has already been placed where it needs to go earlier in the reactor build. In case you actually want to try to reproduce this, I'll attach the custom plugin I mentioned which has two goals - one that allows you to override project.build.directory and another that allows you to override project.build.outputDirectory. > if an artifact in the list of ear modules already exists in the ear, the ear > mojo will copy it on top of itself, zeroing out the file > - > > Key: MEAR-49 > URL: http://jira.codehaus.org/browse/MEAR-49 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ian Springer > Assigned To: Stephane Nicoll > Fix For: 2.3 > > Attachments: skip-already-deployed-module.patch > > > The ear plugin doesn't check for artifacts that are already deployed within > the ear, and so ends up redundantly copying such artifacts, e.g.: > copy C:/appserver/deploy/my.ear/lib/my.jar > C:/appserver/deploy/my.ear/lib/my.jar > and when you copy a file onto itself using the Plexus copy util method, it > zeros out the file (a bug in itself IMO but that's beside the point :). > A check should be added, so the ear plugin intelligently handles this, albeit > unusual, case. -- 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: (MEAR-49) if an artifact in the list of ear modules already exists in the ear, the ear mojo will copy it on top of itself, zeroing out the file
[ http://jira.codehaus.org/browse/MEAR-49?page=all ] Ian Springer updated MEAR-49: - Attachment: on-build-m2-plugin.zip > if an artifact in the list of ear modules already exists in the ear, the ear > mojo will copy it on top of itself, zeroing out the file > - > > Key: MEAR-49 > URL: http://jira.codehaus.org/browse/MEAR-49 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ian Springer > Assigned To: Stephane Nicoll > Fix For: 2.3 > > Attachments: on-build-m2-plugin.zip, > skip-already-deployed-module.patch > > > The ear plugin doesn't check for artifacts that are already deployed within > the ear, and so ends up redundantly copying such artifacts, e.g.: > copy C:/appserver/deploy/my.ear/lib/my.jar > C:/appserver/deploy/my.ear/lib/my.jar > and when you copy a file onto itself using the Plexus copy util method, it > zeros out the file (a bug in itself IMO but that's beside the point :). > A check should be added, so the ear plugin intelligently handles this, albeit > unusual, case. -- 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: (MDEP-26) New goal to write classpath string with all dependencies from local repo
[ http://jira.codehaus.org/browse/MDEP-26?page=comments#action_80723 ]
Timo Wolf commented on MDEP-26:
---
Hi All,
In addition, it would make sense to write the dependencies into a file with a
defined pattern.
I am using the assembly plugin to create a Mac OS X java application. OS X
applications are using an xml file to describe the application, containing the
main class and the jar files that are in the classpath.
Currently I have to change the xml file by hand if I add a new jar file or if I
am using a new version.
Below is a sample of the xml file used by OS X.
Java
Arguments
rat.properties
ClassPath
ant-optional.jar
avalon-framework.jar
batik-1.5-fop.jar
binding.jar
colt.jar
commons-beanutils.jar
commons-collections.jar
> New goal to write classpath string with all dependencies from local repo
>
>
> Key: MDEP-26
> URL: http://jira.codehaus.org/browse/MDEP-26
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
>Affects Versions: 1.0
>Reporter: Anagnostopoulos Kostis
> Assigned To: Brian Fox
>Priority: Minor
> Attachments: MDEP-26_BuildClasspathMojo.java
>
>
> Hi to all,
> 'm wondering whether it would be usefull to make a new mojo that when
> executed it will output a text file containing the required classpath string
> to run a project directly from the local repository.
> For instance, the file would contain a classpath string like that :
> {noformat}
> /home/foo/.m2/repository/org/java/utils/util/util-1.0.jar:/home/foo/.m2/
>
> {noformat}
> The result file could then be used like that:
> {noformat}
> java -cp `cat resultFile` MyClass
> {noformat}
> The new goal should maybe a sub-class of AbstractFromDependenciesMojo.
> In that case, the "useSubDirectoryPerType" and "useSubDirectoryPerArtifact"
> params should move to (copy/unpack)-dependencies mojo classes. Anyway, these
> params are only used by sub-classes, so, their definition should be propably
> inside of those.
> Next are the parameters of the mojo i propose:
>
> goal name: dependency:printClasspath
> params:
> || Param Name || Type || Description
> | outputFile| File | The file to write the classpath string into.
> |
> | overwrite | boolean| If true, re-write file even when nothing has
> changed. |
> | includeTypes | String | Comma Separated list of Types to include. |
> | excludeTypes | String | Comma Separated list of Types to exclude |
> | includeProjectArtifact| boolean | see [this
> issue|http://jira.codehaus.org/browse/MDEP-25]. |
--
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: (MANTRUN-54) Provide ability to register (test) resource roots [patch included!]
[ http://jira.codehaus.org/browse/MANTRUN-54?page=comments#action_80724 ]
Greg Kick commented on MANTRUN-54:
--
I was just thinking that this feature would make my life much easier... and it
comes with a patch! +1
> Provide ability to register (test) resource roots [patch included!]
> ---
>
> Key: MANTRUN-54
> URL: http://jira.codehaus.org/browse/MANTRUN-54
> Project: Maven 2.x Antrun Plugin
> Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Andreas Schildbach
>
> Index:
> C:/dev/workspace/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java
> ===
> ---
> C:/dev/workspace/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java
> (revision 416302)
> +++
> C:/dev/workspace/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java
> (working copy)
> @@ -18,6 +18,7 @@
>
> import java.io.File;
>
> +import org.apache.maven.model.Resource;
> import org.apache.maven.plugin.MojoExecutionException;
> import org.apache.maven.project.MavenProject;
> import org.apache.tools.ant.Target;
> @@ -75,6 +76,16 @@
> private File testSourceRoot;
>
> /**
> + * @parameter expression="${resourceRoot}"
> + */
> +private Resource resourceRoot;
> +
> +/**
> + * @parameter expression="${testResourceRoot}"
> + */
> +
> +private Resource testResourceRoot;
> +/**
> */
> public void execute()
> throws MojoExecutionException
> @@ -93,5 +104,16 @@
> project.addTestCompileSourceRoot( testSourceRoot.toString() );
> }
>
> +if (resourceRoot != null)
> +{
> +getLog().info("Registering resource root " + resourceRoot);
> +project.addResource(resourceRoot);
> +}
> +
> +if (testResourceRoot != null)
> +{
> +getLog().info("Registering test resource root " +
> testResourceRoot);
> +project.addResource(resourceRoot);
> +}
> }
> }
--
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-1240) Please upload new version of xmlenc
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1240?page=comments#action_80725 ] Joerg Schaible commented on MAVENUPLOAD-1240: - Step 1 is creating the bundle ... you did not provide one (re-read the instructions). See, it is a tedious task for Carlos to upload all the artifacts manually to the repo. Therefore a bundle has to be provided to allow at least some kind of semi-automatism and checks. > Please upload new version of xmlenc > --- > > Key: MAVENUPLOAD-1240 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1240 > Project: maven-upload-requests > Issue Type: Task >Reporter: Anthony Goubard > Attachments: pom.xml > > > Note that xmlenc is already known in Maven2 repository (but it wasn't me who > put it). > If you have any questions, contact me at [EMAIL PROTECTED] -- 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: (MPECLIPSE-128) NPE during eclipse:make-artifacts
NPE during eclipse:make-artifacts - Key: MPECLIPSE-128 URL: http://jira.codehaus.org/browse/MPECLIPSE-128 Project: maven-eclipse-plugin Issue Type: Bug Environment: I'm using maven with ubuntu edgy. Running eclipse 3.2.1 with many installed features/plugins. Reporter: Markus Wolf During the eclipse:make-artifacts goal is a NPE for the org.apache.geronimo.runtime.v1_1.0.0 plugin with the following stacktrace: java.lang.NullPointerException at org.apache.maven.plugin.eclipse.MakeArtifactsMojo.processSingleFile(MakeArtifactsMojo.java:288) at org.apache.maven.plugin.eclipse.MakeArtifactsMojo.execute(MakeArtifactsMojo.java:199) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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
