[jira] Commented: (MNG-2484) Document the naming convention for archetypes
[ http://jira.codehaus.org/browse/MNG-2484?page=comments#action_71599 ] Franz Allan Valencia See commented on MNG-2484: --- Good day to you, Wendy, I have recently created a maven-archetype-plugin's documentation for [1], and it's still currently being reviewed ([2]). Anyway, I have placed in there the "Guide to Creating Archetypes" ([3]) and "Introduction to Archetypes" ([4]). And so far, nobody has objected with that. If you want, you can place apply your changes there as well so if [3] and [4] do get transfered to the maven-archetype-plugin documentation, the naming convention would still be there. WDYT? Thanks a bunch, Franz [1] http://jira.codehaus.org/browse/ARCHETYPE-45 [2] http://www.nabble.com/Maven-Archetype-Plugin-Documentation-needs-Reviewing-tf1997860.html [3] http://maven.apache.org/guides/mini/guide-creating-archetypes.html [4] http://maven.apache.org/guides/introduction/introduction-to-archetypes.html > Document the naming convention for archetypes > - > > Key: MNG-2484 > URL: http://jira.codehaus.org/browse/MNG-2484 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Wendy Smoak > Attachments: archetype-naming-convention.diff > > > As discussed, document the archetype naming convention as > -archetype-. > http://mail-archives.apache.org/mod_mbox/maven-dev/200607.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-1774) Upgrade maven-ejb-plugin to v 1.7.3
[ http://jira.codehaus.org/browse/MAVEN-1774?page=all ] Lukas Theussl updated MAVEN-1774: - Fix Version/s: 1.1-rc1 > Upgrade maven-ejb-plugin to v 1.7.3 > --- > > Key: MAVEN-1774 > URL: http://jira.codehaus.org/browse/MAVEN-1774 > Project: Maven > Issue Type: Sub-task >Reporter: Lukas Theussl > Fix For: 1.1-rc1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1774) Upgrade maven-ejb-plugin to v 1.7.3
Upgrade maven-ejb-plugin to v 1.7.3 --- Key: MAVEN-1774 URL: http://jira.codehaus.org/browse/MAVEN-1774 Project: Maven Issue Type: Sub-task Reporter: Lukas Theussl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1774) Upgrade maven-ejb-plugin to v 1.7.3
[ http://jira.codehaus.org/browse/MAVEN-1774?page=comments#action_71597 ] Lukas Theussl commented on MAVEN-1774: -- http://jira.codehaus.org/browse/MPEJB?report=com.atlassian.jira.plugin.system.project:roadmap-panel > Upgrade maven-ejb-plugin to v 1.7.3 > --- > > Key: MAVEN-1774 > URL: http://jira.codehaus.org/browse/MAVEN-1774 > Project: Maven > Issue Type: Sub-task >Reporter: Lukas Theussl > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPEJB-23) ejb:init does not compile java code if tests are not run
[ http://jira.codehaus.org/browse/MPEJB-23?page=all ] Lukas Theussl updated MPEJB-23: --- Fix Version/s: 1.7.3 > ejb:init does not compile java code if tests are not run > > > Key: MPEJB-23 > URL: http://jira.codehaus.org/browse/MPEJB-23 > Project: maven-ejb-plugin > Issue Type: Bug >Reporter: Shinobu Kawai >Priority: Critical > Fix For: 1.7.3 > > Attachments: MPEJB-23 > > > When there are no tests, or maven.test.skip=true, then the build classes and > resources are not included in the ejb jar file. > As a workaround, you can set java:compile and java:jar-resources as preGoals > for ejb:ejb in your maven.xml: > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MASSEMBLY-132) Assembly for multi-project ignoring specified scope
Assembly for multi-project ignoring specified scope
---
Key: MASSEMBLY-132
URL: http://jira.codehaus.org/browse/MASSEMBLY-132
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: All
Reporter: Vinod Panicker
Priority: Critical
After converting my project to a multi-project, the assembly plugin fails to
filter out dependency jars that have a scope other than runtime, even when the
scope in the descriptor is explicitly provided. My dep.xml -
mims-${version}/lib
false
runtime
I even tried putting exclude statements in the
section, but even that doesn't work. As a result, the assembly is littered with
unnecessary jars such as junit.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2123) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
[ http://jira.codehaus.org/browse/MNG-2123?page=all ] Edwin Punzalan updated MNG-2123: Affects Version/s: 2.0.4 > NullPointerException when a dependency uses version range and another uses an > actual version incompatible with that range > - > > Key: MNG-2123 > URL: http://jira.codehaus.org/browse/MNG-2123 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.3, 2.0.2, 2.0.4 >Reporter: Carlos Sanchez > Assigned To: Edwin Punzalan > Fix For: 2.0.5 > > Attachments: pom.xml > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Struts 1.2.7 depends on commons-digester 1.6 and jasperreports 1.1.1 in [1.7,) > Build fails with a null pointer exception that is not very explanatory > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - test:test:jar:1.0-SNAPSHOT > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for commons-digester:commons-digester > [INFO] > > [INFO] Trace > java.lang.NullPointerException: version was null for > commons-digester:commons-digester > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:361) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:222) > at > org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(ResolutionNode.java:115) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:88) > 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) > 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) > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sun Mar 05 23:26:16 PST 2006 > [INFO] Final Memory: 3M/5M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/s
[jira] Commented: (MRELEASE-146) Release tag with SVN under Cygwin fails when sending the svn command a bad absolute path
[ http://jira.codehaus.org/browse/MRELEASE-146?page=comments#action_71596 ] Joerg Schaible commented on MRELEASE-146: - Use the Windows version of the Subversion client (SCM-213). > Release tag with SVN under Cygwin fails when sending the svn command a bad > absolute path > > > Key: MRELEASE-146 > URL: http://jira.codehaus.org/browse/MRELEASE-146 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Windows XP >Reporter: Christian Gruber > > When release:prepare is invoked, on a cygwin system using svn provided with > cygwin, the following error occurs. > [INFO] Checking in modified POMs... > [INFO] Executing: svn --non-interactive commit --file > E:\DOCUME~1\CGRUBE~1.DJI\LOCALS~1\Temp\maven-scm-1141263545.commit > E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml > [INFO] Working directory: E:\projects\israfil-fw\net.israfil.foundation-JDK1.4 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The svn command failed. > Command output: > svn: > '/projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4' > is not a working copy > ... > SVN on cygwin interprets > E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml to be > /projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4, > essentially appending the absolute path on the current working driectory as > if it were a relative path. > This is very odd, since "svn > E:/projects/israfil-fw/net.israfil.foundation-JDK1.4" works like a charm. I > tried it with E: and e: to no avail. > Proposed solution: Use relative paths > Alternative - really really bad alternative: detect the presence of cygwin > and re-structure the file path to use /cygdrive/e/blah/blah format. > Ultimate remedy: Figure out why SVN is interpreting this way and fix in svn. > -Christian. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2123) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
[ http://jira.codehaus.org/browse/MNG-2123?page=all ] Edwin Punzalan updated MNG-2123: Assignee: Edwin Punzalan Due Date: 07/Aug/06 Remaining Estimate: 4 hours Original Estimate: 4 hours > NullPointerException when a dependency uses version range and another uses an > actual version incompatible with that range > - > > Key: MNG-2123 > URL: http://jira.codehaus.org/browse/MNG-2123 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.3, 2.0.2 >Reporter: Carlos Sanchez > Assigned To: Edwin Punzalan > Fix For: 2.0.5 > > Attachments: pom.xml > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Struts 1.2.7 depends on commons-digester 1.6 and jasperreports 1.1.1 in [1.7,) > Build fails with a null pointer exception that is not very explanatory > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - test:test:jar:1.0-SNAPSHOT > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for commons-digester:commons-digester > [INFO] > > [INFO] Trace > java.lang.NullPointerException: version was null for > commons-digester:commons-digester > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:361) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:222) > at > org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(ResolutionNode.java:115) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:88) > 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) > 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) > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sun Mar 05 23:26:16 PST 2006 > [INFO] Final Memory: 3M/5M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.co
[jira] Commented: (MANTRUN-55) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MANTRUN-55?page=comments#action_71595 ] Allan Ramirez commented on MANTRUN-55: -- Applied patch, and I also updated your staging site http://people.apache.org/~aramirez/maven-antrun-plugin/index.html Thanks! > Review Plugin Documentation > --- > > Key: MANTRUN-55 > URL: http://jira.codehaus.org/browse/MANTRUN-55 > Project: Maven 2.x Antrun Plugin > Issue Type: Task >Reporter: Allan Ramirez > Assigned To: Allan Ramirez > Attachments: MANTRUN-55-maven-antrun-plugin-2.patch, > MANTRUN-55-maven-antrun-plugin-3.patch, MANTRUN-55-maven-antrun-plugin.patch > > Original Estimate: 12 hours > Remaining Estimate: 12 hours > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2484) Document the naming convention for archetypes
Document the naming convention for archetypes - Key: MNG-2484 URL: http://jira.codehaus.org/browse/MNG-2484 Project: Maven 2 Issue Type: Improvement Components: Documentation: Guides Reporter: Wendy Smoak Attachments: archetype-naming-convention.diff As discussed, document the archetype naming convention as -archetype-. http://mail-archives.apache.org/mod_mbox/maven-dev/200607.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-138) complete the proxy interface
[ http://jira.codehaus.org/browse/MRM-138?page=all ] Brett Porter updated MRM-138: - Remaining Estimate: 16 hours Original Estimate: 16 hours > complete the proxy interface > > > Key: MRM-138 > URL: http://jira.codehaus.org/browse/MRM-138 > Project: Maven Repository Manager > Issue Type: New Feature > Components: remote proxy >Reporter: Brett Porter > Fix For: 1.0-beta-1 > > Original Estimate: 16 hours > Remaining Estimate: 16 hours > > the current proxy interface is not well integrated and the tests are failing. > Complete this integration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPEJB-23) ejb:init does not compile java code if tests are not run
[ http://jira.codehaus.org/browse/MPEJB-23?page=comments#action_71585 ] dion gillard commented on MPEJB-23: --- This is a showstopper for another 1.1 beta release for me, as well. > ejb:init does not compile java code if tests are not run > > > Key: MPEJB-23 > URL: http://jira.codehaus.org/browse/MPEJB-23 > Project: maven-ejb-plugin > Issue Type: Bug >Reporter: Shinobu Kawai >Priority: Critical > Attachments: MPEJB-23 > > > When there are no tests, or maven.test.skip=true, then the build classes and > resources are not included in the ejb jar file. > As a workaround, you can set java:compile and java:jar-resources as preGoals > for ejb:ejb in your maven.xml: > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2481) project builder should make the processed project cache configurable
[ http://jira.codehaus.org/browse/MNG-2481?page=comments#action_71584 ] Brett Porter commented on MNG-2481: --- WHM would be a good start, probably sufficient for some needs, but I also think having a caching plexus component of which one impl is a WHM would be nice too ;) I can see a possibility for wanting greater control over this to pre-emptively clean up memory. > project builder should make the processed project cache configurable > > > Key: MNG-2481 > URL: http://jira.codehaus.org/browse/MNG-2481 > Project: Maven 2 > Issue Type: Bug > Components: POM, Performance >Affects Versions: 2.0.4 >Reporter: Brett Porter > Fix For: 2.0.5 > > > the cache in the project builder is a simple map. This is usually fine for > Maven, but in long lived processes (Continuum, MRM, and I imagine the IDE > plugins as it gets used more) it can chew up quite some memory. > I'd suggest we make it configurable: > - can turn it on or off using plexus configuration > - can limit its size using plexus configuration > - can change other options, such as adding expiry ages to items regardless of > size > Rather than implementing something in the project builder itself, I suggest > having a cache plexus component that does everything we need it to (this > could be reused in the webapps as well). I'm not sure of any existing caching > solutions (I know OSCache has a general Java cache but don't know how > suitable it is). One alterantive might be to round out commons-cache with > some features and plexus descriptors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1029) fit-1.1
fit-1.1 Key: MAVENUPLOAD-1029 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1029 Project: maven-upload-requests Issue Type: Wish Reporter: Mauro Talevi Please upload fit-1.1.jar with POM 4.0.0 fit fit Fit 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] Commented: (MECLIPSE-132) "Class not found" when run/debug JUnit tests
[ http://jira.codehaus.org/browse/MECLIPSE-132?page=comments#action_71583 ] Jimisola Laursen commented on MECLIPSE-132: --- The proposed workaround doesn't work for me. Hence, it seems to be something else causing the problem. Sadly, I haven't been able to gain much more information. However, I followed the instructions in the mailing list thread mentioned in the description and came to the conclusion that there is no significant difference between the command line when the JUnit tests runs normally and when NoClassDefFoundError are thrown. The once chance is the port and testName filename. Quite annoying bug since there isn't a known workaround. I'll be glad to investigate further if I get some instructions. > "Class not found" when run/debug JUnit tests > > > Key: MECLIPSE-132 > URL: http://jira.codehaus.org/browse/MECLIPSE-132 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution > Environment: gentoo linux 2006, kernel 2.6, sun-jdk-1.5.0.06, maven > 2.0.4, eclipse sdk 3.2, myeclipse 5 m2 >Reporter: Diego Ballve > > This is for the behavior described in > http://www.nabble.com/Keep-getting-%22Class-not-found%22-when-running-debugging-JUnit-tests-tf1851758.html#a5442440 > You get "Class not found" when running/debuging JUnit tests. > For me it happened when I was importing another project and its dependencies > (both m2 projects). > Clean compile works fine, problem is with run. > The workaround to get it working is: > In the project containing your tests, edit Java Build Path | Order and > Export: Make sure M2 Dependencies appears BEFORE JRE System Library. > Thanks, > Diego -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1771) Upgrade maven-xdoc-plugin to v 1.10.1
[ http://jira.codehaus.org/browse/MAVEN-1771?page=comments#action_71582 ] Lukas Theussl commented on MAVEN-1771: -- Sure, I agree. I just wanted to point out that MPXDOC-197 is a very minor issue that alone doesn't necessitate a new release IMO. > Upgrade maven-xdoc-plugin to v 1.10.1 > - > > Key: MAVEN-1771 > URL: http://jira.codehaus.org/browse/MAVEN-1771 > Project: Maven > Issue Type: Sub-task > Components: planning >Affects Versions: 1.1-beta-3 >Reporter: Arnaud Heritier > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPXDOC?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPXDOC-198) Wrong margin around organization/name when no organization/logo is present
[ http://jira.codehaus.org/browse/MPXDOC-198?page=all ] Dennis Lundberg closed MPXDOC-198. -- Resolution: Fixed Fix Version/s: 1.10.1 > Wrong margin around organization/name when no organization/logo is present > -- > > Key: MPXDOC-198 > URL: http://jira.codehaus.org/browse/MPXDOC-198 > Project: maven-xdoc-plugin > Issue Type: Bug >Affects Versions: 1.10 > Environment: Maven 1.0.2, Windows XP >Reporter: Dennis Lundberg > Assigned To: Dennis Lundberg >Priority: Minor > Fix For: 1.10.1 > > > If you have a project.xml with this organization element: > > Our organization > > The margin around the "logo" in the upper left corner of the generated site > is not set. The "logo" in this case consists of the text from the > organization/name element. > If you have have a logo element inside the organization element, then the > margin is set. Like this: > > Our organization > http://our.organization.org/logo.png > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-804) Problem with continuum-webapp test and aspectj plugin
[ http://jira.codehaus.org/browse/CONTINUUM-804?page=all ] Jesse McConnell closed CONTINUUM-804. - Resolution: Fixed remove the test-compile goal and things work > Problem with continuum-webapp test and aspectj plugin > - > > Key: CONTINUUM-804 > URL: http://jira.codehaus.org/browse/CONTINUUM-804 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Affects Versions: 1.1 > Environment: acegi branch >Reporter: Carlos Sanchez > Assigned To: Jesse McConnell >Priority: Blocker > Fix For: 1.1 > > > When the aspectj plugin is in the pom the test fails > I traced the problem, in the test phase (after test-compile) for some reason > target\classes\META-INF\plexus\components.xml is the one in > src/test/resources instead of the main one -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPXDOC-197) report fails if repository is not defined
[ http://jira.codehaus.org/browse/MPXDOC-197?page=all ]
Lukas Theussl closed MPXDOC-197.
Resolution: Fixed
> report fails if repository is not defined
> -
>
> Key: MPXDOC-197
> URL: http://jira.codehaus.org/browse/MPXDOC-197
> Project: maven-xdoc-plugin
> Issue Type: Bug
>Affects Versions: 1.10
> Environment: maven 1.1-beta-3-SNAPSHOT(20060729), Operating system
> Windows 2000
>Reporter: Piotr Kania
> Assigned To: Lukas Theussl
> Fix For: 1.10.1
>
>
> If project definition contain empty repository tag then report fails:
> Project definition
>
>
> 3
> rfl-project-main
> RFL Project Main
> ${groupId}
> ${version}
>
>
>
> maven-faq-plugin
> maven-multiproject-plugin
> maven-dashboard-plugin
>
>
> xdoc:register-reports:
> faq:init:
> maven-faq-plugin:register:
> xdoc:generate-from-pom:
> [echo] Generating xdocs from POM ...
> BUILD FAILED
> org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> resource 'scm/${connscm}.xml
> '
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl
> .java:458)
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.
> java:341)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831)
> at org.apache.velocity.runtime.directive.Parse.render(Parse.java:141)
> at
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
> at
> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
> at
> org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:89)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
> at org.apache.velocity.Template.merge(Template.java:256)
> at
> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:450)
> at
> org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:186)
> at
> org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:68)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
> at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
> at
> org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
> at
> org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at
> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
> at
> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
> .java:115)
> at org.apache.maven.werkz.Goal.fire(Goal.java:647)
> at org.apache.maven.werkz.Goal.attain(Goal.java:582)
> at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:494)
> at org.apache.maven.werkz.Goal.attain(Goal.java:580)
> at
> org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208)
> at
> org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at
> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
> at
> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
> .java:115)
> at org.apache.maven.werkz.Goal.fire(Goal.java:647)
> at org.apache.maven.werkz.Goal.attain(Goal.java:582)
> at
> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:709)
> at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264)
> at org.apache.maven.cli.App.doMain(App.java:546)
>
[jira] Created: (MPXDOC-198) Wrong margin around organization/name when no organization/logo is present
Wrong margin around organization/name when no organization/logo is present -- Key: MPXDOC-198 URL: http://jira.codehaus.org/browse/MPXDOC-198 Project: maven-xdoc-plugin Issue Type: Bug Affects Versions: 1.10 Environment: Maven 1.0.2, Windows XP Reporter: Dennis Lundberg Assigned To: Dennis Lundberg Priority: Minor If you have a project.xml with this organization element: Our organization The margin around the "logo" in the upper left corner of the generated site is not set. The "logo" in this case consists of the text from the organization/name element. If you have have a logo element inside the organization element, then the margin is set. Like this: Our organization http://our.organization.org/logo.png -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-792) duplication session container in default, resubmitting failed request can force server restart to work again
[ http://jira.codehaus.org/browse/CONTINUUM-792?page=all ] Jesse McConnell closed CONTINUUM-792. - Assignee: Jesse McConnell Resolution: Fixed Fix Version/s: 1.1 this was fixed as a result of the xwork integration changes I patched up on CONTINUUM-797 > duplication session container in default, resubmitting failed request can > force server restart to work again > > > Key: CONTINUUM-792 > URL: http://jira.codehaus.org/browse/CONTINUUM-792 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Jesse McConnell > Assigned To: Jesse McConnell > Fix For: 1.1 > > > upon starting continuum-webapp with the jetty plugin occasionally a request > owill fail or timeout resulting in the followed exception for every > subsequent page. > java.lang.RuntimeException: > org.codehaus.plexus.DuplicateChildContainerException: Cannot create child > container, because child named 'session' already exists in parent 'default'. > at > org.codehaus.plexus.xwork.PlexusLifecycleListener.sessionCreated(PlexusLifecycleListener.java:117) > at > org.mortbay.jetty.servlet.AbstractSessionManager.newHttpSession(AbstractSessionManager.java:312) > at org.mortbay.jetty.Request.getSession(Request.java:963) > at > javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:215) > at > com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:47) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1042) > at > com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:78) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1042) > at > org.codehaus.plexus.xwork.PlexusFilter.doFilter(PlexusFilter.java:111) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1042) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:355) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:615) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:150) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141) > at org.mortbay.jetty.Server.handle(Server.java:272) > at > org.mortbay.jetty.HttpConnection.handlerRequest(HttpConnection.java:402) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:648) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:488) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:198) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:317) > at > org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) > Caused by: org.codehaus.plexus.DuplicateChildContainerException: Cannot > create child container, because child named 'session' already exists in > parent 'default'. > at > org.codehaus.plexus.DefaultPlexusContainer.createChildContainer(DefaultPlexusContainer.java:276) > at > org.codehaus.plexus.DefaultPlexusContainer.createChildContainer(DefaultPlexusContainer.java:268) > at > org.codehaus.plexus.xwork.PlexusLifecycleListener.sessionCreated(PlexusLifecycleListener.java:107) > ... 23 more > the only way to back out of this is to restart the jetty server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-804) Problem with continuum-webapp test and aspectj plugin
[ http://jira.codehaus.org/browse/CONTINUUM-804?page=comments#action_71576 ] Carlos Sanchez commented on CONTINUUM-804: -- but the strange part is they are copied in the test phase or I'm I wrong? > Problem with continuum-webapp test and aspectj plugin > - > > Key: CONTINUUM-804 > URL: http://jira.codehaus.org/browse/CONTINUUM-804 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Affects Versions: 1.1 > Environment: acegi branch >Reporter: Carlos Sanchez > Assigned To: Jesse McConnell >Priority: Blocker > Fix For: 1.1 > > > When the aspectj plugin is in the pom the test fails > I traced the problem, in the test phase (after test-compile) for some reason > target\classes\META-INF\plexus\components.xml is the one in > src/test/resources instead of the main one -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-797) NoSuchElementException forces restart of continuum to resolve
[ http://jira.codehaus.org/browse/CONTINUUM-797?page=all ] Jesse McConnell closed CONTINUUM-797. - Resolution: Fixed Fix Version/s: 1.1 fixed this with jason and brett, had to switch over to use the plexus-xwork-integration-single that brett had fixed up for mrm I fixed things up and jason applied my patches and the trunk should be working quite well now. > NoSuchElementException forces restart of continuum to resolve > - > > Key: CONTINUUM-797 > URL: http://jira.codehaus.org/browse/CONTINUUM-797 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 > Environment: continuum trunk >Reporter: Jesse McConnell > Assigned To: Jesse McConnell > Fix For: 1.1 > > > if a jsp reloads or you visit an invalid page then the follow exception is > thrown, and is thrown for every request after that, even to valid > pages...forcing you to restart continuum to recover. > java.util.NoSuchElementException > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:790) > at java.util.HashMap$ValueIterator.next(HashMap.java:817) > at > org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:527) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:204) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:190) > at > org.codehaus.plexus.DefaultPlexusContainer.createChildContainer(DefaultPlexusContainer.java:279) > at > org.codehaus.plexus.DefaultPlexusContainer.createChildContainer(DefaultPlexusContainer.java:268) > at org.codehaus.plexus.xwork.PlexusFilter.doFilter(PlexusFilter.java:92) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1042) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:355) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:615) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:150) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141) > at org.mortbay.jetty.Server.handle(Server.java:272) > at > org.mortbay.jetty.HttpConnection.handlerRequest(HttpConnection.java:402) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:648) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:488) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:198) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:317) > at > org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-804) Problem with continuum-webapp test and aspectj plugin
[ http://jira.codehaus.org/browse/CONTINUUM-804?page=comments#action_71573 ] Jesse McConnell commented on CONTINUUM-804: --- yes, if you look at the target/test-classes directory you see all of the classes from the target/classes copied over with aspect stuff run on them, this might also have copied over the components.xml file which is what you observed. > Problem with continuum-webapp test and aspectj plugin > - > > Key: CONTINUUM-804 > URL: http://jira.codehaus.org/browse/CONTINUUM-804 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Affects Versions: 1.1 > Environment: acegi branch >Reporter: Carlos Sanchez > Assigned To: Jesse McConnell >Priority: Blocker > Fix For: 1.1 > > > When the aspectj plugin is in the pom the test fails > I traced the problem, in the test phase (after test-compile) for some reason > target\classes\META-INF\plexus\components.xml is the one in > src/test/resources instead of the main one -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MSITE-156) site with FAQ plugin strips XML entities
[ http://jira.codehaus.org/browse/MSITE-156?page=all ] Vincent Siveton reopened MSITE-156: --- Thanks Ted for your test case! Thus, we need to handle XmlPullParser.ENTITY_REF in the FmlParser class. I will do. > site with FAQ plugin strips XML entities > > > Key: MSITE-156 > URL: http://jira.codehaus.org/browse/MSITE-156 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: WinXP >Reporter: Ted Husted > Assigned To: Vincent Siveton > > When using the FAQ plugin with site, entities lke < and > are stripped > out, and the corresponding character is not injected. > Apache Struts > renders as > a href="http://struts.apache.org"Apache Struts/a > instead of > http://struts.apache.org";>Apache Struts > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-116) Wrong SCM info put by the release plugin for modules
[ http://jira.codehaus.org/browse/MRELEASE-116?page=all ] Matthew Beermann updated MRELEASE-116: -- Attachment: patch.txt Here's a better version; I believe that this implements precisely the logic that Emmanuel mentioned above. > Wrong SCM info put by the release plugin for modules > > > Key: MRELEASE-116 > URL: http://jira.codehaus.org/browse/MRELEASE-116 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Sun JDK 1.5, M2 2.0.3-SNAPSHOT (2006-01-30), Subversion > SCM >Reporter: Arik Kfir > Fix For: 2.0 > > Attachments: patch.txt, patch.txt > > > Hi, > I have a project with several modules in it. The entire project is > stored in one SVN repository, in the following layout: > myproject > | > +-- module A > | > +-- module B > | > +-- . > The root pom has a url like "http://svn.myserver/.../trunk/";, and each > sub module also has its own tag with a url such as > "http://svn.myserver/.../trunk/moduleA";, etc. > When running "release:prepare", the URL encoded back into the modules' POMs > (the back-to-trunk pom, not the released one) is the same URL as the root > POM, rather than the original module's SCM url. So module A's urls > would be "http://svn.myserver/.../trunk/"; without the "moduleA" directory > appended to it (as it was before releasing). > Carlos has pointed out to me that the best practice for this use case is not > specifying the tag for the modules' POMs at all. He did, however, also > noted that it's still a bug - hence this JIRA ;-) > Cheers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-804) Problem with continuum-webapp test and aspectj plugin
[ http://jira.codehaus.org/browse/CONTINUUM-804?page=all ] Carlos Sanchez updated CONTINUUM-804: - Priority: Blocker (was: Major) Description: When the aspectj plugin is in the pom the test fails I traced the problem, in the test phase (after test-compile) for some reason target\classes\META-INF\plexus\components.xml is the one in src/test/resources instead of the main one Affects Version/s: 1.1 Fix Version/s: 1.1 Component/s: Web interface Environment: acegi branch > Problem with continuum-webapp test and aspectj plugin > - > > Key: CONTINUUM-804 > URL: http://jira.codehaus.org/browse/CONTINUUM-804 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Affects Versions: 1.1 > Environment: acegi branch >Reporter: Carlos Sanchez > Assigned To: Jesse McConnell >Priority: Blocker > Fix For: 1.1 > > > When the aspectj plugin is in the pom the test fails > I traced the problem, in the test phase (after test-compile) for some reason > target\classes\META-INF\plexus\components.xml is the one in > src/test/resources instead of the main one -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-804) Problem with continuum-webapp test and aspectj plugin
Problem with continuum-webapp test and aspectj plugin - Key: CONTINUUM-804 URL: http://jira.codehaus.org/browse/CONTINUUM-804 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Assigned To: Jesse McConnell -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-116) Wrong SCM info put by the release plugin for modules
[ http://jira.codehaus.org/browse/MRELEASE-116?page=comments#action_71569 ] Matthew Beermann commented on MRELEASE-116: --- Make that band-aid for sure, because it doesn't cover the case where the modules are nested a couple of levels deep. I'm having a hard time finding the point in the code where all of the information needed for correctness (the items that Emmanuel mentioned) are visible. > Wrong SCM info put by the release plugin for modules > > > Key: MRELEASE-116 > URL: http://jira.codehaus.org/browse/MRELEASE-116 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Sun JDK 1.5, M2 2.0.3-SNAPSHOT (2006-01-30), Subversion > SCM >Reporter: Arik Kfir > Fix For: 2.0 > > Attachments: patch.txt > > > Hi, > I have a project with several modules in it. The entire project is > stored in one SVN repository, in the following layout: > myproject > | > +-- module A > | > +-- module B > | > +-- . > The root pom has a url like "http://svn.myserver/.../trunk/";, and each > sub module also has its own tag with a url such as > "http://svn.myserver/.../trunk/moduleA";, etc. > When running "release:prepare", the URL encoded back into the modules' POMs > (the back-to-trunk pom, not the released one) is the same URL as the root > POM, rather than the original module's SCM url. So module A's urls > would be "http://svn.myserver/.../trunk/"; without the "moduleA" directory > appended to it (as it was before releasing). > Carlos has pointed out to me that the best practice for this use case is not > specifying the tag for the modules' POMs at all. He did, however, also > noted that it's still a bug - hence this JIRA ;-) > Cheers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-116) Wrong SCM info put by the release plugin for modules
[ http://jira.codehaus.org/browse/MRELEASE-116?page=all ] Matthew Beermann updated MRELEASE-116: -- Attachment: patch.txt This is a possible fix... at the very least, it's a band-aid that appears to work around the problem. > Wrong SCM info put by the release plugin for modules > > > Key: MRELEASE-116 > URL: http://jira.codehaus.org/browse/MRELEASE-116 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Sun JDK 1.5, M2 2.0.3-SNAPSHOT (2006-01-30), Subversion > SCM >Reporter: Arik Kfir > Fix For: 2.0 > > Attachments: patch.txt > > > Hi, > I have a project with several modules in it. The entire project is > stored in one SVN repository, in the following layout: > myproject > | > +-- module A > | > +-- module B > | > +-- . > The root pom has a url like "http://svn.myserver/.../trunk/";, and each > sub module also has its own tag with a url such as > "http://svn.myserver/.../trunk/moduleA";, etc. > When running "release:prepare", the URL encoded back into the modules' POMs > (the back-to-trunk pom, not the released one) is the same URL as the root > POM, rather than the original module's SCM url. So module A's urls > would be "http://svn.myserver/.../trunk/"; without the "moduleA" directory > appended to it (as it was before releasing). > Carlos has pointed out to me that the best practice for this use case is not > specifying the tag for the modules' POMs at all. He did, however, also > noted that it's still a bug - hence this JIRA ;-) > Cheers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPPOM-6) Id in POM is deprecated.
[ http://jira.codehaus.org/browse/MPPOM-6?page=comments#action_71567 ] Arnaud Heritier commented on MPPOM-6: - I reopened MAVEN-1410 > Id in POM is deprecated. > > > Key: MPPOM-6 > URL: http://jira.codehaus.org/browse/MPPOM-6 > Project: maven-pom-plugin > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Arnaud Heritier >Priority: Critical > Fix For: 1.5.1 > > > The pom:validate goal uses a schema which is false. The id element is > deprecated and replaced by groupId/artifactId. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MAVEN-1410) pom.artifactId is missing from XML schema and pom.id should be removed
[ http://jira.codehaus.org/browse/MAVEN-1410?page=all ] Arnaud Heritier reopened MAVEN-1410: The Id is always mandatory in the xsd. and thus in the pom plugin > pom.artifactId is missing from XML schema and pom.id should be removed > -- > > Key: MAVEN-1410 > URL: http://jira.codehaus.org/browse/MAVEN-1410 > Project: Maven > Issue Type: Bug > Components: model >Affects Versions: 1.0 >Reporter: Dennis Lundberg > Fix For: 1.1-beta-1 > > Attachments: maven-project-3.xsd.patch, > maven-project.xsd-1_0-BRANCH.patch, xdocs-artifactId-version2.patch, > xdocs-artifactId.patch > > > After some discussion on the dev-list "pom.id versus pom.artifactId - which > is correct?" there seems to be some inconsistencies in the 1.0 release. > The discussion resulted in the following conclusions: > 1. The element project.id should be removed from the XML schema > 2. The element project.artifactId should be added to the XML schema > 3. Documentation needs to be updated to reflect the above issues > 1 and 2 should probably be done by one of the core developers, including > decisions regarding version numbers for the XML schema. I can make a patch > for it if you think that's ok. > I can make patches for the xdocs to fix 3. On which branch should I create > the patches? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1771) Upgrade maven-xdoc-plugin to v 1.10.1
[ http://jira.codehaus.org/browse/MAVEN-1771?page=comments#action_71564 ] Arnaud Heritier commented on MAVEN-1771: In theory yes ;-) You have to know that our users have the habit to take a release and to not update their plugins. Why ? Because in maven 1 you can't easily update them like in maven 2. You have to ensure that all the developers in the team use the same set of plugins. It's based on my own experience I saw that several times ... It's why the users consider we didn't make a release since september, even if we republished a lot of plugins > Upgrade maven-xdoc-plugin to v 1.10.1 > - > > Key: MAVEN-1771 > URL: http://jira.codehaus.org/browse/MAVEN-1771 > Project: Maven > Issue Type: Sub-task > Components: planning >Affects Versions: 1.1-beta-3 >Reporter: Arnaud Heritier > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPXDOC?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-799) One sub module randomly appears twice after adding a parent multi-module
[ http://jira.codehaus.org/browse/CONTINUUM-799?page=comments#action_71562 ] Jonathan Johnson commented on CONTINUUM-799: Adam [EMAIL PROTECTED] found that if you delete the build definitions from the doubled project, you should be able to delete the project then. I tried that and it worked. This is a workaround for now. > One sub module randomly appears twice after adding a parent multi-module > - > > Key: CONTINUUM-799 > URL: http://jira.codehaus.org/browse/CONTINUUM-799 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.0.3 > Environment: Linux Red Hat >Reporter: Jonathan Johnson > Fix For: 1.0.3 > > > One sub module randomly appears twice after adding a parent multi-module to > continuum 1.0.3. > I have a parent maven 2 pom with 16 sub-modules. If I reset the database ( > by removing the database directory) and add my parent pom.xml all the modules > will be added correctly except one random module will be added twice. I > tried this three times and a different module in the list is duplicated once. > This also happens after a fresh install of version 1.0.3. > If I run a "Build All" one of the duplicate modules builds, while the other > remains with a "New" status. When attempting to remove the duplicate module > with the "New" status I get the error below. > -- > [EMAIL PROTECTED] also reported this... > "I've had a similar problem when using continuum with SVN. I end up with two > projects that have the exact same SCM url, but different continuum build id's > (sequential, in my case). Updating the build definition for one, > automatically updates it for the other. However, updates inside svn only > trigger one of them to be built by continuum, and not both. If I try to > delete the duplicated project, I get the continuum error page with the same > error output." > -- > Additional findinds... > I looked in the working directory. I have 1-15 directories under > working-directory. The module that is duplicated has an id of 10 and another > of 16. The one that is 16 is the module that still has the status of "New" > and throws the database DELETE exception when I try to remove the module from > the Continuum list. > the duplicateD module has different ids (10 and 16) but working directory > does not have a "16" folder. > Here is theexception when removing the duplicate module with the id of "16" > ognl.MethodFailedException: Method "removeProject" failed for object [EMAIL > PROTECTED] [javax.jdo.JDOUserException: One or more instances could not be > deleted > NestedThrowables: > javax.jdo.JDODataStoreException: Delete request failed: DELETE FROM > BUILDDEFINITION WHERE ID = ? > NestedThrowables: > SQL Exception: DELETE on table 'BUILDDEFINITION' caused a violation of > foreign key constraint 'PROJECT_BUILP8_FK2' for key (10). The statement has > been rolled back.] > at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) > at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) > at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) > at ognl.ASTMethod.getValueBody(ASTMethod.java:75) > at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) > at ognl.SimpleNode.getValue(SimpleNode.java:210) > at ognl.Ognl.getValue(Ognl.java:333) > at ognl.Ognl.getValue(Ognl.java:378) > at ognl.Ognl.getValue(Ognl.java:357) > at > org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) > at > org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) > at > org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) > at > org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) > at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) > at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) > at org.mortbay.http.HttpServer.service(HttpServer.java:879) > at org.mortbay.http.HttpConnection.service(Ht
[jira] Updated: (JXR-21) Greather than sign not handle as predefined entity
[ http://jira.codehaus.org/browse/JXR-21?page=all ]
Vincent Siveton updated JXR-21:
---
Attachment: JXR-21.diff
Associated patch
> Greather than sign not handle as predefined entity
> --
>
> Key: JXR-21
> URL: http://jira.codehaus.org/browse/JXR-21
> Project: Maven JXR
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Vincent Siveton
> Attachments: JXR-21.diff
>
>
> Currently, the less than sign ( < ) is correctly handle:
> {code}
> "<" is replaced by "<"
> {code}
> Should be the same for greather than sign ( > )
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (JXR-21) Greather than sign not handle as predefined entity
Greather than sign not handle as predefined entity
--
Key: JXR-21
URL: http://jira.codehaus.org/browse/JXR-21
Project: Maven JXR
Issue Type: Bug
Affects Versions: 1.1
Reporter: Vincent Siveton
Currently, the less than sign ( < ) is correctly handle:
{code}
"<" is replaced by "<"
{code}
Should be the same for greather than sign ( > )
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MPPOM-6) Id in POM is deprecated.
[ http://jira.codehaus.org/browse/MPPOM-6?page=comments#action_71556 ] Dennis Lundberg commented on MPPOM-6: - I was a bit surprised by this myself, as I had had seen MAVEN-1410 being closed. I thought that the xsd had been changed according to the previous comments in that issue. I didn't realize that the pom-plugin needed to be changed as well. Anyway, how about releasing a new version of the pom-plugin that is Maven 1.1 only. This has been done with other plugins already. That new version would then use a new xsd, call it 3.0.1 or 3.1 or whatever, in which the id element is not required and artifactId/groupId is. > Id in POM is deprecated. > > > Key: MPPOM-6 > URL: http://jira.codehaus.org/browse/MPPOM-6 > Project: maven-pom-plugin > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Arnaud Heritier >Priority: Critical > Fix For: 1.5.1 > > > The pom:validate goal uses a schema which is false. The id element is > deprecated and replaced by groupId/artifactId. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-146) Release tag with SVN under Cygwin fails when sending the svn command a bad absolute path
Release tag with SVN under Cygwin fails when sending the svn command a bad absolute path Key: MRELEASE-146 URL: http://jira.codehaus.org/browse/MRELEASE-146 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Environment: Windows XP Reporter: Christian Gruber When release:prepare is invoked, on a cygwin system using svn provided with cygwin, the following error occurs. [INFO] Checking in modified POMs... [INFO] Executing: svn --non-interactive commit --file E:\DOCUME~1\CGRUBE~1.DJI\LOCALS~1\Temp\maven-scm-1141263545.commit E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml [INFO] Working directory: E:\projects\israfil-fw\net.israfil.foundation-JDK1.4 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: '/projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4' is not a working copy ... SVN on cygwin interprets E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml to be /projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4, essentially appending the absolute path on the current working driectory as if it were a relative path. This is very odd, since "svn E:/projects/israfil-fw/net.israfil.foundation-JDK1.4" works like a charm. I tried it with E: and e: to no avail. Proposed solution: Use relative paths Alternative - really really bad alternative: detect the presence of cygwin and re-structure the file path to use /cygdrive/e/blah/blah format. Ultimate remedy: Figure out why SVN is interpreting this way and fix in svn. -Christian. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1884) settings.xml in home directory/.m2/ doesn't have an effect
[ http://jira.codehaus.org/browse/MNG-1884?page=comments#action_71551 ] Milos Kleint commented on MNG-1884: --- i think the stuff in trunk should work fine already, it least it is for the netbeans integration.. > settings.xml in home directory/.m2/ doesn't have an effect > -- > > Key: MNG-1884 > URL: http://jira.codehaus.org/browse/MNG-1884 > Project: Maven 2 > Issue Type: Bug > Components: Embedding > Environment: Windows XP + J2SE 1.5 + Eclipse 3.1.0 >Reporter: Simon Vos > Assigned To: Jason van Zyl > Fix For: 2.1 > > > I have to use a proxy-server to connect to the internet and for that I use a > settings.xml file for maven2 which is configured to use the proxy server and > a local remote server. This remote server is a server in our network which > contains our jars, ejbs, etc. and most of the packages we use to develop our > applications. This all works fine, but the plugin doesn't seem to keep the > settings.xml file into account when trying to retrieve the dependencies. > What I tried was just putting the settings.xml file I use in my home > directory/.m2/, but the plugin doesn't react to that, eventhough it says it's > looking there when I choose to see the debug output.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNGECLIPSE-174) settings.xml ignored when building classpath
[ http://jira.codehaus.org/browse/MNGECLIPSE-174?page=all ] Justin Edelson updated MNGECLIPSE-174: -- Attachment: settings.xml plugintest.zip Basic steps to reproduce: install this settings.xml file ensure there's nothing in org/apache/maven/maven directory in your local repository add the zipped project to your Eclipse workspace Observe this error in the M2 console: 8/3/06 1:07:14 PM EDT: Project build error Cannot find parent: org.apache.maven:maven for project: test:plugintest:jar:2.1-SNAPSHOT > settings.xml ignored when building classpath > > > Key: MNGECLIPSE-174 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-174 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.10 >Reporter: Justin Edelson > Assigned To: Eugene Kuleshov > Attachments: m2eclipse.patch, plugintest.zip, settings.xml > > > It appears that the current trunk (targetting 0.0.10) fixes most of the bugs > related to using the user settings.xml file when running a maven 2 build. > However, it still does not use settings.xml when building the classpath > entries. I first encountered this problem when the parent pom was contained > in a repository added by my settings.xml. > In any case, the solution seems to be to create a MavenEmbedRequest object > with the user settings file and pass it to embedder.start(). > Patch attached. > This did make me wonder if the plugin should lose the local repository > preference and instead have a user settings file preference. 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] Created: (MASSEMBLY-131) Missing 'return' statement in AbstractAssemblyMojo#isProjectModule()
Missing 'return' statement in AbstractAssemblyMojo#isProjectModule() Key: MASSEMBLY-131 URL: http://jira.codehaus.org/browse/MASSEMBLY-131 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Alexis Midon Attachments: AbstractAssemblyMojo.java A 'return' statement is missing line 716, in AbstractAssemblyMojo#isProjectModule() Check the "else if ( recurse )" close. Path is delimited by : // PATCH BEGIN // PATCH END -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2464) [regression] maven 2.1 uses snapshot repository to look for plugins
[ http://jira.codehaus.org/browse/MNG-2464?page=comments#action_71547 ] Carlos Sanchez commented on MNG-2464: - IIRC 2.0.x worked fine > [regression] maven 2.1 uses snapshot repository to look for plugins > --- > > Key: MNG-2464 > URL: http://jira.codehaus.org/browse/MNG-2464 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle, Dependencies >Affects Versions: 2.1 >Reporter: Carlos Sanchez > Fix For: 2.1 > > Attachments: mvn2.0.4.log, mvn2.1.log > > > Building components trunk with 2.0.4 and 2.1-SNAPSHOT from > http://maven.zones.apache.org/~maven/builds/trunk/m2-20060724.103002.tar.gz -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MNGECLIPSE-174) settings.xml ignored when building classpath
[ http://jira.codehaus.org/browse/MNGECLIPSE-174?page=comments#action_71546 ] Eugene Kuleshov commented on MNGECLIPSE-174: Please attach Eclipse Eclipse project, settings.xml and exact steps to reproduce this issue. Thanks. > settings.xml ignored when building classpath > > > Key: MNGECLIPSE-174 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-174 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.10 >Reporter: Justin Edelson > Assigned To: Eugene Kuleshov > Attachments: m2eclipse.patch > > > It appears that the current trunk (targetting 0.0.10) fixes most of the bugs > related to using the user settings.xml file when running a maven 2 build. > However, it still does not use settings.xml when building the classpath > entries. I first encountered this problem when the parent pom was contained > in a repository added by my settings.xml. > In any case, the solution seems to be to create a MavenEmbedRequest object > with the user settings file and pass it to embedder.start(). > Patch attached. > This did make me wonder if the plugin should lose the local repository > preference and instead have a user settings file preference. 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] Created: (MNGECLIPSE-174) settings.xml ignored when building classpath
settings.xml ignored when building classpath Key: MNGECLIPSE-174 URL: http://jira.codehaus.org/browse/MNGECLIPSE-174 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Affects Versions: 0.0.10 Reporter: Justin Edelson Assigned To: Eugene Kuleshov Attachments: m2eclipse.patch It appears that the current trunk (targetting 0.0.10) fixes most of the bugs related to using the user settings.xml file when running a maven 2 build. However, it still does not use settings.xml when building the classpath entries. I first encountered this problem when the parent pom was contained in a repository added by my settings.xml. In any case, the solution seems to be to create a MavenEmbedRequest object with the user settings file and pass it to embedder.start(). Patch attached. This did make me wonder if the plugin should lose the local repository preference and instead have a user settings file preference. 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: (MNGECLIPSE-172) Eclipse PDE seems slightly incompatible with plugin
[ http://jira.codehaus.org/browse/MNGECLIPSE-172?page=all ] Yuri Schimke closed MNGECLIPSE-172. --- Resolution: Duplicate duplicate of MNGECLIPSE-106 > Eclipse PDE seems slightly incompatible with plugin > --- > > Key: MNGECLIPSE-172 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-172 > Project: Maven 2.x Extension for Eclipse > Issue Type: Improvement >Affects Versions: 0.0.9 >Reporter: Yuri Schimke > Assigned To: Eugene Kuleshov > > Eclipse PDE Rich Clients seem to have trouble when using the maven plugin. > To actually build the client application it seems to need the dependency jars > within the project. To get around this we use the > dependency:copy-dependencies task. However this setup stops debugging from > working. It also means you need to run mvn install for the other projects > each time before you copy the dependencies. > In constrast, after applying the patch from MNGECLIPSE-59, non-PDE projects > work brilliantly. > I'm reporting this improvement for a number of reasons 1) in case others are > facing the same problem, 2) in case other have solved the same problem > already and 3) in case it might be something you guys can fix easily. > You guys might be the best candidates to answer 2) since you presumably use > Eclipse to edit the maven2 plugin anyway. > Another option might be to make each maven JAR a valid OSGI plugin, which is > mainly a couple of extra files in the JAR. This could potentially be done > with a MOJO that added the default, most liberal OSGI settings into the JAR. > But this seems a bit extreme, and also inflexible in the case of truly > internal dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Assembly including binaries: Bug on a n depth hierarchy
I forgot to add that there is a real bug in
AbstractAssemblyMojo.isProjectModule() method.
A return statement is missing line716
private boolean isProjectModule( String parentId, MavenProject
reactorProject, boolean recurse )
{
MavenProject parent = reactorProject.getParent();
if ( parent != null )
{
if ( parent.getId().equals( parentId ) )
{
return true;
}
else if ( recurse )
{
return isProjectModule( parentId, parent, true );
}
}
return false;
}
On 8/3/06, Alexis Midon <[EMAIL PROTECTED]> wrote:
Hi all,
I have the following complex but common pom hierarchy (sample) :
The syntax is packaging:pom:level.#
pom:pom0.0
/\
/ \
/\
/ \
/\
jar:pom1.0 pom:pom1.1
/\
/ \
/\
/ \
/\
jar:pom2.0 jar:pom2.1
I'd like to use the assembly plugin to gather all the output jars in a
single directory.
(So every child/target/artifact.jar must copy to root/target/assembly/...)
To do so I execute the assemby:assembly goal with the following descriptor
:
collect-alljars
dir
false
false
Unfortunately this always fails into an exception: "pom:pom1.1 does not
have an artifact with a file. Please ensure the package phase (...)"
This use case highlights 2 problems I think:
1. the assembly plugin does not support n depth hierarchy
Actually pom:pom1.1 should not be included in the module list while
jar:pom2.0 and jar:pom2.1 should.
2. the tag must not throw an exception if there is no
file, I think
To understand what's going on with bug #1, I decided to debug the plugin.
The problem occurs in AbstractAssemblyMojo.processModules (...) line 471
The getModulesFromReactor() method is invoked but with recurse set to
false!
As a result when jar:pom2.0 is tested, the isProjectModule() method
returns false, which is not correct (in our case).
May be 'recurse' could be a plugin parameter?
I don't know if everybody will call this a bug, nor if this list is the
right place to report but I hope it will help.
Thanks in advance if you have any workaround.
Alexis
[jira] Updated: (MNG-2483) Review caching strategies throughout Maven for long-lived processes
[ http://jira.codehaus.org/browse/MNG-2483?page=all ] John Casey updated MNG-2483: Fix Version/s: 2.1 > Review caching strategies throughout Maven for long-lived processes > --- > > Key: MNG-2483 > URL: http://jira.codehaus.org/browse/MNG-2483 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories, Plugins and Lifecycle, > Plugin Creation Tools, Logging, maven-archiver, Plugin API, Ant tasks, > Inheritence and Interpolation, Embedding, Plugin Requests, Reactor and > workspace, Performance, Dependencies, Deployment, Sites & Reporting, General, > Repositories, Artifacts, Settings >Affects Versions: 2.0.5, 2.0.4 >Reporter: John Casey >Priority: Critical > Fix For: 2.1 > > > We need to revisit all instances where Maps, etc. are used to cache data > inside Maven (maven-artifact has some, as does maven-project, f.e.). Wherever > caching is used, we need to apply some sort of aging and/or size-limiting > implementation to keep Maven from chewing up massive amounts of memory in > long-lived processes, such as IDE extensions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2483) Review caching strategies throughout Maven for long-lived processes
Review caching strategies throughout Maven for long-lived processes --- Key: MNG-2483 URL: http://jira.codehaus.org/browse/MNG-2483 Project: Maven 2 Issue Type: Improvement Components: Ant tasks, Artifacts, Artifacts and Repositories, Dependencies, Deployment, Embedding, General, Inheritence and Interpolation, Logging, maven-archiver, Performance, Plugin API, Plugin Creation Tools, Plugin Requests, Plugins and Lifecycle, Reactor and workspace, Repositories, Settings, Sites & Reporting Affects Versions: 2.0.4, 2.0.5 Reporter: John Casey Priority: Critical We need to revisit all instances where Maps, etc. are used to cache data inside Maven (maven-artifact has some, as does maven-project, f.e.). Wherever caching is used, we need to apply some sort of aging and/or size-limiting implementation to keep Maven from chewing up massive amounts of memory in long-lived processes, such as IDE extensions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2481) project builder should make the processed project cache configurable
[ http://jira.codehaus.org/browse/MNG-2481?page=all ] John Casey updated MNG-2481: Fix Version/s: 2.0.5 > project builder should make the processed project cache configurable > > > Key: MNG-2481 > URL: http://jira.codehaus.org/browse/MNG-2481 > Project: Maven 2 > Issue Type: Bug > Components: POM, Performance >Affects Versions: 2.0.4 >Reporter: Brett Porter > Fix For: 2.0.5 > > > the cache in the project builder is a simple map. This is usually fine for > Maven, but in long lived processes (Continuum, MRM, and I imagine the IDE > plugins as it gets used more) it can chew up quite some memory. > I'd suggest we make it configurable: > - can turn it on or off using plexus configuration > - can limit its size using plexus configuration > - can change other options, such as adding expiry ages to items regardless of > size > Rather than implementing something in the project builder itself, I suggest > having a cache plexus component that does everything we need it to (this > could be reused in the webapps as well). I'm not sure of any existing caching > solutions (I know OSCache has a general Java cache but don't know how > suitable it is). One alterantive might be to round out commons-cache with > some features and plexus descriptors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2481) project builder should make the processed project cache configurable
[ http://jira.codehaus.org/browse/MNG-2481?page=comments#action_71543 ] John Casey commented on MNG-2481: - Do you think this requires a full-blown caching solution, or will a WeakHashMap suffice? > project builder should make the processed project cache configurable > > > Key: MNG-2481 > URL: http://jira.codehaus.org/browse/MNG-2481 > Project: Maven 2 > Issue Type: Bug > Components: POM, Performance >Affects Versions: 2.0.4 >Reporter: Brett Porter > Fix For: 2.0.5 > > > the cache in the project builder is a simple map. This is usually fine for > Maven, but in long lived processes (Continuum, MRM, and I imagine the IDE > plugins as it gets used more) it can chew up quite some memory. > I'd suggest we make it configurable: > - can turn it on or off using plexus configuration > - can limit its size using plexus configuration > - can change other options, such as adding expiry ages to items regardless of > size > Rather than implementing something in the project builder itself, I suggest > having a cache plexus component that does everything we need it to (this > could be reused in the webapps as well). I'm not sure of any existing caching > solutions (I know OSCache has a general Java cache but don't know how > suitable it is). One alterantive might be to round out commons-cache with > some features and plexus descriptors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2464) [regression] maven 2.1 uses snapshot repository to look for plugins
[ http://jira.codehaus.org/browse/MNG-2464?page=all ] John Casey updated MNG-2464: Fix Version/s: 2.1 Carlos, do you know whether this is happening on the current 2.0.x branch as well? I'm assigning Fix For to 2.1 for now... > [regression] maven 2.1 uses snapshot repository to look for plugins > --- > > Key: MNG-2464 > URL: http://jira.codehaus.org/browse/MNG-2464 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle, Dependencies >Affects Versions: 2.1 >Reporter: Carlos Sanchez > Fix For: 2.1 > > Attachments: mvn2.0.4.log, mvn2.1.log > > > Building components trunk with 2.0.4 and 2.1-SNAPSHOT from > http://maven.zones.apache.org/~maven/builds/trunk/m2-20060724.103002.tar.gz -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1771) Upgrade maven-xdoc-plugin to v 1.10.1
[ http://jira.codehaus.org/browse/MAVEN-1771?page=comments#action_71541 ] Lukas Theussl commented on MAVEN-1771: -- Not sure this is really necessary. We should only schedule plugin issues if they are relevant for a core release. MPXDOC-197 is is just a minor issue that can be fixed independently. > Upgrade maven-xdoc-plugin to v 1.10.1 > - > > Key: MAVEN-1771 > URL: http://jira.codehaus.org/browse/MAVEN-1771 > Project: Maven > Issue Type: Sub-task > Components: planning >Affects Versions: 1.1-beta-3 >Reporter: Arnaud Heritier > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPXDOC?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Assembly including binaries: Bug on a n depth hierarchy
Hi all, I have the following complex but common pom hierarchy (sample) : The syntax is packaging:pom:level.# pom:pom0.0 /\ / \ /\ / \ /\ jar:pom1.0 pom:pom1.1 /\ / \ /\ / \ /\ jar:pom2.0 jar:pom2.1 I'd like to use the assembly plugin to gather all the output jars in a single directory. (So every child/target/artifact.jar must copy to root/target/assembly/...) To do so I execute the assemby:assembly goal with the following descriptor : collect-alljars dir false false Unfortunately this always fails into an exception: "pom:pom1.1 does not have an artifact with a file. Please ensure the package phase (...)" This use case highlights 2 problems I think: 1. the assembly plugin does not support n depth hierarchy Actually pom:pom1.1 should not be included in the module list while jar:pom2.0 and jar:pom2.1 should. 2. the tag must not throw an exception if there is no file, I think To understand what's going on with bug #1, I decided to debug the plugin. The problem occurs in AbstractAssemblyMojo.processModules (...) line 471 The getModulesFromReactor() method is invoked but with recurse set to false! As a result when jar:pom2.0 is tested, the isProjectModule() method returns false, which is not correct (in our case). May be 'recurse' could be a plugin parameter? I don't know if everybody will call this a bug, nor if this list is the right place to report but I hope it will help. Thanks in advance if you have any workaround. Alexis
[jira] Created: (MPA-77) Process Jeff Jensen
Process Jeff Jensen --- Key: MPA-77 URL: http://jira.codehaus.org/browse/MPA-77 Project: Maven Project Administration Issue Type: Task Components: New Committers Reporter: Lukas Theussl Assigned To: Jason van Zyl Fix For: 2006-q3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPA-76) Process Shinobu Kawai
Process Shinobu Kawai - Key: MPA-76 URL: http://jira.codehaus.org/browse/MPA-76 Project: Maven Project Administration Issue Type: Task Components: New Committers Reporter: Lukas Theussl Assigned To: Jason van Zyl Fix For: 2006-q3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-803) Unable to upload pom
[ http://jira.codehaus.org/browse/CONTINUUM-803?page=comments#action_71536 ] Carlos Sanchez commented on CONTINUUM-803: -- This was in continuum trunk > Unable to upload pom > > > Key: CONTINUUM-803 > URL: http://jira.codehaus.org/browse/CONTINUUM-803 > Project: Continuum > Issue Type: Bug > Components: Web interface > Environment: Linux FC4, Maven 2.0.4, JDK 1.5 >Reporter: Napoleon Esmundo C. Ramirez > > When uploading a pom, I see the ff In the logs: > 21:09:41,890 ERROR > com.opensymphony.webwork.dispatcher.multipart.MultiPartRequest > [com.opensymphony.webwork.dispatcher.multipart.JakartaMultiPartRequest] > org.apache.commons.fileupload.FileUploadException: Processing of > multipart/form-data request failed. > ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or > directory) > 21:09:41,893 ERROR com.opensymphony.webwork.interceptor.FileUploadInterceptor > [com.opensymphony.webwork.interceptor.FileUploadInterceptor] Processing of > multipart/form-data request failed. > ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or > directory) > 21:09:42,349 ERROR com.opensymphony.webwork.interceptor.FileUploadInterceptor > [com.opensymphony.webwork.interceptor.FileUploadInterceptor] Processing of > multipart/form-data request failed. > ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or > directory) > 21:09:42,369 WARN com.opensymphony.xwork.DefaultActionInvocation > [com.opensymphony.xwork.DefaultActionInvocation] No result defined for action > org.apache.maven.continuum.web.action.ConfigurationAction and result input -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MNGECLIPSE-172) Eclipse PDE seems slightly incompatible with plugin
[ http://jira.codehaus.org/browse/MNGECLIPSE-172?page=comments#action_71535 ] Eugene Kuleshov commented on MNGECLIPSE-172: How this issue is different from MNGECLIPSE-106 ? Please let me know if this is a duplicate. Otherwise please provide example Eclipse project that can be used to reproduce your issues. I don't think we should be tweaking maven jars. Though it doesn't seem like PDE will recognize dependencies that came from maven container. Unless PDE build process will take it into the account, the only option I see is to completely use Maven to build plugins. There is an issue in Maven eclipse plugin about this. Currently our plugin is not using maven and we have all the dependencies (both embedder and new lucene) as internal jars. > Eclipse PDE seems slightly incompatible with plugin > --- > > Key: MNGECLIPSE-172 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-172 > Project: Maven 2.x Extension for Eclipse > Issue Type: Improvement >Affects Versions: 0.0.9 >Reporter: Yuri Schimke > Assigned To: Eugene Kuleshov > > Eclipse PDE Rich Clients seem to have trouble when using the maven plugin. > To actually build the client application it seems to need the dependency jars > within the project. To get around this we use the > dependency:copy-dependencies task. However this setup stops debugging from > working. It also means you need to run mvn install for the other projects > each time before you copy the dependencies. > In constrast, after applying the patch from MNGECLIPSE-59, non-PDE projects > work brilliantly. > I'm reporting this improvement for a number of reasons 1) in case others are > facing the same problem, 2) in case other have solved the same problem > already and 3) in case it might be something you guys can fix easily. > You guys might be the best candidates to answer 2) since you presumably use > Eclipse to edit the maven2 plugin anyway. > Another option might be to make each maven JAR a valid OSGI plugin, which is > mainly a couple of extra files in the JAR. This could potentially be done > with a MOJO that added the default, most liberal OSGI settings into the JAR. > But this seems a bit extreme, and also inflexible in the case of truly > internal dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPXDOC-111) is transformed into
[ http://jira.codehaus.org/browse/MPXDOC-111?page=comments#action_71534 ] Arnaud Heritier commented on MPXDOC-111: One more, one less ;-) But it's a good idea we can propose that you join the jakarta-commons team !! ;-) > is transformed into > --- > > Key: MPXDOC-111 > URL: http://jira.codehaus.org/browse/MPXDOC-111 > Project: maven-xdoc-plugin > Issue Type: Bug >Reporter: Carlos Sanchez > > This causes two line breaks (at least in IE 6) > For example (at > http://cvs.apache.org/viewcvs.cgi/maven-plugins/aspectj/xdocs/index.xml?rev=1.7&view=auto) > > > To install or update the plugin do the following: > maven plugin:download -DgroupId=maven > -DartifactId=maven-aspectj-plugin -Dversion=> > > is transformed into (at http://maven.apache.org/reference/plugins/aspectj/) > > Installing > > To install or update the plugin do the following: > maven plugin:download -DgroupId=maven > -DartifactId=maven-aspectj-plugin -Dversion= > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (ARCHETYPE-50) archetype:create-from-project
archetype:create-from-project - Key: ARCHETYPE-50 URL: http://jira.codehaus.org/browse/ARCHETYPE-50 Project: Maven Archetype Issue Type: Improvement Components: Creator Environment: winxpsp2 jdk1.5 maven2.0.4 Reporter: Adam Leggett Attachments: archetype-creator-src.zip I've created a prototype patch for the create-from-project ArchetypeCreator impl. I was hoping to work out how to invoke this using -DarchetypeCreator= at the cli but am not sure as yet. I created a template method in an abstract class to define the steps in creation so i could understand it better. Also with one eye on doing a multi-mod implementation. Also refactored some of the logic into a utility so the main creator class is cleaner. Code 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: (MCHECKSTYLE-51) Rules summary flexibility:add possibility to hide non-violated rules and to sort by descending number of occurences
[ http://jira.codehaus.org/browse/MCHECKSTYLE-51?page=comments#action_71532 ] Olivier Vierlinck commented on MCHECKSTYLE-51: -- ok, I see more documentation there on the possibile customization of the plugin. I'm ok to put the doc for the 2 new settings... if my patch is accepted! What are the next steps? > Rules summary flexibility:add possibility to hide non-violated rules and to > sort by descending number of occurences > --- > > Key: MCHECKSTYLE-51 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-51 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.1 > Environment: NA >Reporter: Olivier Vierlinck >Priority: Minor > Attachments: MNG-39787-maven-plugin-checkstyle.patch > > > While using maven + Checkstyle on a new project, the amount of > errors/warnings was quite high, due both because checkstyle was not yet > configured to match our preferences.. and also to real style errors. > To refine this, it very useful to tackle first the big problems=the one > occuring often > Similarly, it is helpful NOT to see the rules that are not violated, so that > we can concentrate on the existing problems -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPPOM-6) Id in POM is deprecated.
[ http://jira.codehaus.org/browse/MPPOM-6?page=comments#action_71531 ] Arnaud Heritier commented on MPPOM-6: - I'm sorry, but it was my fault. I didn't noticed this problem. I don't know why MAVEN-1410 was closed without to fix the schema. For me we must change the schema and maven-model to avoid errors from users. But for me the choice is id or groupId+artifactId. If need the model and the xsd can become a version 3.1 instead of a 3.0.2 WDYT ? > Id in POM is deprecated. > > > Key: MPPOM-6 > URL: http://jira.codehaus.org/browse/MPPOM-6 > Project: maven-pom-plugin > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Arnaud Heritier >Priority: Critical > Fix For: 1.5.1 > > > The pom:validate goal uses a schema which is false. The id element is > deprecated and replaced by groupId/artifactId. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MASSEMBLY-128) Refactor and improve unit testing
[ http://jira.codehaus.org/browse/MASSEMBLY-128?page=all ] John Casey closed MASSEMBLY-128. Assignee: John Casey Resolution: Fixed refactor complete, and unit tests have 50% coverage, including the generated classes. Items left to test: - the mojos themselves (these are simple facades for the rest of the plugin) - default repository assembler - DigestUtils (not sure I have the expertise to test this one) - the remainder of the generated classes (esp the reader and writer classes) I believe we have a workable set of unit tests here, and I'd like to start investigating how to reinstate the functional tests as actual Maven builds that get run in the integration-test phase... > Refactor and improve unit testing > - > > Key: MASSEMBLY-128 > URL: http://jira.codehaus.org/browse/MASSEMBLY-128 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Casey > Assigned To: John Casey >Priority: Blocker > Fix For: 2.2 > > > The current implementation of the assembly plugin is that of a few really > hard to manage monoliths, from which all the mojos extend. Also, the tests > included in this plugin are not true unit tests, but more functional tests, > in that they test the entirety of a mojo under a particular use case, as if > it were a black box. > If we break the assembly plugin's abstract classes up into a reasonable set > of helper/utility classes, we should be able to unit test individual pieces > of the system without resorting to black-box testing of an entire mojo. This > should improve the resilience of these tests when a new feature is added. > Currently, it's nearly impossible to add a feature without spending a day > trying to figure out why the tests are failing (a day is not an exaggeration, > BTW). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MSUREFIRE-153) Ability to add additions to classpath
[ http://jira.codehaus.org/browse/MSUREFIRE-153?page=all ] David J. M. Karlsen updated MSUREFIRE-153: -- Attachment: MSUREFIRE-153-maven-surefire-plugin.patch The first patch was incorrect. Please delete the first attachment and use this one. Thanks, David > Ability to add additions to classpath > - > > Key: MSUREFIRE-153 > URL: http://jira.codehaus.org/browse/MSUREFIRE-153 > Project: Maven 2.x Surefire Plugin > Issue Type: Improvement > Environment: N/A >Reporter: David J. M. Karlsen > Attachments: MSUREFIRE-153-maven-surefire-plugin.patch, > SurefirePlugin.java-diff > > > There should be a possibility to add arbritary resources to the classpath > while executing the tests. These resources would only be available while > executing the tests, so they won't be added in the archive. > i suggest a configuration element > > some/path > /some/other/path > > This issue somewhat related to http://jira.codehaus.org/browse/MJAR-13 / > ability to exclude/include filtering in archiver/jar-plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPXDOC-111) is transformed into
[ http://jira.codehaus.org/browse/MPXDOC-111?page=comments#action_71528 ] Lukas Theussl commented on MPXDOC-111: -- Another custom jelly build? :( If that carries on like that we might as well take over jelly maintenance... ;) I don't think this issue is important enough for that... > is transformed into > --- > > Key: MPXDOC-111 > URL: http://jira.codehaus.org/browse/MPXDOC-111 > Project: maven-xdoc-plugin > Issue Type: Bug >Reporter: Carlos Sanchez > > This causes two line breaks (at least in IE 6) > For example (at > http://cvs.apache.org/viewcvs.cgi/maven-plugins/aspectj/xdocs/index.xml?rev=1.7&view=auto) > > > To install or update the plugin do the following: > maven plugin:download -DgroupId=maven > -DartifactId=maven-aspectj-plugin -Dversion=> > > is transformed into (at http://maven.apache.org/reference/plugins/aspectj/) > > Installing > > To install or update the plugin do the following: > maven plugin:download -DgroupId=maven > -DartifactId=maven-aspectj-plugin -Dversion= > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPPOM-6) Id in POM is deprecated.
[ http://jira.codehaus.org/browse/MPPOM-6?page=comments#action_71526 ] Lukas Theussl commented on MPPOM-6: --- Sorry but I am quite annoyed by this. Trygve mentioned on the user list that the id element was deprecated some 3 years ago, that's 2 years before I joined the Maven team. I haven't been aware that it was deprecated until this recent thread on the user list. Apparently the docs patch by Dennis at MAVEN-1410 has never been applied. When I released the last version of the pom plugin, I spent quite some time getting the validation routines to work and I compiled a table of required elements [1]. That was about half a year ago, nobody complained since, nor during vote. The main problem is that I'm not sure if some plugins don't still expect/use the id element, I'd have to check. Also, as pointed out at MAVEN-1410, we can't just change the POM-3 xsd, as it might break some existing builds. The consensus at MAVEN-1410 seems to have been to just document the deprecation, but not to change anything. The pom plugin only validates against a given xsd, so if an element is required by the xsd then it can hardly be considered a bug if the plugin complains. My personal preference would be to keep the id element required by the xsd, but to document that it's actually not used anymore by the maven core (it might still be used by some plugins). WDYT? [1] http://maven.apache.org/maven-1.x/plugins/pom/validation.html#Required_elements > Id in POM is deprecated. > > > Key: MPPOM-6 > URL: http://jira.codehaus.org/browse/MPPOM-6 > Project: maven-pom-plugin > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Arnaud Heritier >Priority: Critical > Fix For: 1.5.1 > > > The pom:validate goal uses a schema which is false. The id element is > deprecated and replaced by groupId/artifactId. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPXDOC-111) is transformed into
[ http://jira.codehaus.org/browse/MPXDOC-111?page=comments#action_71525 ] Arnaud Heritier commented on MPXDOC-111: Can we plan to upgrade our custom Jelly to fix this in the RC1 ? > is transformed into > --- > > Key: MPXDOC-111 > URL: http://jira.codehaus.org/browse/MPXDOC-111 > Project: maven-xdoc-plugin > Issue Type: Bug >Reporter: Carlos Sanchez > > This causes two line breaks (at least in IE 6) > For example (at > http://cvs.apache.org/viewcvs.cgi/maven-plugins/aspectj/xdocs/index.xml?rev=1.7&view=auto) > > > To install or update the plugin do the following: > maven plugin:download -DgroupId=maven > -DartifactId=maven-aspectj-plugin -Dversion=> > > is transformed into (at http://maven.apache.org/reference/plugins/aspectj/) > > Installing > > To install or update the plugin do the following: > maven plugin:download -DgroupId=maven > -DartifactId=maven-aspectj-plugin -Dversion= > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-410) maven plugins seem to choke on properties containing a "-"?
[ http://jira.codehaus.org/browse/MAVEN-410?page=comments#action_71524 ]
Arnaud Heritier commented on MAVEN-410:
---
It's perhaps not enough visible but I think that we can close this issue.
> maven plugins seem to choke on properties containing a "-"?
> ---
>
> Key: MAVEN-410
> URL: http://jira.codehaus.org/browse/MAVEN-410
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 1.0-beta-9
> Environment: RedHat Linux 7.3, JDK 1.3.1
>Reporter: Henning Schmiedehausen
> Fix For: 1.1-rc1
>
>
> I'm using the Torque plugin to create id-table init sql files from my
> XML schemas. If I download maven 1.0b9 from apache.org, install it and
> then issue
> % maven -X torque
> I get
> torque:id-table-init-sql:
> Using contextProperties file:
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath:
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: [0]
> excludes: [0] }
> BUILD SUCCESSFUL
> Total time: 7 seconds
> Note the [0] for include and exclude list in the file scanner.
> If I now load the plugin.properties and plugin.jelly file from
> Torque and replace in both files for the properties
> torque.schema.init-sql.includes
> torque.schema.init-sql.excludes
> the "init-sql" part with "initsql"
> and re-issue the command:
> % maven -X torque
> then I get
> torque:id-table-init-sql:
> Using contextProperties file:
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath:
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes:
> [*-schema.xml] excludes: [id-table-schema.xml] }
> Parsing file: 'scheduler-schema.xml'
> log4j:WARN No appenders could be found for logger
> (org.apache.torque.engine.database.transform.DTDResolver).
> log4j:WARN Please initialize the log4j system properly.
> Parsing file: 'torque-security-schema.xml'
> Parsing file: 'scheduler-idtable-schema.xml'
> Parsing file: 'torque-security-idtable-schema.xml'
> BUILD SUCCESSFUL
> Total time: 9 seconds
> Note that now the file scanner correctly picks up my schema files
> and builds the sql init files.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1704) artifactId is used as groupId when the latest is not defined
[ http://jira.codehaus.org/browse/MAVEN-1704?page=comments#action_71523 ] Arnaud Heritier commented on MAVEN-1704: If groupId isn't defined, groupId=artifactId thus the behaviour described seems normal. The parent and the child projects will have a different groupId. The solution could be to force users to define groupId/artifactId if id isn't defined. Otherwise we fail the build. Will it broke so many projects ? I don't think. > artifactId is used as groupId when the latest is not defined > > > Key: MAVEN-1704 > URL: http://jira.codehaus.org/browse/MAVEN-1704 > Project: Maven > Issue Type: Bug > Components: inheritance >Affects Versions: 1.1-beta-2 >Reporter: Carlos Sanchez > Fix For: 1.1-rc1 > > > artifactId is used as groupId when the latest is not defined (using extends > at least), both in 1.0.2 and 1.1b2, which I believe it's a problem, maven > should complain. > Which is really a problem is that if pom a extends pom b, and no groupId is > defined in any of both, in 1.0.2 the artifactId of a is chosen as groupId, > while in 1.1 artifactId of b is the chosen one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPXDOC-111) is transformed into
[ http://jira.codehaus.org/browse/MPXDOC-111?page=comments#action_71522 ] Lukas Theussl commented on MPXDOC-111: -- I checked it and it's still not fixed. The bug I opened in dom4j is fixed in the version we are shipping with m11b3, but the feature has to be switched on explicitly, and it's an issue of jelly using dom4j, and I forgot to check that when I custom-built our own jelly, so it's not fixed yet... :( > is transformed into > --- > > Key: MPXDOC-111 > URL: http://jira.codehaus.org/browse/MPXDOC-111 > Project: maven-xdoc-plugin > Issue Type: Bug >Reporter: Carlos Sanchez > > This causes two line breaks (at least in IE 6) > For example (at > http://cvs.apache.org/viewcvs.cgi/maven-plugins/aspectj/xdocs/index.xml?rev=1.7&view=auto) > > > To install or update the plugin do the following: > maven plugin:download -DgroupId=maven > -DartifactId=maven-aspectj-plugin -Dversion=> > > is transformed into (at http://maven.apache.org/reference/plugins/aspectj/) > > Installing > > To install or update the plugin do the following: > maven plugin:download -DgroupId=maven > -DartifactId=maven-aspectj-plugin -Dversion= > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-410) maven plugins seem to choke on properties containing a "-"?
[ http://jira.codehaus.org/browse/MAVEN-410?page=comments#action_71521 ]
Lukas Theussl commented on MAVEN-410:
-
I have added a comment already:
http://maven.apache.org/maven-1.x/using/customising.html#Extending_the_Build_with_Properties.
> maven plugins seem to choke on properties containing a "-"?
> ---
>
> Key: MAVEN-410
> URL: http://jira.codehaus.org/browse/MAVEN-410
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 1.0-beta-9
> Environment: RedHat Linux 7.3, JDK 1.3.1
>Reporter: Henning Schmiedehausen
> Fix For: 1.1-rc1
>
>
> I'm using the Torque plugin to create id-table init sql files from my
> XML schemas. If I download maven 1.0b9 from apache.org, install it and
> then issue
> % maven -X torque
> I get
> torque:id-table-init-sql:
> Using contextProperties file:
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath:
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: [0]
> excludes: [0] }
> BUILD SUCCESSFUL
> Total time: 7 seconds
> Note the [0] for include and exclude list in the file scanner.
> If I now load the plugin.properties and plugin.jelly file from
> Torque and replace in both files for the properties
> torque.schema.init-sql.includes
> torque.schema.init-sql.excludes
> the "init-sql" part with "initsql"
> and re-issue the command:
> % maven -X torque
> then I get
> torque:id-table-init-sql:
> Using contextProperties file:
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath:
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes:
> [*-schema.xml] excludes: [id-table-schema.xml] }
> Parsing file: 'scheduler-schema.xml'
> log4j:WARN No appenders could be found for logger
> (org.apache.torque.engine.database.transform.DTDResolver).
> log4j:WARN Please initialize the log4j system properly.
> Parsing file: 'torque-security-schema.xml'
> Parsing file: 'scheduler-idtable-schema.xml'
> Parsing file: 'torque-security-idtable-schema.xml'
> BUILD SUCCESSFUL
> Total time: 9 seconds
> Note that now the file scanner correctly picks up my schema files
> and builds the sql init files.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-426) Quartz 1.5.2 missing pom and jar. Has source.
[ http://jira.codehaus.org/browse/MEV-426?page=all ] Carlos Sanchez closed MEV-426. -- Assignee: Carlos Sanchez Resolution: Fixed > Quartz 1.5.2 missing pom and jar. Has source. > - > > Key: MEV-426 > URL: http://jira.codehaus.org/browse/MEV-426 > Project: Maven Evangelism > Issue Type: Improvement >Reporter: Lee Meador > Assigned To: Carlos Sanchez > Attachments: maven-repo-quartz-1.5.2.zip, pom.xml, pom.xml > > > The pom and jar are missing but the source jar, etc are there. Quartz 1.5.1 > has a pom with no dependencies. The supplied file has a pom with all the > dependencies needed to compile quartz EXCEPT ejb.jar and servlet.jar (or > servlet-api.jar) JTA and MAIL are marked optional. The others are things like > beanutils and such that are already in the repository. > Here's what I did: > 1) Download 1.5.2 from http://www.opensymphony.com/quartz/download.action > 2) Unzip and take the jar from the lib directory of what unzipped.. > 3) Build an Eclipse project with a the maven 2 plugin, using the maven layout. > 4) Copy all the unzipped source into src/main/java from the src/java > directory of what unzipped. > 5) Create a pom by turning on the maven2 eclipse plugin for the project. > 5) Add dependencies to the pom based on what wouldn't compile in eclipse. > 6) Repeat step 5 and building with mvn compile until there were no errors. > Then I copied the pom to quartz-1.5.2.pom and edited it a bit more: > 1) I removed ejb.jar and servlet.jar since I figured those would be around if > needed in quartz. > 2) I added true to jta and java mail since those jars > are Sun's and aren't in the repo > 3) I added runtime to everything else. > That is what I am sending you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1704) artifactId is used as groupId when the latest is not defined
[ http://jira.codehaus.org/browse/MAVEN-1704?page=comments#action_71520 ] Lukas Theussl commented on MAVEN-1704: -- Checked and verified. I don't think the first point should be fixed (for backwards compat), but we could give a warning message. For the second observation, I'd like to know what is the expected/defined behavior? > artifactId is used as groupId when the latest is not defined > > > Key: MAVEN-1704 > URL: http://jira.codehaus.org/browse/MAVEN-1704 > Project: Maven > Issue Type: Bug > Components: inheritance >Affects Versions: 1.1-beta-2 >Reporter: Carlos Sanchez > Fix For: 1.1-rc1 > > > artifactId is used as groupId when the latest is not defined (using extends > at least), both in 1.0.2 and 1.1b2, which I believe it's a problem, maven > should complain. > Which is really a problem is that if pom a extends pom b, and no groupId is > defined in any of both, in 1.0.2 the artifactId of a is chosen as groupId, > while in 1.1 artifactId of b is the chosen one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2482) defining a plugin within affects configuration of the same plugin defined within
defining a plugin within affects configuration of the same plugin defined within - Key: MNG-2482 URL: http://jira.codehaus.org/browse/MNG-2482 Project: Maven 2 Issue Type: Bug Components: Ant tasks, Plugin API Affects Versions: 2.0.4 Environment: windows xp sp2 Reporter: Martin Ploeckinger Attachments: build_part_of_pom.xml a problem occurs using the antrun-plugin in maven for some different tasks. first i defined the antrun-plugin within for execution tasks only in the child poms, even with 2 different execution tags and phases and it worked perfect. and now i wanted to add an ant job which should be executed only once at top level and therefore i had to "redefine" the antrun-plugin outside of with an false option. but however this does not work, the ant tasks within are now executed at top level too it is funny that both definitions work, the top-level job and the child jobs, but not togehter in one pom...i always have to leave the other ones aside i used the attached build section in my top level pom.xml and the error i get is that "rmic" is also executed at top level pom where no source is available understandably -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=all ] Denis Cabasson updated MNG-2471: Attachment: index[wlogo_wfocus_XHTML_CSS2].html I'm getting crazy Hope this time uploaded html will be right. I guess this entry need a little clean-up (but I haven't got the necessary credentials). > Add search box to the index page > > > Key: MNG-2471 > URL: http://jira.codehaus.org/browse/MNG-2471 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: General >Reporter: Marvin King > Assigned To: Marvin King > Attachments: index-wfocus-woutlogo-wmojocodehausoption.html, > index-with-focus.html, index-without-logo-with-mojocodehausoption.html, > index.html, index[wlogo_wfocus_XHTML].html, > index[wlogo_wfocus_XHTML_CSS2].html, index[wlogo_wfocus_XHTML_CSS].html, > MNG-2471-site.patch, > MNG-2471-site[with_focus_smallsearchbox_withmojocodehausoption].patch, > MNG-2471-site[wlogo_wfocus_XHTML].patch, > site-without-logo-with-mojocodehausoption.css, site[wlogo_wfocus_XHTML].css > > > - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-803) Unable to upload pom
Unable to upload pom Key: CONTINUUM-803 URL: http://jira.codehaus.org/browse/CONTINUUM-803 Project: Continuum Issue Type: Bug Components: Web interface Environment: Linux FC4, Maven 2.0.4, JDK 1.5 Reporter: Napoleon Esmundo C. Ramirez When uploading a pom, I see the ff In the logs: 21:09:41,890 ERROR com.opensymphony.webwork.dispatcher.multipart.MultiPartRequest [com.opensymphony.webwork.dispatcher.multipart.JakartaMultiPartRequest] org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or directory) 21:09:41,893 ERROR com.opensymphony.webwork.interceptor.FileUploadInterceptor [com.opensymphony.webwork.interceptor.FileUploadInterceptor] Processing of multipart/form-data request failed. ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or directory) 21:09:42,349 ERROR com.opensymphony.webwork.interceptor.FileUploadInterceptor [com.opensymphony.webwork.interceptor.FileUploadInterceptor] Processing of multipart/form-data request failed. ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or directory) 21:09:42,369 WARN com.opensymphony.xwork.DefaultActionInvocation [com.opensymphony.xwork.DefaultActionInvocation] No result defined for action org.apache.maven.continuum.web.action.ConfigurationAction and result input -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=all ] Denis Cabasson updated MNG-2471: Attachment: index[wlogo_wfocus_XHTML_CSS].html Corrected link to css (so that HTML page can be viewed) > Add search box to the index page > > > Key: MNG-2471 > URL: http://jira.codehaus.org/browse/MNG-2471 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: General >Reporter: Marvin King > Assigned To: Marvin King > Attachments: index-wfocus-woutlogo-wmojocodehausoption.html, > index-with-focus.html, index-without-logo-with-mojocodehausoption.html, > index.html, index[wlogo_wfocus_XHTML].html, > index[wlogo_wfocus_XHTML_CSS].html, MNG-2471-site.patch, > MNG-2471-site[with_focus_smallsearchbox_withmojocodehausoption].patch, > MNG-2471-site[wlogo_wfocus_XHTML].patch, > site-without-logo-with-mojocodehausoption.css, site[wlogo_wfocus_XHTML].css > > > - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=all ] Denis Cabasson updated MNG-2471: Attachment: site[wlogo_wfocus_XHTML].css corrected CSS stylesheet > Add search box to the index page > > > Key: MNG-2471 > URL: http://jira.codehaus.org/browse/MNG-2471 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: General >Reporter: Marvin King > Assigned To: Marvin King > Attachments: index-wfocus-woutlogo-wmojocodehausoption.html, > index-with-focus.html, index-without-logo-with-mojocodehausoption.html, > index.html, index[wlogo_wfocus_XHTML].html, MNG-2471-site.patch, > MNG-2471-site[with_focus_smallsearchbox_withmojocodehausoption].patch, > MNG-2471-site[wlogo_wfocus_XHTML].patch, > site-without-logo-with-mojocodehausoption.css, site[wlogo_wfocus_XHTML].css > > > - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=all ] Denis Cabasson updated MNG-2471: Attachment: MNG-2471-site[wlogo_wfocus_XHTML].patch index[wlogo_wfocus_XHTML].html Submitted my recommended changes: * Include smallest Google logo, for legal reasons * Strip br in the box, as they don't have any use * Change id of new box, and make use of classes instead * Try to comply with XHTML standard. Only 3 issues remaining on this point, but they are already there in current version. + Make use of existing focus script (with improvement to Javascript code). > Add search box to the index page > > > Key: MNG-2471 > URL: http://jira.codehaus.org/browse/MNG-2471 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: General >Reporter: Marvin King > Assigned To: Marvin King > Attachments: index-wfocus-woutlogo-wmojocodehausoption.html, > index-with-focus.html, index-without-logo-with-mojocodehausoption.html, > index.html, index[wlogo_wfocus_XHTML].html, MNG-2471-site.patch, > MNG-2471-site[with_focus_smallsearchbox_withmojocodehausoption].patch, > MNG-2471-site[wlogo_wfocus_XHTML].patch, > site-without-logo-with-mojocodehausoption.css > > > - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1676) Problem generation with antlr
[ http://jira.codehaus.org/browse/MAVEN-1676?page=all ] Emmanuel Lécharny closed MAVEN-1676. Resolution: Fixed One year old beta bugs are not anymore valid :) Let's burry it... > Problem generation with antlr > - > > Key: MAVEN-1676 > URL: http://jira.codehaus.org/browse/MAVEN-1676 > Project: Maven > Issue Type: Bug >Affects Versions: 1.1-beta-1 > Environment: Linux >Reporter: Emmanuel Lécharny > > The 1.1-beta-1 version cannot handle multiple antlr generation. 1.0.2 version > handles it correctly. > Here is a sample of this error : > on apacheds, in shared/ldap/common, > $ maven clean > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1 > plugin maven-cruisecontrol-plugin-1.6 is cached (dynatag dep) but no longer > present > Cache invalidated due to out of date plugins > DEPRECATED: the default goal should be specified in the section of > project.xml instead of maven.xml > build:start: > clean:clean: > xdoc:clean: > [delete] Deleting directory > /home/elecharny/workspace-ads-auto/shared-ldap/common/target > BUILD SUCCESSFUL > Total time : 3 seconds > Finished at : Friday, August 26, 2005 12:24:38 PM CEST > $ maven java:compile > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1 > DEPRECATED: the default goal should be specified in the section of > project.xml instead of maven.xml > build:start: > java:prepare-filesystem: > [mkdir] Created dir: > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes > java:compile: > [copy] Copying 1 file to > /home/elecharny/workspace-ads-auto/shared-ldap/common > antlr:prepare-filesystem: > [mkdir] Created dir: > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/antlr > antlr:generate: > ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com > warning: public lexical rule SIMPLE_STRING is optional (can match "nothing") > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > [delete] Deleting: > /home/elecharny/workspace-ads-auto/shared-ldap/common/DnCommonTokenTypes.txt > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > [echo] Compiling to > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes > [javac] Compiling 200 source files to > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes > [javac] > /home/elecharny/workspace-ads-auto/shared-ldap/common/src/java/org/apache/ldap/common/filter/FilterParserImpl.java:31: > cannot find symbol > [javac] symbol : class AntlrFilterParser > [javac] location: class org.apache.ldap.common.filter.FilterParserImpl > [javac] private AntlrFilterParser parser; > [javac] ^ > (... many errors) > [javac] 16 errors > BUILD FAILED > File.. /home/elecharny/.maven/cache/maven-java-plugin-1.5/plugin.jelly > Element... ant:javac > Line.. 63 > Column 48 > Compile failed; see the compiler error output for details. > Total time : 4 seconds > Finished at : Friday, August 26, 2005 12:24:50 PM CEST > The very same operation using maven-1.0.2 : > $ maven clean > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > build:start: > clean:clean: > [delete] Deleting directory > /home/elecharny/workspace-ads-auto/shared-ldap/common/target > BUILD SUCCESSFUL > Total time: 1 seconds > Finished at: Fri Aug 26 12:24:11 CEST 2005 > $maven java:compile > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > build:start: > java:prepare-filesystem: > [mkdir] Created dir: > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes > java:compile
[jira] Commented: (MAVEN-1676) Problem generation with antlr
[ http://jira.codehaus.org/browse/MAVEN-1676?page=comments#action_71513 ] Emmanuel Lécharny commented on MAVEN-1676: -- Don't loose your time on this pb. Since I filled the JIRA last year, it has been fixed, and we have switched to m2, which is far better !!! I will close the issue Thanks anyway. > Problem generation with antlr > - > > Key: MAVEN-1676 > URL: http://jira.codehaus.org/browse/MAVEN-1676 > Project: Maven > Issue Type: Bug >Affects Versions: 1.1-beta-1 > Environment: Linux >Reporter: Emmanuel Lécharny > > The 1.1-beta-1 version cannot handle multiple antlr generation. 1.0.2 version > handles it correctly. > Here is a sample of this error : > on apacheds, in shared/ldap/common, > $ maven clean > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1 > plugin maven-cruisecontrol-plugin-1.6 is cached (dynatag dep) but no longer > present > Cache invalidated due to out of date plugins > DEPRECATED: the default goal should be specified in the section of > project.xml instead of maven.xml > build:start: > clean:clean: > xdoc:clean: > [delete] Deleting directory > /home/elecharny/workspace-ads-auto/shared-ldap/common/target > BUILD SUCCESSFUL > Total time : 3 seconds > Finished at : Friday, August 26, 2005 12:24:38 PM CEST > $ maven java:compile > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1 > DEPRECATED: the default goal should be specified in the section of > project.xml instead of maven.xml > build:start: > java:prepare-filesystem: > [mkdir] Created dir: > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes > java:compile: > [copy] Copying 1 file to > /home/elecharny/workspace-ads-auto/shared-ldap/common > antlr:prepare-filesystem: > [mkdir] Created dir: > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/antlr > antlr:generate: > ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com > warning: public lexical rule SIMPLE_STRING is optional (can match "nothing") > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > [delete] Deleting: > /home/elecharny/workspace-ads-auto/shared-ldap/common/DnCommonTokenTypes.txt > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > [echo] Compiling to > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes > [javac] Compiling 200 source files to > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes > [javac] > /home/elecharny/workspace-ads-auto/shared-ldap/common/src/java/org/apache/ldap/common/filter/FilterParserImpl.java:31: > cannot find symbol > [javac] symbol : class AntlrFilterParser > [javac] location: class org.apache.ldap.common.filter.FilterParserImpl > [javac] private AntlrFilterParser parser; > [javac] ^ > (... many errors) > [javac] 16 errors > BUILD FAILED > File.. /home/elecharny/.maven/cache/maven-java-plugin-1.5/plugin.jelly > Element... ant:javac > Line.. 63 > Column 48 > Compile failed; see the compiler error output for details. > Total time : 4 seconds > Finished at : Friday, August 26, 2005 12:24:50 PM CEST > The very same operation using maven-1.0.2 : > $ maven clean > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > build:start: > clean:clean: > [delete] Deleting directory > /home/elecharny/workspace-ads-auto/shared-ldap/common/target > BUILD SUCCESSFUL > Total time: 1 seconds > Finished at: Fri Aug 26 12:24:11 CEST 2005 > $maven java:compile > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > build:start: > java
[jira] Updated: (MNG-671) implement a license clickthrough
[ http://jira.codehaus.org/browse/MNG-671?page=all ] Daniel Gredler updated MNG-671: --- Attachment: maven-artifact-manager-patch-2.txt maven-artifact-patch-2.txt maven-settings-patch-2.txt Thanks for the comments. I'm attaching new patches to three of the modules (maven-settings, maven-artifact and maven-artifact-manager). They address the issues you raised previously. Let me know what you think. The only unknowns are still basically the same as last time, namely: - How to get access to the current Settings object (right now ArtifactResolver interface has been modified to take it as a parameter). - How to persist changes to the current Settings object. Any response on the dev list? > implement a license clickthrough > > > Key: MNG-671 > URL: http://jira.codehaus.org/browse/MNG-671 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Fix For: 2.1 > > Attachments: maven-artifact-manager-patch-2.txt, > maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, > maven-settings-patch-2.txt, maven-settings-patch.txt > > > we need some basic license acceptance policy for downloadable artifacts. For > now, this can just be a Y/N that is saved forever. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-802) Use fine grained permissions per project
Use fine grained permissions per project Key: CONTINUUM-802 URL: http://jira.codehaus.org/browse/CONTINUUM-802 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Assigned To: Carlos Sanchez -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1576) expecects ForeheadClassLoader, finds sun.misc.Launcher$AppClassLoader
[ http://jira.codehaus.org/browse/MAVEN-1576?page=all ] Arnaud Heritier closed MAVEN-1576. -- Resolution: Won't Fix Not enough important to fix it. > expecects ForeheadClassLoader, finds sun.misc.Launcher$AppClassLoader > - > > Key: MAVEN-1576 > URL: http://jira.codehaus.org/browse/MAVEN-1576 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.0.2 > Environment: Linux >Reporter: Willie Milnor > > I am trying to get around using com.werken.forehead.Forehead to run Maven, > and instead use my own class that extends org.apache.maven.cli.App. However, > I get the following error no matter what I try: > java.lang.ClassCastException: sun.misc.Launcher$AppClassLoader > at > org.apache.maven.plugin.PluginManager.processDependencies(PluginManager.java:437) > at > org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:642) > at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) > at MyApp.myDoMain(MyApp.java:80) > at MyApp.main(MyApp.java:575) > I know that this is caused by the following line: > ForeheadClassLoader projectClassLoader = > (ForeheadClassLoader)project.getContext().getClassLoader(); > I assume that when com.werken.forehead.Forehead is called, it somehow sets > the class loader (for the context) to an instance of ForeheadClassLoader; but > by calling my class directly, the context uses an instance of > sun.misc.Launcher$AppClassLoader. > I am able to run my own class calling com.werken.forehead.Forehead first (I > edited the forehead.conf file), and it works as it should. I tried setting > the class loader for the context using a ForeheadClassLoader, but that loader > is changed somewhere along the way to processing the dependencies. > Is there a way around this problem? I am using maven 1.0.2...is there a > newer beta version of maven that expects simply a ClassLoader rather than a > ForeheadClassLoader? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1676) Problem generation with antlr
[ http://jira.codehaus.org/browse/MAVEN-1676?page=comments#action_71510 ] Arnaud Heritier commented on MAVEN-1676: I'll test it, but it was certainly due to MAVEN-1691 which was fixed in the beta 3 > Problem generation with antlr > - > > Key: MAVEN-1676 > URL: http://jira.codehaus.org/browse/MAVEN-1676 > Project: Maven > Issue Type: Bug >Affects Versions: 1.1-beta-1 > Environment: Linux >Reporter: Emmanuel Lécharny > > The 1.1-beta-1 version cannot handle multiple antlr generation. 1.0.2 version > handles it correctly. > Here is a sample of this error : > on apacheds, in shared/ldap/common, > $ maven clean > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1 > plugin maven-cruisecontrol-plugin-1.6 is cached (dynatag dep) but no longer > present > Cache invalidated due to out of date plugins > DEPRECATED: the default goal should be specified in the section of > project.xml instead of maven.xml > build:start: > clean:clean: > xdoc:clean: > [delete] Deleting directory > /home/elecharny/workspace-ads-auto/shared-ldap/common/target > BUILD SUCCESSFUL > Total time : 3 seconds > Finished at : Friday, August 26, 2005 12:24:38 PM CEST > $ maven java:compile > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1 > DEPRECATED: the default goal should be specified in the section of > project.xml instead of maven.xml > build:start: > java:prepare-filesystem: > [mkdir] Created dir: > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes > java:compile: > [copy] Copying 1 file to > /home/elecharny/workspace-ads-auto/shared-ldap/common > antlr:prepare-filesystem: > [mkdir] Created dir: > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/antlr > antlr:generate: > ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com > warning: public lexical rule SIMPLE_STRING is optional (can match "nothing") > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > [delete] Deleting: > /home/elecharny/workspace-ads-auto/shared-ldap/common/DnCommonTokenTypes.txt > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > antlr:prepare-filesystem: > antlr:generate: > Overriding previous definition of reference to maven.antlr.compile.src.set > [echo] Compiling to > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes > [javac] Compiling 200 source files to > /home/elecharny/workspace-ads-auto/shared-ldap/common/target/classes > [javac] > /home/elecharny/workspace-ads-auto/shared-ldap/common/src/java/org/apache/ldap/common/filter/FilterParserImpl.java:31: > cannot find symbol > [javac] symbol : class AntlrFilterParser > [javac] location: class org.apache.ldap.common.filter.FilterParserImpl > [javac] private AntlrFilterParser parser; > [javac] ^ > (... many errors) > [javac] 16 errors > BUILD FAILED > File.. /home/elecharny/.maven/cache/maven-java-plugin-1.5/plugin.jelly > Element... ant:javac > Line.. 63 > Column 48 > Compile failed; see the compiler error output for details. > Total time : 4 seconds > Finished at : Friday, August 26, 2005 12:24:50 PM CEST > The very same operation using maven-1.0.2 : > $ maven clean > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > build:start: > clean:clean: > [delete] Deleting directory > /home/elecharny/workspace-ads-auto/shared-ldap/common/target > BUILD SUCCESSFUL > Total time: 1 seconds > Finished at: Fri Aug 26 12:24:11 CEST 2005 > $maven java:compile > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > build:start: > java:prepare-filesystem: > [mkdir] Created dir: > /home/elecharny/workspace-ads-auto/shared-ldap/com
[jira] Commented: (MAVEN-1492) use whole id, not artifact ID, for identifying plugins
[ http://jira.codehaus.org/browse/MAVEN-1492?page=comments#action_71509 ] Arnaud Heritier commented on MAVEN-1492: Must be checked but I'm not sure that we can do it easily for the RC1 without risking to create some problems... > use whole id, not artifact ID, for identifying plugins > -- > > Key: MAVEN-1492 > URL: http://jira.codehaus.org/browse/MAVEN-1492 > Project: Maven > Issue Type: Bug > Components: plugin manager >Affects Versions: 1.0.1 >Reporter: Brett Porter > > currently we map artifactId's to plugins. This is not guaranteed to be > unique, so switch to mapping the groupId:artifactId combo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-173) doesn't execute the right profile
doesn't execute the right profile - Key: MNGECLIPSE-173 URL: http://jira.codehaus.org/browse/MNGECLIPSE-173 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Components: Maven Launcher Affects Versions: 0.0.9 Environment: Windows Xp, Eclipse 3.2 Reporter: femke ongenae Assigned To: Eugene Kuleshov Priority: Blocker Fix For: 0.0.9 Attachments: pom.xml When i do run -> maven2 build... i get a screen. In my pom i have to profiles : 1) a dev profile, that is active by default 2) a test profile (in command promt activated by -Ptest) but i can't get this maven integration for eclipse to run the test profile i have tried to fill in anything at the parameters name value P test -P test ptest -p test active-profiles test if you could resolve this i would be very happy, cause it's very annoying that i can only execute the default profile from eclipse. i have included the pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MAVEN-1656) Doco that explains the protocols required to allow maven.xml or any plugin.jelly to inject values into or retrieve values from another plugin
[ http://jira.codehaus.org/browse/MAVEN-1656?page=all ] Arnaud Heritier updated MAVEN-1656: --- Fix Version/s: 1.1-rc1 To be documented if it's not yet done > Doco that explains the protocols required to allow maven.xml or any > plugin.jelly to inject values into or retrieve values from another plugin > - > > Key: MAVEN-1656 > URL: http://jira.codehaus.org/browse/MAVEN-1656 > Project: Maven > Issue Type: Bug > Components: documentation >Affects Versions: 1.1-beta-1 > Environment: All >Reporter: Andy Glick > Fix For: 1.1-rc1 > > > Brett recently posted a suggestion to someone who asked how to access the > contents of "plugin a" from the context of "plugin b" or from maven.xml. > Brett stated that "plugin a" would have to be initialized before it could be > accessed, and that from what I could understand he recommended 1 or 2 ways to > do that: > 1) reference the artifact plugin's namespace in the project tag > 2) specify value="some.value"/> (I think that this is the proper syntax, but I'm not > sure :-). > Thierry Lach, who asked the question this time around, reported that using > the artifact namespace didn't work in his instance, but that setting the > scope to parent did. I'm hoping that we can put together a fairly > comprehensive explanation about what is going on here, and if that means > explaining why the project gave up on Jelly and switched to M2, then so be it. > See http://news.gmane.org/gmane.comp.jakarta.turbine.maven.user for the > postings > Given that during the last couple of months Vincent Massol recommended that > people use the now deprecated mechanism on the > mavenbook.org site (see Tip #2), I should think that there ought to be a > priority on documenting this issue in an obvious place, probably the FAQ, but > also on the Maven Jelly tags get and set entries. > If this is actually explicitly documented somewhere, I'm sorry to have wasted > anyone's time. I have seen several plugins that have successfully used the > artifact namespace tag, so there must be some way that people have learned > this. I simply wish that I knew how they had done so. ;-) > I'm willing to write the doco if someone would explain the details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MAVEN-1482) some genuine errors result in "fatal" errors
[ http://jira.codehaus.org/browse/MAVEN-1482?page=all ] Arnaud Heritier updated MAVEN-1482: --- Fix Version/s: 1.1-rc1 To be checked before the RC1 > some genuine errors result in "fatal" errors > > > Key: MAVEN-1482 > URL: http://jira.codehaus.org/browse/MAVEN-1482 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Brett Porter > Fix For: 1.1-rc1 > > > for example: extend a POM that doesn't exist. > Need to gracefully catch such exceptions and handle differently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MAVEN-1659) Dependency jars are not downloading from remote repository placed in Subversion with http access
[ http://jira.codehaus.org/browse/MAVEN-1659?page=all ] Arnaud Heritier updated MAVEN-1659: --- Fix Version/s: 1.1-rc1 If nobody can reproduce it before the end of the month, we'll close it. > Dependency jars are not downloading from remote repository placed in > Subversion with http access > > > Key: MAVEN-1659 > URL: http://jira.codehaus.org/browse/MAVEN-1659 > Project: Maven > Issue Type: Bug >Affects Versions: 1.1-beta-1 > Environment: Server: Apache 1.3.x with Subversion 1.1.1 > Client: Linux 2.6/Windows 2000, J2SE 5.0 >Reporter: Roman Krutyakov > Fix For: 1.1-rc1 > > > Dependencies are not downloading from remote repository if it's placed in > Subversion with http access (with apache and mod_davsvn) > In verbose mode maven logs (under linux): > --- > Getting failed dependencies: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL > PROTECTED] > Attempting to download slamd_client-1.8.1.jar. > http://server.net:81/svn/v2/trunk/target/maven//slamd/jars/slamd_client-1.8.1.jar > - Status code: 200 > Local file is newer: not downloaded > Attempting to download slamd_server-1.8.1.jar. > http://server.net:81/svn/v2/trunk/target/maven//slamd/jars/slamd_server-1.8.1.jar > - Status code: 200 > Local file is newer: not downloaded > > Artifact '/opt/maven-repository/slamd/jars/slamd_client-1.8.1.jar' not found > to add to classpath > Artifact '/opt/maven-repository/slamd/jars/slamd_server-1.8.1.jar' not found > to add to classpath > --- > in local repository appropriate paths are created, but jar files are missing > this was checked against repository server with basic auth and without > authentication - result is the same > affected version 1.1-beta-1, 1.0.x works well -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MAVEN-410) maven plugins seem to choke on properties containing a "-"?
[ http://jira.codehaus.org/browse/MAVEN-410?page=all ]
Arnaud Heritier updated MAVEN-410:
--
Fix Version/s: 1.1-rc1
I agree to add a documentation about it. If it's not supported by Jelly, we
won't fix it.
> maven plugins seem to choke on properties containing a "-"?
> ---
>
> Key: MAVEN-410
> URL: http://jira.codehaus.org/browse/MAVEN-410
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 1.0-beta-9
> Environment: RedHat Linux 7.3, JDK 1.3.1
>Reporter: Henning Schmiedehausen
> Fix For: 1.1-rc1
>
>
> I'm using the Torque plugin to create id-table init sql files from my
> XML schemas. If I download maven 1.0b9 from apache.org, install it and
> then issue
> % maven -X torque
> I get
> torque:id-table-init-sql:
> Using contextProperties file:
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath:
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: [0]
> excludes: [0] }
> BUILD SUCCESSFUL
> Total time: 7 seconds
> Note the [0] for include and exclude list in the file scanner.
> If I now load the plugin.properties and plugin.jelly file from
> Torque and replace in both files for the properties
> torque.schema.init-sql.includes
> torque.schema.init-sql.excludes
> the "init-sql" part with "initsql"
> and re-issue the command:
> % maven -X torque
> then I get
> torque:id-table-init-sql:
> Using contextProperties file:
> /mnt/home.net/henning/cvs/turbine-2/project.properties
> [torque-sql] [VERBOSE] Using templatePath:
> /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
> [torque-sql] Using classpath
> [torque-sql] Generating to file
> /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
> [torque-sql] [DEBUG] fileset: Setup scanner in dir
> /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes:
> [*-schema.xml] excludes: [id-table-schema.xml] }
> Parsing file: 'scheduler-schema.xml'
> log4j:WARN No appenders could be found for logger
> (org.apache.torque.engine.database.transform.DTDResolver).
> log4j:WARN Please initialize the log4j system properly.
> Parsing file: 'torque-security-schema.xml'
> Parsing file: 'scheduler-idtable-schema.xml'
> Parsing file: 'torque-security-idtable-schema.xml'
> BUILD SUCCESSFUL
> Total time: 9 seconds
> Note that now the file scanner correctly picks up my schema files
> and builds the sql init files.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MAVEN-1688) The ${pom.versions} List behaves differently when running plugins under maven 1.1 and maven 1.0
[ http://jira.codehaus.org/browse/MAVEN-1688?page=all ]
Arnaud Heritier updated MAVEN-1688:
---
Fix Version/s: 1.1-rc1
By default if id isn't set, wa can returns the name (with a warning message)
> The ${pom.versions} List behaves differently when running plugins under maven
> 1.1 and maven 1.0
> ---
>
> Key: MAVEN-1688
> URL: http://jira.codehaus.org/browse/MAVEN-1688
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1-beta-2
>Reporter: Henning Schmiedehausen
> Fix For: 1.1-rc1
>
>
> Consider the following POM snipped:
>
>
> 2.1
> TURBINE_2_1
>
>
> 2.2
> TURBINE_2_2_0
>
>
> 2.3-rc1
> TURBINE_2_3_RC1
>
>
> 2.3-rc2
> TURBINE_2_3_RC2
>
>
> 2.3
> TURBINE_2_3
>
>
> 2.3.1-RC1
> TURBINE_2_3_1_RC1
>
>
> 2.3.1-RC2
> TURBINE_2_3_1_RC2
>
>
> 2.3.1
> TURBINE_2_3_1
> 2.3.1
>
>
> 2.3.2-RC1
> TURBINE_2_3_2_RC1
>
>
> echoing ${pom.versions} under the 1.0.2 maven release issues the following
> output:
> [echo] [2.1, 2.2, 2.3-rc1, 2.3-rc2, 2.3, 2.3.1-RC1, 2.3.1-RC2, 2.3.1,
> 2.3.2-RC1]
> doing the same thing under the 1.1-beta 2 core results in
> [echo] [null, null, null, null, null, null, null, 2.3.1, null]
> It seems that 1.0 uses the name as key and 1.1 uses the id. This causes e.g.
> the clirr plugin to fail if a project
> defines names for a version entry but no id.
> If it is necessary that a version entry contains name and/or id, it should be
> enforced by the maven core and bad
> entries should be reported.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MAVEN-1704) artifactId is used as groupId when the latest is not defined
[ http://jira.codehaus.org/browse/MAVEN-1704?page=all ] Arnaud Heritier updated MAVEN-1704: --- Fix Version/s: 1.1-rc1 To be check > artifactId is used as groupId when the latest is not defined > > > Key: MAVEN-1704 > URL: http://jira.codehaus.org/browse/MAVEN-1704 > Project: Maven > Issue Type: Bug > Components: inheritance >Affects Versions: 1.1-beta-2 >Reporter: Carlos Sanchez > Fix For: 1.1-rc1 > > > artifactId is used as groupId when the latest is not defined (using extends > at least), both in 1.0.2 and 1.1b2, which I believe it's a problem, maven > should complain. > Which is really a problem is that if pom a extends pom b, and no groupId is > defined in any of both, in 1.0.2 the artifactId of a is chosen as groupId, > while in 1.1 artifactId of b is the chosen one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-1677) "No directory specified for fileset" when debugging for org.apache.commons.jelly.tags.ant.AntTag on
[ http://jira.codehaus.org/browse/MAVEN-1677?page=all ]
Arnaud Heritier updated MAVEN-1677:
---
Fix Version/s: 1.1-rc1
To be checked for the RC1
> "No directory specified for fileset" when debugging for
> org.apache.commons.jelly.tags.ant.AntTag on
> ---
>
> Key: MAVEN-1677
> URL: http://jira.codehaus.org/browse/MAVEN-1677
> Project: Maven
> Issue Type: Bug
> Components: jelly/ant integration
>Affects Versions: 1.1-beta-1
> Environment: OS X 10.4.2, java version "1.5.0_02"
>Reporter: Scott Lamb
>Priority: Minor
> Fix For: 1.1-rc1
>
>
> I've been trying to debug problems by specifying an alternate
> log4j.configuration:
> $ MAVEN_OPTS="-Dlog4j.configuration=file:$HOME/log4j.properties" maven
> In the process, I discovered that when the level for
> org.apache.commons.jelly.tags.ant.AntTag is set to DEBUG, maven yields this
> error:
> File.. ${1}
> Element... ant:fileset
> Line.. 49
> Column 45
> No directory specified for fileset.
> When logging for that class is at INFO level, this error does not occur.
> This happens on the "java:compile" goal of even the simplest project. I can
> attach full exception info, the project I used, and the log4j config file I
> used if desired.
> I'd like to figure out what jelly file this occurred in. The file "${1}" is
> not too helpful, though.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-1440) Clearing maven.repo.remote results in incorrect reporting of unsatisfied dependencies
[ http://jira.codehaus.org/browse/MAVEN-1440?page=all ] Arnaud Heritier updated MAVEN-1440: --- Fix Version/s: 1.1-rc1 I don't want to put the build offline if maven.repo.remote isn't defined. It's not logical. I prefer to fail the build if maven.repo.remote is empty and the build is online. > Clearing maven.repo.remote results in incorrect reporting of unsatisfied > dependencies > - > > Key: MAVEN-1440 > URL: http://jira.codehaus.org/browse/MAVEN-1440 > Project: Maven > Issue Type: Bug >Affects Versions: 1.0 > Environment: Solaris >Reporter: Cameron Horn >Priority: Minor > Fix For: 1.1-rc1 > > > Running "maven -Dmaven.repo.remote= -Dmaven.mode.online=false" > > The use of the remote repository has been disabled. (x10) > BUILD FAILED > File.. > /export/home/cruise/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly > Element... maven:reactor > Line.. 217 > Column 9 > The build cannot continue because of the following unsatisfied dependency: > kernel-core-SNAPSHOT.jar > > Which is misleading. kernel-core-SNAPSHOT.jar failed to build because it was > missing dependencies. Running "maven -o -Dmaven.repo.remote= > multiproject:install-snapshot" shows the correct dependencies: > > The use of the remote repository has been disabled. (x10) > You are working offline so the build will continue, but > kernel-core-SNAPSHOT.jar may be out of date! > You are working offline so the build will continue, but > kernel-container-SNAPSHOT.jar may be out of date! > BUILD FAILED > File.. > /export/home/cruise/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly > Element... maven:reactor > Line.. 217 > Column 9 > The build cannot continue because of the following unsatisfied dependencies: > commons-beanutils-1.6.1.jar > commons-digester-1.4.1.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: (MAVEN-1660) DependencyVerifier class doesn't resolve an snapshot artifact after attaining a first goal.
[ http://jira.codehaus.org/browse/MAVEN-1660?page=all ] Arnaud Heritier updated MAVEN-1660: --- Fix Version/s: 1.1-rc1 > DependencyVerifier class doesn't resolve an snapshot artifact after attaining > a first goal. > --- > > Key: MAVEN-1660 > URL: http://jira.codehaus.org/browse/MAVEN-1660 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.1-beta-1 >Reporter: Pascal Larin >Priority: Minor > Fix For: 1.1-rc1 > > > Since revision 179556 of > src/java/org/apache/maven/verifier/DependencyVerifier.java, the > satisfyDependencies() method check if an artifact has already been resolved. > It changes the behavior from version 1.0. > For example, if you call maven with goals multiproject:clean and > multiproject:deploy with artifact versions set to snaphot, maven doesn't > resolve the dependencies for the multiproject:deploy because it has been > already done for the multiproject:clean. > I know that a multiproject:clean should not resolve the project dependencies > but it can probably cause problems in other cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MAVEN-1660) DependencyVerifier class doesn't resolve an snapshot artifact after attaining a first goal.
[ http://jira.codehaus.org/browse/MAVEN-1660?page=all ] Arnaud Heritier updated MAVEN-1660: --- I'll have a look at it for the RC1 > DependencyVerifier class doesn't resolve an snapshot artifact after attaining > a first goal. > --- > > Key: MAVEN-1660 > URL: http://jira.codehaus.org/browse/MAVEN-1660 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.1-beta-1 >Reporter: Pascal Larin >Priority: Minor > > Since revision 179556 of > src/java/org/apache/maven/verifier/DependencyVerifier.java, the > satisfyDependencies() method check if an artifact has already been resolved. > It changes the behavior from version 1.0. > For example, if you call maven with goals multiproject:clean and > multiproject:deploy with artifact versions set to snaphot, maven doesn't > resolve the dependencies for the multiproject:deploy because it has been > already done for the multiproject:clean. > I know that a multiproject:clean should not resolve the project dependencies > but it can probably cause problems in other cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MAVEN-1636) cryptic error message
[ http://jira.codehaus.org/browse/MAVEN-1636?page=all ] Arnaud Heritier updated MAVEN-1636: --- Fix Version/s: 1.1-rc1 We'll try to create the directory before to extract the plugin. If we can't we'll throw a message about it. > cryptic error message > - > > Key: MAVEN-1636 > URL: http://jira.codehaus.org/browse/MAVEN-1636 > Project: Maven > Issue Type: Bug > Components: plugin manager >Affects Versions: 1.1-beta-1 > Environment: Windows XP, network profile >Reporter: Jan Haderka >Priority: Trivial > Fix For: 1.1-rc1 > > > Using nework profile with top level directory of the profile without > privilege to create new directoriew, makes maven to fail on first startup > with a bit cryptic message: > org.apache.maven.MavenException: Unable to extract plugin: C:\Maven > 1.1-beta-1\plugins\maven-nsis-plugin-1.1.jar > at > org.apache.maven.plugin.PluginManager.unpackPlugin(PluginManager.java:1097) > ... > --- Nested Exception --- > java.io.FileNotFoundException: > \\server\username$\.maven\cache\maven-nsis-plugin-1.1\META-INF\MANIFEST.MF > (The system cannot find the path specified) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:179) > at java.io.FileOutputStream.(FileOutputStream.java:131) > at org.apache.maven.util.Expand.extractFile(Expand.java:147) > at org.apache.maven.util.Expand.expandFile(Expand.java:85) > at org.apache.maven.util.Expand.execute(Expand.java:67) > at > org.apache.maven.plugin.PluginManager.unpackPlugin(PluginManager.java:1093) > ... > The reason for failure is not that plugin is corrupted but that .maven > directory can't be created. > Work around is to set MAVEN_HOME_LOCAL to point somewhere in the user space. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-172) Eclipse PDE seems slightly incompatible with plugin
Eclipse PDE seems slightly incompatible with plugin --- Key: MNGECLIPSE-172 URL: http://jira.codehaus.org/browse/MNGECLIPSE-172 Project: Maven 2.x Extension for Eclipse Issue Type: Improvement Affects Versions: 0.0.9 Reporter: Yuri Schimke Assigned To: Eugene Kuleshov Eclipse PDE Rich Clients seem to have trouble when using the maven plugin. To actually build the client application it seems to need the dependency jars within the project. To get around this we use the dependency:copy-dependencies task. However this setup stops debugging from working. It also means you need to run mvn install for the other projects each time before you copy the dependencies. In constrast, after applying the patch from MNGECLIPSE-59, non-PDE projects work brilliantly. I'm reporting this improvement for a number of reasons 1) in case others are facing the same problem, 2) in case other have solved the same problem already and 3) in case it might be something you guys can fix easily. You guys might be the best candidates to answer 2) since you presumably use Eclipse to edit the maven2 plugin anyway. Another option might be to make each maven JAR a valid OSGI plugin, which is mainly a couple of extra files in the JAR. This could potentially be done with a MOJO that added the default, most liberal OSGI settings into the JAR. But this seems a bit extreme, and also inflexible in the case of truly internal dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-145) release:prepare requires all modules to be SNAPSHOTS
release:prepare requires all modules to be SNAPSHOTS Key: MRELEASE-145 URL: http://jira.codehaus.org/browse/MRELEASE-145 Project: Maven 2.x Release Plugin Issue Type: Improvement Reporter: Jörg Hohwiller Fix For: 2.0-beta-4 The biggest need for the maven-release-plugin is in complex projects with a lot of modules (that may again have modules). If I do not get it wrong, the current released version forces all modules to be snapshots and releases them individually. This is completely useless in my situation because in the end this forces me to release alle modules together for every change that is to be released and more or less causes that all modules have the same version number. When I call mvn replease:prepare on my toplevel project this is no snapshot, it fails with this error: The project : isn't a snapshot (). I would expect release:prepare to leave non SNAPSHOT modules untouched (and only verify that they do not have SNAPSHOT dependencies, what should never be the case if the version is no snapshot). All reactor projects that have a "-SNAPHSOT" version should be released and theier project-internal dependencies should also be set to the acording released version (and later be set to the new SNAPSHOT). Additionally I want to have the complete project to be tagged as a whole instead of each module. This could potentially be configureable (especially which directory is actually tagged, e.g. if the toplevel project is not in trunk/ but somewhere deeper say trunk/develop because other directories in trunk are huge but do not need to be checked out by every developer but need to be tagged). I personally think that the best flexibility and final freedom would be to split off the release:prepare goal into 3 goals: -create release version(s) -create tag(s) -update to snapshot version(s) These goals could be used individually and one could add some custom steps or replace one with something else. For creating the snapshot versions there is also the problem, that you do not know right away which project will be modified when in the future. The coolest thing would be if this would happen automatically when the first change is commited to the module. But this is of cause not praticable in reality (maybe if all commits would be done with maven). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
