[jira] Commented: (MRM-370) NPE when trying to proxy a request for a plugin
[ http://jira.codehaus.org/browse/MRM-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98841 ] Fabrice BELLINGARD commented on MRM-370: Jens, can you create a patch and attach it to this issue? I'll test it. Thanks. > NPE when trying to proxy a request for a plugin > --- > > Key: MRM-370 > URL: http://jira.codehaus.org/browse/MRM-370 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: Wendy Smoak > Fix For: 1.0-alpha-2 > > > My first test for Archiva 1.0 was to delete maven-clean-plugin from my local > repository, then try 'mvn clean' on the Struts 2 build. > I noted that it is pre-configured to proxy the central repo through > 'internal' and deleted the pre-configured network proxy. > $ cd /path/to/project > $ rm -rf $M2_REPO/org/apache/maven/plugins/maven-clean-plugin > $ mvn clean > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Struts 2 > [INFO] Struts Annotations > [INFO] Struts 2 Core > [INFO] Struts 2 API > [INFO] > - > --- > [INFO] Building Struts 2 > [INFO]task-segment: [clean] > [INFO] > - > --- > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] The plugin 'org.apache.maven.plugins:maven-clean-plugin' does not > exist or no valid version could be found > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Fri May 25 23:04:07 MST 2007 > [INFO] Final Memory: 1M/3M > [INFO] > > In the Archiva log/console: > INFO | jvm 1| 2007/05/25 23:02:05 | May 25, 2007 11:02:05 PM > org.mortbay.jetty.servlet.ServletHandler handle > INFO | jvm 1| 2007/05/25 23:02:05 | WARNING: > /archiva/repository/internal/org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml: > > INFO | jvm 1| 2007/05/25 23:02:05 | java.lang.NullPointerException > INFO | jvm 1| 2007/05/25 23:02:05 | at > java.util.regex.Matcher.getTextLength(Matcher.java:1127) > INFO | jvm 1| 2007/05/25 23:02:05 | at > java.util.regex.Matcher.reset(Matcher.java:284) > INFO | jvm 1| 2007/05/25 23:02:05 | at > java.util.regex.Matcher.(Matcher.java:205) > INFO | jvm 1| 2007/05/25 23:02:05 | at > java.util.regex.Pattern.matcher(Pattern.java:879) > INFO | jvm 1| 2007/05/25 23:02:05 | at > org.apache.maven.archiva.common.utils.VersionUtil.getBaseVersion(VersionUtil.java:144) > INFO | jvm 1| 2007/05/25 23:02:05 | at > org.apache.maven.archiva.repository.layout.DefaultBidirectionalRepositoryLayout.toPath(DefaultBidirectionalRepositoryLayout.java:137) > INFO | jvm 1| 2007/05/25 23:02:05 | at > org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.fetchFromProxies(DefaultRepositoryProxyConnectors.java:181) > INFO | jvm 1| 2007/05/25 23:02:05 | at > org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchContentFromProxies(ProxiedDavServer.java:177) > INFO | jvm 1| 2007/05/25 23:02:05 | at > org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:134) > INFO | jvm 1| 2007/05/25 23:02:05 | at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:119) > INFO | jvm 1| 2007/05/25 23:02:05 | at > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > INFO | jvm 1| 2007/05/25 23:02:05 | at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) > INFO | jvm 1| 2007/05/25 23:02:05 | at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) > INFO | jvm 1| 2007/05/25 23:02:05 | at > com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) > INFO | jvm 1| 2007/05/25 23:02:05 | at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > INFO | jvm 1| 2007/05/25 23:02:05 | at > com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) > INFO | jvm 1| 2007/05/25 23:02:05 | at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > INFO | jvm 1| 2007/05/25 23:02:05 | at > com.opens
[jira] Commented: (MASSEMBLY-206) Filtering does not work when using in fileSet inside moduleSet
[ http://jira.codehaus.org/browse/MASSEMBLY-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98846 ] Kevin Stembridge commented on MASSEMBLY-206: Looks like a duplicate of MASSEMBLY-154 > Filtering does not work when using in fileSet inside moduleSet > -- > > Key: MASSEMBLY-206 > URL: http://jira.codehaus.org/browse/MASSEMBLY-206 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: win32 >Reporter: Liya Jan > > i have a descriptor : > > > com.cc:module1 > com.cc:module2 > com.cc:module3 > > > > > src/main > true > core > > conf/* > > > > false > > > and although there is "true", the copied sources are not > filtered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3042) Extending a Mojo Class and used in a new Mojo Project, parameter fields in the parent mojo are not set, this disables reuse of existing mojo project.
Extending a Mojo Class and used in a new Mojo Project, parameter fields in the parent mojo are not set, this disables reuse of existing mojo project. - Key: MNG-3042 URL: http://jira.codehaus.org/browse/MNG-3042 Project: Maven 2 Issue Type: Bug Components: Plugin API Reporter: Leopoldo Agdeppa III I have an Existing maven-plugin-a and I want to extend its functionality and put it in maven-plugin-b, so what i did is I put the the maven-plugin-a as a dependecy in maven-plugin-b and extended the mojo class from A, the issue on this is that paramter fields from A is not set, when I used plugin-B, I think this disables reusing and extending of mojos -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1302) Build requires tests disabled
Build requires tests disabled - Key: CONTINUUM-1302 URL: http://jira.codehaus.org/browse/CONTINUUM-1302 Project: Continuum Issue Type: Bug Components: Testing Affects Versions: 1.1-alpha-2 Environment: Cygwin/winXP/Java1.5/Maven 2.0.6 Reporter: Tim Pizey Building for the first time on a machine: build.sh and build.sh fail for Maven 2.06 and 2.0.7 with missing ClassWorldsLauncher Build page: http://maven.apache.org/continuum/guides/development/guide-build-continuum.html does not mention need to download Sun jars. I could not understand last paragraph about assembly:assembly. mvn install fails the test for continuum-release: Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.344 sec <<< FAILURE! testReleases(org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest) Time elapsed: 1.203 sec <<< ERROR! java.io.FileNotFoundException: c:\continuum\continuum-release\target\test-classes\work-dir\pom.xml (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at org.codehaus.plexus.util.FileUtils.fileRead(FileUtils.java:273) at org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.releaseSimpleProject(ReleaseTaskExecutorTest.java:110) at org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.testReleases(ReleaseTaskExecutorTest.java:129) mvn -Dmaven.test.skip=true install does work !! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1302) Build requires tests disabled
[ http://jira.codehaus.org/browse/CONTINUUM-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98852 ] Emmanuel Venisse commented on CONTINUUM-1302: - What do you have in the surefire output file for org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest? > Build requires tests disabled > - > > Key: CONTINUUM-1302 > URL: http://jira.codehaus.org/browse/CONTINUUM-1302 > Project: Continuum > Issue Type: Bug > Components: Testing >Affects Versions: 1.1-alpha-2 > Environment: Cygwin/winXP/Java1.5/Maven 2.0.6 >Reporter: Tim Pizey > > Building for the first time on a machine: > build.sh and build.sh fail for Maven 2.06 and 2.0.7 with missing > ClassWorldsLauncher > Build page: > http://maven.apache.org/continuum/guides/development/guide-build-continuum.html > does not mention need to download Sun jars. > I could not understand last paragraph about assembly:assembly. > mvn install fails the test for continuum-release: > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.344 sec <<< > FAILURE! > testReleases(org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest) > Time elapsed: 1.203 sec <<< ERROR! > java.io.FileNotFoundException: > c:\continuum\continuum-release\target\test-classes\work-dir\pom.xml (The > system cannot find the path specified) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at org.codehaus.plexus.util.FileUtils.fileRead(FileUtils.java:273) > at > org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.releaseSimpleProject(ReleaseTaskExecutorTest.java:110) > at > org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.testReleases(ReleaseTaskExecutorTest.java:129) > mvn -Dmaven.test.skip=true install does work !! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPA-102) Clean up Wiki
[ http://jira.codehaus.org/browse/MPA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MPA-102. - Resolution: Fixed Good enough for now as a first pass. It's all improvements now. > Clean up Wiki > - > > Key: MPA-102 > URL: http://jira.codehaus.org/browse/MPA-102 > Project: Maven Project Administration > Issue Type: Task >Reporter: Brett Porter >Assignee: Jason van Zyl > Fix For: Maven 2.1 Prep > > > # Separate the design documents from the Taxonomy > # Separate out other documents like "How to Help" and our dev processes > # Align Wiki to Taxonomy, the start being the actual home page of the Maven > space > # Document structure and document progression (to site, etc) for future > reference and consistency checking -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MEJB-26) Plugin documentation for clientExcludes property is incorrect
Plugin documentation for clientExcludes property is incorrect - Key: MEJB-26 URL: http://jira.codehaus.org/browse/MEJB-26 Project: Maven 2.x Ejb Plugin Issue Type: Task Affects Versions: 2.0 Reporter: Jo Vandermeeren Priority: Trivial The plugin documentation for the clientExcludes property is incorrect: **/*Ejb.class **/*Bean.class Should be **/*Ejb.class **/*Bean.class -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98855 ] Binyan commented on MNG-2546: - Jason, I see you've picked this issue up. If I can shed more light on why this is needed or how it applies in the eclipse plug-in or specifically in the more general building OSGi bundles case then please let me know. I missed seeing Brian F. previous comments but it al most seems like he's talking about a new interface a mojo would implement to get pluggeg into the super-init phase. Similar I imagine to how spring uses its create and destroy interfaces for beans to be hooked into the spring context's lifecycle. I imagine that this issue might be addresses/targeted for Maven 2.1, so on a tangential issue will it be possible to dynamically create/augment MavenProject instances and add them to the Reactor's list before it sorts them? I ask because I just last week started taking another crack at solving the Eclipse PDE build issue with Maven. Basically I have written up in a Confluence page everything that the Eclipse PDE build ant scripts do, with the intent of replacing that with several mojos. However, PDE is not about to change and I don't want developers maintaining build info in 2 places, so I want to have a simple pom.xml in every plugin, feature, fragment, etc project that has a mojo bound that will augment the MavenProject instance with data pulled from eclipse's own project files. Utimatley I would want to do this augmentation in the "super-init" phase. The layout could be the following: MyPluginProject: - pom.xml - features/ - com.example.foo/ - pom.xml - ... - plugins/ - com.example.bar/ - pom.xml - ... - com.example.baz/ - pom.xml - ... Note that the pom files in the individual features and plugins folders might not exist if they can be dynamically created a mojos in the top level pom. > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan >Assignee: Jason van Zyl > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98856 ] Jason van Zyl commented on MNG-2546: Have you looked at Tom's work? http://svn.codehaus.org/m2eclipse/tycho/trunk/ > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan >Assignee: Jason van Zyl > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-280) Update Manager Problem
Update Manager Problem -- Key: MECLIPSE-280 URL: http://jira.codehaus.org/browse/MECLIPSE-280 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Reporter: Werner Keil Priority: Blocker Trying to install Maven 2.0 Eclipse Integration, currently your Update Manager Site seems pretty much down. Both the Production and Dev URL cause Update Manager to remain stuck between 15 and 30% 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: (MPMD-57) cpd: wrong symlink detection if relative source path is used
cpd: wrong symlink detection if relative source path is used Key: MPMD-57 URL: http://jira.codehaus.org/browse/MPMD-57 Project: Maven 2.x PMD Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Carsten Krebs When specifying relative paths as source directory, i.e. ../../main/src/java pmd:cpd detects misleadingly all source files in there as "symbolic links" and skips them: Skipping /opt/gd/project/../../main/src/foo/MyClass.java since it appears to be a symlink -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98857 ] Binyan commented on MNG-2546: - No, but I will now. Thnx. > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan >Assignee: Jason van Zyl > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98859 ] Jason van Zyl commented on MNG-2546: It's probably the most comprehensive and Tom has been using it in production for quite some time. We have talked about reading manifests directly and it embeds the PDE resolver so it's not just a PDE wrapper. That approach still works and there is the PDE plugin and the PST work: http://svn.codehaus.org/m2eclipse/maven-pst/ > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan >Assignee: Jason van Zyl > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3040) Failure to construct build plan fatal error on trunk r545155
[ http://jira.codehaus.org/browse/MNG-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3040: Description: see attached pom which causes this: mcbrett:~/scm/maven/sandbox/continuum/continuum-data-upgrade brett$ mvn clean install -e + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT [INFO] task-segment: [clean, install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to construct build plan for: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( task-segment: [clean, install] ). Reason: No phase specified for goal: exec in plugin: org.codehaus.mojo:exec-maven-plugin from POM: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT [INFO] [INFO] Trace org.apache.maven.BuildFailureException: Failed to construct build plan for: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( task-segment: [clean, install] ). Reason: No phase specified for goal: exec in plugin: org.codehaus.mojo:exec-maven-plugin from POM: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:296) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:112) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:906) at org.apache.maven.cli.MavenCli.main(MavenCli.java:367) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to construct build plan for: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( task-segment: [clean, install] ). Reason: No phase specified for goal: exec in plugin: org.codehaus.mojo:exec-maven-plugin from POM: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleBindings(DefaultLifecycleExecutor.java:305) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:246) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) ... 11 more Caused by: org.apache.maven.lifecycle.LifecycleSpecificationException: No phase specified for goal: exec in plugin: org.codehaus.mojo:exec-maven-plugin from POM: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT at org.apache.maven.lifecycle.binding.DefaultLifecycleBindingManager.getProjectCustomBindings(DefaultLifecycleBindingManager.java:295) at org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan(DefaultBuildPlanner.java:54) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleBindings(DefaultLifecycleExecutor.java:294) ... 14 more [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Thu Jun 07 22:40:57 EST 2007 [INFO] Final Memory: 2M/5M [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Thu Jun 07 22:40:57 EST 2007 [INFO] Final Memory: 2M/5M [INFO] was: see attached pom which causes this: mcbrett:~/scm/maven/sandbox/continuum/continuum-data-upgrade brett$ mvn clean install -e + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT [INFO]task-segment: [clean, instal
[jira] Updated: (MNG-1911) Building plugins with extensions in a reactor fails
[ http://jira.codehaus.org/browse/MNG-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-1911: Description: I have the following in my main pom org.apache.servicemix.plugins maven2-jbi-plugin 1.0-SNAPSHOT true If i try to add it to the modules, the first time, maven complains that it can not download the plugin. If i remove the tag, all works, but i need it :) was: I have the following in my main pom org.apache.servicemix.plugins maven2-jbi-plugin 1.0-SNAPSHOT true If i try to add it to the modules, the first time, maven complains that it can not download the plugin. If i remove the tag, all works, but i need it :) no, i haven't tested this use case with the new build plan. It may work, but I haven't tried yet. > Building plugins with extensions in a reactor fails > --- > > Key: MNG-1911 > URL: http://jira.codehaus.org/browse/MNG-1911 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Guillaume Nodet >Assignee: John Casey >Priority: Critical > Fix For: 2.0.x > > > I have the following in my main pom > > > > > org.apache.servicemix.plugins > maven2-jbi-plugin > 1.0-SNAPSHOT > true > > > > > If i try to add it to the modules, the first time, maven complains that it > can not download the plugin. > If i remove the tag, all works, but i need it :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2015) create an inter-plugin communication bus, for setting flags about the generalized build state
[
http://jira.codehaus.org/browse/MNG-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-2015.
---
Resolution: Fixed
I'd like to bake this further into plexus eventually, as a sort of context
injection/extraction method, eventually (moreso than the Contextualizable
interface offers). But, for now, it works.
> create an inter-plugin communication bus, for setting flags about the
> generalized build state
> -
>
> Key: MNG-2015
> URL: http://jira.codehaus.org/browse/MNG-2015
> Project: Maven 2
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.2
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.1.x
>
>
> Currently, there is no way for mojos in different plugins to communicate with
> one another in any way, other than flag files written into someplace like
> ${project.build.directory}.
> We need a communication bus by which plugins can communicate build state with
> one another. This communication can be limited, both in terms of legal values
> (allow only Strings?), and in terms of the messages that can be sent (eg.
> "compile" phase ran == Boolean.TRUE or something).
> Such communication can greatly enhance Maven's ability to optimize builds,
> and only perform the steps necessary to respond to changes since the last
> build, where possible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-44) multiple profiles
[ http://jira.codehaus.org/browse/CONTINUUM-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98862 ] Emmanuel Venisse commented on CONTINUUM-44: --- I created new screens as brett's screens are old. First a user can define all installation directories (jdk, maven, ant...), installations are independant of profiles and can be reused in profiles. http://people.apache.org/~evenisse/design/continuum/continuum_profiles/installations.htm http://people.apache.org/~evenisse/design/continuum/continuum_profiles/installation.htm http://people.apache.org/~evenisse/design/continuum/continuum_profiles/installation_read.htm When installations are defined, The user can create profiles. Profiles are a set of installation, ie maven 2.0.6+jdk5 http://people.apache.org/~evenisse/design/continuum/continuum_profiles/profiles.htm http://people.apache.org/~evenisse/design/continuum/continuum_profiles/profile.htm http://people.apache.org/~evenisse/design/continuum/continuum_profiles/profile_read.htm I don't know yet if schedule, build file and SCM policy should be move from the build definition to the profile. If we do it, the build definition config would be simplified Build definition screens: http://people.apache.org/~evenisse/design/continuum/continuum_profiles/builddefinitions.htm http://people.apache.org/~evenisse/design/continuum/continuum_profiles/builddefinition.htm Comments? > multiple profiles > - > > Key: CONTINUUM-44 > URL: http://jira.codehaus.org/browse/CONTINUUM-44 > Project: Continuum > Issue Type: New Feature > Components: Core - Profiles >Reporter: Brett Porter > Fix For: 1.1-alpha-# > > > would like to be able to define a profile (which can include certain > environmental things such as the version of m2 to use, the JDK version, etc). > Profiles should be able to be used globally, per group or per project. In > this way, you could build certain projects under a variety of different JDKs > for example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3040) Failure to construct build plan fatal error on trunk r545155
[ http://jira.codehaus.org/browse/MNG-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3040: The mojo itself does not seem to have an @phase annotation, so are you binding it to a phase in your ? > Failure to construct build plan fatal error on trunk r545155 > > > Key: MNG-3040 > URL: http://jira.codehaus.org/browse/MNG-3040 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter >Assignee: John Casey > Attachments: pom.xml > > > see attached pom which causes this: > mcbrett:~/scm/maven/sandbox/continuum/continuum-data-upgrade brett$ mvn clean > install -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT > [INFO] task-segment: [clean, install] > [INFO] > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to construct build plan for: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( > task-segment: [clean, install] ). Reason: No phase specified for goal: exec > in plugin: org.codehaus.mojo:exec-maven-plugin from POM: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT > [INFO] > > [INFO] Trace > org.apache.maven.BuildFailureException: Failed to construct build plan for: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( > task-segment: [clean, install] ). Reason: No phase specified for goal: exec > in plugin: org.codehaus.mojo:exec-maven-plugin from POM: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:296) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:112) > at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:906) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:367) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > construct build plan for: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( > task-segment: [clean, install] ). Reason: No phase specified for goal: exec > in plugin: org.codehaus.mojo:exec-maven-plugin from POM: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleBindings(DefaultLifecycleExecutor.java:305) > > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:246) > > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) > ... 11 more > Caused by: org.apache.maven.lifecycle.LifecycleSpecificationException: No > phase specified for goal: exec in plugin: org.codehaus.mojo:exec-maven-plugin > from POM: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT > at > org.apache.maven.lifecycle.binding.DefaultLifecycleBindingManager.getProjectCustomBindings(DefaultLifecycleBindingManager.java:295) > > at > org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan(DefaultBuildPlanner.java:54) > > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleBindings(DefaultLifecycleExecutor.java:294) > > ... 14 more > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Thu Jun 07 22:40:57 EST 2007 > [INFO] Final Memory: 2M/5M > [INFO] > > [INFO] > -
[jira] Updated: (MECLIPSE-262) Maven compilation and eclipse classpath don't match with conflicting versions at same dependency depth
[ http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Klaus Brunner updated MECLIPSE-262: --- Attachment: screenshot-1.jpg version conflict between eclipse and maven build (WAR project) > Maven compilation and eclipse classpath don't match with conflicting versions > at same dependency depth > -- > > Key: MECLIPSE-262 > URL: http://jira.codehaus.org/browse/MECLIPSE-262 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.3 > Environment: Maven 2.0.6, 2.0.4 >Reporter: Carlos Sanchez > Attachments: compile.txt, eclipse.txt, screenshot-1.jpg, testcase.zip > > > https://svn.apache.org/repos/asf/maven/components/trunk/maven-core rev# 533182 > compile uses plexus-component-api-1.0-alpha-24 (the right one) > eclipse:eclipse uses plexus-component-api-1.0-alpha-16 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-262) Maven compilation and eclipse classpath don't match with conflicting versions at same dependency depth
[ http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Klaus Brunner updated MECLIPSE-262: --- Attachment: testcase.zip Test case (WAR project). > Maven compilation and eclipse classpath don't match with conflicting versions > at same dependency depth > -- > > Key: MECLIPSE-262 > URL: http://jira.codehaus.org/browse/MECLIPSE-262 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.3 > Environment: Maven 2.0.6, 2.0.4 >Reporter: Carlos Sanchez > Attachments: compile.txt, eclipse.txt, testcase.zip > > > https://svn.apache.org/repos/asf/maven/components/trunk/maven-core rev# 533182 > compile uses plexus-component-api-1.0-alpha-24 (the right one) > eclipse:eclipse uses plexus-component-api-1.0-alpha-16 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-262) Maven compilation and eclipse classpath don't match with conflicting versions at same dependency depth
[ http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98868 ] Klaus Brunner commented on MECLIPSE-262: I'm apparently having the same problem. I wrote this up for opening a new bug report, but I'll attach it anyway in case it helps: Find attached a sample WAR project (testcase.zip) that lists commons-configuration and commons-jxpath as dependencies. Both of these artifacts depend (directly or transitively) on commons-collections, although there is a version conflict: c-configuration requires c-collections 3.2, but c-jxpath requires c-collections 2.0. Running "mvn clean eclipse:eclipse package" has the following effect: 1) The Eclipse classpath includes commons-collections-3.2.jar 2) The Maven-built WAR archive in the target folder includes commons-collections-2.0.jar (WEB-INF/lib). Also seen on attached screenshot. In this specific case, the result is that everything works fine in Eclipse, but when the Maven-built WAR is deployed, it fails because c-collections 3.2 is definitely required at runtime. Not good. > Maven compilation and eclipse classpath don't match with conflicting versions > at same dependency depth > -- > > Key: MECLIPSE-262 > URL: http://jira.codehaus.org/browse/MECLIPSE-262 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.3 > Environment: Maven 2.0.6, 2.0.4 >Reporter: Carlos Sanchez > Attachments: compile.txt, eclipse.txt, testcase.zip > > > https://svn.apache.org/repos/asf/maven/components/trunk/maven-core rev# 533182 > compile uses plexus-component-api-1.0-alpha-24 (the right one) > eclipse:eclipse uses plexus-component-api-1.0-alpha-16 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1589) Upload request for StatSCM 1.0.0
Upload request for StatSCM 1.0.0 Key: MAVENUPLOAD-1589 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1589 Project: maven-upload-requests Issue Type: Wish Reporter: Doug Culnane Attachments: rsync_Stat-SCM.sh Maven 2 Mojo Plugin that generates Source Code Management Metrics Reports as part of the mvn site command. This Plugin is a wrapper around StatCVS and StatSVN. Version 1.0.0 is stable and I have have had requests that I upload this to the central repository. I have added the public key to the access list on the SourceForge site. Thanks in advance, Doug Culnane -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98876 ] Binyan commented on MNG-2546: - If I understand the last sentence, then you're saying that we have have 3 separate initiatives going on with Tom's work the PST plug-in (which I'm reading about now) and the PDE plug-in I worked up. If I got that wrong then please correct. I have some work similar to the PST stuff as I created mojos to handle an eclipse target platform and put it into a maven repo too. I started looking at Tom's work before I headed to the office and I'll pick back up after lunch today and after I finish the article on the PST mojos. I'm pretty sure Tom's ahead of me and would welcome the chance to work with him to solve this generic OSGi bundle building problem. > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan >Assignee: Jason van Zyl > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-262) Maven compilation and eclipse classpath don't match with conflicting versions at same dependency depth
[ http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98875 ] Carlos Sanchez commented on MECLIPSE-262: - it may be caused because the eclipse plugin depend on maven 2.0.1 libraries, will need to update to 2.0.6 to see > Maven compilation and eclipse classpath don't match with conflicting versions > at same dependency depth > -- > > Key: MECLIPSE-262 > URL: http://jira.codehaus.org/browse/MECLIPSE-262 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.3 > Environment: Maven 2.0.6, 2.0.4 >Reporter: Carlos Sanchez > Attachments: compile.txt, eclipse.txt, screenshot-1.jpg, testcase.zip > > > https://svn.apache.org/repos/asf/maven/components/trunk/maven-core rev# 533182 > compile uses plexus-component-api-1.0-alpha-24 (the right one) > eclipse:eclipse uses plexus-component-api-1.0-alpha-16 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1378) Make dependencies of test-jars transitive
[ http://jira.codehaus.org/browse/MNG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated MNG-1378: -- Summary: Make dependencies of test-jars transitive (was: Make test dependencies transitive) changed the title as 'Make test dependencies transitive' is incorrect. Test dependencies are dependencies with scope test. test-jar dependencies are something totally different, and they can have scope compile. > Make dependencies of test-jars transitive > - > > Key: MNG-1378 > URL: http://jira.codehaus.org/browse/MNG-1378 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0 >Reporter: Mark Hobson > Fix For: 2.1.x > > > test-jar transitive dependencies are calculated as per compile scope rather > than test scope. > The situation is demonstrated nicely in it0077: > * module sub1 has a test-scoped dependency of commons-lang > * module sub2 has a test-scoped dependency of sub1 test-jar > sub2 tests should inherit the commons-lang transitive dependency. For > example: > Index: > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > === > --- > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > (revision > 328307) > +++ > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > (working > copy) > @@ -1,6 +1,7 @@ > package org.apache.maven.it0077; > import junit.framework.TestCase; > +import org.apache.commons.lang.BooleanUtils; > public class PersonTwoTest > extends PersonTest > Results in: > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31] > package org.apache.commons.lang does not exist -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTTASKS-72) Remove hardcoded groupId in install-provider task
Remove hardcoded groupId in install-provider task - Key: MANTTASKS-72 URL: http://jira.codehaus.org/browse/MANTTASKS-72 Project: Maven 2.x Ant Tasks Issue Type: Improvement Affects Versions: 2.0.6 Reporter: Ben Hale Currently, the InstallWagonProviderTask hard-codes the 'WAGON_GROUP_ID' value internally with no way to override it. Because of this, it is impossible to use a custom wagon that does not have a groupId of 'org.apache.maven.wagon' to upload files with a deploy task. It would be better if the install-provider task used that value as a default (so that it would be specified in the common case), but had a groupId setter allowing it to overriden. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor
Allow 'mvn test' to work with test-jar dependencies in a reactor Key: MNG-3043 URL: http://jira.codehaus.org/browse/MNG-3043 Project: Maven 2 Issue Type: Bug Components: Dependencies, Reactor and workspace Affects Versions: 2.0.6, 2.0.7, 2.1 Reporter: Kenney Westerhof Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn install', you run 'mvn test'. Test classes of dependencies should be resolved from the reactor, just as main classes, if there's no archive available. I'm not sure how to go about this. Specifying a dependency on something with test-jar, and having that dependency declare the maven-jar-plugin with the 'test-jar' goal is insufficient. Perhaps we can just add a standard classifier that maven is aware of, in this case 'tests'. The jar packaging would export this as a known classifier, and tells maven how it contributes to what classpath. Since test sources are a first class citizen, just as main sources are (they have the same phases, same elements in the pom (but differently named)). It seems logical to me that somehow the test classes should be made available to dependencies, if they declare a dependency with classifier 'tests'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3044) A dependency on a test-jar should bring in the main artifact as a dependency
A dependency on a test-jar should bring in the main artifact as a dependency Key: MNG-3044 URL: http://jira.codehaus.org/browse/MNG-3044 Project: Maven 2 Issue Type: Bug Reporter: Kenney Westerhof Note that this issue is NOT a duplicate of MNG-1378 ea. Since test-classes (src/test/java) have src/main/java in the classpath while compiling, and often use code from it, the main classes should be included in the classpath if there's a dependency on the test jar. Consider: Project A has src/main/java/Main.java and src/test/java/Test.java, where Test.java uses Main.java. Project A is packaged as a normal jar and has an attached test-jar. Project B depends on A's test-jar, because it wants to use Test.java (Test.class). This fails because of a NoClassDefFound on Main.class: B's compiletime classpath contains B's sources and the test-jar. It should also contain A's main artifact. Test-jars have a compile-time (and runtime) dependency on the main classes; maven should bring in the main artifact aswell. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1590) Java Bean Library
Java Bean Library - Key: MAVENUPLOAD-1590 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1590 Project: maven-upload-requests Issue Type: Task Reporter: Hanson Char Attachments: beanlib-3.3.0beta6.jar, beanlib-hibernate-3.3.0beta6.jar Java Bean Library (beanlib) is a utilities library for use with JavaBean's. Java Bean Library for Hibernate (beanlib-hibernate) is particularly handy when used with Hibernate. It allows developers to easily reuse the same pojo classes for both persistence instances and data transfer objects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-278) duplicated classpathentries
[ http://jira.codehaus.org/browse/MECLIPSE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98887 ] Carlos Sanchez commented on MECLIPSE-278: - In your patch only the first will be picked up, is that going to work or should jar be picked up over any other type? > duplicated classpathentries > --- > > Key: MECLIPSE-278 > URL: http://jira.codehaus.org/browse/MECLIPSE-278 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Tom Spengler >Priority: Critical > Fix For: 2.4 > > Attachments: MECLIPSE-278.patch > > > if artifacts with transitive dependencies contains the same dependency with > different types it will be a .classpath generated , contains duplicat enries > of the same file. > The problem occures e.g. with type ejb and jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-223) Add dependencies to eclipse project build path when working on a pom project
[ http://jira.codehaus.org/browse/MECLIPSE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MECLIPSE-223. --- Assignee: Carlos Sanchez Resolution: Duplicate > Add dependencies to eclipse project build path when working on a pom project > > > Key: MECLIPSE-223 > URL: http://jira.codehaus.org/browse/MECLIPSE-223 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Reporter: Sebastien Brunot >Assignee: Carlos Sanchez > > The eclipse plugin does not generate a build path with all the pom > dependencies when applyed to a project which type is pom (while it performs > ok when the project type is jar). > The maven book states that it is usefull to group acceptance tests of a J2EE > application in a dedicated module which type is pom (See section 4.13 of the > Mergere book "Better builds with maven"). Even if this project type is pom, > the project contains unit test source files to be run as acceptance tests, so > it is (more than) usefull to generate an eclipse project for developping > those tests. > Unfortunately, at the time, you cannot generate an eclipse project with > complete dependencies if the type of your maven project is pom. > :-( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-216) Allow writing of .project files for pom projects if not workspace is specified
[
http://jira.codehaus.org/browse/MECLIPSE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sanchez closed MECLIPSE-216.
---
Assignee: Carlos Sanchez
Resolution: Duplicate
> Allow writing of .project files for pom projects if not workspace is specified
> --
>
> Key: MECLIPSE-216
> URL: http://jira.codehaus.org/browse/MECLIPSE-216
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Jochen Kuhnle
>Assignee: Carlos Sanchez
> Attachments: MECLIPSE-216.patch
>
>
> The patch adds a parameter alwaysWritePomProjects (expression
> ${eclipse.alwaysWritePomProjects}, default false). This parameter forces the
> creation of .project files for pom projects, even if no other workspace
> location is specified.
> This is useful when using a flat directory layout where pom projects have
> their own directory and no subdirs, e.g:
> project
> +--rootproject/pom.xml
> +--module1/pom.xml
> +--module2/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] Closed: (MECLIPSE-227) mvn eclipse:eclipse for pom should create a .project file
[ http://jira.codehaus.org/browse/MECLIPSE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MECLIPSE-227. --- Assignee: Carlos Sanchez Resolution: Duplicate > mvn eclipse:eclipse for pom should create a .project > file > > > Key: MECLIPSE-227 > URL: http://jira.codehaus.org/browse/MECLIPSE-227 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: all >Reporter: THURNER rupert >Assignee: Carlos Sanchez > > mvn eclipse:eclipse for pom should create a .project > file. > currently it does nothing. this is especially annoying if using parent poms > with other poms in subdirectories, see also description on > http://maven.apache.org/guides/mini/guide-ide-eclipse.html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_9 ] Carlos Sanchez commented on MECLIPSE-94: There's a patch in MECLIPSE-216 for a new property to generate .project in pom projects http://jira.codehaus.org/secure/attachment/25262/MECLIPSE-216.patch > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Felipe Leme > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-525) The tagsoup (org/ccil/cowan/tagsoup/tagsoup) v 1.0.1 has some unclosed "url" tags in the licences section.
[
http://jira.codehaus.org/browse/MEV-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98890
]
Henri Yandell commented on MEV-525:
---
Ah, I see.
Your c+p above put < in, I thought that was the implied error. Will fix
manually.
> The tagsoup (org/ccil/cowan/tagsoup/tagsoup) v 1.0.1 has some unclosed "url"
> tags in the licences section.
> --
>
> Key: MEV-525
> URL: http://jira.codehaus.org/browse/MEV-525
> Project: Maven Evangelism
> Issue Type: Bug
> Components: Invalid POM
>Reporter: Daniel Alheiros
>
> http://repo1.maven.org/maven2/org/ccil/cowan/tagsoup/tagsoup/1.0.1/tagsoup-1.0.1.pom
> it's trying to close the tag with a mistyped instead of a
> for the academic free license (AFL):
>
>
> Academic Free License ("AFL") v. 3.0
> http://www.opensource.org/licenses/afl-3.0.php
> repo
>
>
> GNU GPL version 2.0
> http://www.opensource.org/licenses/gpl-license.php
> repo
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-279) PDE projects should be considered java projects in all cases
[ http://jira.codehaus.org/browse/MECLIPSE-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MECLIPSE-279. --- Resolution: Fixed > PDE projects should be considered java projects in all cases > > > Key: MECLIPSE-279 > URL: http://jira.codehaus.org/browse/MECLIPSE-279 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: PDE support >Affects Versions: 2.4 > Environment: java version "1.5.0_10" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) > Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode, sharing) >Reporter: Graham Leggett > Fix For: 2.4 > > Attachments: pde-fix.diff > > > When an attempt is made to use the pde-maven-plugin to build plugin code, > this attempt fails. > It turns out that when the PDE artifact is set to zip as required by the > pde-maven-plugin, it in effect tells the maven-eclipse-plugin that this > artifact is no longer a java artifact. > The effect is that the .classpath file is not written, and this breaks the > eclipse build. > The fix is to modify the isJavaProject test to treat all PDE projects as java > projects, regardless of the packaging type. > The attached patch allows the pde-maven-plugin and maven-eclipse-plugin to > work together again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-457) Geronimo jar fails to download
[ http://jira.codehaus.org/browse/MEV-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98892 ] Henri Yandell commented on MEV-457: --- I'll do a manual convert in a test location, then copy the files over manually. > Geronimo jar fails to download > -- > > Key: MEV-457 > URL: http://jira.codehaus.org/browse/MEV-457 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Henri Yandell >Assignee: Henri Yandell > > If you look at http://www.ibiblio.org/maven/geronimo/jars/, you can see that > there is a geronimo-javamail-transport-1.1.1.jar file. If you try to click on > that/download it you get a reply of 'Not found'. > (http://www.ibiblio.org/maven/geronimo/jars/geronimo-javamail-transport-1.1.1.jar) > mod_rewrite or permissions problem? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-261) IdeUtils.toRelativeAndFixSeparator returns incomplete path
[ http://jira.codehaus.org/browse/MECLIPSE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98893 ] Carlos Sanchez commented on MECLIPSE-261: - can you provide a patch? > IdeUtils.toRelativeAndFixSeparator returns incomplete path > -- > > Key: MECLIPSE-261 > URL: http://jira.codehaus.org/browse/MECLIPSE-261 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows XP, jdk 1.5.0_11-b03, maven 2.0.5 >Reporter: Marcio Paulo Guedes > Attachments: .classpath, baseDirIsRoot.patch, > EclipseClasspathWriter.java, EclipsePlugin-2.4.zip, IdeUtils.java, patch.txt, > pom.xml > > > .classpath file is generated with incomplete path for classpathentry when > kind is "var". > Example: > > when path="M2_REPO/ognl/ognl/2.6.9/ognl-2.6.9.jar"/> is expected. > It's caused by IdeUtils.toRelativeAndFixSeparator when basepath is not equal > absolutepath. Code on line 99 shifts the string 1 character to the right, > corrupting the result path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MASSEMBLY-210) repository does not include the parent pom
[
http://jira.codehaus.org/browse/MASSEMBLY-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-210:
-
Description:
I am running the assembly on a project with a parent pom. dist
zip
true
foo-${version}
. foo-base
true
/target/
repository test
The parent pom is not included at all.
was:
I am running the assembly on a project with a parent pom. dist
zip
true
foo-${version}
. foo-base
true
*/target/*
repository test
The parent pom is not included at all.
I just republished the assembly snapshot...it looks like it was a problem in
the 2.1 maven snapshot I was using when I published this last...sorry about
that, but can you try now?
> repository does not include the parent pom
> --
>
> Key: MASSEMBLY-210
> URL: http://jira.codehaus.org/browse/MASSEMBLY-210
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Stephane Nicoll
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
>
> I am running the assembly on a project with a parent pom. encoding="ISO-8859-15"?> dist
> zip
> true
> foo-${version}
> . foo-base
> true
> /target/
> repository
> test
> The parent pom is not included at all.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-498) javax.xml.ws:jaxws-api:2.1 is bad
[ http://jira.codehaus.org/browse/MEV-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98896 ] Henri Yandell commented on MEV-498: --- Seems that this issue should be WONTFIX -> request 2.1-1 release. Sound right? > javax.xml.ws:jaxws-api:2.1 is bad > - > > Key: MEV-498 > URL: http://jira.codehaus.org/browse/MEV-498 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Dan Tran > > Sun just released jaxws 2.1 and the jaxws-api available at repo1.maven.org is > not the same with the Sun's one (both pom and the jar ) > I am working jaxws-maven-plugin and the generate code crash due to missing > interfaces > We can either sync the sun version over, or remove it from repo1 to remove > confusion > Here is the link to java.net repo > https://maven-repository.dev.java.net/nonav/repository/com.sun.xml.ws/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-352) Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib
[ http://jira.codehaus.org/browse/MEV-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98897 ] Henri Yandell commented on MEV-352: --- Looks like MAVENUPLOAD-1388 was the request, and it's been done. > Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib > > > Key: MEV-352 > URL: http://jira.codehaus.org/browse/MEV-352 > Project: Maven Evangelism > Issue Type: Task > Components: Relocation >Reporter: Emmanuel Venisse >Assignee: Edwin Punzalan > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-498) javax.xml.ws:jaxws-api:2.1 is bad
[ http://jira.codehaus.org/browse/MEV-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-498. -- Assignee: Carlos Sanchez Resolution: Won't Fix right > javax.xml.ws:jaxws-api:2.1 is bad > - > > Key: MEV-498 > URL: http://jira.codehaus.org/browse/MEV-498 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Dan Tran >Assignee: Carlos Sanchez > > Sun just released jaxws 2.1 and the jaxws-api available at repo1.maven.org is > not the same with the Sun's one (both pom and the jar ) > I am working jaxws-maven-plugin and the generate code crash due to missing > interfaces > We can either sync the sun version over, or remove it from repo1 to remove > confusion > Here is the link to java.net repo > https://maven-repository.dev.java.net/nonav/repository/com.sun.xml.ws/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-427) relocate ehcache:ehcache to net.sf.ehcache
[ http://jira.codehaus.org/browse/MEV-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98899 ] Henri Yandell commented on MEV-427: --- *winces and requests a better relocation system* :) > relocate ehcache:ehcache to net.sf.ehcache > -- > > Key: MEV-427 > URL: http://jira.codehaus.org/browse/MEV-427 > Project: Maven Evangelism > Issue Type: Bug > Components: Relocation >Reporter: fabrizio giustina > > version 1.2 of ehcache has already been relocated to groupid net.sf.ehcache, > relocation should also be performed for all the previous versions (0.6, 0.7, > 0.9, 1.0, 1.1, 1.2beta4) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-375) Relocate xpp to xpp3
[ http://jira.codehaus.org/browse/MEV-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed MEV-375. - Resolution: Won't Fix http://repo1.maven.org/maven2/xpp is empty, nothing there now, so presumably this is a WONTFIX. > Relocate xpp to xpp3 > > > Key: MEV-375 > URL: http://jira.codehaus.org/browse/MEV-375 > Project: Maven Evangelism > Issue Type: Bug > Components: Relocation >Reporter: 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] Created: (MAVENUPLOAD-1591) subethasmtp-smtp 1.2 and subethasmtp-wiser 1.2
subethasmtp-smtp 1.2 and subethasmtp-wiser 1.2 -- Key: MAVENUPLOAD-1591 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1591 Project: maven-upload-requests Issue Type: Bug Reporter: Ben Speakmon 1.2 version of subethasmtp and subethasmtp-wiser. Description at subethasmtp.tigris.org. These bundles were created from their 1.2 tag with patches to the POMs to ensure correct versioning and bundling. URL contains bz2 archives (which include the java14 retrotranslated version and the javadoc, which repository:bundle-create refused to include) and the 1.1 version of the subethasmtp-parent POM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-454) testng-spring has a invalid dependency on testng.
[ http://jira.codehaus.org/browse/MEV-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed MEV-454. - Resolution: Won't Fix You can access them using the classifier tag. See: http://maven.apache.org/ref/2.0.4/maven-model/maven.html#class_dependency > testng-spring has a invalid dependency on testng. > - > > Key: MEV-454 > URL: http://jira.codehaus.org/browse/MEV-454 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Alexandre Poitras > > The following dependency is found in the pom : > > org.testng > testng > 4.7 > > But testng requires a classifier value specifying either to use the jdk 1.4 > or 1.5. I have absolutely no idea how to fix this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-352) Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib
[ http://jira.codehaus.org/browse/MEV-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed MEV-352. - Resolution: Fixed Assuming this has been fixed by the other issue. Please reopen if it's not. > Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib > > > Key: MEV-352 > URL: http://jira.codehaus.org/browse/MEV-352 > Project: Maven Evangelism > Issue Type: Task > Components: Relocation >Reporter: Emmanuel Venisse >Assignee: Edwin Punzalan > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MNGSITE-1) http://maven.apache.org/pom.html is out of date and broken
http://maven.apache.org/pom.html is out of date and broken -- Key: MNGSITE-1 URL: http://jira.codehaus.org/browse/MNGSITE-1 Project: Maven Project Web Site Issue Type: Bug Reporter: Henri Yandell The links at the top don't work, and the information is dated. For example it lacks info on dependency->classifier. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-90) add advanced search options
[ http://jira.codehaus.org/browse/MRM-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98906 ] Wendy Smoak commented on MRM-90: Would this include searching the contents of the jars? There's a need for something like http://www.jarhoo.com provides. > add advanced search options > --- > > Key: MRM-90 > URL: http://jira.codehaus.org/browse/MRM-90 > Project: Archiva > Issue Type: New Feature > Components: web application >Reporter: Brett Porter > Fix For: Future > > > we need to add the ability to query on particular fields and across some > ranges. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-1554) antlr-3.0 and antlr-runtime-3.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Proctor updated MAVENUPLOAD-1554: -- Attachment: antlr-runtime-3.0.jar Wierd, I must have uploaded the jar rather than the bundle. Here it is corrected. > antlr-3.0 and antlr-runtime-3.0 > --- > > Key: MAVENUPLOAD-1554 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1554 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mark Proctor > Attachments: antlr-3.0-bundle.jar, antlr-3.0-bundle.jar, > antlr-runtime-3.0.jar, antlr-runtime-3.0.jar > > > Please upload these two antlr 3.0 bundles -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-448) xmlrpc POM should include commons-codec
[ http://jira.codehaus.org/browse/MEV-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98908 ] Henri Yandell commented on MEV-448: --- 3.0 is good. But 2.0 and 2.0.1 are not. The question to ask I guess is whether 2.0.x is important now that 3.0 is out. > xmlrpc POM should include commons-codec > --- > > Key: MEV-448 > URL: http://jira.codehaus.org/browse/MEV-448 > Project: Maven Evangelism > Issue Type: Task > Components: Dependencies >Reporter: Brett Porter > > this appears to be a stub POM, missing the commons-codec and other > dependencies: > http://ws.apache.org/xmlrpc/xmlrpc2/dependencies.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-262) Maven compilation and eclipse classpath don't match with conflicting versions at same dependency depth
[ http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98907 ] Carlos Sanchez commented on MECLIPSE-262: - Klaus, with Maven 2.0.6 I get the same commons-collections in both places > Maven compilation and eclipse classpath don't match with conflicting versions > at same dependency depth > -- > > Key: MECLIPSE-262 > URL: http://jira.codehaus.org/browse/MECLIPSE-262 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.3 > Environment: Maven 2.0.6, 2.0.4 >Reporter: Carlos Sanchez > Attachments: compile.txt, eclipse.txt, screenshot-1.jpg, testcase.zip > > > https://svn.apache.org/repos/asf/maven/components/trunk/maven-core rev# 533182 > compile uses plexus-component-api-1.0-alpha-24 (the right one) > eclipse:eclipse uses plexus-component-api-1.0-alpha-16 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MNGSITE-2) Have somewhere for people to go after 'What is it?'
Have somewhere for people to go after 'What is it?' --- Key: MNGSITE-2 URL: http://jira.codehaus.org/browse/MNGSITE-2 Project: Maven Project Web Site Issue Type: Improvement Reporter: Henri Yandell >From IRC: clincks: Can you add in the doc a part named: "what can Maven do for you?" and another "What should Maven not do for you"? hen: http://maven.apache.org/what-is-maven.html has that doesn't it? clincks: Yes and no clincks: It helps me to understand I have found that Maven can help me... but how far can Maven help me? clincks: Problem is every body has different goals... clincks: I understand that Maven will help me... but it will also take me long to configure it. clincks: I have to add manually in a Pom the dependencies one by one. (Compile and see which import fail). That's a big job on a big project. Maybe we could lead them into "How to migrate to 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
[jira] Closed: (MEV-296) Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables
[
http://jira.codehaus.org/browse/MEV-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed MEV-296.
-
Resolution: Won't Fix
I'm going to close this. ActiveMQ 4.1.1 is out and its pom looks good:
http://repo1.maven.org/maven2/org/apache/activemq/activemq-core/4.1.1/activemq-core-4.1.1.pom
Given the age of this issue, I think we should just move on and then catch this
issue when we start analyzing the repository for quality.
> Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables
> ---
>
> Key: MEV-296
> URL: http://jira.codehaus.org/browse/MEV-296
> Project: Maven Evangelism
> Issue Type: Bug
> Components: Invalid POM
>Reporter: Johannes Brodwall
>Assignee: james strachan
> Attachments: activeio-2.1-local.pom, activemq-4.0-M4-local.pom,
> activemq-core-3.2.1.pom, MEV-296-activemq.patch
>
>
> The version numbers for dependencies are wrong. For example:
>
> commons-collections
> commons-collections
> ${commons_collections_version}
>
> When I substituted values from activemq-3.2.pom I got it to work.
> That being said, the number of optional dependencies that are included as
> required in activemq is just staggering!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-356) Missing dep on jboss-common in jbossmq-client & jnp-client 4.0.2
[
http://jira.codehaus.org/browse/MEV-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98915
]
Henri Yandell commented on MEV-356:
---
Continue to leave this one for the moment pending having JBoss hooked up for
automatic syncs.
> Missing dep on jboss-common in jbossmq-client & jnp-client 4.0.2
>
>
> Key: MEV-356
> URL: http://jira.codehaus.org/browse/MEV-356
> Project: Maven Evangelism
> Issue Type: Bug
> Components: Dependencies
>Reporter: Yann Le Du
>Assignee: Edwin Punzalan
>
> Since svn://svn.codehaus.org/maven/scm/repository/ is not up-to-date yet, I
> cannot make a diff. The patch is to add the following in both jbossmq-client
> & jnp-client POMs :
> {code:xml}
>
>
> jboss
> jboss-common
> 4.0.2
>
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-48) openejb poms
[ http://jira.codehaus.org/browse/MEV-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98916 ] Henri Yandell commented on MEV-48: -- Was this found by a script Brett? > openejb poms > > > Key: MEV-48 > URL: http://jira.codehaus.org/browse/MEV-48 > Project: Maven Evangelism > Issue Type: Task > Components: Invalid POM >Reporter: Brett Porter > Attachments: repository.report.openejb.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-334) Stax POM points to an invalid XMLBeans dependency
[ http://jira.codehaus.org/browse/MEV-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed MEV-334. - Resolution: Won't Fix I've gone ahead and 'removed' the following: xmlbeans/ xmlbeans/xmlbeans-jsr173-ri xmlbeans/xmlbeans-jsr173-ri/maven-metadata.xml xmlbeans/xmlbeans-jsr173-ri/maven-metadata.xml.md5 xmlbeans/xmlbeans-jsr173-ri/2.0-dev xmlbeans/xmlbeans-jsr173-ri/maven-metadata.xml.sha1 xmlbeans/xmlbeans-xmlpublic xmlbeans/xmlbeans-xmlpublic/2.0-dev xmlbeans/xbean_xpath-v1HEAD xmlbeans/xbean_xpath-v1HEAD/maven-metadata.xml xmlbeans/xbean_xpath-v1HEAD/maven-metadata.xml.md5 xmlbeans/xbean_xpath-v1HEAD/maven-metadata.xml.sha1 xmlbeans/xmlbeans xmlbeans/xmlbeans/2.0-dev xmlbeans/xbean-v1HEAD xmlbeans/xbean-v1HEAD/maven-metadata.xml xmlbeans/xbean-v1HEAD/maven-metadata.xml.md5 xmlbeans/xbean-v1HEAD/maven-metadata.xml.sha1 xmlbeans/xmlbeans-jsr173-api xmlbeans/xmlbeans-jsr173-api/maven-metadata.xml xmlbeans/xmlbeans-jsr173-api/maven-metadata.xml.md5 xmlbeans/xmlbeans-jsr173-api/2.0-dev xmlbeans/xmlbeans-jsr173-api/maven-metadata.xml.sha1 > Stax POM points to an invalid XMLBeans dependency > - > > Key: MEV-334 > URL: http://jira.codehaus.org/browse/MEV-334 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Julien Dubois >Assignee: Henri Yandell > > Stax 1.1.2-dev points to an empty directory : > http://www.ibiblio.org/maven2/xmlbeans/xmlbeans-jsr173-api/2.0-dev/ > The files in this directory seem to have been deleted for whatever reason. > I've reconstructed the correct files in my personnal repo, you can grab them > from here : > http://julien.dubois.free.fr/maven2/xmlbeans/xmlbeans-jsr173-api/2.0-dev/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-404) pom for cactus:cactus-ant:13-1.7.2
[ http://jira.codehaus.org/browse/MEV-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98920 ] Henri Yandell commented on MEV-404: --- Presumably this is a bad pom - one would assume this pom depends on Ant in some way. > pom for cactus:cactus-ant:13-1.7.2 > -- > > Key: MEV-404 > URL: http://jira.codehaus.org/browse/MEV-404 > Project: Maven Evangelism > Issue Type: Bug > Components: Missing POM >Reporter: Shinobu Kawai >Assignee: Henri Yandell > Attachments: cactus-ant-13-1.7.2.pom > > > initial pom suggestion for cactus:cactus-ant:13-1.7.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-404) pom for cactus:cactus-ant:13-1.7.2
[
http://jira.codehaus.org/browse/MEV-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98921
]
Henri Yandell commented on MEV-404:
---
The build.xml for 1.7.2 also lists:
Dependencies:
cargo.jar = [${cargo.jar}]
commons.logging.jar = [${commons.logging.jar}]
junit.jar = [${junit.jar}]
mockobjects.jar = [${mockobjects.jar}]
xerces.jar (optional) = [${xerces.jar}]
xmlapis.jar (optional) = [${xmlapis.jar}]
> pom for cactus:cactus-ant:13-1.7.2
> --
>
> Key: MEV-404
> URL: http://jira.codehaus.org/browse/MEV-404
> Project: Maven Evangelism
> Issue Type: Bug
> Components: Missing POM
>Reporter: Shinobu Kawai
>Assignee: Henri Yandell
> Attachments: cactus-ant-13-1.7.2.pom
>
>
> initial pom suggestion for cactus:cactus-ant:13-1.7.2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-405) pom for cactus:cactus:13-1.7.2
[ http://jira.codehaus.org/browse/MEV-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98922 ] Henri Yandell commented on MEV-405: --- Fun. Nothing like the pom on the Cactus side: http://svn.apache.org/repos/asf/jakarta/cactus/tags/CACTUS_172_RELEASE/framework/project.xml In many cases the 1.7.1 that is in the repository has more advanced versions of dependencies than the real project.xml in 1.7.2 has. > pom for cactus:cactus:13-1.7.2 > -- > > Key: MEV-405 > URL: http://jira.codehaus.org/browse/MEV-405 > Project: Maven Evangelism > Issue Type: Bug > Components: Missing POM >Reporter: Shinobu Kawai >Assignee: Henri Yandell > Attachments: cactus-13-1.7.2.pom > > > initial pom suggestion for cactus:cactus:13-1.7.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-404) pom for cactus:cactus-ant:13-1.7.2
[ http://jira.codehaus.org/browse/MEV-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98924 ] Henri Yandell commented on MEV-404: --- I think we need a better pom for this one. Otherwise, WONTFIX. > pom for cactus:cactus-ant:13-1.7.2 > -- > > Key: MEV-404 > URL: http://jira.codehaus.org/browse/MEV-404 > Project: Maven Evangelism > Issue Type: Bug > Components: Missing POM >Reporter: Shinobu Kawai >Assignee: Henri Yandell > Attachments: cactus-ant-13-1.7.2.pom > > > initial pom suggestion for cactus:cactus-ant:13-1.7.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPA-96) Make an archetype for test cases
[ http://jira.codehaus.org/browse/MPA-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MPA-96: - John there is a sample integration test in the repository: http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-test-sample/ And from that you can probably use the new archetypeng code and not have to do anything by hand. I've asked Rafale to help you. > Make an archetype for test cases > > > Key: MPA-96 > URL: http://jira.codehaus.org/browse/MPA-96 > Project: Maven Project Administration > Issue Type: Sub-task >Reporter: Brett Porter >Assignee: John Casey > Fix For: Maven 2.1 Prep > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-523) prefuse -sources.jar is missing
[ http://jira.codehaus.org/browse/MEV-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed MEV-523. - Resolution: Fixed -source and -javadoc manually put in place, and sha1/md5 generated for each. > prefuse -sources.jar is missing > --- > > Key: MEV-523 > URL: http://jira.codehaus.org/browse/MEV-523 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Peter Kolbus >Assignee: Henri Yandell > Attachments: prefuse-beta-20060220-javadoc.jar, > prefuse-beta-20060220-sources.jar, prefuse-beta-20060220.jar > > > The sources jar for prefuse is missing, this makes it more awkward to use it > as a dependency when working in Eclipse. > To reproduce: > svn co > http://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/grafo/grafo-maven-plugin > cd grafo-maven-plugin > mvn eclipse:eclipse -DdownloadSources=true > Results in message: > [INFO] >Sources for some artifacts are not available. >List of artifacts without a source archive: > o org.prefuse:prefuse:beta-20060220 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-525) The tagsoup (org/ccil/cowan/tagsoup/tagsoup) v 1.0.1 has some unclosed "url" tags in the licences section.
[
http://jira.codehaus.org/browse/MEV-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed MEV-525.
-
Resolution: Fixed
Modfied by hand in maven/ maven2-converted-from-maven1/ and maven2.
md5/sha1 regenerated in maven2.
> The tagsoup (org/ccil/cowan/tagsoup/tagsoup) v 1.0.1 has some unclosed "url"
> tags in the licences section.
> --
>
> Key: MEV-525
> URL: http://jira.codehaus.org/browse/MEV-525
> Project: Maven Evangelism
> Issue Type: Bug
> Components: Invalid POM
>Reporter: Daniel Alheiros
>Assignee: Henri Yandell
>
> http://repo1.maven.org/maven2/org/ccil/cowan/tagsoup/tagsoup/1.0.1/tagsoup-1.0.1.pom
> it's trying to close the tag with a mistyped instead of a
> for the academic free license (AFL):
>
>
> Academic Free License ("AFL") v. 3.0
> http://www.opensource.org/licenses/afl-3.0.php
> repo
>
>
> GNU GPL version 2.0
> http://www.opensource.org/licenses/gpl-license.php
> repo
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-513) Invalid POM: aspectwerkz/aspectwerkz-core
[ http://jira.codehaus.org/browse/MEV-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed MEV-513. - Resolution: Fixed Fixed manually in maven2/. md5 and sha1 regenerated. Declaring the rest as WONTFIX, and someday we can kick this out of the repository when we clean things up. > Invalid POM: aspectwerkz/aspectwerkz-core > - > > Key: MEV-513 > URL: http://jira.codehaus.org/browse/MEV-513 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Jing Xue >Assignee: Henri Yandell > > http://repo1.maven.org/maven2/aspectwerkz/aspectwerkz-core/2.0/aspectwerkz-core-2.0.pom > The closing tag is missing the "/". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-524) Javadoc jar not uploaded correctly for digester
[ http://jira.codehaus.org/browse/MEV-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98931 ] Henri Yandell commented on MEV-524: --- There are 70 javadoc.javadoc's in maven2. (also in maven2-converted...). Time for a script. > Javadoc jar not uploaded correctly for digester > --- > > Key: MEV-524 > URL: http://jira.codehaus.org/browse/MEV-524 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Henri Yandell >Assignee: Henri Yandell > > The migration of the javadoc jar from the Apache rsync to the central > repository doesn't seem to work well for javadocs - or more likely I did > something wrong. Any thoughts? > http://repo1.maven.org/maven2/commons-digester/commons-digester/1.8/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-524) Javadoc jar not uploaded correctly for digester
[ http://jira.codehaus.org/browse/MEV-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98933 ] Henri Yandell commented on MEV-524: --- Script written: ~/bin/javadoc2.sh Now to build up the courage to remove the echo's and run it. First against the maven2-converted directory without the -b flag, and then against maven2 with the -b flag. > Javadoc jar not uploaded correctly for digester > --- > > Key: MEV-524 > URL: http://jira.codehaus.org/browse/MEV-524 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Henri Yandell >Assignee: Henri Yandell > > The migration of the javadoc jar from the Apache rsync to the central > repository doesn't seem to work well for javadocs - or more likely I did > something wrong. Any thoughts? > http://repo1.maven.org/maven2/commons-digester/commons-digester/1.8/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-48) openejb poms
[ http://jira.codehaus.org/browse/MEV-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98935 ] Brett Porter commented on MEV-48: - this was the output of the repository converter that runs on m1 repositories. > openejb poms > > > Key: MEV-48 > URL: http://jira.codehaus.org/browse/MEV-48 > Project: Maven Evangelism > Issue Type: Task > Components: Invalid POM >Reporter: Brett Porter > Attachments: repository.report.openejb.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPH-25) Simplify Help Plugin - Add medium describe flag
Simplify Help Plugin - Add medium describe flag --- Key: MPH-25 URL: http://jira.codehaus.org/browse/MPH-25 Project: Maven 2.x Help Plugin Issue Type: Bug Reporter: Eric Redmond Priority: Blocker This simplifies the help plugin "describe" goal printout in "full" mode by removing redundant spaces to condense the overall size of the output. This patch also adds a "medium" flag - allowing one to get a simple plugin description with a list of available goals (no parameter data). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3040) Failure to construct build plan fatal error on trunk r545155
[ http://jira.codehaus.org/browse/MNG-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98936 ] Brett Porter commented on MNG-3040: --- No, that's the point. I don't want to use it in the lifecycle (the pom is there if you'd like to look at the execution) > Failure to construct build plan fatal error on trunk r545155 > > > Key: MNG-3040 > URL: http://jira.codehaus.org/browse/MNG-3040 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter >Assignee: John Casey > Attachments: pom.xml > > > see attached pom which causes this: > mcbrett:~/scm/maven/sandbox/continuum/continuum-data-upgrade brett$ mvn clean > install -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT > [INFO] task-segment: [clean, install] > [INFO] > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to construct build plan for: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( > task-segment: [clean, install] ). Reason: No phase specified for goal: exec > in plugin: org.codehaus.mojo:exec-maven-plugin from POM: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT > [INFO] > > [INFO] Trace > org.apache.maven.BuildFailureException: Failed to construct build plan for: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( > task-segment: [clean, install] ). Reason: No phase specified for goal: exec > in plugin: org.codehaus.mojo:exec-maven-plugin from POM: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:296) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:112) > at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:906) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:367) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > construct build plan for: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( > task-segment: [clean, install] ). Reason: No phase specified for goal: exec > in plugin: org.codehaus.mojo:exec-maven-plugin from POM: > org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleBindings(DefaultLifecycleExecutor.java:305) > > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:246) > > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) > ... 11 more > Caused by: org.apache.maven.lifecycle.LifecycleSpecificationException: No > phase specified for goal: exec in plugin: org.codehaus.mojo:exec-maven-plugin > from POM: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT > at > org.apache.maven.lifecycle.binding.DefaultLifecycleBindingManager.getProjectCustomBindings(DefaultLifecycleBindingManager.java:295) > > at > org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan(DefaultBuildPlanner.java:54) > > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleBindings(DefaultLifecycleExecutor.java:294) > > ... 14 more > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Thu Jun 07 22:40:57 EST 2007 > [INFO] Final Memory: 2M/5M > [INFO] > > [INFO] > --
[jira] Updated: (MPH-25) Simplify Help Plugin - Add medium describe flag
[ http://jira.codehaus.org/browse/MPH-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond updated MPH-25: Attachment: mylar-context.zip > Simplify Help Plugin - Add medium describe flag > --- > > Key: MPH-25 > URL: http://jira.codehaus.org/browse/MPH-25 > Project: Maven 2.x Help Plugin > Issue Type: Bug >Reporter: Eric Redmond >Priority: Blocker > Attachments: maven-help-plugin-medium.diff, mylar-context.zip > > > This simplifies the help plugin "describe" goal printout in "full" mode by > removing redundant spaces to condense the overall size of the output. > This patch also adds a "medium" flag - allowing one to get a simple plugin > description with a list of available goals (no parameter data). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPH-25) Simplify Help Plugin - Add medium describe flag
[ http://jira.codehaus.org/browse/MPH-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond updated MPH-25: Attachment: maven-help-plugin-medium.diff Add medium flag and simplify output > Simplify Help Plugin - Add medium describe flag > --- > > Key: MPH-25 > URL: http://jira.codehaus.org/browse/MPH-25 > Project: Maven 2.x Help Plugin > Issue Type: Bug >Reporter: Eric Redmond >Priority: Blocker > Attachments: maven-help-plugin-medium.diff, mylar-context.zip > > > This simplifies the help plugin "describe" goal printout in "full" mode by > removing redundant spaces to condense the overall size of the output. > This patch also adds a "medium" flag - allowing one to get a simple plugin > description with a list of available goals (no parameter data). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-90) add advanced search options
[ http://jira.codehaus.org/browse/MRM-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98938 ] Brett Porter commented on MRM-90: - it already does this (try searching for a class/package) > add advanced search options > --- > > Key: MRM-90 > URL: http://jira.codehaus.org/browse/MRM-90 > Project: Archiva > Issue Type: New Feature > Components: web application >Reporter: Brett Porter > Fix For: Future > > > we need to add the ability to query on particular fields and across some > ranges. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPH-25) Simplify Help Plugin - Add medium describe flag
[ http://jira.codehaus.org/browse/MPH-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MPH-25: Priority: Major (was: Blocker) > Simplify Help Plugin - Add medium describe flag > --- > > Key: MPH-25 > URL: http://jira.codehaus.org/browse/MPH-25 > Project: Maven 2.x Help Plugin > Issue Type: Bug >Reporter: Eric Redmond > Attachments: maven-help-plugin-medium.diff, mylar-context.zip > > > This simplifies the help plugin "describe" goal printout in "full" mode by > removing redundant spaces to condense the overall size of the output. > This patch also adds a "medium" flag - allowing one to get a simple plugin > description with a list of available goals (no parameter data). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPH-25) Simplify Help Plugin - Add medium describe flag
[ http://jira.codehaus.org/browse/MPH-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MPH-25: Patch Submitted: [Yes] > Simplify Help Plugin - Add medium describe flag > --- > > Key: MPH-25 > URL: http://jira.codehaus.org/browse/MPH-25 > Project: Maven 2.x Help Plugin > Issue Type: Bug >Reporter: Eric Redmond > Attachments: maven-help-plugin-medium.diff, mylar-context.zip > > > This simplifies the help plugin "describe" goal printout in "full" mode by > removing redundant spaces to condense the overall size of the output. > This patch also adds a "medium" flag - allowing one to get a simple plugin > description with a list of available goals (no parameter data). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MANTTASKS-72) Remove hardcoded groupId in install-provider task
[ http://jira.codehaus.org/browse/MANTTASKS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Hale updated MANTTASKS-72: -- Attachment: InstallWagonProviderTask.java.patch A patch with the uploaded code. > Remove hardcoded groupId in install-provider task > - > > Key: MANTTASKS-72 > URL: http://jira.codehaus.org/browse/MANTTASKS-72 > Project: Maven 2.x Ant Tasks > Issue Type: Improvement >Affects Versions: 2.0.6 >Reporter: Ben Hale > Attachments: InstallWagonProviderTask.java.patch > > > Currently, the InstallWagonProviderTask hard-codes the 'WAGON_GROUP_ID' value > internally with no way to override it. Because of this, it is impossible to > use a custom wagon that does not have a groupId of 'org.apache.maven.wagon' > to upload files with a deploy task. > It would be better if the install-provider task used that value as a default > (so that it would be specified in the common case), but had a groupId setter > allowing it to overriden. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MWAR-104) handle zip dependencies in war plugin
handle zip dependencies in war plugin - Key: MWAR-104 URL: http://jira.codehaus.org/browse/MWAR-104 Project: Maven 2.x War Plugin Issue Type: Improvement Environment: all Reporter: Olivier Lamy As MNG-1683 has been applied, the zip artifact must be handled in the war 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] Updated: (MWAR-104) handle zip dependencies in war plugin
[
http://jira.codehaus.org/browse/MWAR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MWAR-104:
--
Attachment: foobar.zip
MWAR-104
Attached patch.
The attached zip file (needed for junit) must be located in
${basedir}/src/test/resources/unit/warziptest
> handle zip dependencies in war plugin
> -
>
> Key: MWAR-104
> URL: http://jira.codehaus.org/browse/MWAR-104
> Project: Maven 2.x War Plugin
> Issue Type: Improvement
> Environment: all
>Reporter: Olivier Lamy
> Attachments: foobar.zip, MWAR-104
>
>
> As MNG-1683 has been applied, the zip artifact must be handled in the war
> 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
