[jira] Created: (MECLIPSE-214) Non-flat multiproject support (like idea plugin) + docs
Non-flat multiproject support (like idea plugin) + docs --- Key: MECLIPSE-214 URL: http://jira.codehaus.org/browse/MECLIPSE-214 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Affects Versions: 2.3 Reporter: Geoffrey De Smet Fix For: 2.4 A parent pom of a non-flat multiproject should be editable in Eclipse. It's possible, but it involves some tricks: Eclipse 3.2.1 With svn at least Subversive 1.1.x (RC4 currently) - Subclipse didn't work, older versions of Subversive either. Preferences/Team/SVN: For Subversive select SVNKit as provider. Here's what maven can do (because it works manually): - Create a simple project (!= not a java project) of the multiproject directory. - Mark all folders which are modules under that simple project as Derrived (right click/Info). - Create the module projects as they are created now. Note: If the simple project exists, its impractical to import the module projects in Eclipse: either you select each module folder as root during "import existing project" or you move the simple project for a moment. -- 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-1299) Document m1 xdocs compatibility with the m2 site plug-in
[ http://jira.codehaus.org/browse/MNG-1299?page=all ]
Jason van Zyl closed MNG-1299.
--
Resolution: Fixed
> Document m1 xdocs compatibility with the m2 site plug-in
>
>
> Key: MNG-1299
> URL: http://jira.codehaus.org/browse/MNG-1299
> Project: Maven 2
> Issue Type: Improvement
>Reporter: Jason van Zyl
> Fix For: 2.0.6
>
>
> The m2 site plugin now supports the ${basedir}/xdocs directory.
--
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: (MEV-487) Xalan and hsqldb versions outdated
[ http://jira.codehaus.org/browse/MEV-487?page=all ] Mikko Wuokko updated MEV-487: - Attachment: xalan-hsqldb-dependency.patch A proposal patch for the db-ojb-1.0.4.pom > Xalan and hsqldb versions outdated > -- > > Key: MEV-487 > URL: http://jira.codehaus.org/browse/MEV-487 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Mikko Wuokko > Attachments: xalan-hsqldb-dependency.patch > > > Xalan seems to use now x.x.x type of version so 2.4 -> 2.4.0. > I couldn find from the main Maven2 repos hsqldb of version 1.8.0, but there > are 1.8.0.1, 1.8.0.4, 1.8.0.5 and 1.8.0.1.7 versions. > Another thing I noticed is that the jar file for jdo 1.0.1 or neither the jar > or the pom files could not be found for jdori for any version. Don't know how > to handle that. -- 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: (MEV-487) Xalan and hsqldb versions outdated
Xalan and hsqldb versions outdated -- Key: MEV-487 URL: http://jira.codehaus.org/browse/MEV-487 Project: Maven Evangelism Issue Type: Bug Reporter: Mikko Wuokko Xalan seems to use now x.x.x type of version so 2.4 -> 2.4.0. I couldn find from the main Maven2 repos hsqldb of version 1.8.0, but there are 1.8.0.1, 1.8.0.4, 1.8.0.5 and 1.8.0.1.7 versions. Another thing I noticed is that the jar file for jdo 1.0.1 or neither the jar or the pom files could not be found for jdori for any version. Don't know how to handle that. -- 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-1318) Please upload DWR 2.0.rc2 to maven repo
Please upload DWR 2.0.rc2 to maven repo --- Key: MAVENUPLOAD-1318 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1318 Project: maven-upload-requests Issue Type: Task Reporter: Brendan Grainger Attachments: dwr-2.0.rc2-bundle.jar Hi, Please upload dwr 2.0.rc2 to ibiblio. DWR2 (rc1) has been uploaded previously. I've attached the bundle and it is also available on the project page at java.net. Please let me know if there are any issues. Regards Brendan Grainger -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-691) Build Numbers are obscured by the queuing/building icon
[ http://jira.codehaus.org/browse/CONTINUUM-691?page=comments#action_84712 ] Wendy Smoak commented on CONTINUUM-691: --- Screen shot demonstrating the problem: http://people.apache.org/~wsmoak/maven/continuum/continuum-build-in-progress-icon-obscures-build-number.jpg The icon is already displayed in the first column, it should not be duplicated in the 'Build' column, obscuring the build number. > Build Numbers are obscured by the queuing/building icon > --- > > Key: CONTINUUM-691 > URL: http://jira.codehaus.org/browse/CONTINUUM-691 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0.3 >Reporter: Christian Gruber >Priority: Critical > Fix For: 1.1 > > > In our system, we're building every five minutes or so, and we can't see the > last good build version number when things are queued or building. It would > be very helpful if the last good build could be completely independent of the > build status. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1121) Incorrect build number links on Project Group Summary
[ http://jira.codehaus.org/browse/CONTINUUM-1121?page=comments#action_84711 ] Wendy Smoak commented on CONTINUUM-1121: A series of screen shots from continuum/trunk r494414 showing the problem: http://people.apache.org/~wsmoak/maven/continuum/CONTINUUM-1121/ > Incorrect build number links on Project Group Summary > - > > Key: CONTINUUM-1121 > URL: http://jira.codehaus.org/browse/CONTINUUM-1121 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Wendy Smoak > > On the Project Group Summary, the 'build number' link is incorrect. > For example, the text '1' links to > > http://localhost:9090/continuum/buildResult.action?buildId=1&projectId=121&projectGroupId=10&projectName=Apache+Struts > This produces an error: >org.apache.maven.continuum.ContinuumException: No such object > The wrong buildId request parameter value is being used. The 1-based > sequential build number for each project is apparently not the key to the > results where they are stored. > For example, the corresponding 'build state' icon in the first column for > this project links to: >http://localhost:9090/continuum/buildResult.action?buildId=72&projectId=121 > Note: buildId=1 in the first link vs. buildId=72 in the second link. -- 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-1133) Project Site URL in wagon notifier edit pages is required but doesn't have validation
[ http://jira.codehaus.org/browse/CONTINUUM-1133?page=all ] Henry S. Isidro updated CONTINUUM-1133: --- Attachment: [CONTINUUM-1133]-continuum-webapp.patch File Attached: [CONTINUUM-1133]-continuum-webapp.patch The patch adds the necessary validation. > Project Site URL in wagon notifier edit pages is required but doesn't have > validation > - > > Key: CONTINUUM-1133 > URL: http://jira.codehaus.org/browse/CONTINUUM-1133 > Project: Continuum > Issue Type: Bug > Components: Notification Subsystem >Reporter: Henry S. Isidro >Priority: Minor > Attachments: [CONTINUUM-1133]-continuum-webapp.patch > > -- 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: (CONTINUUM-1133) Project Site URL in wagon notifier edit pages is required but doesn't have validation
Project Site URL in wagon notifier edit pages is required but doesn't have validation - Key: CONTINUUM-1133 URL: http://jira.codehaus.org/browse/CONTINUUM-1133 Project: Continuum Issue Type: Bug Components: Notification Subsystem Reporter: Henry S. Isidro Priority: Minor -- 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: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=comments#action_84708 ] Chris Byrd commented on MCOMPILER-22: - So this time I did step 1, then in step 2 I downloaded the source code from the maven-compiler-plugin-2.0.1 tag. That made things considerably easier. From what I can see on this page, it says the fix version is 2.0.2, I assume that is the version these fixes will be going into, eventually. >From that point I was able to apply Allan's patch >(maven-compiler-plugin-space-fix.patch) and install the new version of the >maven-compiler-plugin version 2.0.1 to my local repository. I went back to my original project and did another clean compile. This time I am back to the problem where there are spaces in the compiler options, so the compile fails. The error message is below. === [DEBUG] Command line options: [DEBUG] -d D:\Documents and Settings\xfxc104\My Documents\Dev\workspace\pw-qis\p w-qis-core\target\classes @D:\Documents and Settings\xfxc104\My Documents\Dev\wo rkspace\pw-qis\pw-qis-core\target\classes/options -classpath options; -g -nowarn -target 1.3 Compiling 1 source file to D:\Documents and Settings\xfxc104\My Documents\Dev\wo rkspace\pw-qis\pw-qis-core\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure Failure executing javac, but could not parse the error: javac: invalid argument: D:\Documents Usage: javac === After all that I am back to the original question, what patches am I supposed to apply, and in what order do I apply them? Any help is greatly appreciated. > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Matthew Beermann > Assigned To: Carlos Sanchez >Priority: Critical > Fix For: 2.1 > > Attachments: maven-compiler-plugin-space-fix.patch, > maven-compiler-plugin.patch, MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac-1.5.2.jar, > plexus-compiler-javac.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > 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:249) > 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.cod
[jira] Closed: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=all ] Carlos Sanchez closed MCOMPILER-22. --- Resolution: Fixed Fix Version/s: (was: 2.0.2) 2.1 Fixed in PLX-314 > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Matthew Beermann > Assigned To: Carlos Sanchez >Priority: Critical > Fix For: 2.1 > > Attachments: maven-compiler-plugin-space-fix.patch, > maven-compiler-plugin.patch, MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac-1.5.2.jar, > plexus-compiler-javac.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > 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:249) > 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.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 more -- 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: (MAVEN-1817) Maven doesn't try to find snapshots in all repositories
[ http://jira.codehaus.org/browse/MAVEN-1817?page=all ] Arnaud Heritier closed MAVEN-1817. -- Resolution: Won't Fix It's the normal behavior. In theory, a project doesn't deploy its snapshots on several repositories. For one project you have a repository for snapshots and one for release (or only one for both). > Maven doesn't try to find snapshots in all repositories > --- > > Key: MAVEN-1817 > URL: http://jira.codehaus.org/browse/MAVEN-1817 > Project: Maven 1.x > Issue Type: Bug > Components: core >Affects Versions: 1.1-beta-3 >Reporter: Arnaud Heritier > Assigned To: Arnaud Heritier > Fix For: 1.1-rc1 > > > In my environment I have several remote repositories. > When Maven tries to update a snapshot, as soon as it found the snapshot on a > given repo, it doesn't try to check if there's a more recent in another repo. -- 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: (MAVEN-1755) Backward Incompability : Usage of xml entities in the POM doesn't work in maven 1.1 beta 1 & 2
[ http://jira.codehaus.org/browse/MAVEN-1755?page=comments#action_84703 ] Arnaud Heritier commented on MAVEN-1755: It's now fixed. We use the stax reader/writer generated by modello. To close this issue we just have to wait for the releases of : modello 1.0-alpha-14, maven-modello-plugin 1.0, maven-model 3.0.2. We'll update our dependencies and it will be good. > Backward Incompability : Usage of xml entities in the POM doesn't work in > maven 1.1 beta 1 & 2 > -- > > Key: MAVEN-1755 > URL: http://jira.codehaus.org/browse/MAVEN-1755 > Project: Maven 1.x > Issue Type: Bug > Components: core >Affects Versions: 1.1-beta-2, 1.1-beta-1, 1.1-beta-3 >Reporter: Arnaud Heritier > Assigned To: Arnaud Heritier >Priority: Critical > Fix For: 1.1-rc1 > > Attachments: project-entities.zip > > > In maven 1.0.X it was possible to use entities in the POM. > It was used for example to share some elements like the organization, ... -- 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: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=comments#action_84702 ] Chris Byrd commented on MCOMPILER-22: - Thanks for the link, but I am still having issues. I will describe my steps below, and the issues that arose in each respective step. 1) I downloaded the jar file sent by Brahim Bakayoko. I then replaced the jar file in my local repository for the plexus-compiler-javac artifact. -- Issue: Just as Allan Shoup described, the fix provided by Brahim fails if there is a space in your path. This did not occur before the change. 2) Allan provided a patch to the maven-compiler-plugin, to fix the failure when you have a space in the path. I went to https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-compiler-plugin and checked out the most recent source code. -- Issue: I tried to clean compile the code, and I received an error. The code depends on the maven-plugins parent pom, version 8-SNAPSHOT. I looked for it in the central repository and http://snapshots.repository.codehaus.org/, but didn't find it. I finally found a link to plugin snapshots at http://cvs.apache.org/maven-snapshot-repository. 3) I added the http://cvs.apache.org/maven-snapshot-repository repository to the recently checked out maven-compiler-plugin code and tried the clean compile again. -- Issue: Aparently there are the 2-SNAPSHOT and 4-SNAPSHOT versions of the code in this repository, but not the 8-SNAPSHOT. Once again, I don't have the necessary dependencies to do the build. 4) I edited the pom.xml of the recently checked out maven-compiler-plugin source code, and changed the parent dependency from 8-SNAPSHOT to 4-SNAPSHOT. -- Issue: This did resolve the dependency and download the 4-SNAPSHOT artifact, so the build could continue. However, when I issued a mvn test command, the unit tests failed. 5) In the spirit of just trying things, I decided to skip the tests and just apply the patch and install. I applied Allan Shoup provided successfully. I then skipped the unit tests and installed the maven-compiler-plugin as the 2.1-SNAPSHOT it has listed in the code. -- Issue: This might be where I am going wrong here. Should I not check out the code from the trunk here? I guess I should check out the tagged 2.0.2 version instead. 6) The patch went in successfully. I installed the maven-compiler-plugin, edited my original project pom to use the new maven-compiler plugin 2.1-SNAPSHOT and tried a clean compile. -- Issue: I got a new error message, but things were still the same, I couldn't complete the build when forking to a new JDK. [INFO] [compiler:compile] [INFO] Os is :windows xp [INFO] Total # of java files for compilation are 25 [INFO] Compiling 1 source file to D:\Documents and Settings\xfxc104\My Documents \Dev\workspace\pw-qis\pw-qis-core\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure Failure executing javac, but could not parse the error: javac: invalid argument: D:\Documents and Settings\xfxc104\My Documents\Dev\work space\pw-qis\pw-qis-core\classes Usage: javac Summary: Can anyone give me some hints as to where to go from here. I'm looking at the attachments above, and I only used 2 of the 8 up there. I don't know if I am supposed to use all of them, only some of them, and in what order am I supposed to use them. I'm sure all of this seems quite mundane to those of you who perform these activities every day, but I assure you the process is far from clear for me. Any help you can provide is greatly appreciated. > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Matthew Beermann >Priority: Critical > Fix For: 2.0.2 > > Attachments: maven-compiler-plugin-space-fix.patch, > maven-compiler-plugin.patch, MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac-1.5.2.jar, > plexus-compiler-javac.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -targ
[jira] Closed: (MSITE-203) bannerRight is not right aligned if no image is used
[ http://jira.codehaus.org/browse/MSITE-203?page=all ] Vincent Siveton closed MSITE-203. - Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.0 Fixed by DOXIA-88 > bannerRight is not right aligned if no image is used > > > Key: MSITE-203 > URL: http://jira.codehaus.org/browse/MSITE-203 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Wendy Smoak > Assigned To: Vincent Siveton >Priority: Minor > Fix For: 2.0 > > Attachments: site-plugin-banner-right.jpg > > > In site.xml, if bannerRight does not contain a src element with a URL, then > the text or link produced from the name and href elements is not right > aligned. > To reproduce, generate a site module using the site archetype and make the > following change to site.xml: > @@ -6,7 +6,8 @@ > http://maven.apache.org/ > > > -http://maven.apache.org/images/maven-small.gif > +My Site > +http://maven.apache.org > > > > See attached image. The link with text "My Site" should be right aligned, > but isn't. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-88) Everything in bannerRight should be right aligned, not just images
[ http://jira.codehaus.org/browse/DOXIA-88?page=all ] Vincent Siveton closed DOXIA-88. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.0 Applied Thanks Wendy! > Everything in bannerRight should be right aligned, not just images > -- > > Key: DOXIA-88 > URL: http://jira.codehaus.org/browse/DOXIA-88 > Project: doxia > Issue Type: Bug > Components: Site Renderer >Affects Versions: 1.0 >Reporter: Wendy Smoak > Assigned To: Vincent Siveton >Priority: Minor > Fix For: 1.0 > > Attachments: banner-right-css.patch > > > Currently the bannerRight style is only applied to images. This causes > problems when only a name (and optionally a url) is provided in the site > descriptor, as the text will not be right aligned. > Tested by building maven-site-plugin which depends on doxia > 1.0-alpha-9-SNAPSHOT, and using it to build a site as described in MSITE-203. > Thanks to Dennis Lundberg for pointing out where to find this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-90) siternderer does not build
[ http://jira.codehaus.org/browse/DOXIA-90?page=comments#action_84699 ] Vincent Siveton commented on DOXIA-90: -- I tried with mvn 2.0.x and all seems ok here and in the zones [1] Could you provide us debug trace and the surefire reports? Thanks. Moreover, commons-collections:3.2 is needed by htmlunit (which uses it as dependency) in the test phase so it will be better to add test [1] http://maven.zones.apache.org/continuum/buildResults.action?projectId=123&projectGroupId=10 > siternderer does not build > -- > > Key: DOXIA-90 > URL: http://jira.codehaus.org/browse/DOXIA-90 > Project: doxia > Issue Type: Bug > Components: Site Renderer >Reporter: Henning Schmiedehausen > Fix For: 1.0 > > Attachments: ds.patch > > > The doxia-siterenderer module does not build. it does some automatic > dependency resolution for commons-collections and ends up with version 2.0 > which does not contain a required class: > patch is attached. -- 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: (MJAR-66) Maven fails to include generated resources
[ http://jira.codehaus.org/browse/MJAR-66?page=comments#action_84698 ]
Baerrach bonDierne commented on MJAR-66:
I haven't spent any time looking into it but I would suspect that because on a
clean the resource directory
{noformat}
target/generated-sources/axistools/java2wsdl
{noformat}
does not exist that it is not included in the project model.
The second run works as expected because the directory was created on the first
run.
Why isn't the axistools-maven-plugin programatically adding in additional
resources so the user doesn't need to modify their pom?
> Maven fails to include generated resources
> --
>
> Key: MJAR-66
> URL: http://jira.codehaus.org/browse/MJAR-66
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Linux (not tested on windows)
>Reporter: Leszek Ciesielski
> Attachments: ConfigurationServerAPI.tar.gz
>
>
> My project is generating a wsdl with axistools plugin. When maven is run with
> mvn clean install (or after a checkout), the wsdl is not packaged into the
> jar, although it is present when the jar is generated and included in
> resources. On second run (mvn install) the wsdl file, is, as expected,
> included.
> A test project showing this behaviour is attached.
--
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-1678) missing element does not trigger any warning
[ http://jira.codehaus.org/browse/MNG-1678?page=comments#action_84696 ] Brett Porter commented on MNG-1678: --- just a little clarification - this is not so much missing elements, as invalid elements. should be invalid. Modello does detect missing elements (via required), but we haven't been able to use it because of inheritence not being taken into consideration. In that case, we want to run some validation on the final model - maybe modello could generate a validator based on and some other bean validation (like xworks?) > missing element does not trigger any warning > > > Key: MNG-1678 > URL: http://jira.codehaus.org/browse/MNG-1678 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0, 2.0.4 >Reporter: Jorg Heymans > Assigned To: Maria Odea Ching > Fix For: 2.0.6 > > Original Estimate: 12 hours > Remaining Estimate: 12 hours > > spot the subtle error in below pom : > > > 4.0.0 > org.my.project > myProject > 0.1 > The Project > jar > > > apache-maven2-snapshot > Apache Maven2 Snapshot Repository > http://cvs.apache.org/maven-snapshot-repository > > > > org.apache.cocoon > cocoon-core > 2.2.0-SNAPSHOT > > > The dependency element is missing inside . Maven did not give > any warning or error though. > Note that in my actual project, the dependency was not needed for compilation -- 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-1592) Top level element in POM is not correctly validated
[ http://jira.codehaus.org/browse/MNG-1592?page=comments#action_84695 ] Brett Porter commented on MNG-1592: --- actually, I need to clarify this after updating. This should not be changed in the repository (and it's possibly not ever needed in the repository). It should be changed when reading the POM you are building. The fix to modello creates this situation, so I believe that using modello alpha-14 is enough to close this bug (and can be done in 2.0.x, 2.1, or whatever). > Top level element in POM is not correctly validated > --- > > Key: MNG-1592 > URL: http://jira.codehaus.org/browse/MNG-1592 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Carlos Sanchez > Assigned To: Jason van Zyl > Fix For: 2.1 > > Attachments: it1019.patch > > > this pom doesn't make the build break > > 4.0.0 > test > test > 1.0 > > and I'm starting to see wrong poms with a top level instead of > -- 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: (MAVEN-1825) Multiple tags not allowed in RC-1 (Duplicated tag: 'project')
[ http://jira.codehaus.org/browse/MAVEN-1825?page=comments#action_84692 ] G.J. Sterenborg commented on MAVEN-1825: Btw, it's an inheritance problem, like the post in the mail-thread. > Multiple tags not allowed in RC-1 (Duplicated tag: 'project') > > > Key: MAVEN-1825 > URL: http://jira.codehaus.org/browse/MAVEN-1825 > Project: Maven 1.x > Issue Type: Bug >Affects Versions: 1.1-rc1 >Reporter: G.J. Sterenborg > > We have combined multiple modules into components: > * component 1 > root-module-generic -- project-descriptor (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 2 > root-module-specific -- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 3 > root-module-specific2-- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * ... > Every module is released seperately in one big 'component-release'. > This component-release checks if a module has changed since the last release > and if so ups the version (and adds a -entry to module's pom.) > > Sub-modules root-module and the root-pom extends all dependent > component-descriptors. > The root-pom is specifies the component-version. > Every module gets it's own version and cvs-tag (including root-pom for the > component-version.) > After testing RC-1, seeing the 'Duplicated tag: 'project'' error and reading: > http://www.mail-archive.com/users@maven.apache.org/msg55210.html > I'm very surprised that tag duplication in parent/child modules isn't allowed > anymore. > Doesn't the parent-pom specify the entire project and the sub-module-poms > their own? -- 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-129) modules list empty if modules don't use this project as parent in reactor build
[ http://jira.codehaus.org/browse/MSITE-129?page=comments#action_84691 ]
Jason Melnick commented on MSITE-129:
-
I would like to have the priority raised on this issue as this will be a factor
in whether the enterprise decides to adopt maven for it's centralized builds.
The site generation "out-of-the-box" is a more than minor reason that it's
being investigated as the tool of choice.
Yes, there are other ways around this issue, but necessitating inheritance for
a reactor build is more than a nuisance at this point. I'm not happy with the
enormous parent POM that will now need maintained over the hierarchy I've
listed above.
I appreciate any help that can be given :)
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
> Assigned To: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0.1
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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-1592) Top level element in POM is not correctly validated
[ http://jira.codehaus.org/browse/MNG-1592?page=all ] Jason van Zyl updated MNG-1592: --- Assignee: Jason van Zyl Fix Version/s: (was: 2.0.5) 2.1 > Top level element in POM is not correctly validated > --- > > Key: MNG-1592 > URL: http://jira.codehaus.org/browse/MNG-1592 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Carlos Sanchez > Assigned To: Jason van Zyl > Fix For: 2.1 > > Attachments: it1019.patch > > > this pom doesn't make the build break > > 4.0.0 > test > test > 1.0 > > and I'm starting to see wrong poms with a top level instead of > -- 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-1678) missing element does not trigger any warning
[ http://jira.codehaus.org/browse/MNG-1678?page=all ] Jason van Zyl updated MNG-1678: --- Fix Version/s: (was: 2.0.5) 2.0.6 Strict mode in parsing doesn't catch any missing elements. > missing element does not trigger any warning > > > Key: MNG-1678 > URL: http://jira.codehaus.org/browse/MNG-1678 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0, 2.0.4 >Reporter: Jorg Heymans > Assigned To: Maria Odea Ching > Fix For: 2.0.6 > > Original Estimate: 12 hours > Remaining Estimate: 12 hours > > spot the subtle error in below pom : > > > 4.0.0 > org.my.project > myProject > 0.1 > The Project > jar > > > apache-maven2-snapshot > Apache Maven2 Snapshot Repository > http://cvs.apache.org/maven-snapshot-repository > > > > org.apache.cocoon > cocoon-core > 2.2.0-SNAPSHOT > > > The dependency element is missing inside . Maven did not give > any warning or error though. > Note that in my actual project, the dependency was not needed for compilation -- 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: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=comments#action_84687 ] Carlos Sanchez commented on MCOMPILER-22: - Breahim, please send a patch Check "Creating and submitting a patch" http://maven.apache.org/guides/development/guide-m2-development.html > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Matthew Beermann >Priority: Critical > Fix For: 2.0.2 > > Attachments: maven-compiler-plugin-space-fix.patch, > maven-compiler-plugin.patch, MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac-1.5.2.jar, > plexus-compiler-javac.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > 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:249) > 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.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 more -- 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: (MCOMPILER-48) Add maven.compile.failonerror equivalent functionality
[ http://jira.codehaus.org/browse/MCOMPILER-48?page=comments#action_84686 ]
Ben Alex commented on MCOMPILER-48:
---
If only JIRA maintained the same index numbers for attached files...
The two files to use are #1 and #3. Disregard the compiler-failonerror-test.zip
with a timestamp of 10/Jan/07 12:56 AM.
> Add maven.compile.failonerror equivalent functionality
> --
>
> Key: MCOMPILER-48
> URL: http://jira.codehaus.org/browse/MCOMPILER-48
> Project: Maven 2.x Compiler Plugin
> Issue Type: Improvement
>Reporter: Ben Alex
>Priority: Critical
> Attachments: compiler-failonerror-test.zip,
> compiler-failonerror-test.zip, patch.txt
>
>
> Maven 1.x's "java" plugin offered a maven.compile.failonerror property, which
> could be set false in order to skip compilation errors.
> I am working on a code generation framework that uses a Maven plugin. The
> mojo spawns a parallel lifecycle via @execute phase="test-compile", as the
> mojo itself is @phase generate-sources. This is necessary as the code
> generator needs to instantiate certain classes to obtain metadata. The nature
> of the generated types means that users might write code that depends on the
> generated types to already be compiled on the classpath, although this has
> not yet happened at this phase because the code generator requires compiled
> classes first. By the time the generated-sources phase completes and releases
> to the original lifecycle, the subsequent compilation will work as the
> generated sources are now available for compilation.
> In practice this issue is easily resolved if AbstractCompilerMojo supported
> the Maven 1 style maven.compile.failonerror = false property, which could be
> injected via the MavenProject class during the parallel lifecycle (and
> reverted upon completion). The relevant lines are:
> 504 if ( compilationError )
> 505 {
> 506 throw new CompilationFailureException( messages );
> 507 }
> 508 else
> 509 {
> 510 for ( Iterator i = messages.iterator(); i.hasNext(); )
> 511 {
> 512 CompilerError message = (CompilerError) i.next();
> 513
> 514 getLog().warn( message.toString() );
> 515 }
> 516 }
> Could you change line 504 to reference an injected property, so the exception
> can be consumed with simply a warning?
> At present I am planning on working around this issue by using exclude
> filters (excluding common filename patterns users are likely to generated
> dependent code for) but this is an inelegant solution by comparison with
> supporting the injected property. If there is another way to skip errors and
> I am not aware of it, would you please let me know. Thanks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCOMPILER-48) Add maven.compile.failonerror equivalent functionality
[ http://jira.codehaus.org/browse/MCOMPILER-48?page=all ]
Ben Alex updated MCOMPILER-48:
--
Attachment: compiler-failonerror-test.zip
Use this file, not attachment #1
> Add maven.compile.failonerror equivalent functionality
> --
>
> Key: MCOMPILER-48
> URL: http://jira.codehaus.org/browse/MCOMPILER-48
> Project: Maven 2.x Compiler Plugin
> Issue Type: Improvement
>Reporter: Ben Alex
>Priority: Critical
> Attachments: compiler-failonerror-test.zip,
> compiler-failonerror-test.zip, patch.txt
>
>
> Maven 1.x's "java" plugin offered a maven.compile.failonerror property, which
> could be set false in order to skip compilation errors.
> I am working on a code generation framework that uses a Maven plugin. The
> mojo spawns a parallel lifecycle via @execute phase="test-compile", as the
> mojo itself is @phase generate-sources. This is necessary as the code
> generator needs to instantiate certain classes to obtain metadata. The nature
> of the generated types means that users might write code that depends on the
> generated types to already be compiled on the classpath, although this has
> not yet happened at this phase because the code generator requires compiled
> classes first. By the time the generated-sources phase completes and releases
> to the original lifecycle, the subsequent compilation will work as the
> generated sources are now available for compilation.
> In practice this issue is easily resolved if AbstractCompilerMojo supported
> the Maven 1 style maven.compile.failonerror = false property, which could be
> injected via the MavenProject class during the parallel lifecycle (and
> reverted upon completion). The relevant lines are:
> 504 if ( compilationError )
> 505 {
> 506 throw new CompilationFailureException( messages );
> 507 }
> 508 else
> 509 {
> 510 for ( Iterator i = messages.iterator(); i.hasNext(); )
> 511 {
> 512 CompilerError message = (CompilerError) i.next();
> 513
> 514 getLog().warn( message.toString() );
> 515 }
> 516 }
> Could you change line 504 to reference an injected property, so the exception
> can be consumed with simply a warning?
> At present I am planning on working around this issue by using exclude
> filters (excluding common filename patterns users are likely to generated
> dependent code for) but this is an inelegant solution by comparison with
> supporting the injected property. If there is another way to skip errors and
> I am not aware of it, would you please let me know. 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: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=comments#action_84684 ] Chris Byrd commented on MCOMPILER-22: - Can anyone point me to documentation on how I go about applying the maven patches? I can't seem to find anything in the maven site. Also, I'm not sure in which order or what files I actually need to use in the attachments listed for this issue. Any direction would be greatly appreciated. In the comment above, I was linking this issue to PLX-314. I didn't realize the comment would just be dumped in the main area. > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Matthew Beermann >Priority: Critical > Fix For: 2.0.2 > > Attachments: maven-compiler-plugin-space-fix.patch, > maven-compiler-plugin.patch, MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac-1.5.2.jar, > plexus-compiler-javac.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > 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:249) > 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.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 more -- 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-2742) Using a version range in a plugin dependency causes "failure to resolve artifact" error
[ http://jira.codehaus.org/browse/MNG-2742?page=comments#action_84683 ] Matthew Adams commented on MNG-2742: I just noticed that the same problem exists when building my Maven2 plugin as well if I declare a dependency on a version range: In my plugin's pom.xml: ... com.xcalia xic [4.3.1-1231,) ... Here is the log, starting with the error: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. No versions are present in the repository for the artifact with a range [4.3.1-1231,) com.xcalia:xic:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: No versions are present in the repository for the artifact with a range [4.3.1-1231,) com.xcalia:xic:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) 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.artifact.versioning.OverConstrainedVersionException: No versions are present in the repository for the artifact with a range [ 1231,) com.xcalia:xic:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:253) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more > Using a version range in a plugin dependency causes "failure to resolve > artifact" error > --- > > Key: MNG-2742 > URL: http://jira.codehaus.org/browse/MNG-2742 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: Windows XP SP2, java version "1.5.0_08" >Reporter: Matthew Adams > Attachments: mvn.txt, pom.xml > > > If I declare a dependency in a plugin using an exact version, Maven correctly > resolves the artifact. If, however, I change the dependency's version to a > version range, Maven no longer resolves the artifact. I'm using the very > same artifact and version range in my project's dependencies and everything > works ok. See my attached pom.xml file for details, in particular, the > comments "" and "". > I am using the "major.minor.revision-buildNumber" version string syntax as > described on the wiki. -- This message is aut
[jira] Commented: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[ http://jira.codehaus.org/browse/MSITE-129?page=comments#action_84679 ]
Jason Melnick commented on MSITE-129:
-
IMHO a "module" doesn't necessarily mean "child", nor should it... Project
aggregation via the reactor is just that - aggregation and shouldn't have any
bearing on inheritance.
This is my inheritance tree:
Enterprise POM (xxxManagement sections)
Enterprise Base POM (base declarations)
Web POM
Jar POM
EJB POM
That hierarchy is all defined at the enterprise level. A new project that wants
to develop under our build system needs to inherit from each of the artifact
types. I don't want to have to create basically a dummy set of poms between the
parent poms and the project child poms just so that a reactor project that
builds the application can correctly generate the website.
Since one branch of the site logic simply uses the declaration at
face value (i.e. relative directories), it could make links based on the
default target locations, or it could inspect the POMs contained within the
directories of the declared modules. Moreoever, additional configuration
options could be added to the site plugin configuration to make link creation
locations more logical.
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
> Assigned To: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0.1
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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: (MEV-485) jackrabit pom fix suggestions
[ http://jira.codehaus.org/browse/MEV-485?page=all ] Carlos Sanchez closed MEV-485. -- Assignee: Carlos Sanchez Resolution: Fixed fixed client and webdav modules > jackrabit pom fix suggestions > - > > Key: MEV-485 > URL: http://jira.codehaus.org/browse/MEV-485 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Laszlo Hornyak Kocka > Assigned To: Carlos Sanchez > Attachments: jackrabbit-poms.tar.gz > > > mandatory 'groupId' and 'version' tags missing, some dependency has strange > version (and it looks trivial which version it should use) > attached poms fix the issues -- 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: (MEV-484) broken pom for poi-3.0-alpha3
[ http://jira.codehaus.org/browse/MEV-484?page=all ] Carlos Sanchez closed MEV-484. -- Assignee: Carlos Sanchez Resolution: Duplicate > broken pom for poi-3.0-alpha3 > - > > Key: MEV-484 > URL: http://jira.codehaus.org/browse/MEV-484 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: fabrizio giustina > Assigned To: Carlos Sanchez > > [WARNING] POM for 'poi:poi:pom:3.0-alpha3:compile' is invalid. It will be > ignored for artifact resolution. Reason: Parse error reading POM. Reason: > expected START_TAG or END_TAG not TEXT (position: TE > XT seen > ...http://jakarta.apache.org/images/original-jakarta-logo.gif @28:69) > http://repo1.maven.org/maven2/poi/poi/3.0-alpha3/poi-3.0-alpha3.pom -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-480) geronimo-spec-* groupdid should be geronimo-spec in the db-ojb pom.xml and has wrong artifactId
[ http://jira.codehaus.org/browse/MEV-480?page=all ] Carlos Sanchez closed MEV-480. -- Assignee: Carlos Sanchez Resolution: Fixed Fixed and reported in https://issues.apache.org/jira/browse/OJB-127 > geronimo-spec-* groupdid should be geronimo-spec in the db-ojb pom.xml and > has wrong artifactId > --- > > Key: MEV-480 > URL: http://jira.codehaus.org/browse/MEV-480 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Mikko Wuokko > Assigned To: Carlos Sanchez > > In the pom file the geronimo-spec dependencies are defined like this: > geronimo-spec-j2ee > geronimo-spec-j2ee > 1.4-rc4 > > > geronimo-spec-jta > geronimo-spec-jta > 1.0.1B-rc4 > > > geronimo-spec-servlet > geronimo-spec-servlet > 2.4-rc4 > > The groupId should be just geronimo-spec for all of them. AFAIK that is the > groupId used in all the Maven2 repos I found. > And also in the pom file the artifactId is ojb and it should be db-ojb > instead. -- 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: (MEV-337) OJB 1.0.4 has a number of dependencies that should be optional
[ http://jira.codehaus.org/browse/MEV-337?page=all ] Carlos Sanchez closed MEV-337. -- Resolution: Fixed Fixed and reported in https://issues.apache.org/jira/browse/OJB-127 > OJB 1.0.4 has a number of dependencies that should be optional > -- > > Key: MEV-337 > URL: http://jira.codehaus.org/browse/MEV-337 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Matt Raible > Assigned To: Carlos Sanchez > > Compare the 1.0.3 pom with the 1.0.4 - there seems to be a number of > dependencies that should be optional in 1.0.4. > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.4/db-ojb-1.0.4.pom > For example: xjavadoc, xdoclet, velocity, torque, p6spy > It does appear that some dependencies changed with this release (which is odd > for a point release) - so you should probably get in touch with the OJB > developers and see which ones are absolutely required. -- 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: (MEV-337) OJB 1.0.4 has a number of dependencies that should be optional
[ http://jira.codehaus.org/browse/MEV-337?page=all ] Carlos Sanchez reopened MEV-337: > OJB 1.0.4 has a number of dependencies that should be optional > -- > > Key: MEV-337 > URL: http://jira.codehaus.org/browse/MEV-337 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Matt Raible > Assigned To: Carlos Sanchez > > Compare the 1.0.3 pom with the 1.0.4 - there seems to be a number of > dependencies that should be optional in 1.0.4. > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.4/db-ojb-1.0.4.pom > For example: xjavadoc, xdoclet, velocity, torque, p6spy > It does appear that some dependencies changed with this release (which is odd > for a point release) - so you should probably get in touch with the OJB > developers and see which ones are absolutely required. -- 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: (MEV-481) Wrong artifact name for groovy-sources in maven repo
[ http://jira.codehaus.org/browse/MEV-481?page=all ] Carlos Sanchez closed MEV-481. -- Assignee: Carlos Sanchez Resolution: Fixed > Wrong artifact name for groovy-sources in maven repo > > > Key: MEV-481 > URL: http://jira.codehaus.org/browse/MEV-481 > Project: Maven Evangelism > Issue Type: Bug >Reporter: nicolas de loof > Assigned To: Carlos Sanchez > > in http://repo1.maven.org/maven2/groovy/groovy/1.0-jsr-06/ the sources jar > has a typo and is set to "grrovy" -- 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: (MEV-482) jackrabbit-jcr-webdav-1.1.1.pom is invalid.
[ http://jira.codehaus.org/browse/MEV-482?page=all ]
Carlos Sanchez closed MEV-482.
--
Assignee: Carlos Sanchez
Resolution: Fixed
> jackrabbit-jcr-webdav-1.1.1.pom is invalid.
> ---
>
> Key: MEV-482
> URL: http://jira.codehaus.org/browse/MEV-482
> Project: Maven Evangelism
> Issue Type: Bug
> Components: Invalid POM
>Reporter: Joakim Erdfelt
> Assigned To: Carlos Sanchez
>
> The 1.1.1 pom is invalid.
> Checking with jackrabbit svn repository for their 1.2-SNAPSHOT release. they
> have corrected this issue.
> I would like to see the 1.1.1 pom brought up to the bare minimum specs for a
> valid pom.
> What's missing.
> * for pom itself.
> * for pom itself
> * section to define the ${jackrabbit.build.version.jackrabbit}
> as 1.1.1
--
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: (MEV-486) Invalid checksums and PGP signature for maven-project-info-reports-plugin/maven-metadata.xml
[ http://jira.codehaus.org/browse/MEV-486?page=all ] Carlos Sanchez closed MEV-486. -- Assignee: Carlos Sanchez Resolution: Fixed > Invalid checksums and PGP signature for > maven-project-info-reports-plugin/maven-metadata.xml > > > Key: MEV-486 > URL: http://jira.codehaus.org/browse/MEV-486 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher > Assigned To: Carlos Sanchez > > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-project-info-reports-plugin/maven-metadata.xml > * fails MD5 verification > * fails SHA1 verification > * fails PGP verification -- 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-1317) SweetXML 0.2 bundles ready for repository
SweetXML 0.2 bundles ready for repository - Key: MAVENUPLOAD-1317 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1317 Project: maven-upload-requests Issue Type: Task Reporter: Paul Cantrell http://innig.net/tmp/maven-sweetxml-bundles-0.2/sweetxml-parent-pom-0.2-bundle.jar http://innig.net/tmp/maven-sweetxml-bundles-0.2/sweetxml-0.2-bundle.jar http://innig.net/tmp/maven-sweetxml-bundles-0.2/sweetxml-ant-0.2-bundle.jar http://innig.net/tmp/maven-sweetxml-bundles-0.2/sweetxml-maven-0.2-bundle.jar http://innig.net/software/sweetxml/ http://innig.net/software/sweetxml/faq.html#who The project has three modules, all of which inherit from a project-wide parent POM. My understanding is that I have to release the parent POM as a separate fourth artifact, so I have bundled it in its own jar. (I did this manually, since repository:bundle-create doesn't work when the packaging type is "pom".) If this is incorrect, or if there is a better way to handle this, please let me know and I will recreate the bundles. -- 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-2201) Interpolation problem when using surefire
[ http://jira.codehaus.org/browse/MNG-2201?page=all ]
Jason van Zyl closed MNG-2201.
--
Resolution: Fixed
Proven to be fixed with it0104.
> Interpolation problem when using surefire
> -
>
> Key: MNG-2201
> URL: http://jira.codehaus.org/browse/MNG-2201
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0, 2.0.1, 2.0.3, 2.0.2, 2.0.4
>Reporter: Vincent Massol
> Assigned To: Jason van Zyl
>Priority: Critical
> Fix For: 2.0.5
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> I've just tried the cargo build with the latest trunk versions of
> 2.0.4-SNAPSHOT and surefire plugin, and it seems there's some interpolation
> issue (I don't know if the problem is with the surefire plugin or with maven
> core).
> Here's what I have:
> {code:xml}
>
>
>
>
> maven-surefire-plugin
>
> pertest
>
> [...]
>
> cargo.target.dir
> ${project.build.directory}
>
> [...]
> {code}
> It seems the ${project.build.directory} property is no longer getting
> resolved as I got a directory named ${project.build.directory} created.
> It used to work fine before.
--
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: (MEV-486) Invalid checksums and PGP signature for maven-project-info-reports-plugin/maven-metadata.xml
Invalid checksums and PGP signature for maven-project-info-reports-plugin/maven-metadata.xml Key: MEV-486 URL: http://jira.codehaus.org/browse/MEV-486 Project: Maven Evangelism Issue Type: Bug Reporter: Max Bowsher http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-project-info-reports-plugin/maven-metadata.xml * fails MD5 verification * fails SHA1 verification * fails PGP verification -- 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: (MJAR-66) Maven fails to include generated resources
Maven fails to include generated resources -- Key: MJAR-66 URL: http://jira.codehaus.org/browse/MJAR-66 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.1 Environment: Linux (not tested on windows) Reporter: Leszek Ciesielski Attachments: ConfigurationServerAPI.tar.gz My project is generating a wsdl with axistools plugin. When maven is run with mvn clean install (or after a checkout), the wsdl is not packaged into the jar, although it is present when the jar is generated and included in resources. On second run (mvn install) the wsdl file, is, as expected, included. A test project showing this behaviour is attached. -- 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-2755) Use it0104 and the maven-it-plugin-configuration plugin for comprehensive interpolation/inheritence tests
Use it0104 and the maven-it-plugin-configuration plugin for comprehensive interpolation/inheritence tests - Key: MNG-2755 URL: http://jira.codehaus.org/browse/MNG-2755 Project: Maven 2 Issue Type: Task Components: Inheritance and Interpolation Reporter: Jason van Zyl Fix For: 2.1 -- 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-2755) Use it0104 and the maven-it-plugin-configuration plugin for comprehensive interpolation/inheritence tests
[ http://jira.codehaus.org/browse/MNG-2755?page=all ] Jason van Zyl updated MNG-2755: --- Fix Version/s: 2.1 > Use it0104 and the maven-it-plugin-configuration plugin for comprehensive > interpolation/inheritence tests > - > > Key: MNG-2755 > URL: http://jira.codehaus.org/browse/MNG-2755 > Project: Maven 2 > Issue Type: Task > Components: Inheritance and Interpolation >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.1 > > -- 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-2704) Range check don't work correct
[ http://jira.codehaus.org/browse/MNG-2704?page=comments#action_84667 ] Stephan Zehrer commented on MNG-2704: - again and again and again ... and I did not change something in my configuration (hopefully *g*) 10.01.07 18:15:30 CET: Reading /vse/pom.xml 10.01.07 18:15:30 CET: Local repository folder "" does not exist 10.01.07 18:15:30 CET: No versions are present in the repository for the artifact with a range [3.2.0,4.0.0) org.eclipse.equinox:org.eclipse.equinox.common-null.jar I read an an article about cleanups in the rep. ... is this maybe a reason?? > Range check don't work correct > -- > > Key: MNG-2704 > URL: http://jira.codehaus.org/browse/MNG-2704 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: OS: Windows XP > Java: jdk1.5.0_10 >Reporter: Stephan Zehrer >Priority: Minor > Attachments: demo.zip > > > I included the following part in my pom.xml: > > org.eclipse.jface > org.eclipse.jface > 3.2.0 > > I always get the following error > No versions are present in the repository for the artifact with a range > [3.2.0,4.0.0) > org.eclipse.equinox:org.eclipse.equinox.common:jar:null > But I am sure that version 3.2.0 is available in the repository. > If I define only a dependency on this library like this > > org.eclipse.equinox > org.eclipse.equinox.common > 3.2.0 > > it works! > If I define both it will not work. Why? > According > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution > It could be forced by this > My current workaround is the exclusion definition. > What did I wrong or is this a bug? > See the demo I Attached, you need the Eclipse 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] Commented: (CONTINUUM-1103) Build Fresh checkbox doesn't stay checked
[ http://jira.codehaus.org/browse/CONTINUUM-1103?page=comments#action_84664 ] Emmanuel Venisse commented on CONTINUUM-1103: - jpox-1.1.3 fix your tests but continuum doesn't start with it > Build Fresh checkbox doesn't stay checked > - > > Key: CONTINUUM-1103 > URL: http://jira.codehaus.org/browse/CONTINUUM-1103 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Wendy Smoak > Attachments: buildFresh.patch, jpox1.1.3.patch > > > To reproduce: > Project Groups -> [any group] -> Build Definitions tab > 1. Edit a build definition > 2. check the 'Build Fresh' checkbox > 3. Save > 4. Edit the same build definition > The checkbox should remain checked, but it does not. -- 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-2731) Regression: new container handling cannot locate resources properly
[ http://jira.codehaus.org/browse/MNG-2731?page=all ]
Vincent Siveton updated MNG-2731:
-
Attachment: doxia-site-renderer-MNG-2731.diff
maven-project-info-reports-plugin-MNG-2731.diff
This issue seems to be related to plexus, via doxia. These patches excludes
some plexus artifacts in doxia.
Works *only* for maven 2.0.x. With maven 2.1-snap, I got another exception:
{noformat}
org.apache.maven.BuildFailureException: Can't find bundle for base name
project-info-report, locale en
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:109)
at
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:520)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:341)
...
{noformat}
> Regression: new container handling cannot locate resources properly
> ---
>
> Key: MNG-2731
> URL: http://jira.codehaus.org/browse/MNG-2731
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.1
>Reporter: Brett Porter
>Priority: Blocker
> Attachments: doxia-site-renderer-MNG-2731.diff,
> maven-project-info-reports-plugin-MNG-2731.diff
>
>
> Run: mvn project-info-reports:scm on any Maven project.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Can't find bundle for base name project-info-report, locale en_AU
> [INFO]
>
> [INFO] Trace
> org.apache.maven.BuildFailureException: Can't find bundle for base name
> project-info-report, locale en_AU
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:315)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:141)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:550)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:346)
> 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
> Caused by: java.util.MissingResourceException: Can't find bundle for base
> name project-info-report, locale en_AU
> at
> org.codehaus.plexus.i18n.DefaultI18N.cacheBundle(DefaultI18N.java:394)
> at
> org.codehaus.plexus.i18n.DefaultI18N.getBundle(DefaultI18N.java:157)
> at
> org.codehaus.plexus.i18n.DefaultI18N.getString(DefaultI18N.java:206)
> at
> org.apache.maven.report.projectinfo.ScmReport.getName(ScmReport.java:68)
> at
> org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute(AbstractProjectInfoReport.java:158)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:435)
> 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:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
> ... 11 more
> This works in Maven 2.0.4/2.0.5-SNAPSHOT, but not on trunk.
--
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-2684) local repository can only be specified per user, not per build, which impacts scalability
[ http://jira.codehaus.org/browse/MNG-2684?page=comments#action_84657 ] Marilyn E. Sander commented on MNG-2684: Problem solved. I found on http://maven.apache.org/ant-tasks.html a link to sample.build.xml which contained the examples I needed. The link was brown and not underscored, so I did not previously recognize it as a link, and had gone looking in the antlib jar file for the example. I will add this comment and then see if I can close this report. > local repository can only be specified per user, not per build, which impacts > scalability > - > > Key: MNG-2684 > URL: http://jira.codehaus.org/browse/MNG-2684 > Project: Maven 2 > Issue Type: Improvement > Components: Ant tasks >Affects Versions: 2.0.4 > Environment: Linux >Reporter: Marilyn E. Sander > > Because the local repository can only be specified in the ~/.m2/settings.xml > or ~/.m2/ant/settings.xml file, there can be only one local repository per > user per executing build. Worst case, the repository is on a mounted > filesystem and thus the user can run only one build at a time. Best case, > the repository is on the local machine, and the user can run one build per > machine. This does not scale to an installation with large-capacity build > servers, where one user might run several builds of different products or > releases simultaneously, with each build using its own local repository. > This can be done with Maven alone, but not with Maven ant tasks. > I would like a mechanism for the ant tasks to pick up the local repository > from a property, an environment variable, or a file in the base directory for > the build. Even $M2_HOME/conf/settings.xml would be acceptable, as we could > jigger $M2_HOME so as to have a unique one for each build. Any mechanism > would be suitable, as long as it would allow a unique local repostory for > each build. > Feel free to lower this from major to minor if you do not agree with the > impact. For our shop it is a major inconvenience, and we are considering a > major rewrite to our build in order to avoid the ant tasks. We really need > to make good use of our build servers. -- 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-1117) Cannot add a wagon notifier because it doesn't appear in the notifiers list.
[ http://jira.codehaus.org/browse/CONTINUUM-1117?page=all ] Emmanuel Venisse closed CONTINUUM-1117. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 Applied. Thanks > Cannot add a wagon notifier because it doesn't appear in the notifiers list. > > > Key: CONTINUUM-1117 > URL: http://jira.codehaus.org/browse/CONTINUUM-1117 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Henry S. Isidro > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > Attachments: [CONTINUUM-1117]-continuum-webapp.patch, > [CONTINUUM-1117]-continuum-webapp.patch-2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1131) Wagon notifier does not use configuration.
[ http://jira.codehaus.org/browse/CONTINUUM-1131?page=all ] Emmanuel Venisse closed CONTINUUM-1131. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 Applied. Thanks > Wagon notifier does not use configuration. > -- > > Key: CONTINUUM-1131 > URL: http://jira.codehaus.org/browse/CONTINUUM-1131 > Project: Continuum > Issue Type: Bug >Reporter: Henry S. Isidro > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > Attachments: [CONTINUUM-1131]-continuum-notifier-wagon.patch > > > Wagon notifier (which is used to deploy build history report to the project > site) does not get it's configuration setting from configuration. -- 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-1132) Project view page does not show the recipient of the wagon notifier.
[ http://jira.codehaus.org/browse/CONTINUUM-1132?page=all ] Emmanuel Venisse closed CONTINUUM-1132. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 Applied. Thanks > Project view page does not show the recipient of the wagon notifier. > > > Key: CONTINUUM-1132 > URL: http://jira.codehaus.org/browse/CONTINUUM-1132 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Henry S. Isidro > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > Attachments: [CONTINUUM-1132]-continuum-webapp.patch > > -- 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-1316) upload vraptor 2.3.1
upload vraptor 2.3.1 Key: MAVENUPLOAD-1316 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1316 Project: maven-upload-requests Issue Type: Task Reporter: Nico Steppat VRaptor 2.3.1 comes with minor changes, bug fixes and a site updated. VRaptor 2 is a mvc controller based on the idea (stolen) from Rails that configuration should be minimal and conventions should be maximized. -- 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-151) Incorrect name for test sources jars
[ http://jira.codehaus.org/browse/MECLIPSE-151?page=all ] fabrizio giustina updated MECLIPSE-151: --- Assignee: fabrizio giustina Fix Version/s: 2.4 patch look fine, I will apply it as soon as other tests are fixed (tests don't work properly on some platforms at the moment) > Incorrect name for test sources jars > > > Key: MECLIPSE-151 > URL: http://jira.codehaus.org/browse/MECLIPSE-151 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Richard van der Hoff > Assigned To: fabrizio giustina > Fix For: 2.4 > > Attachments: maven-eclipse-plugin.patch > > > The eclipse plugin currently sets the source attachment of dependencies on > test-jars (as created by the test-jar goal of the jar plugin) to the same as > that of the main jar. > To fix, we need to check the classifier of dependencies when finding sources, > and if it is "tests", use "test-sources" rather than "sources" for the > classifier on the sources jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-151) Incorrect name for test sources jars
[ http://jira.codehaus.org/browse/MECLIPSE-151?page=all ] Richard van der Hoff updated MECLIPSE-151: -- Attachment: maven-eclipse-plugin.patch This also affects version 2.3. Here's a patch, with unit tests, which fixes it. > Incorrect name for test sources jars > > > Key: MECLIPSE-151 > URL: http://jira.codehaus.org/browse/MECLIPSE-151 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Richard van der Hoff > Attachments: maven-eclipse-plugin.patch > > > The eclipse plugin currently sets the source attachment of dependencies on > test-jars (as created by the test-jar goal of the jar plugin) to the same as > that of the main jar. > To fix, we need to check the classifier of dependencies when finding sources, > and if it is "tests", use "test-sources" rather than "sources" for the > classifier on the sources jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-485) jackrabit pom fix suggestions
[ http://jira.codehaus.org/browse/MEV-485?page=comments#action_84637 ] Laszlo Hornyak Kocka commented on MEV-485: -- http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com.bla bla jar 1.0-SNAPSHOT bla-bla http://blabla.com junit junit 3.8.1 test commons-dbcp commons-dbcp 1.2.1 org.apache.jackrabbit jackrabbit-jcr-client 1.1.1 In my previous comment: the dependency problem is not in the core pom, but in http://repo1.maven.org/maven2/org/apache/jackrabbit/jackrabbit-jcr-webdav/1.1.1/jackrabbit-jcr-webdav-1.1.1.pom A diff may explain better... > jackrabit pom fix suggestions > - > > Key: MEV-485 > URL: http://jira.codehaus.org/browse/MEV-485 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Laszlo Hornyak Kocka > Attachments: jackrabbit-poms.tar.gz > > > mandatory 'groupId' and 'version' tags missing, some dependency has strange > version (and it looks trivial which version it should use) > attached poms fix the issues -- 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: (MEV-485) jackrabit pom fix suggestions
[ http://jira.codehaus.org/browse/MEV-485?page=comments#action_84636 ]
Laszlo Hornyak Kocka commented on MEV-485:
--
In
http://repo1.maven.org/maven2/org/apache/jackrabbit/jackrabbit-jcr-client/1.1.1/jackrabbit-jcr-client-1.1.1.pom
and
http://repo1.maven.org/maven2/org/apache/jackrabbit/jackrabbit-jcr-webdav/1.1.1/jackrabbit-jcr-webdav-1.1.1.pom
groupid and version is missing.
Also in
http://repo1.maven.org/maven2/org/apache/jackrabbit/jackrabbit-core/1.1.1/jackrabbit-core-1.1.1.pom
"
org.apache.jackrabbit
jackrabbit-jcr-commons
${jackrabbit.build.version.jackrabbit}
" I think jackrabbit-jcr-commons-1.1.1.jar is tested against
jackrabbit version 1.1.1 components.
I will attach a test pom soon.
> jackrabit pom fix suggestions
> -
>
> Key: MEV-485
> URL: http://jira.codehaus.org/browse/MEV-485
> Project: Maven Evangelism
> Issue Type: Bug
> Components: Invalid POM
>Reporter: Laszlo Hornyak Kocka
> Attachments: jackrabbit-poms.tar.gz
>
>
> mandatory 'groupId' and 'version' tags missing, some dependency has strange
> version (and it looks trivial which version it should use)
> attached poms fix the issues
--
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: (MAVEN-1825) Multiple tags not allowed in RC-1 (Duplicated tag: 'project')
[ http://jira.codehaus.org/browse/MAVEN-1825?page=comments#action_84635 ] G.J. Sterenborg commented on MAVEN-1825: I'll try to create a testcase asap. > Multiple tags not allowed in RC-1 (Duplicated tag: 'project') > > > Key: MAVEN-1825 > URL: http://jira.codehaus.org/browse/MAVEN-1825 > Project: Maven 1.x > Issue Type: Bug >Affects Versions: 1.1-rc1 >Reporter: G.J. Sterenborg > > We have combined multiple modules into components: > * component 1 > root-module-generic -- project-descriptor (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 2 > root-module-specific -- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 3 > root-module-specific2-- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * ... > Every module is released seperately in one big 'component-release'. > This component-release checks if a module has changed since the last release > and if so ups the version (and adds a -entry to module's pom.) > > Sub-modules root-module and the root-pom extends all dependent > component-descriptors. > The root-pom is specifies the component-version. > Every module gets it's own version and cvs-tag (including root-pom for the > component-version.) > After testing RC-1, seeing the 'Duplicated tag: 'project'' error and reading: > http://www.mail-archive.com/users@maven.apache.org/msg55210.html > I'm very surprised that tag duplication in parent/child modules isn't allowed > anymore. > Doesn't the parent-pom specify the entire project and the sub-module-poms > their own? -- 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: (MAVEN-1825) Multiple tags not allowed in RC-1 (Duplicated tag: 'project')
[ http://jira.codehaus.org/browse/MAVEN-1825?page=comments#action_84633 ] Arnaud Heritier commented on MAVEN-1825: In theory, It's always possible to have several times the same element in different poms (parent/child). I'll try to add a testcase for this. I'm working on the model actually. > Multiple tags not allowed in RC-1 (Duplicated tag: 'project') > > > Key: MAVEN-1825 > URL: http://jira.codehaus.org/browse/MAVEN-1825 > Project: Maven 1.x > Issue Type: Bug >Affects Versions: 1.1-rc1 >Reporter: G.J. Sterenborg > > We have combined multiple modules into components: > * component 1 > root-module-generic -- project-descriptor (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 2 > root-module-specific -- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 3 > root-module-specific2-- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * ... > Every module is released seperately in one big 'component-release'. > This component-release checks if a module has changed since the last release > and if so ups the version (and adds a -entry to module's pom.) > > Sub-modules root-module and the root-pom extends all dependent > component-descriptors. > The root-pom is specifies the component-version. > Every module gets it's own version and cvs-tag (including root-pom for the > component-version.) > After testing RC-1, seeing the 'Duplicated tag: 'project'' error and reading: > http://www.mail-archive.com/users@maven.apache.org/msg55210.html > I'm very surprised that tag duplication in parent/child modules isn't allowed > anymore. > Doesn't the parent-pom specify the entire project and the sub-module-poms > their own? -- 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: (MAVEN-1825) Multiple tags not allowed in RC-1 (Duplicated tag: 'project')
[ http://jira.codehaus.org/browse/MAVEN-1825?page=comments#action_84634 ] Lukas Theussl commented on MAVEN-1825: -- Sorry, I still don't get it. Do you have several tags within one project.xml? Or are you saying that it's an inheritance problem? Can you attach a reproducible test case, that would be helpful. Note also that you should be able to validate each pom (parent or sub-project) with the pom:validate goal (http://maven.apache.org/maven-1.x/plugins/pom/validation.html). > Multiple tags not allowed in RC-1 (Duplicated tag: 'project') > > > Key: MAVEN-1825 > URL: http://jira.codehaus.org/browse/MAVEN-1825 > Project: Maven 1.x > Issue Type: Bug >Affects Versions: 1.1-rc1 >Reporter: G.J. Sterenborg > > We have combined multiple modules into components: > * component 1 > root-module-generic -- project-descriptor (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 2 > root-module-specific -- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 3 > root-module-specific2-- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * ... > Every module is released seperately in one big 'component-release'. > This component-release checks if a module has changed since the last release > and if so ups the version (and adds a -entry to module's pom.) > > Sub-modules root-module and the root-pom extends all dependent > component-descriptors. > The root-pom is specifies the component-version. > Every module gets it's own version and cvs-tag (including root-pom for the > component-version.) > After testing RC-1, seeing the 'Duplicated tag: 'project'' error and reading: > http://www.mail-archive.com/users@maven.apache.org/msg55210.html > I'm very surprised that tag duplication in parent/child modules isn't allowed > anymore. > Doesn't the parent-pom specify the entire project and the sub-module-poms > their own? -- 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: (MPPMD-29) Upgrade to PMD 3.9
[ http://jira.codehaus.org/browse/MPPMD-29?page=all ] Francois Le Droff updated MPPMD-29: --- Attachment: maven1-pmd-plugin.zip I forgot to modify the plugin.jelly file and within the pmd and cpd classpath. So this time I'll attach the source projet > Upgrade to PMD 3.9 > -- > > Key: MPPMD-29 > URL: http://jira.codehaus.org/browse/MPPMD-29 > Project: maven-pmd-plugin > Issue Type: Task >Affects Versions: 1.9 >Reporter: Anthony Whitford > Assigned To: Jeff Jensen > Fix For: 1.10 > > Attachments: maven-pmd-plugin-1.10.jar, maven1-pmd-plugin.zip > > > PMD 3.8 was released October 4, 2006. The Maven plugin should be updated too. > http://sourceforge.net/project/shownotes.php?release_id=452776&group_id=56262 -- 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-1097) Release start and end time are set to "Jan 01, 1970 01:00:00 AM CET" when a release error occurs before the actual release process
[ http://jira.codehaus.org/browse/CONTINUUM-1097?page=all ] Emmanuel Venisse closed CONTINUUM-1097. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 Applied. Thanks. > Release start and end time are set to "Jan 01, 1970 01:00:00 AM CET" when a > release error occurs before the actual release process > -- > > Key: CONTINUUM-1097 > URL: http://jira.codehaus.org/browse/CONTINUUM-1097 > Project: Continuum > Issue Type: Bug > Components: Core system >Reporter: Edwin Punzalan > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > Attachments: CONTINUUM-1097-continuum-release.patch, > CONTINUUM-1097-continuum-release.patch, CONTINUUM-1097-continuum-release.patch > > > Also, does not include the actual start time of the release process. -- 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: (MAVEN-1825) Multiple tags not allowed in RC-1 (Duplicated tag: 'project')
[ http://jira.codehaus.org/browse/MAVEN-1825?page=comments#action_84631 ] G.J. Sterenborg commented on MAVEN-1825: The versions-tags are not duplicates. (The pom's are not being treated as one entity.) Parent pom specifies the entire project, child-pom specifies itself. Our hierarchy: sub-module/project.xml -- extends -- parent-pom/project.xml (i.e. '../project.xml') parent-pom/project.xml -- extends -- descriptor/project.xml This allows the entire set to have a version that will be added to parent-pom/project.xml. > Multiple tags not allowed in RC-1 (Duplicated tag: 'project') > > > Key: MAVEN-1825 > URL: http://jira.codehaus.org/browse/MAVEN-1825 > Project: Maven 1.x > Issue Type: Bug >Affects Versions: 1.1-rc1 >Reporter: G.J. Sterenborg > > We have combined multiple modules into components: > * component 1 > root-module-generic -- project-descriptor (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 2 > root-module-specific -- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 3 > root-module-specific2-- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * ... > Every module is released seperately in one big 'component-release'. > This component-release checks if a module has changed since the last release > and if so ups the version (and adds a -entry to module's pom.) > > Sub-modules root-module and the root-pom extends all dependent > component-descriptors. > The root-pom is specifies the component-version. > Every module gets it's own version and cvs-tag (including root-pom for the > component-version.) > After testing RC-1, seeing the 'Duplicated tag: 'project'' error and reading: > http://www.mail-archive.com/users@maven.apache.org/msg55210.html > I'm very surprised that tag duplication in parent/child modules isn't allowed > anymore. > Doesn't the parent-pom specify the entire project and the sub-module-poms > their own? -- 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-1097) Release start and end time are set to "Jan 01, 1970 01:00:00 AM CET" when a release error occurs before the actual release process
[ http://jira.codehaus.org/browse/CONTINUUM-1097?page=all ] Edwin Punzalan updated CONTINUUM-1097: -- Attachment: CONTINUUM-1097-continuum-release.patch Replacing the previous... had an erroneous merge with the other. > Release start and end time are set to "Jan 01, 1970 01:00:00 AM CET" when a > release error occurs before the actual release process > -- > > Key: CONTINUUM-1097 > URL: http://jira.codehaus.org/browse/CONTINUUM-1097 > Project: Continuum > Issue Type: Bug > Components: Core system >Reporter: Edwin Punzalan > Attachments: CONTINUUM-1097-continuum-release.patch, > CONTINUUM-1097-continuum-release.patch, CONTINUUM-1097-continuum-release.patch > > > Also, does not include the actual start time of the release process. -- 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: (MAVEN-1825) Multiple tags not allowed in RC-1 (Duplicated tag: 'project')
[ http://jira.codehaus.org/browse/MAVEN-1825?page=comments#action_84622 ] Lukas Theussl commented on MAVEN-1825: -- I meant tags, of course... > Multiple tags not allowed in RC-1 (Duplicated tag: 'project') > > > Key: MAVEN-1825 > URL: http://jira.codehaus.org/browse/MAVEN-1825 > Project: Maven 1.x > Issue Type: Bug >Affects Versions: 1.1-rc1 >Reporter: G.J. Sterenborg > > We have combined multiple modules into components: > * component 1 > root-module-generic -- project-descriptor (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 2 > root-module-specific -- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 3 > root-module-specific2-- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * ... > Every module is released seperately in one big 'component-release'. > This component-release checks if a module has changed since the last release > and if so ups the version (and adds a -entry to module's pom.) > > Sub-modules root-module and the root-pom extends all dependent > component-descriptors. > The root-pom is specifies the component-version. > Every module gets it's own version and cvs-tag (including root-pom for the > component-version.) > After testing RC-1, seeing the 'Duplicated tag: 'project'' error and reading: > http://www.mail-archive.com/users@maven.apache.org/msg55210.html > I'm very surprised that tag duplication in parent/child modules isn't allowed > anymore. > Doesn't the parent-pom specify the entire project and the sub-module-poms > their own? -- 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-1314) Upload antlr-2.7.7
Upload antlr-2.7.7 -- Key: MAVENUPLOAD-1314 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1314 Project: maven-upload-requests Issue Type: Task Reporter: Jochen Wiedmann The AntLR Parser Generator, version 2.7.7 Note: No dependencies, standalone jar file. Note: Using the "antlr" groupId, which has been used for all jar files of version 2. Will use "org.antlr" for version 3. -- 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-1315) Upload antlr-3.0b5
Upload antlr-3.0b5 -- Key: MAVENUPLOAD-1315 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1315 Project: maven-upload-requests Issue Type: Task Reporter: Jochen Wiedmann The AntLR Parser Generator, version 3.0b5 Note: No dependencies, standalone jar file. Note: Using the "org.antlr" groupId, which is in use for version 3, although version 2 used "antlr". -- 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: (MAVEN-1825) Multiple tags not allowed in RC-1 (Duplicated tag: 'project')
[ http://jira.codehaus.org/browse/MAVEN-1825?page=comments#action_84621 ] Lukas Theussl commented on MAVEN-1825: -- Just like I said in the mail thread quoted above, I don't understand what the problem is really. What's the point in having duplicate tags in your pom? Was Maven ever able to distinguish them? Also, multiple version tags are simply not allowed by the current xsd http://maven.apache.org/maven-v3_0_0.xsd, (and never have been, AFAIK, only previous maven's have not enforced this). > Multiple tags not allowed in RC-1 (Duplicated tag: 'project') > > > Key: MAVEN-1825 > URL: http://jira.codehaus.org/browse/MAVEN-1825 > Project: Maven 1.x > Issue Type: Bug >Affects Versions: 1.1-rc1 >Reporter: G.J. Sterenborg > > We have combined multiple modules into components: > * component 1 > root-module-generic -- project-descriptor (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 2 > root-module-specific -- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 3 > root-module-specific2-- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * ... > Every module is released seperately in one big 'component-release'. > This component-release checks if a module has changed since the last release > and if so ups the version (and adds a -entry to module's pom.) > > Sub-modules root-module and the root-pom extends all dependent > component-descriptors. > The root-pom is specifies the component-version. > Every module gets it's own version and cvs-tag (including root-pom for the > component-version.) > After testing RC-1, seeing the 'Duplicated tag: 'project'' error and reading: > http://www.mail-archive.com/users@maven.apache.org/msg55210.html > I'm very surprised that tag duplication in parent/child modules isn't allowed > anymore. > Doesn't the parent-pom specify the entire project and the sub-module-poms > their own? -- 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-1132) Project view page does not show the recipient of the wagon notifier.
[ http://jira.codehaus.org/browse/CONTINUUM-1132?page=all ] Henry S. Isidro updated CONTINUUM-1132: --- Attachment: [CONTINUUM-1132]-continuum-webapp.patch File Attached: [CONTINUUM-1132]-continuum-webapp.patch This fixes the described bug. > Project view page does not show the recipient of the wagon notifier. > > > Key: CONTINUUM-1132 > URL: http://jira.codehaus.org/browse/CONTINUUM-1132 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Henry S. Isidro > Attachments: [CONTINUUM-1132]-continuum-webapp.patch > > -- 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: (CONTINUUM-1132) Project view page does not show the recipient of the wagon notifier.
Project view page does not show the recipient of the wagon notifier. Key: CONTINUUM-1132 URL: http://jira.codehaus.org/browse/CONTINUUM-1132 Project: Continuum Issue Type: Bug Components: Web interface Reporter: Henry S. Isidro -- 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-1131) Wagon notifier does not use configuration.
[ http://jira.codehaus.org/browse/CONTINUUM-1131?page=all ] Henry S. Isidro updated CONTINUUM-1131: --- Attachment: [CONTINUUM-1131]-continuum-notifier-wagon.patch File Attached: [CONTINUUM-1131]-continuum-notifier-wagon.patch This patch makes wagon notifier read the configuration for its destination url. If the url is not set in configuration, it uses the one set in in the distributionManagement section of the pom. > Wagon notifier does not use configuration. > -- > > Key: CONTINUUM-1131 > URL: http://jira.codehaus.org/browse/CONTINUUM-1131 > Project: Continuum > Issue Type: Bug >Reporter: Henry S. Isidro > Attachments: [CONTINUUM-1131]-continuum-notifier-wagon.patch > > > Wagon notifier (which is used to deploy build history report to the project > site) does not get it's configuration setting from configuration. -- 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: (MSUREFIREREP-26) Incoherent data between 'Package List ' and 'Test Cases' items in report
[ http://jira.codehaus.org/browse/MSUREFIREREP-26?page=comments#action_84616 ] Damien Lecan commented on MSUREFIREREP-26: -- Can this patch be merged into svn ? > Incoherent data between 'Package List ' and 'Test Cases' items in report > > > Key: MSUREFIREREP-26 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-26 > Project: Maven 2.x Surefire report Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Damien Lecan > Attachments: MSUREFIREREP-26-maven-surefire-plugin.patch, > MSUREFIREREP-26-maven-surefire-plugin.patch, surefire-report.html > > > As it can be seen of the attached file, the ConfigTest has incoherent data > between items 'Package List ' and 'Test Cases' . > In 'Package List ' : > Class Tests Errors FailuresSuccess RateTime > ConfigTest3 0 0100% > 0.585 > ConfigTest has just 3 tests. > But, in 'Test Cases', there are much more than 3 tests (they are duplicated > from the other tested class ManagerTest !) > ConfigTest > testCBEM1 0.039 > testCBEM2 0.001 > testCBEM3 0.001 > testCBEM4 0.001 > testCBEM5 0 > testCBEM6 0 > testCBEM7 0 > testCBEM8 0 > testCBEM9 0 > testCBEM10 0.001 > testCBEM11 0 > testCBEM12 0.001 > testGetBooleanProperty 0.528 > testGetFloatProperty0.029 > testGetIntProperty 0.012 -- 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: (CONTINUUM-1131) Wagon notifier does not use configuration.
Wagon notifier does not use configuration. -- Key: CONTINUUM-1131 URL: http://jira.codehaus.org/browse/CONTINUUM-1131 Project: Continuum Issue Type: Bug Reporter: Henry S. Isidro Wagon notifier (which is used to deploy build history report to the project site) does not get it's configuration setting from configuration. -- 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-1313) Upload stringtemplates-3.0
Upload stringtemplates-3.0 -- Key: MAVENUPLOAD-1313 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1313 Project: maven-upload-requests Issue Type: Task Reporter: Jochen Wiedmann Stringtemplate is a template library based on and using the AntLR project. -- 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-1097) Release start and end time are set to "Jan 01, 1970 01:00:00 AM CET" when a release error occurs before the actual release process
[ http://jira.codehaus.org/browse/CONTINUUM-1097?page=all ] Edwin Punzalan updated CONTINUUM-1097: -- Attachment: CONTINUUM-1097-continuum-release.patch Updated my patch against the latest from trunk > Release start and end time are set to "Jan 01, 1970 01:00:00 AM CET" when a > release error occurs before the actual release process > -- > > Key: CONTINUUM-1097 > URL: http://jira.codehaus.org/browse/CONTINUUM-1097 > Project: Continuum > Issue Type: Bug > Components: Core system >Reporter: Edwin Punzalan > Attachments: CONTINUUM-1097-continuum-release.patch, > CONTINUUM-1097-continuum-release.patch > > > Also, does not include the actual start time of the release process. -- 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-1312) Upload ZK 2.2.1 to the central repository
Upload ZK 2.2.1 to the central repository - Key: MAVENUPLOAD-1312 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1312 Project: maven-upload-requests Issue Type: Task Reporter: Tom M. Yeh http://www.zkoss.org/maven/bundles/2.2.1/zcommon-2.2.1-bundle.jar http://www.zkoss.org/maven/bundles/2.2.1/zweb-2.2.1-bundle.jar http://www.zkoss.org/maven/bundles/2.2.1/zk-2.2.1-bundle.jar http://www.zkoss.org/maven/bundles/2.2.1/zul-2.2.1-bundle.jar http://www.zkoss.org/maven/bundles/2.2.1/zhtml-2.2.1-bundle.jar http://www.zkoss.org/maven/bundles/2.2.1/zkplus-2.2.1-bundle.jar http://www.zkoss.org/maven/bundles/2.2.1/fckez-2.3-2-bundle.jar http://www.zkoss.org http://sourceforge.net/users/tomyeh/ ZK is an open-source Ajax Web framework that enables rich user interface for Web applications with no JavaScript and little programming. -- 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-1311) Upload net.sf.oval-0.8
Upload net.sf.oval-0.8 -- Key: MAVENUPLOAD-1311 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1311 Project: maven-upload-requests Issue Type: Task Reporter: Sebastian Thomschke OVal is an extensible Java 5 based object validation framework that uses annotations to express constraints and AspectJ to handle automatic validation (programming by contract). This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html 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] Created: (MECLIPSE-213) more jee support for wtp
more jee support for wtp Key: MECLIPSE-213 URL: http://jira.codehaus.org/browse/MECLIPSE-213 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: WTP support Affects Versions: 2.3 Environment: linux suse 10.0 eclipse 3.2.1 and wtp 1.5.1 java 1.5.0_8 Reporter: Richard van Nieuwenhoven Attachments: maven-eclipse-plugin-R494407.patch I tried the new release 2.3 of the eclipse plugin and noteted that not alle of my paches where included. I re-pached the 2.3 version again this time i made my changes configurable so they can be turned on and off. my changes: - prohibit dupicate entries in the classpath provided system paths in combination with log4j/commons-logging/xerces can easely create such problems - system paths are only included in ears and war when they are inside the project bether behavior would be to exclude all system paths because the war and ear plugin also ignore these - an application.xml specialy for eclipse-wtp this makes wtp ears function correctly it includes the eclipse project modules instead of the maven generated jars - manifest generation for wtp wtp needs manifest files, but not the ones maven creates because they have version names for all modules etc this generates a wtp manifest that will be in a ons eclipse source directory that is ignored my maven itself use the parameters -Declipse.wtpmanifest=true -Declipse.wtpapplicationxml=true to acivate the patch. The manifest generator could be combined with the RadManifestWriter in the future, they are almost the same. regards, Ritchie -- 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: (MAVEN-1825) Multiple tags not allowed in RC-1 (Duplicated tag: 'project')
[ http://jira.codehaus.org/browse/MAVEN-1825?page=comments#action_84601 ] G.J. Sterenborg commented on MAVEN-1825: (Since I can't edit the description) * component 2 root-module-specific -- project-descriptor (project.xml,project.properties) -- generic-component-descriptor (project.xml,project.properties) -- sub-module-1 -- sub-module-2 -- .. Every component has it's own descriptor which is a dir containing a project.xml and project.properties. The project.properties in the descriptor describes sub-module-versions. > Multiple tags not allowed in RC-1 (Duplicated tag: 'project') > > > Key: MAVEN-1825 > URL: http://jira.codehaus.org/browse/MAVEN-1825 > Project: Maven 1.x > Issue Type: Bug >Affects Versions: 1.1-rc1 >Reporter: G.J. Sterenborg > > We have combined multiple modules into components: > * component 1 > root-module-generic -- project-descriptor (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 2 > root-module-specific -- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * component 3 > root-module-specific2-- project-descriptor (project.xml,project.properties) > -- generic-component-descriptor > (project.xml,project.properties) > -- sub-module-1 > -- sub-module-2 > -- ... > * ... > Every module is released seperately in one big 'component-release'. > This component-release checks if a module has changed since the last release > and if so ups the version (and adds a -entry to module's pom.) > > Sub-modules root-module and the root-pom extends all dependent > component-descriptors. > The root-pom is specifies the component-version. > Every module gets it's own version and cvs-tag (including root-pom for the > component-version.) > After testing RC-1, seeing the 'Duplicated tag: 'project'' error and reading: > http://www.mail-archive.com/users@maven.apache.org/msg55210.html > I'm very surprised that tag duplication in parent/child modules isn't allowed > anymore. > Doesn't the parent-pom specify the entire project and the sub-module-poms > their own? -- 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: (MAVEN-1825) Multiple tags not allowed in RC-1 (Duplicated tag: 'project')
Multiple tags not allowed in RC-1 (Duplicated tag: 'project') Key: MAVEN-1825 URL: http://jira.codehaus.org/browse/MAVEN-1825 Project: Maven 1.x Issue Type: Bug Affects Versions: 1.1-rc1 Reporter: G.J. Sterenborg We have combined multiple modules into components: * component 1 root-module-generic -- project-descriptor (project.xml,project.properties) -- sub-module-1 -- sub-module-2 -- ... * component 2 root-module-specific -- project-descriptor (project.xml,project.properties) -- generic-component-descriptor (project.xml,project.properties) -- sub-module-1 -- sub-module-2 -- ... * component 3 root-module-specific2-- project-descriptor (project.xml,project.properties) -- generic-component-descriptor (project.xml,project.properties) -- sub-module-1 -- sub-module-2 -- ... * ... Every module is released seperately in one big 'component-release'. This component-release checks if a module has changed since the last release and if so ups the version (and adds a -entry to module's pom.) Sub-modules root-module and the root-pom extends all dependent component-descriptors. The root-pom is specifies the component-version. Every module gets it's own version and cvs-tag (including root-pom for the component-version.) After testing RC-1, seeing the 'Duplicated tag: 'project'' error and reading: http://www.mail-archive.com/users@maven.apache.org/msg55210.html I'm very surprised that tag duplication in parent/child modules isn't allowed anymore. Doesn't the parent-pom specify the entire project and the sub-module-poms their own? -- 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
