Re: Continuum 1.1 roadmap
Hi, Just wondering what happened to this idea: http://www.nabble.com/2.1-Design-and-Process-tf1617559.html#a4383722 Cheers, Rahul Jesse McConnell wrote: hi everyone, I have been trying to help emmanuel some with pulling together the roadmap for Continuum 1.1 on the wiki and maybe help organize some of the discussions on there. I wanted to get out the url to the wiki roadmap and maybe see how you guys feel about the content on it. I tried to pull out some of the important things from the 170 + issues in jira currently slated for 1.1 and also the roadmap thread that started on this mailing list last month. so..any thoughts and improvements would be much appreciated, I was kinda hoping I could get a somewhat definitive list of the major hotbutton items for Continuum 1.1 on that roadmap page and then link out the appropriate wiki page or jira ticket. http://docs.codehaus.org/display/CONTINUUM/Continuum+1.1+Development+Roadmap I also reworked the front page a bit...it was sort plain...or empty rather. http://docs.codehaus.org/display/CONTINUUM/Home jesse
Re: Continuum 1.1 roadmap
it disappeared into the ether of the mailing list? :) I still think its a good idea, thanks for bringing it back up...could be very useful on some of the larger issues like security and project groups, etc.. jesse On 7/12/06, Rinku [EMAIL PROTECTED] wrote: Hi, Just wondering what happened to this idea: http://www.nabble.com/2.1-Design-and-Process-tf1617559.html#a4383722 Cheers, Rahul Jesse McConnell wrote: hi everyone, I have been trying to help emmanuel some with pulling together the roadmap for Continuum 1.1 on the wiki and maybe help organize some of the discussions on there. I wanted to get out the url to the wiki roadmap and maybe see how you guys feel about the content on it. I tried to pull out some of the important things from the 170 + issues in jira currently slated for 1.1 and also the roadmap thread that started on this mailing list last month. so..any thoughts and improvements would be much appreciated, I was kinda hoping I could get a somewhat definitive list of the major hotbutton items for Continuum 1.1 on that roadmap page and then link out the appropriate wiki page or jira ticket. http://docs.codehaus.org/display/CONTINUUM/Continuum+1.1+Development+Roadmap I also reworked the front page a bit...it was sort plain...or empty rather. http://docs.codehaus.org/display/CONTINUUM/Home jesse -- jesse mcconnell [EMAIL PROTECTED]
[repost: review request] Re: MJAR-28 Advice from dev: Mainfest.mf/Class-Path entries by MavenArchiver, Assembly and Jar
Reposting to request someone with MavenArchiver, Assembly and Jar dev experience to provide some guidance on which is the correct direction so I can file a patch. Cheers Bae - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review javadoc plugin documentation
A staging site is now available at http://people.apache.org/~oching/maven-javadoc-plugin http://people.apache.org/%7Eoching/maven-javadoc-plugin Thanks :) Richard van der Hoff wrote: Maria Odea Ching wrote: Okay, will do :) Thanks.. Could you also fix your clock? It seems to be set for the wrong timezone, or something ... either way, it's about 15 hours fast. Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Listeners for build events
Thanks for your response. Glad to hear that a listener based approach is a viable solution. I have already obtained the source from Subversion trunk and will begin looking at implementing such an approach. Any thoughts on the events people may want to listen on? -- View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5284524 Sent from the Continuum - Dev forum at Nabble.com.
Re: Listeners for build events
Ahmed Omarjee wrote: Thanks for your response. Glad to hear that a listener based approach is a viable solution. I have already obtained the source from Subversion trunk and will begin looking at implementing such an approach. Any thoughts on the events people may want to listen on? Are there any but: - before scm update - after scm update There are already notifiers for the other build events so you can do additional operations there. -- Trygve
Re: Listeners for build events
Agreed. Just to confirm that this listener based approach is indepedent of the current notifiers based approach with respect to its intended use. (not necessarily drastically different with respect to implementation). -- View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5284666 Sent from the Continuum - Dev forum at Nabble.com.
J2EE killer: For multi module builds CLASSPATH != resolved dependencies
Hi developers, after working now for some time with M2, we run really in troubles with the M2 setup here. We use a company wide super POM and have a lot of multi module projects. Now after releasing some of the artifacts, we run into big trouble, since we had to detect, that the CLASSPATH does not match the dependencies in multi module builds (note, all modules build fine with the correct dependencies if Maven is started locally). Problem: If a module references another one also part of the multi module build, a defined version is completely ignored building the CLASSPATH. Even if a module references a released version as dependency, the classpath will contain the other module as SNAPSHOT (MNG-2424). The situation is even worse if your module packages an EJB. In this case the manifest will contain the versions from the CLASSPATH, but not from the resolved dependencies (MEJB-18). Including such an EJB into an EAR will fail, because the bundled libs in the EAR correspond to the versions in the resolved dependencies, but not to the ones in the CLASSPATH i.e. the EJB is broken and cannot find its classpath elements from the manifest. This issue really kills our complete development environment, since you have to build either all those hundred artifacts individually or you have to release all of them everytime before you can test even a single one. And there's nothing you can configure in the POM to circumvent this. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M1] maven-eclipse-plugin 1.11 creates phantom sources attachement
Hello, I'm using maven1.1 and latest eclipse plugin (1.11). Plugin downloads sources and creates sources attachement in my eclipse classpath. Some libs have no source jars available, so downloading the sources.jar fails, but the generated .classpath has a source reference to this unavailable jar. Is this a known bug ? Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M1] maven-eclipse-plugin 1.11 creates phantom sources attachement
I've found it myself on MPECLIPSE-118 Is there a snapshot for the 1.11.1 maven-eclipse-plugin ? Nicolas De Loof a écrit : Hello, I'm using maven1.1 and latest eclipse plugin (1.11). Plugin downloads sources and creates sources attachement in my eclipse classpath. Some libs have no source jars available, so downloading the sources.jar fails, but the generated .classpath has a source reference to this unavailable jar. Is this a known bug ? Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with the new plugin plugin: missing parameters from parent mojo
Brett Porter wrote:
Thanks - is it definitely the inheritence? If so, that's a bug.
No, it's not the inheritance. I spoke too soon.
There are two other factors:
- a bug that meant a parameter without expression didn't appear (I
committed Edwin's fix yesterday, but didn't deploy a snapshot)
Two of the missing parameters would be hit by this.
- readonly and components are now omitted by design
OK, I had missed that.
Is a parameter like this:
@parameter expression=${component.org.apache...
considered a component as well as one that has:
@component?
If that is the case, then I think that all is OK. Let me know when a new
snapshot is available and I'll double check it.
Definitely needs to be looked in to.
- Brett
On 12/07/2006 9:45 AM, Dennis Lundberg wrote:
Dennis Lundberg wrote:
Hi
I've found a problem using the new plugin plugin. The new look for
the mojo documentation doesn't include everything that it used to.
I'm documenting the jar plugin. This plugin has an AbstractJarMojo
which the JarMojo extends. The abstract class has many parameters
that don't get included in the new look page. Only parameters
declared in JarMojo end up in the page jar-mojo.html. If I revert to
using maven-plugin-plugin-2.1 the parameters show up again.
Here are some examples.
Old plugin plugin:
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html
New plugin plugin:
http://people.apache.org/~dennisl/maven-jar-plugin/jar-mojo.html
--
Dennis Lundberg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review the documentation for the maven-jar-plugin
I did that yesterday, before posting this to the list. Can't you see my change? Edwin Punzalan wrote: Also, can you please update this page: http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation Thanks. ^_^ Dennis Lundberg wrote: Hi all I have finished going over the documentation for the maven-jar-plugin. I hope you can spare a moment and read through it. This is what I have done: [MJAR-46] Document manifestFile element in configuration [MJAR-47] maven-jar-plugin documentation should point to additional documentation, such as manifest guide [MJAR-48] Review plugin documentation - Add FAQ - Add links to the Javadocs for MavenArchiveConfiguration - Restructured the documentation according to the new guidelines for plugins - Review all the parameters to ensure they have good docs - Use the new and improved plugin report A staged site is available for browsing here: http://people.apache.org/~dennisl/maven-jar-plugin/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review Javadoc Plugin Documentation
Thanks :) Btw, a staging site is already available at http://people.apache.org/~oching/maven-javadoc-plugin http://people.apache.org/%7Eoching/maven-javadoc-plugin Mike Perham wrote: Done. -Original Message- From: Maria Odea Ching [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 11, 2006 8:17 PM To: dev@maven.apache.org Subject: Review Javadoc Plugin Documentation Hi Everyone, I've made some changes in the javadoc plugin. Could someone please review it? :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please review maven source plugin documentation
Hi Everyone, The documentation for the source plugin is now ready for review :) Thanks, Odea - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Error building plugins
Hi
I am trying to build the plugins, but I am getting an error that indicates that
there must be an error in one of the pom's:
[INFO] The projects in the reactor contain a cyclic reference:
Edge between 'Vertex{label='org.apache.maven.plugins:maven-jxr-plugin'}' and
'Vertex{label='org.apache.maven.plugins:maven-javadoc-plugin'}'
introduces to cycle in the graph org.apache.maven.plugins:maven-javadoc-plugin
-- org.apache.maven.plugins:maven-jxr-plugin --
org.apache.maven.plugins:maven-javadoc-plugin
Hermod
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that the DnB NOR Group
cannot accept any payment orders or other legally binding correspondence with
customers as a part of an email.
This email message has been virus checked by the anti virus programs used
in the DnB NOR Group.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Problem Accessing docck Plugin
I have seen references to the docck plugin floating around the list and thought I would give it a try to see what it does. When I tried to reference it on the command line, I got some strange output [1]. What surprised me was that it resolved the version to a snapshot and tried to get it from central. I checked my local repository and found maven-metadata-central.xml [2] which explained why Maven resolved the version. Is it an error for there to be metadata in central for a snapshot plugin? --[1] [EMAIL PROTECTED] logging]$ mvn docck:check [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'docck'. [INFO] org.codehaus.mojo: checking for updates from central [INFO] qaccess.plugins: checking for updates from central [INFO] org.apache.maven.plugins: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-docck-plugin: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-docck-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-docck-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-docck-plugin:pom:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 12 seconds [INFO] Finished at: Wed Jul 12 06:19:08 EDT 2006 [INFO] Final Memory: 2M/4M [INFO] --[2] ?xml version=1.0 encoding=UTF-8?metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-docck-plugin/artifactId version1.0-SNAPSHOT/version versioning latest1.0-SNAPSHOT/latest versions version1.0-SNAPSHOT/version /versions lastUpdated20060711175747/lastUpdated /versioning /metadata This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 2.1 - Optional dependencies, exclude all ...
Hi guys, Yesterday, during the explanation of the roadmap of maven 2.1 in the meeting Maven day, Jason said that a new setting will be supported to exclude all the transitive dependencies. I had effectively see numerous users that were complaining about the big exclusion list they have to maintain which is as annoying as in m1 for the list of all the dependencies. My question : Is there someone who proposed to add a list of profiles (We can use this term because we already use it in m2 but I don't have another idea today) in a dependency. For example for a complex librairie like Spring we can ask them to create as many POM as they have usecases of this library. But it will be difficult to maintain. Or we could do something like : In the POM of MyHorribleProjectWithALotOfOptionalDependencies project ... dependencies dependency groupIdgrp-A/groupId artifactIdlib-A/artifactId optionaltrue/optional profiles profileprofile-1/profile /profiles /dependency dependency groupIdgrp-B/groupId artifactIdlib-B/artifactId optionaltrue/optional profiles profileprofile-2/profile /profiles /dependency dependency groupIdgrp-C/groupId artifactIdlib-C/artifactId optionaltrue/optional profiles profileprofile-1/profile profileprofile-2/profile /profiles /dependency dependency groupIdgrp-D/groupId artifactIdlib-D/artifactId /dependency /dependencies ... /project It's something more fine than the optional element. In the POM of my project which uses this framework, I can use the dependency without profile : dependency groupIdMyHorribleProjectWithALotOfOptionalDependencies/groupId artifactIdMyHorribleProjectWithALotOfOptionalDependencies/artifactId /dependency To get all the dependencies. I can use the profile-1 dependency groupIdMyHorribleProjectWithALotOfOptionalDependencies/groupId artifactIdMyHorribleProjectWithALotOfOptionalDependencies/artifactId profileprofile-1/profile /dependency To get lib-A, lib-C, lib-D I can use the profile-2 to get lib-B, lib-C, lib-D ... WDYT ? Arnaud
Re: J2EE killer: For multi module builds CLASSPATH != resolved dependencies
In MNG-2424, you say it may be related to MNG-1245 which is now fixed. Does that correct that issue? There have been some classspath related archiver fixes that might help with MEJB-18. Would fixing both of these resolve your issue? - Brett On 12/07/2006 6:23 PM, Jörg Schaible wrote: Hi developers, after working now for some time with M2, we run really in troubles with the M2 setup here. We use a company wide super POM and have a lot of multi module projects. Now after releasing some of the artifacts, we run into big trouble, since we had to detect, that the CLASSPATH does not match the dependencies in multi module builds (note, all modules build fine with the correct dependencies if Maven is started locally). Problem: If a module references another one also part of the multi module build, a defined version is completely ignored building the CLASSPATH. Even if a module references a released version as dependency, the classpath will contain the other module as SNAPSHOT (MNG-2424). The situation is even worse if your module packages an EJB. In this case the manifest will contain the versions from the CLASSPATH, but not from the resolved dependencies (MEJB-18). Including such an EJB into an EAR will fail, because the bundled libs in the EAR correspond to the versions in the resolved dependencies, but not to the ones in the CLASSPATH i.e. the EJB is broken and cannot find its classpath elements from the manifest. This issue really kills our complete development environment, since you have to build either all those hundred artifacts individually or you have to release all of them everytime before you can test even a single one. And there's nothing you can configure in the POM to circumvent this. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with the new plugin plugin: missing parameters from parent mojo
Yep, that's right. I'll push up a snapshot now.
On 12/07/2006 7:33 PM, Dennis Lundberg wrote:
Brett Porter wrote:
Thanks - is it definitely the inheritence? If so, that's a bug.
No, it's not the inheritance. I spoke too soon.
There are two other factors:
- a bug that meant a parameter without expression didn't appear (I
committed Edwin's fix yesterday, but didn't deploy a snapshot)
Two of the missing parameters would be hit by this.
- readonly and components are now omitted by design
OK, I had missed that.
Is a parameter like this:
@parameter expression=${component.org.apache...
considered a component as well as one that has:
@component?
If that is the case, then I think that all is OK. Let me know when a new
snapshot is available and I'll double check it.
Definitely needs to be looked in to.
- Brett
On 12/07/2006 9:45 AM, Dennis Lundberg wrote:
Dennis Lundberg wrote:
Hi
I've found a problem using the new plugin plugin. The new look for
the mojo documentation doesn't include everything that it used to.
I'm documenting the jar plugin. This plugin has an AbstractJarMojo
which the JarMojo extends. The abstract class has many parameters
that don't get included in the new look page. Only parameters
declared in JarMojo end up in the page jar-mojo.html. If I revert to
using maven-plugin-plugin-2.1 the parameters show up again.
Here are some examples.
Old plugin plugin:
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html
New plugin plugin:
http://people.apache.org/~dennisl/maven-jar-plugin/jar-mojo.html
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: J2EE killer: For multi module builds CLASSPATH != resolved dependencies
Brett Porter wrote on Wednesday, July 12, 2006 2:18 PM: In MNG-2424, you say it may be related to MNG-1245 which is now fixed. Does that correct that issue? I don't know. I have too less knowledge about the classpath generation in Maven and how it is related to the dependencies - escpecially in multi module mode. There have been some classspath related archiver fixes that might help with MEJB-18. MNG-2424 and MEJB-18 is IMHO the same bug. Would fixing both of these resolve your issue? How do I test this best? I don't want to run into troubles for my standard build environment with all kind of snapshot plugins in my repository. It is already quite complex. Nevertheless the attachments in the issues provide a scenario for a test in an environment with a newer Maven snapshot. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: J2EE killer: For multi module builds CLASSPATH != resolved dependencies
To test MNG-1245 you can just replace your maven-project-2.0.4.jar in MAVEN_HOME/lib with the SNAPSHOT I attached to the issue and see if the issue goes away or changes. -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 12, 2006 8:07 AM To: Maven Developers List Subject: RE: J2EE killer: For multi module builds CLASSPATH != resolved dependencies Brett Porter wrote on Wednesday, July 12, 2006 2:18 PM: In MNG-2424, you say it may be related to MNG-1245 which is now fixed. Does that correct that issue? I don't know. I have too less knowledge about the classpath generation in Maven and how it is related to the dependencies - escpecially in multi module mode. There have been some classspath related archiver fixes that might help with MEJB-18. MNG-2424 and MEJB-18 is IMHO the same bug. Would fixing both of these resolve your issue? How do I test this best? I don't want to run into troubles for my standard build environment with all kind of snapshot plugins in my repository. It is already quite complex. Nevertheless the attachments in the issues provide a scenario for a test in an environment with a newer Maven snapshot. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: General issue with clover plugin requiring creative thinking...
Hi Jesse, -Original Message- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: mardi 11 juillet 2006 14:57 To: Maven Developers List Subject: Re: General issue with clover plugin requiring creative thinking... If it's a matter of sharing information maybe the ability to store data in a sort of temporary HashMap sort of session? Ie clover could do something like: session.store(CLOVER_INSTRUMENTED_SOURCE_DIR, target/src/clover-generated); And the next guy that needs it could pick it up...Probably not easy to do though since it's likely that mvn will be invoked multiple times. The problem is that the next guy are the other plugins (compile, etc) over which the clover plugin has no control. We can't modify these plugins to look a property in the session/context. I think introducing 2 source sets (one for modified sources and one for original sources) would probably be the best option. The plugins would need to decide which source set to operate on. But that requires some core changes and new versions of the plugins. As suggested by Kenney one possible immediate workaround is to ensure that plugins such as checkstyle/PMD/findbugs have ways to add filesets and ways to exclude files. That's not a clean solution. If anyone has a better idea let me know. Thanks -Vincent On 7/11/06, John Allen [EMAIL PROTECTED] wrote: I have found this aspect of clover a great frustration and would welcome any attempt to separate such 'instrument and compile' tasks from the main project build activities. John -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 11 July 2006 06:20 To: Maven Developers List Subject: Re: General issue with clover plugin requiring creative thinking... On 11/07/2006 3:14 PM, Vincent Massol wrote: One solution would be to create a profile for the main lifecycle and another one for the clover lifecycle but that's not very handy for end users I think. I'll try experimenting with this later on but I think it would only be a hack and not a proper solution. Is there anything better I could do? Not that I can think of that doesn't involve core changes (ie, 2.1). - Brett ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem Accessing docck Plugin
Allison, Bob wrote: I have seen references to the docck plugin floating around the list and thought I would give it a try to see what it does. When I tried to reference it on the command line, I got some strange output [1]. What surprised me was that it resolved the version to a snapshot and tried to get it from central. I checked my local repository and found maven-metadata-central.xml [2] which explained why Maven resolved the version. Is it an error for there to be metadata in central for a snapshot plugin? --[1] [EMAIL PROTECTED] logging]$ mvn docck:check [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'docck'. [INFO] org.codehaus.mojo: checking for updates from central [INFO] qaccess.plugins: checking for updates from central [INFO] org.apache.maven.plugins: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-docck-plugin: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-docck-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-docck-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-docck-plugin:pom:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 12 seconds [INFO] Finished at: Wed Jul 12 06:19:08 EDT 2006 [INFO] Final Memory: 2M/4M [INFO] --[2] ?xml version=1.0 encoding=UTF-8?metadata groupIdorg.apache.maven.plugins/groupId artifactIdmaven-docck-plugin/artifactId version1.0-SNAPSHOT/version versioning latest1.0-SNAPSHOT/latest versions version1.0-SNAPSHOT/version /versions lastUpdated20060711175747/lastUpdated /versioning /metadata Here's what I did to make this work. I put this in my settings.xml file: ... profiles profile idapache/id repositories repository idsnapshots/id urlhttp://svn.apache.org/maven-snapshot-repository/url /repository /repositories pluginRepositories pluginRepository idsnapshots/id urlhttp://svn.apache.org/maven-snapshot-repository/url /pluginRepository /pluginRepositories /profile /profiles ... And invoke maven like this: mvn -Papache docck:check -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What's the status of maven-changes-plugin, currently in the sandbox?
Hi Every now and then users are having trouble using the changes plugin. After the move from mojo there has not been any release of the changes plugin. The last version published from mojo was 2.0-beta-1. The current version at Apache, according to the pom in the sandbox, is 2.0-beta-2. What is needed to get a new beta release out? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] Maven 2.1 Design Topics
Hi everyone, I guess it's fairly obvious from some of the advanced discussions going on in this list that we're starting to think a little more seriously about writing Maven 2.1. I think it's a bad idea for us to attempt another massive release (akin to 2.0) that attempts to fix everything that's wrong with the world - and I don't think anyone would argue with me on that. ;-) So, in the spirit of really getting the ball rolling, I'd like to propose some general topics that we should try to address for 2.1. I've discussed this a little bit with Brett on IRC, and I think it would be a good idea if we could pick a few ailing subsystems and try to solve all of the known issues with each of them. This way, we have some coherent progress to report, and maybe we can move past these particular subsystems for the 2.2work. What follows is my own outline of what we should attempt for 2.1. To reiterate, it's not comprehensive of all major issues in Maven 2.0.x; it's only meant to focus on the bigger, more common pain points and give us something coherent to report with the 2.1 release. These are just some rough thoughts, but if there are no objections to this general list, I'd like to expand each section (similar to, but more detailed than, the Details outline given below) in order to highlight specific problems we're encountering now, and some possible solution strategies. WDYT? -john My thoughts: * Broad Themes - [Refactor] Artifact Handling - [Refactor] POM Loading / Building - [Refactor] Lifecycle / Plugin Handling - [Refactor] Embedder - Alternative Component Support * Details ** Artifact Handling - Version Ranges - Artifact Identity * Handling platform naming * Handling the 2^n variance problem with directives in C: possibly using an assertion-based approach to sense the flavor of artifact to use? * Alternative identity schemes? Layout, VersionRange, Artifact impls... - Conflict Resolution - Resolution Problems * Exclude-all * Exclusions * Role of dependencyManagement - Artifact Identity and Multi-language Support ** POM Loading / Building - Running Away from XPP3 - Encoding - Chain of Command Project Loading - Interpolation Problems - Inheritance / Profile Injection Problems ** Lifecycle / Plugin Handling - Aggregation - Suppression (reports plugins) - Fine-grained Phase-binding Ordering - Super-lifecycle (for tools that embed Maven, like Continuum, to register pre- and post- hooks) - Flexible Artifact Filtering for Maven Core ClassRealm * Embedding We need to get this up to snuff to support some real IDE tooling, as this will be our bread and butter for competing with commercial tools and Eclipse. * Alternative Component Support In order to flex to meet the needs of the larger community (including other languages and OSGi), we may need to introduce alternative version conflict resolution strategies, artifact resolvers, repository layouts, and so forth. We should find a way to enable this from the POM and settings.xml (?)
Re: Please review javadoc plugin documentation
Maria Odea Ching wrote: Hi Everyone, I've made some changes in the javadoc plugin docs. Could someone please review it? :-) Thanks, Odea I've read through the docs and here are some comments: All - The title for all pages is Maven Javadoc Report, but all references in the text refers to Maven Javadoc Plugin. usage.html - Do we need to include the configuration section in the sample pom? There is no mention of the max/minmemory settings in the text. jar-mojo.html - This page is very wide, wider than my 1280 screen. The reason is the groups param example code, and also the tags example. I see in the source code that there are line breaks inside the pre-tag, but they seem to be ignored. Perhaps a bug in the plugin plugin or the used javadoc parser? - finalName param: Specified the - Specifies the - nocomment param: Ssee - See - nonavbar param: Seems to be copy-and-pasted from noindex + two default values - old param: This option created - This option creates - windowtitle param: two default values examples/*.html (except alternate-doclet.html) - The poms in these examples have the javadoc plugin configured in the build section. Shouldn't it be the reporting section? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: git repository provider
I just fixed the patch. It now runs with version 1.0-SNAPSHOT. Regards, Dominik
Re: [proposal] Maven 2.1 Design Topics
Alternative component support would be a big win for maven 2.1 on the OSGi/Eclipse bundle front. I look forward to hopefully contributing in this area. Wb On 7/12/06, John Casey [EMAIL PROTECTED] wrote: Hi everyone, ... * Alternative Component Support In order to flex to meet the needs of the larger community (including other languages and OSGi), we may need to introduce alternative version conflict resolution strategies, artifact resolvers, repository layouts, and so forth. We should find a way to enable this from the POM and settings.xml (?)
Re: Please review maven-idea-plugin documentation
Edwin Punzalan wrote: I've just finished updating the documentation for the maven-idea-plugin. Your feedback is highly appreciated. Thanks. Here are my comments: All - IntelliJ Idea - IntelliJ IDEA and Idea - IDEA in lots of places. Search for it. index.html - The IDEA Plugin has four goals. - The IDEA Plugin has five goals. plugin-info.html - idea:idea goal: .ipr and .iws files - .ipr, .iml and .iws files usage.html - create just the one of - create just one of library.html - The context of libraries is a bit vague. Is this something that you put on the command line, in the configuration section of the pom or elsewhere? Ah, when I read the examples I found it in examples/customize_libraries.html. A link to that page would be nice. examples/attach_library_src_doc.html - if one prefers - if you prefer examples/prevent_module_references.html - can choose do so - can choose to do so - linkModulestrue/linkModules - linkModulesfalse/linkModules examples/provide_deployment_descriptor_file.html - Just out of curiosity, what would happen if you have a project with one ejb module and one war module? Would the two modules get the same descriptor file? examples/*.html - Change the filenames to the dictated filename standard: like-this.apt instead of like_this.apt -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review of install plugin
Allan Ramirez wrote: Hi everyone, Just updated the docs of the install plugin. I hope you dont mind if you take a look and give me some feedback about it. Thanks Cheers, allan Here are my comments: site.xml - Missing the Goals link in the overview section. **/*.html - Remove the text Maven 2 Install Plugin from the titles. The title is picked up from the project name in site.xml - In the example documents, the title and heading are not equal. index.html - Change the title to Introduction usage.html - install:install goal doesnt - the install:install goal doesn't - overriden - overridden - Maven assumes the file is the main artifact for the project. Is this the same as packaging then? faq.html - It's empty... examples/update-release-info.html - Updating the release information changes the project's maven-metadata.xml in the local repository, forcing the current installed version as the latest release version. I'm sorry, but I don't understand what this means :( install-mojo.html - createChecksum param: Flag whether - Whether - updateReleaseInfo param: No default value? It's a boolean. install-file-mojo.html - All parameters but file are optional. Well that's not really true. This problem might occur in other plugins as well. IIUC you have to use *either* pomFile *or* groupId/artifactId/version. How do we document that? - generatePom param: No default value? It's a boolean. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Default Filtered Resources Directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I read about the Super-POM at: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html My question is now, if it was possible to add an additional resources directory that is filtered. It would not hurt anybody if he does not use it, but it would be very handy to have it as default. My suggestion would be to add: resource directorysrc/main/templates/directory filteringtrue/filtering /resource You could also name it filtered-resources or whatever. I dont realy care about the name of the directory - I just would love to have a standard defined by maven. You can also add the same directive for src/test. - From your examples (http://maven.apache.org/guides/getting-started/index.html) people can get the idea to change the resources directory to be filtered. I actually do NOT think that this is a good idea. My problem is that I have to override the complete resources directive to add this AND the maven philosophy is to have a standard directory layout and the need for very little configuration. Wouldn't this be a good idea? Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEtW5DmPuec2Dcv/8RAoWHAJ4g3G/CKeyfcAiHCqkQPmTbsuRudACfXssO sU1NmJjl8BFnBOSMgROz1hY= =HD+O -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review maven source plugin documentation
Maria Odea Ching wrote: Hi Everyone, The documentation for the source plugin is now ready for review :) Thanks, Odea My comments: faq.html - Use the source:test-jar to - Use the source:test-jar goal to examples/configureplugin.html - To customize the configuration of the plugin - To customize the plugin - The generated jar file will hold the value of the - The generated jar file will be named by the value of the - It would be generated - It will be generated - The attach parameter specifies that the produced jar file will be attached to the project artifact. What does this mean? jar-mojo.html - This plugin bundles all the generated sources into a jar archive. - This plugin bundles all the sources into a jar archive. test-jar-mojo.html - This plugin bundles all the generated test sources into a jar archive. - This plugin bundles all the test sources into a jar archive. jar-mojo.html and test-jar-mojo.html - executedProject, finalName and outputDirectory params: These must have some kind of implicit default values, because I can issue the command mvn source:jar and it works. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Maven 2.1 Design Topics
On 7/13/06, Wendell Beckwith [EMAIL PROTECTED] wrote: Alternative component support would be a big win for maven 2.1 on the OSGi/Eclipse bundle front. I look forward to hopefully contributing in this area. +1 here. There have been more than one email chain on the user lists with people building Eclipse bundles and trying to work out how to do this in Maven. I'm still struggling with how to best do this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven dependecies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Maven2 really rocks! I figured out a way to build a plugin that allows solaris as packaging and builds a solaris package for a maven project. Therefore I add the complete static content of the package to the main/resources. Further I have a filtered resources directory where I add files with variables to be replaced during the build (pkginfo, prototype-template, and configuration content of the package). As compile phase I add the dependent artifacts to the package at a configurable directory. Finally I build the solaris package with an ant script using the maven-antrun-plugin. Now I have two questions/suggestions/...? 1. The maven resources plugin does NOT copy empty directories (as it seems to me). Now I am so happy with subversion that I can have empty directories and also be able to maintain them. In this case I still have to add the good olds ignore.txt files to empty directories so they are included in the package. Is there a way to make the maven resources plugin to copy empty directories? 2. To add the dependencies to the package I added the dependency on my maven software modules and used the maven-dependency-plugin to copy the artifacts. Now I came into trouble with maintainance because I want to have my software split in multiple packages. One is containing the thirdparty stuff (lest call it PKG-EXT) and another I containing my custom code (PKG-CUST). Therefore I would need to have the following dependency in PKG-EXT: dependency groupIdmy.foo.id/groupId artifactIdmy-master-app/artifactId version1.0/version excludes exclude groupIdmy.foo.id/groupId artifactIdmy-utils/artifactId /exclude exclude groupIdmy.foo.id/groupId artifactIdmy-core/artifactId /exclude exclude groupIdmy.foo.id/groupId artifactIdmy-master-app/artifactId /exclude ... /excludes /dependency Besides the fact that it does NOT work to exclude the dependency itself, I would need to maintain this whenever the dependencies of my modules change. Additionally I would need to add all the excluded dependencies including their versions as dependencies to PKG-CUST. Now here is what I did (as a brute HACK) to solve my problem: I wrote a maven plugin (the MOJO stuff and maven APIs are really cool - easy to get quick results) that acts as the maven-depdencies-plugin but allows to have * as artifactId in an the exclusion. For the PKG-CUST package I use the plugin with inverted logic. Surprisingly you are still here reading. My questions are now: Will maven support something like this by default one day? If not will my HACK still work in further releases or can it happen that the verification gets updated and my pom becomes invalid because * is no vaild artifactId anymore? Thank you for reading this. I hope to get an answer. BTW: the plexus/components.xml was really hard to figure out. Is there any documentation that I missed? Should I write a mini xdoc about what I figured out about how to create your own packaging? Are you interested in a maven-solaris-package-plugin ? If there is a real solution for my HACK I would love to donate the plugin to maven. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEtXVHmPuec2Dcv/8RAueyAJ0YL1fw2yyyDsQu/my62slM6j6b0gCfdG9T TwwchCw+fVe6Yl+BQj0gZEA= =AJ7l -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum 1.1 roadmap
hi everyone, I have been trying to help emmanuel some with pulling together the roadmap for Continuum 1.1 on the wiki and maybe help organize some of the discussions on there. I wanted to get out the url to the wiki roadmap and maybe see how you guys feel about the content on it. I tried to pull out some of the important things from the 170 + issues in jira currently slated for 1.1 and also the roadmap thread that started on this mailing list last month. so..any thoughts and improvements would be much appreciated, I was kinda hoping I could get a somewhat definitive list of the major hotbutton items for Continuum 1.1 on that roadmap page and then link out the appropriate wiki page or jira ticket. http://docs.codehaus.org/display/CONTINUUM/Continuum+1.1+Development+Roadmap I also reworked the front page a bit...it was sort plain...or empty rather. http://docs.codehaus.org/display/CONTINUUM/Home jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: Please review the documentation for the maven-jar-plugin
Thanks for the review Edwin. Which place are you referring to? Edwin Punzalan wrote: I think I remember that we should be using Maven instead of Maven 2. Aside from that, everything's just great. ^_^ Dennis Lundberg wrote: Hi all I have finished going over the documentation for the maven-jar-plugin. I hope you can spare a moment and read through it. This is what I have done: [MJAR-46] Document manifestFile element in configuration [MJAR-47] maven-jar-plugin documentation should point to additional documentation, such as manifest guide [MJAR-48] Review plugin documentation - Add FAQ - Add links to the Javadocs for MavenArchiveConfiguration - Restructured the documentation according to the new guidelines for plugins - Review all the parameters to ensure they have good docs - Use the new and improved plugin report A staged site is available for browsing here: http://people.apache.org/~dennisl/maven-jar-plugin/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
how to use freshly compiled surefire junit runner
Hi all, i can compile the surefire sources from svn (http://svn.apache.org/repos/asf/maven/surefire/trunk) and run mvn install succesfully to get it into the local repository: [INFO] Installing D:\maven\surefire-trunk\surefire-providers\surefire-junit\target\surefire-junit-2. 1-SNAPSHOT.jar to C:\xxx\.m2\repository\org\apache\maven\surefire\surefi re-junit\2.1-SNAPSHOT\surefire-junit-2.1-SNAPSHOT.jar ... [INFO] BUILD SUCCESSFUL But I could not figure out how to use this snapshot from another project. What would I need to add to the pom? thanks! Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Layout of multiproject projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have a complex maven project that goes down to 3 levels of POM inheritance (= it has sub-sub-projects). I am not really sure about what the suggested layout is: TREE: trunk/ trunk/foo-project/pom.xml trunk/foo-project/foo-project-util/pom.xml trunk/foo-project/foo-project-service/pom.xml trunk/foo-project/foo-project-service/foo-project-service-core/pom.xml trunk/foo-project/foo-project-service/foo-project-service-main/pom.xml or FLAT: trunk/ trunk/foo-project/pom.xml trunk/foo-project-util/pom.xml trunk/foo-project-service/pom.xml trunk/foo-project-service-core/pom.xml trunk/foo-project-service-main/pom.xml As it seems by most plugins the FLAT layout is required for them to work. On the other hand some parts of maven seem to expect the TREE layout (e.g. parent POMs are sometimes looked up at ../pom.xml). I personally prefer the TREE variant. Especially if someone only wants to checkout and work on a sub-project this makes it way easier! But because I got into heavy trouble with maven I changed to the FLAT variant (what caused a lot of stupid work). I could not find any offical documentation about this toppic. My personal oppinion is that maven should support both ways (without heavy customization). The problem is that there are lots of plugins heavily involved in this issue (maven-release-plugin, all the reports such as the source repository, etc) and the maven-core itself. So what do you think about this one? Take care Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFEtXmnmPuec2Dcv/8RAro1AJjOTcE8zTE0+9zIasxYo6MRmuX6AJ9NgmIZ P98hl7J0gp8mRI3rHl4SEA== =g9rO -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to use freshly compiled surefire junit runner
you will need fetch maven-surefire-plugin source and makesure it uses the surefire components snapshot ( mostlikely it is already done so) after that new binary kicks in automatically try mvn -X -Dan On 7/12/06, berndq [EMAIL PROTECTED] wrote: Hi all, i can compile the surefire sources from svn (http://svn.apache.org/repos/asf/maven/surefire/trunk) and run mvn install succesfully to get it into the local repository: [INFO] Installing D:\maven\surefire-trunk\surefire-providers\surefire-junit\target\surefire-junit-2. 1-SNAPSHOT.jar to C:\xxx\.m2\repository\org\apache\maven\surefire\surefi re-junit\2.1-SNAPSHOT\surefire-junit-2.1-SNAPSHOT.jar ... [INFO] BUILD SUCCESSFUL But I could not figure out how to use this snapshot from another project. What would I need to add to the pom? thanks! Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to use freshly compiled surefire junit runner
User question. Please post it to the users list. BTW, did you try: dependency groupIdorg.apache.maven.surefire/groupId artifactIdsurefire-junit/artifactId version2.1-SNAPSHOT/version /dependency Cheers, Vincent 2006/7/12, berndq [EMAIL PROTECTED]: Hi all, i can compile the surefire sources from svn (http://svn.apache.org/repos/asf/maven/surefire/trunk) and run mvn install succesfully to get it into the local repository: [INFO] Installing D:\maven\surefire-trunk\surefire-providers\surefire-junit\target\surefire-junit-2. 1-SNAPSHOT.jar to C:\xxx\.m2\repository\org\apache\maven\surefire\surefi re-junit\2.1-SNAPSHOT\surefire-junit-2.1-SNAPSHOT.jar ... [INFO] BUILD SUCCESSFUL But I could not figure out how to use this snapshot from another project. What would I need to add to the pom? thanks! Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Plugins can't be built!
Hi all Someone seems to have broken something in the trunk. A lot of plugins are failing in continuum. They all have similar error messages. Does anyone know what might be wrong? I get the same error when I try to build the plugins locally. I'm not sure if this is true for all plugins, but the ones I have tried so far all fail: javadoc, jar, source, deploy. [INFO] [plugin:descriptor] [INFO] Using 2 extractors. [INFO] Applying extractor for language: java [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V [INFO] [INFO] Trace java.lang.NoSuchMethodError: org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.extractParameters(JavaMojoDescriptorExtractor.java:431) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.createMojoDescriptor(JavaMojoDescriptorExtractor.java:303) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.java:500) at org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:69) at org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:99) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to use freshly compiled surefire junit runner
dan tran wrote: you will need fetch maven-surefire-plugin source and makesure it uses the surefire components snapshot ( mostlikely it is already done so) after that new binary kicks in automatically that worked, thanks! Bernd try mvn -X -Dan On 7/12/06, berndq [EMAIL PROTECTED] wrote: Hi all, i can compile the surefire sources from svn (http://svn.apache.org/repos/asf/maven/surefire/trunk) and run mvn install succesfully to get it into the local repository: [INFO] Installing D:\maven\surefire-trunk\surefire-providers\surefire-junit\target\surefire-junit-2. 1-SNAPSHOT.jar to C:\xxx\.m2\repository\org\apache\maven\surefire\surefi re-junit\2.1-SNAPSHOT\surefire-junit-2.1-SNAPSHOT.jar ... [INFO] BUILD SUCCESSFUL But I could not figure out how to use this snapshot from another project. What would I need to add to the pom? thanks! Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to use freshly compiled surefire junit runner
Vincent Siveton wrote: User question. Please post it to the users list. ok, sorry, was not sure where to post. BTW, did you try: dependency groupIdorg.apache.maven.surefire/groupId artifactIdsurefire-junit/artifactId version2.1-SNAPSHOT/version /dependency did not help, but Dan's answer did, anyway, thanks and sorry for the noise Bernd Cheers, Vincent 2006/7/12, berndq [EMAIL PROTECTED]: Hi all, i can compile the surefire sources from svn (http://svn.apache.org/repos/asf/maven/surefire/trunk) and run mvn install succesfully to get it into the local repository: [INFO] Installing D:\maven\surefire-trunk\surefire-providers\surefire-junit\target\surefire-junit-2. 1-SNAPSHOT.jar to C:\xxx\.m2\repository\org\apache\maven\surefire\surefi re-junit\2.1-SNAPSHOT\surefire-junit-2.1-SNAPSHOT.jar ... [INFO] BUILD SUCCESSFUL But I could not figure out how to use this snapshot from another project. What would I need to add to the pom? thanks! Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugins can't be built!
Hi, I have seen this one ... long time ago! Can you rename/remove the folder that maps to org.apache.maven groupId in your local repo, and try building again. I think its coming from an old version of a library Cheers, Rahul Dennis Lundberg wrote: Hi all Someone seems to have broken something in the trunk. A lot of plugins are failing in continuum. They all have similar error messages. Does anyone know what might be wrong? I get the same error when I try to build the plugins locally. I'm not sure if this is true for all plugins, but the ones I have tried so far all fail: javadoc, jar, source, deploy. [INFO] [plugin:descriptor] [INFO] Using 2 extractors. [INFO] Applying extractor for language: java [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V [INFO] [INFO] Trace java.lang.NoSuchMethodError: org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.extractParameters(JavaMojoDescriptorExtractor.java:431) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.createMojoDescriptor(JavaMojoDescriptorExtractor.java:303) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.java:500) at org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:69) at org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:99) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugins can't be built!
I went back and checked my session to see what happened just before things stopped working. Here's what I found: Downloading: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/maven-plugin-tools-java/2.0.5-SNAPSHOT/maven-plugin-tools-java-2.0.5-20060712.135652-2.jar 10K downloaded Downloading: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/maven-plugin-tools-beanshell/2.0.5-SNAPSHOT/maven-plugin-tools-beanshell-2.0.5-20060712.135652-2.jar 9K downloaded Downloading: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/maven-plugin-tools-api/2.0.5-SNAPSHOT/maven-plugin-tools-api-2.0.5-20060712.135652-4.jar 25K downloaded Dennis Lundberg wrote: Hi all Someone seems to have broken something in the trunk. A lot of plugins are failing in continuum. They all have similar error messages. Does anyone know what might be wrong? I get the same error when I try to build the plugins locally. I'm not sure if this is true for all plugins, but the ones I have tried so far all fail: javadoc, jar, source, deploy. [INFO] [plugin:descriptor] [INFO] Using 2 extractors. [INFO] Applying extractor for language: java [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V [INFO] [INFO] Trace java.lang.NoSuchMethodError: org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.extractParameters(JavaMojoDescriptorExtractor.java:431) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.createMojoDescriptor(JavaMojoDescriptorExtractor.java:303) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.java:500) at org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:69) at org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:99) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Layout of multiproject projects
The TREE layout is recommended... the plugins are laid-out flat bec they are all plugins which means they all have a single parent. No use for a sub-parent for now... but there have been talks of categorizing the plugins which maybe a good cause for sub-parents with their own children. Joerg Hohwiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have a complex maven project that goes down to 3 levels of POM inheritance (= it has sub-sub-projects). I am not really sure about what the suggested layout is: TREE: trunk/ trunk/foo-project/pom.xml trunk/foo-project/foo-project-util/pom.xml trunk/foo-project/foo-project-service/pom.xml trunk/foo-project/foo-project-service/foo-project-service-core/pom.xml trunk/foo-project/foo-project-service/foo-project-service-main/pom.xml or FLAT: trunk/ trunk/foo-project/pom.xml trunk/foo-project-util/pom.xml trunk/foo-project-service/pom.xml trunk/foo-project-service-core/pom.xml trunk/foo-project-service-main/pom.xml As it seems by most plugins the FLAT layout is required for them to work. On the other hand some parts of maven seem to expect the TREE layout (e.g. parent POMs are sometimes looked up at ../pom.xml). I personally prefer the TREE variant. Especially if someone only wants to checkout and work on a sub-project this makes it way easier! But because I got into heavy trouble with maven I changed to the FLAT variant (what caused a lot of stupid work). I could not find any offical documentation about this toppic. My personal oppinion is that maven should support both ways (without heavy customization). The problem is that there are lots of plugins heavily involved in this issue (maven-release-plugin, all the reports such as the source repository, etc) and the maven-core itself. So what do you think about this one? Take care Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFEtXmnmPuec2Dcv/8RAro1AJjOTcE8zTE0+9zIasxYo6MRmuX6AJ9NgmIZ P98hl7J0gp8mRI3rHl4SEA== =g9rO -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review the documentation for the maven-jar-plugin
The Introduction (index.html) have two. Dennis Lundberg wrote: Thanks for the review Edwin. Which place are you referring to? Edwin Punzalan wrote: I think I remember that we should be using Maven instead of Maven 2. Aside from that, everything's just great. ^_^ Dennis Lundberg wrote: Hi all I have finished going over the documentation for the maven-jar-plugin. I hope you can spare a moment and read through it. This is what I have done: [MJAR-46] Document manifestFile element in configuration [MJAR-47] maven-jar-plugin documentation should point to additional documentation, such as manifest guide [MJAR-48] Review plugin documentation - Add FAQ - Add links to the Javadocs for MavenArchiveConfiguration - Restructured the documentation according to the new guidelines for plugins - Review all the parameters to ensure they have good docs - Use the new and improved plugin report A staged site is available for browsing here: http://people.apache.org/~dennisl/maven-jar-plugin/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugins can't be built!
I remember submitting patches to maven-plugin-tools-java and maven-plugin-tools-api to reformat the plugin parameter pages... those updates could be them. ^_^ Dennis Lundberg wrote: I went back and checked my session to see what happened just before things stopped working. Here's what I found: Downloading: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/maven-plugin-tools-java/2.0.5-SNAPSHOT/maven-plugin-tools-java-2.0.5-20060712.135652-2.jar 10K downloaded Downloading: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/maven-plugin-tools-beanshell/2.0.5-SNAPSHOT/maven-plugin-tools-beanshell-2.0.5-20060712.135652-2.jar 9K downloaded Downloading: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/maven-plugin-tools-api/2.0.5-SNAPSHOT/maven-plugin-tools-api-2.0.5-20060712.135652-4.jar 25K downloaded Dennis Lundberg wrote: Hi all Someone seems to have broken something in the trunk. A lot of plugins are failing in continuum. They all have similar error messages. Does anyone know what might be wrong? I get the same error when I try to build the plugins locally. I'm not sure if this is true for all plugins, but the ones I have tried so far all fail: javadoc, jar, source, deploy. [INFO] [plugin:descriptor] [INFO] Using 2 extractors. [INFO] Applying extractor for language: java [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V [INFO] [INFO] Trace java.lang.NoSuchMethodError: org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.extractParameters(JavaMojoDescriptorExtractor.java:431) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.createMojoDescriptor(JavaMojoDescriptorExtractor.java:303) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.java:500) at org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:69) at org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:99) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven dependecies
Hi, congratulations on your work with Maven 2.0... I'm not sure if I understand your questions(s) correctly... so I'm just going to point you to jira. It holds the future features aside from bugs, so if you see the feature you want there, then you can vote for it. Otherwise, you can create an issue and ask for the feature. The IRC channel is also a great place to ask these. Joerg Hohwiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Maven2 really rocks! I figured out a way to build a plugin that allows solaris as packaging and builds a solaris package for a maven project. Therefore I add the complete static content of the package to the main/resources. Further I have a filtered resources directory where I add files with variables to be replaced during the build (pkginfo, prototype-template, and configuration content of the package). As compile phase I add the dependent artifacts to the package at a configurable directory. Finally I build the solaris package with an ant script using the maven-antrun-plugin. Now I have two questions/suggestions/...? 1. The maven resources plugin does NOT copy empty directories (as it seems to me). Now I am so happy with subversion that I can have empty directories and also be able to maintain them. In this case I still have to add the good olds ignore.txt files to empty directories so they are included in the package. Is there a way to make the maven resources plugin to copy empty directories? 2. To add the dependencies to the package I added the dependency on my maven software modules and used the maven-dependency-plugin to copy the artifacts. Now I came into trouble with maintainance because I want to have my software split in multiple packages. One is containing the thirdparty stuff (lest call it PKG-EXT) and another I containing my custom code (PKG-CUST). Therefore I would need to have the following dependency in PKG-EXT: dependency groupIdmy.foo.id/groupId artifactIdmy-master-app/artifactId version1.0/version excludes exclude groupIdmy.foo.id/groupId artifactIdmy-utils/artifactId /exclude exclude groupIdmy.foo.id/groupId artifactIdmy-core/artifactId /exclude exclude groupIdmy.foo.id/groupId artifactIdmy-master-app/artifactId /exclude ... /excludes /dependency Besides the fact that it does NOT work to exclude the dependency itself, I would need to maintain this whenever the dependencies of my modules change. Additionally I would need to add all the excluded dependencies including their versions as dependencies to PKG-CUST. Now here is what I did (as a brute HACK) to solve my problem: I wrote a maven plugin (the MOJO stuff and maven APIs are really cool - easy to get quick results) that acts as the maven-depdencies-plugin but allows to have * as artifactId in an the exclusion. For the PKG-CUST package I use the plugin with inverted logic. Surprisingly you are still here reading. My questions are now: Will maven support something like this by default one day? If not will my HACK still work in further releases or can it happen that the verification gets updated and my pom becomes invalid because * is no vaild artifactId anymore? Thank you for reading this. I hope to get an answer. BTW: the plexus/components.xml was really hard to figure out. Is there any documentation that I missed? Should I write a mini xdoc about what I figured out about how to create your own packaging? Are you interested in a maven-solaris-package-plugin ? If there is a real solution for my HACK I would love to donate the plugin to maven. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEtXVHmPuec2Dcv/8RAueyAJ0YL1fw2yyyDsQu/my62slM6j6b0gCfdG9T TwwchCw+fVe6Yl+BQj0gZEA= =AJ7l -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review maven-idea-plugin documentation
hahaha nice catches especially on the number of goals ^_^ I'll update them... thanks. Dennis Lundberg wrote: Edwin Punzalan wrote: I've just finished updating the documentation for the maven-idea-plugin. Your feedback is highly appreciated. Thanks. Here are my comments: All - IntelliJ Idea - IntelliJ IDEA and Idea - IDEA in lots of places. Search for it. index.html - The IDEA Plugin has four goals. - The IDEA Plugin has five goals. plugin-info.html - idea:idea goal: .ipr and .iws files - .ipr, .iml and .iws files usage.html - create just the one of - create just one of library.html - The context of libraries is a bit vague. Is this something that you put on the command line, in the configuration section of the pom or elsewhere? Ah, when I read the examples I found it in examples/customize_libraries.html. A link to that page would be nice. examples/attach_library_src_doc.html - if one prefers - if you prefer examples/prevent_module_references.html - can choose do so - can choose to do so - linkModulestrue/linkModules - linkModulesfalse/linkModules examples/provide_deployment_descriptor_file.html - Just out of curiosity, what would happen if you have a project with one ejb module and one war module? Would the two modules get the same descriptor file? examples/*.html - Change the filenames to the dictated filename standard: like-this.apt instead of like_this.apt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Outstanding Repository Maintenance: Evangelism
Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (25 issues) Subscriber: mavendevlist Key Summary MEV-392 bad dependencies in commons-logging-1.1.pom http://jira.codehaus.org/browse/MEV-392 MEV-296 Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables http://jira.codehaus.org/browse/MEV-296 MEV-413 Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5) http://jira.codehaus.org/browse/MEV-413 MEV-405 pom for cactus:cactus:13-1.7.2 http://jira.codehaus.org/browse/MEV-405 MEV-404 pom for cactus:cactus-ant:13-1.7.2 http://jira.codehaus.org/browse/MEV-404 MEV-401 Incoherences / duplication between javax.xml and com.sun.xml http://jira.codehaus.org/browse/MEV-401 MEV-334 Stax POM points to an invalid XMLBeans dependency http://jira.codehaus.org/browse/MEV-334 MEV-384 velocity 1.4 dependencies are wrong http://jira.codehaus.org/browse/MEV-384 MEV-375 Relocate xpp to xpp3 http://jira.codehaus.org/browse/MEV-375 MEV-364 Fix dependencies of common-lang 1.0 (add test scope for junit) http://jira.codehaus.org/browse/MEV-364 MEV-352 Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib http://jira.codehaus.org/browse/MEV-352 MEV-356 Missing dep on jboss-common in jbossmq-client jnp-client 4.0.2 http://jira.codehaus.org/browse/MEV-356 MEV-351 xmlc-xerces-2.2.7.1.jar is unnecessary and xmlc-apis.jar is required. http://jira.codehaus.org/browse/MEV-351 MEV-337 OJB 1.0.4 has a number of dependencies that should be optional http://jira.codehaus.org/browse/MEV-337 MEV-330 WebWork 2.2.1 POM should list FreeMarker as a dependency since it's required for plain ol' JSPs http://jira.codehaus.org/browse/MEV-330 MEV-325 Description of jaxb-api 1.0.1 is wrong http://jira.codehaus.org/browse/MEV-325 MEV-320 Hibernate 3.1.x POMs pull in Sun jars http://jira.codehaus.org/browse/MEV-320 MEV-201 should have dependency on org.relaxngdatatype.relaxngDatatype http://jira.codehaus.org/browse/MEV-201 MEV-173 xmlpull JARs exist in two different places on ibiblio http://jira.codehaus.org/browse/MEV-173 MEV-48 openejb poms http://jira.codehaus.org/browse/MEV-48 MEV-45 Full list of poms that doesn't respect the m2 format http://jira.codehaus.org/browse/MEV-45 MEV-36 Exo POM(s) missing dependency versions http://jira.codehaus.org/browse/MEV-36 MEV-33 XOM POM references xercesImpl v.2.2.1 which does not exist in repo http://jira.codehaus.org/browse/MEV-33 MEV-31 XOM POM references xmlParserAPIs v2.6.1 which is not in the repo http://jira.codehaus.org/browse/MEV-31 MEV-20 clean up bad IDs in the repository http://jira.codehaus.org/browse/MEV-20 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Outstanding Repository Maintenance: Uploads
Issue Subscription Filter: Outstanding Repository Maintenance: Uploads (8 issues) Subscriber: mavendevlist Key Summary MAVENUPLOAD-986jsontools-log4j-1.2 http://jira.codehaus.org/browse/MAVENUPLOAD-986 MAVENUPLOAD-985jsontools-core-1.2 http://jira.codehaus.org/browse/MAVENUPLOAD-985 MAVENUPLOAD-984Please upload Connector/J 5.0.2 http://jira.codehaus.org/browse/MAVENUPLOAD-984 MAVENUPLOAD-966Upload Retroweaver 1.2.3 http://jira.codehaus.org/browse/MAVENUPLOAD-966 MAVENUPLOAD-982Relocate jWebUnit and upload 1.3-rc2 http://jira.codehaus.org/browse/MAVENUPLOAD-982 MAVENUPLOAD-978Upload ejb-3.0-public-draft-20060502 (needed for hibernate) http://jira.codehaus.org/browse/MAVENUPLOAD-978 MAVENUPLOAD-976Please upload SUN Java 1.2 rutime http://jira.codehaus.org/browse/MAVENUPLOAD-976 MAVENUPLOAD-789Tomcat 5.5.15 poms for existing jars http://jira.codehaus.org/browse/MAVENUPLOAD-789 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugins can't be built!
This shouldn't have broken - needs investigation. A while back, we agreed to add a feature to 2.0.5 (the implementation attribute). The plugin plugin was updated to use the new tools and such. However, it also has a prereq of maven 2.0.5, so maven 2.0.4 and below which give this error should use the previous version of the plugin. - Brett On 13/07/2006 9:45 AM, Edwin Punzalan wrote: I remember submitting patches to maven-plugin-tools-java and maven-plugin-tools-api to reformat the plugin parameter pages... those updates could be them. ^_^ Dennis Lundberg wrote: I went back and checked my session to see what happened just before things stopped working. Here's what I found: Downloading: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/maven-plugin-tools-java/2.0.5-SNAPSHOT/maven-plugin-tools-java-2.0.5-20060712.135652-2.jar 10K downloaded Downloading: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/maven-plugin-tools-beanshell/2.0.5-SNAPSHOT/maven-plugin-tools-beanshell-2.0.5-20060712.135652-2.jar 9K downloaded Downloading: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/maven-plugin-tools-api/2.0.5-SNAPSHOT/maven-plugin-tools-api-2.0.5-20060712.135652-4.jar 25K downloaded Dennis Lundberg wrote: Hi all Someone seems to have broken something in the trunk. A lot of plugins are failing in continuum. They all have similar error messages. Does anyone know what might be wrong? I get the same error when I try to build the plugins locally. I'm not sure if this is true for all plugins, but the ones I have tried so far all fail: javadoc, jar, source, deploy. [INFO] [plugin:descriptor] [INFO] Using 2 extractors. [INFO] Applying extractor for language: java [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V [INFO] [INFO] Trace java.lang.NoSuchMethodError: org.apache.maven.plugin.descriptor.Parameter.setImplementation(Ljava/lang/String;)V at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.extractParameters(JavaMojoDescriptorExtractor.java:431) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.createMojoDescriptor(JavaMojoDescriptorExtractor.java:303) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.java:500) at org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:69) at org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:99) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default Filtered Resources Directory
I think this has already been suggested in JIRA, but if not it is worth adding. - Brett On 13/07/2006 7:48 AM, Joerg Hohwiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I read about the Super-POM at: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html My question is now, if it was possible to add an additional resources directory that is filtered. It would not hurt anybody if he does not use it, but it would be very handy to have it as default. My suggestion would be to add: resource directorysrc/main/templates/directory filteringtrue/filtering /resource You could also name it filtered-resources or whatever. I dont realy care about the name of the directory - I just would love to have a standard defined by maven. You can also add the same directive for src/test. - From your examples (http://maven.apache.org/guides/getting-started/index.html) people can get the idea to change the resources directory to be filtered. I actually do NOT think that this is a good idea. My problem is that I have to override the complete resources directive to add this AND the maven philosophy is to have a standard directory layout and the need for very little configuration. Wouldn't this be a good idea? Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEtW5DmPuec2Dcv/8RAoWHAJ4g3G/CKeyfcAiHCqkQPmTbsuRudACfXssO sU1NmJjl8BFnBOSMgROz1hY= =HD+O -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HTTP compression (http://jira.codehaus.org/browse/WAGON-55)
I tried posting this to the WAGON mailing list, but there doesn't seem to be
any activity over there...
I've posted some attachments to the JIRA issue WAGON-55 [1] to implement
support for accepting GZip-based compression with HTTP GETs for HTTP and
WebDAV. I'm hoping these simple changes can help to reduce some bandwidth
needs. I've seen some significant gains from my personal testing.
In any case, a major barrier to getting these patches approved and applied
is the lack of unit tests. I was able to test these patches myself using an
Apache HTTPD server and mod_deflate, but couldn't quite figure out the best
way to test in the JUnits. I tried setting up a Jetty embedded server and I
was able to get a test to execute, but I couldn't get Jetty to compress the
responses. Here's the test method I had so far trying to do this. If anyone
knows how to get this compressing the response, please let me know. Also,
any comments or suggestions on getting this test massaged to use the base
classes embedded server would be appreciated as well.
public void testGzipGet()
throws Exception
{
HttpServer server = new HttpServer();
SocketListener listener = new SocketListener();
listener.setPort(10008);
server.addListener(listener);
HttpContext context = new HttpContext();
context.setContextPath(/);
context.setResourceBase(c:/temp/);
ResourceHandler rh = new ResourceHandler();
//The javadoc for these methods is confusing, does this compress
the response?
rh.setMinGzipLength(1);
context.addHandler(rh);
server.addContext(context);
server.start();
try
{
HttpWagon wagon = new HttpWagon();
Repository repo = new Repository();
repo.setUrl(http://localhost:8080;);
repo.setId(gzip-temp);
wagon.connect(repo);
wagon.get(hello.txt, new File(c:/temp/hello-copy.txt));
wagon.disconnect();
}
finally
{
server.stop();
}
}
Thanks,
-Nathan Beyer
[1] http://jira.codehaus.org/browse/WAGON-55 [Provide support for HTTP
compression (request and response)]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review of install plugin
Hi Dennis, Thanks for the comments. will fix immediately. allan Dennis Lundberg wrote: Allan Ramirez wrote: Hi everyone, Just updated the docs of the install plugin. I hope you dont mind if you take a look and give me some feedback about it. Thanks Cheers, allan Here are my comments: site.xml - Missing the Goals link in the overview section. **/*.html - Remove the text Maven 2 Install Plugin from the titles. The title is picked up from the project name in site.xml - In the example documents, the title and heading are not equal. index.html - Change the title to Introduction usage.html - install:install goal doesnt - the install:install goal doesn't - overriden - overridden - Maven assumes the file is the main artifact for the project. Is this the same as packaging then? faq.html - It's empty... examples/update-release-info.html - Updating the release information changes the project's maven-metadata.xml in the local repository, forcing the current installed version as the latest release version. I'm sorry, but I don't understand what this means :( install-mojo.html - createChecksum param: Flag whether - Whether - updateReleaseInfo param: No default value? It's a boolean. install-file-mojo.html - All parameters but file are optional. Well that's not really true. This problem might occur in other plugins as well. IIUC you have to use *either* pomFile *or* groupId/artifactId/version. How do we document that? - generatePom param: No default value? It's a boolean. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum 1.1 roadmap
rahul and I chatted last night on irc a bit and I cobbled this together as an example using the Security page that carlos put together and the mailing list thread.. http://docs.codehaus.org/display/CONTINUUM/CPSI+-+Security+Model so, does anyone see the value in this more formal approach? I rather like it, not for everything but some of the items on the roadmap it could be really useful.. namely: large project useability Build on Dependency changes Project Groups etc... jesse On 7/12/06, Jesse McConnell [EMAIL PROTECTED] wrote: it disappeared into the ether of the mailing list? :) I still think its a good idea, thanks for bringing it back up...could be very useful on some of the larger issues like security and project groups, etc.. jesse On 7/12/06, Rinku [EMAIL PROTECTED] wrote: Hi, Just wondering what happened to this idea: http://www.nabble.com/2.1-Design-and-Process-tf1617559.html#a4383722 Cheers, Rahul Jesse McConnell wrote: hi everyone, I have been trying to help emmanuel some with pulling together the roadmap for Continuum 1.1 on the wiki and maybe help organize some of the discussions on there. I wanted to get out the url to the wiki roadmap and maybe see how you guys feel about the content on it. I tried to pull out some of the important things from the 170 + issues in jira currently slated for 1.1 and also the roadmap thread that started on this mailing list last month. so..any thoughts and improvements would be much appreciated, I was kinda hoping I could get a somewhat definitive list of the major hotbutton items for Continuum 1.1 on that roadmap page and then link out the appropriate wiki page or jira ticket. http://docs.codehaus.org/display/CONTINUUM/Continuum+1.1+Development+Roadmap I also reworked the front page a bit...it was sort plain...or empty rather. http://docs.codehaus.org/display/CONTINUUM/Home jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r421484 - /maven/plugins/trunk/maven-plugin-plugin/pom.xml
and the prereq Is there anything on trunk that isn't on the branch? - Brett On 13/07/2006 12:54 PM, [EMAIL PROTECTED] wrote: Author: epunzalan Date: Wed Jul 12 19:54:18 2006 New Revision: 421484 URL: http://svn.apache.org/viewvc?rev=421484view=rev Log: updating the deps to 2.1-SNAPSHOT Modified: maven/plugins/trunk/maven-plugin-plugin/pom.xml Modified: maven/plugins/trunk/maven-plugin-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-plugin-plugin/pom.xml?rev=421484r1=421483r2=421484view=diff == --- maven/plugins/trunk/maven-plugin-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-plugin-plugin/pom.xml Wed Jul 12 19:54:18 2006 @@ -34,7 +34,7 @@ dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-tools-api/artifactId - version2.0.5-SNAPSHOT/version + version2.1-SNAPSHOT/version /dependency dependency groupIdorg.apache.maven/groupId @@ -44,7 +44,7 @@ dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-tools-java/artifactId - version2.0.5-SNAPSHOT/version + version2.1-SNAPSHOT/version scoperuntime/scope /dependency dependency @@ -55,7 +55,7 @@ dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-tools-beanshell/artifactId - version2.0.5-SNAPSHOT/version + version2.1-SNAPSHOT/version scoperuntime/scope /dependency dependency -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: J2EE killer: For multi module builds CLASSPATH != resolved dependencies
Hi Mike Brett, Mike Perham wrote on Wednesday, July 12, 2006 3:18 PM: To test MNG-1245 you can just replace your maven-project-2.0.4.jar in MAVEN_HOME/lib with the SNAPSHOT I attached to the issue and see if the issue goes away or changes. Great. Both issues are also resolved with this SNAPSHOT. I've close the bugs as dups. - Jörg -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 12, 2006 8:07 AM To: Maven Developers List Subject: RE: J2EE killer: For multi module builds CLASSPATH != resolved dependencies Brett Porter wrote on Wednesday, July 12, 2006 2:18 PM: In MNG-2424, you say it may be related to MNG-1245 which is now fixed. Does that correct that issue? I don't know. I have too less knowledge about the classpath generation in Maven and how it is related to the dependencies - escpecially in multi module mode. There have been some classspath related archiver fixes that might help with MEJB-18. MNG-2424 and MEJB-18 is IMHO the same bug. Would fixing both of these resolve your issue? How do I test this best? I don't want to run into troubles for my standard build environment with all kind of snapshot plugins in my repository. It is already quite complex. Nevertheless the attachments in the issues provide a scenario for a test in an environment with a newer Maven snapshot. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] Maven 2.1 Design Topics
John Casey wrote on Wednesday, July 12, 2006 10:41 PM: [snip] ** POM Loading / Building - Running Away from XPP3 [snip] What's wrong with XPP3? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
