Continuum does not provide continous integration
Hi, I'm new tocontinuum and using 1.1-BETA-2 version. I'm using pom.xml files for adding new projects to the continuum. But continuum dont use this pom.xml files instead of this files uses pom.xml files in SCM (we are using subversion for SCM). This dont provide our request. In this case i want to change our subproject versions without any changes in SCM. For example parent project uses 20070904 version of subproject1 in pom.xml in SCM.But while using Continuum i want to change parent project uses this date version of subproject1. As sequence firstly i want to prepare this date version of subprojects and parent project uses this prepared versions. How can i do this?? Any ideas ?? Thanks, Ibrahim -- View this message in context: http://www.nabble.com/Continuum-does-not-provide-continous-integration-tf4384632.html#a12499885 Sent from the Continuum - Dev mailing list archive at Nabble.com.
Re: [vote] Mauro Talevi committer access
+1 -Lukas Brian E. Fox wrote: Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Mauro Talevi committer access
2007/9/5, Brian E. Fox [EMAIL PROTECTED]: Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Maybe I am missing something, but vote for adding a committer shouldn't be made in the private mailing list? Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Embedding issues in JIRA
Hi Jason, You were talking about doing embedder stuff this week - I was just looking at a batch of JIRA issues that you filed for it some time back and wasn't really sure if they were still problems. Could you give that component a once over? Thanks! - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: Cleaning up 2.1.x JIRA
Ok, I started at the bottom and worked up to MNG-1928. I'm starting to get to the point where there is less cruft. I was particularly conservative about things that might be good to have or related to other stuff, and left comments where I could for people to write proposals - I'm sure half of what I left in so far could also be chopped though. I'll carry on again tomorrow... Cheers, Brett On 05/09/2007, at 9:34 AM, Brett Porter wrote: On 05/09/2007, at 5:29 AM, Jason van Zyl wrote: How are you going to decide priority before all the proposals are in? And I would pick features to implement not a 100 arbitrary issues. New features account for about 10-15%, and improvements about 25% (I'm just guessing these from a pie chart). In unscheduled, it's a very small % of new features and about 25% improvements. So I think we can identify what are truly new features and apply the following: - if it is small or related to other things, it stays - if it is a big thing without a proposal, we can suggest they write one But mostly focus on cleaning up other than that.. Handling bug fixes would be fine but anything related to features we can do until all the proposals are in, and then people have to commit to the proposals so that we know they will actually make it into the release as we expect. Yep, no disagreement there. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Mauro Talevi committer access
+1 -Deng On 9/5/07, Brian E. Fox [EMAIL PROTECTED] wrote: Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1
Re: What can possibly go wrong with Maven
Mauro Talevi wrote: - Classloader problems: often difficult to debug them when artifacts are coming from different transitive sources. Would be great to have a better way to display a trace of the dependency tree, without being swamped by all the non-dependency noise. Maybe a new debug flag (different from -X and -e) would help here. You mean something like this? [EMAIL PROTECTED] ~/src/Codehaus/pico/java-2.x/nano/container-bsh $ mvn info:deps-runtime [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'info'. WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building NanoContainer bsh [INFO]task-segment: [info:deps-runtime] [INFO] [INFO] [info:deps-runtime] [INFO] org.nanocontainer:nanocontainer-bsh:jar:2.0-SNAPSHOT [INFO] org.nanocontainer:nanocontainer:jar:2.0-SNAPSHOT [INFO] : org.picocontainer:picocontainer:jar:2.0-SNAPSHOT [INFO] : com.thoughtworks.paranamer:paranamer-asm:jar:1.0.1 [INFO] : com.thoughtworks.paranamer:paranamer:jar:1.0.1 [INFO] : asm:asm:jar:3.0 [INFO] org.beanshell:bsh:jar:2.0b4 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 5 seconds [INFO] Finished at: Wed Sep 05 13:03:28 CEST 2007 [INFO] Final Memory: 3M/6M [INFO] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Mauro Talevi committer access
+1 Raphaêl 2007/9/5, Maria Odea Ching [EMAIL PROTECTED]: +1 -Deng On 9/5/07, Brian E. Fox [EMAIL PROTECTED] wrote: Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1
Re: [vote] Mauro Talevi committer access
+1 Fabrice On 9/5/07, Brian E. Fox [EMAIL PROTECTED] wrote: Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1
Re: [vote] Mauro Talevi committer access
+1 Vincent 2007/9/4, Brian E. Fox [EMAIL PROTECTED]: Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Query on enhancements to SCM VSS provider
Hi I've recently started working with the VSS SCM provider and have found a number of issues. I'm currently working through these and submitting patches via JIRA, however I'm not sure that this project is currently active. Could anyone tell me if enhancements are still being incorporated for SCM and VSS specifically? I think getting the VSS provider working properly make help with adoption of Maven / Continuum into the enterprise (which is certainly what I'm trying to do). Thanks, Allan
Re: [vote] Mauro Talevi committer access
+1 Emmanuel Brian E. Fox a écrit : Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB-client optional in war produces different result (was: Aggregator project war plugin context)
[I wrote:} Sent: Thursday, August 30, 2007 7:29 PM To: dev@maven.apache.org Subject: Aggregator project war plugin context Hi, We have Websphere ejb plugin which we modeled after the existing ejb plugin. (We use the Websphere ejbDeploy command instead to generate stubs, etc.) We are facing an issue related to this posting: http://www.nabble.com/%3Coptional%3Etrue%3C-optional%3E-ignore d-with-build-from-parent-t4349741s177.html#a12393564 It seems the ejb-client dependency comes into the war plugin incorrectly if building from an aggregator project. Since we don't do a lot differently from the existing ejb plugin I'm wondering if this is an issue for both (i can try this later if no one knows off hand.) I have confirmed this issue exists when using the ejb plugin. The optional field is not set when the project is built from the parent project. The root issue is... The iteration in the war plugin's ArtifactsPackagingTask.performPackaging( ...) is finding the the ejb-client artifact optional field false when it is declared true in the web module's pom ... also of interest is the fact that the artifact is of type DefaultArtifact and not of type ActiveProjectArtifact. Don't know if that's the issue... if so maybe that something that the DefaultMavenProjectHelper.attachArtifact should or could handle? I'm having trouble finding where in the Maven code the dependency list is build up for ArtifactsPackagingTask.performPackaging( ...) during execution of a war module in an aggregator project. Or even how I would fix this so that the artifact's optional attribute is correct. Let me know if you have any thoughts on a direction to look in. Right now I'm lost on where to address this. I thought perhaps DefaultMavenProjectHelper needed to attach the ejb-client artifact differently, now I see this probably the wrong direction. I could try to address this in the war plugin by adding an additional step to check the dependency list, but I'm not sure I'll get the optional information here either. Any pointers on how to get the war project's dependencies optional attribute into this attached artifact? Also, I'm not sure where to post the sample project to re-create this. I think I will start with the war plugin? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merging maven-plugin-api and maven-plugin-descriptor in trunk
On 4 Sep 07, at 10:50 PM 4 Sep 07, Jason van Zyl wrote: Hi, I would like to make a single module for plugin execution and this is the first step. The motivator is being able to isolate a version of a plugin apis runtime. These modules do not vary independently in practice and they are not useful separately. I really would like people to look at the top-level source tree and easily see the key moving parts. Any objections? Doesn't seem to be, I'm going to merge these now. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lining up maven-artifact for a release
On 9/3/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 3 Sep 07, at 4:29 PM 3 Sep 07, Brett Porter wrote: On 04/09/2007, at 5:49 AM, Jason van Zyl wrote: Hi, We need to collect all outstanding fixes done on the 2.0.x branch merged into the decoupled version This should hopefully already be the case, I don't believe Mark has done it yet. Don't know what Carlos has done. my changes are in both trunk/artifact and 2.0.x branch I try and keep an eye on merges and flag stuff that isn't going trunk first. Probably a good idea for everyone that's done recent stuff on artifact to check for themselves though - Mark, Carlos? and we need to collect all the filters that are floating around all over the place. I think the filters can be in a separate tree and we can decide what we want to shade in by default but we need to collect this before doing a release. Sorry, bit dense this morning - can you explain why that's needed? To prevent the duplication of filters and to have all related code together. To date I have not seen any filters that are really specific to a particular domain, the all appear to be general in nature. We don't collect them, they will be duplicated. (I understand it's a good thing to get rid of all the duplicate and almost-the-same ones, and m-artifact is the right place - just wondering if that's becoming a requirement for it to work or not). Mark do you want to try and get your changes into the decouple maven-artifact? Would it be better to hold this until after the release since things are pretty stable right now and this might take a bit to integrate? I don't think so, the sooner it goes in the better. It's easy enough to try it with trunk, we can hold off on 2.0.x but I want to try it all with 2.1x ASAP. I will hunt around for filters and make some space in SVN for them. Does this mean m-artifact will be a multi-module project? If the filters depend on m-artifact, I don't see why they need to be separate? Just like providers, but they are not numerous when we collect them (as we might not have many different ones). - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Mauro Talevi committer access
+1 Stéphane On 9/5/07, Brian E. Fox [EMAIL PROTECTED] wrote: Mauro is an existing Apache Committer on the Excalibur project (http://excalibur.apache.org/team-list.html) as well as the mojo project at Codehaus. He has recently been working on the shade plugin currently up for vote to be moved to Apache. As he has demonstrated ability and we can use the help maintaining shade and Maven in general, I'd like to call a vote to add Mauro as a Maven Committer. Vote will be open for 72 hrs. Adopted Project Conventions for new Committer votes: The vote duration should be specified in the mail, but must be a minimum of 72 hours (it may be made longer if there is a weekend or holiday in the middle). Votes on committers should be accepted from all committers on the project. There is no minimum number of votes needed for a vote to pass. The vote is decided by the majority (simply add all the +1's and -1's). Candidates can not be vetoed. Votes can be changed any time while the vote is still open and will supercede the previous vote by an individual. The vote should then be tallied, and if it has passed, the process for adding a new committer is followed. +1 -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB-client optional in war produces different result
It seems the ejb-client dependency comes into the war plugin incorrectly if building from an aggregator project. Since we don't do a lot differently from the existing ejb plugin I'm wondering if this is an issue for both (i can try this later if no one knows off hand.) I think that you are talking about this issue: http://jira.codehaus.org/browse/MNG-2871 It was applied to trunk (2.1-SNAPSHOT). I hope it will be applied to (2.0.x). Thank you, Piotr Tabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-project broken
It's missing a class in maven artifact org.apache.maven.artifact.resolver.ArtifactResolutionRequest Also i can't find the trunk building in Continuum in maven.zones.apache.org, permissions issue? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedder Configuration Changes
I don't quite get it, are you talking about the method ConfigurationValidationResult validateConfiguration( Configuration configuration ) in the embedder? I changed it to store the settings (if there is no error) and the exception (if there is). Before there was no way to know what the problem with the settings was. Couple of comments about the other changes made: * ConfigurationValidationResult changed Throwable to Exception, although in other places like MavenExecutionResult Throwable is being used * setters in interfaces Do we really want setters in the interfaces (MavenExecutionRequest, MavenExecutionResult,...). I don't think they should be there, only in the implementations. On 9/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: Carlos, Please put back the validation methods. I don't want to catch exception to validation user configuration. I want to be able to know exactly what's wrong. I don't need to throw an exception to find out the specific settings are not present and I'm using all these methods extensively. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-project broken
On 5 Sep 07, at 2:11 PM 5 Sep 07, Carlos Sanchez wrote: It's missing a class in maven artifact org.apache.maven.artifact.resolver.ArtifactResolutionRequest It's been sitting there for days: http://svn.apache.org/repos/asf/maven/artifact/trunk/src/main/java/ org/apache/maven/artifact/resolver/ArtifactResolutionRequest.java Also i can't find the trunk building in Continuum in maven.zones.apache.org, permissions issue? I use Hudson and don't go near the Continuum instance. Set up what you like, more checks can't hurt. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedder Configuration Changes
On 5 Sep 07, at 2:49 PM 5 Sep 07, Carlos Sanchez wrote: I don't quite get it, are you talking about the method ConfigurationValidationResult validateConfiguration( Configuration configuration ) in the embedder? I changed it to store the settings (if there is no error) and the exception (if there is). Before there was no way to know what the problem with the settings was. Couple of comments about the other changes made: * ConfigurationValidationResult changed Throwable to Exception, although in other places like MavenExecutionResult Throwable is being used * setters in interfaces Do we really want setters in the interfaces (MavenExecutionRequest, MavenExecutionResult,...). I don't think they should be there, only in the implementations. You can't force people to do: MavenExecutionRequest request = new DefaultMavenExecutionRequest() .setBaseDirectory( baseDirectory ) .setGoals( goals ); and not allow MavenExecutionRequest request = new DefaultMavenExecutionRequest(); request.setBaseDirectory( baseDirectory ); // won't work request.Goals( goals ); // won't work So yes, I do want them. On 9/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: Carlos, Please put back the validation methods. I don't want to catch exception to validation user configuration. I want to be able to know exactly what's wrong. I don't need to throw an exception to find out the specific settings are not present and I'm using all these methods extensively. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
resolving pluginArtifacts.
Hey, I'm trying to use pluginArtifacts to include the current plugin's jar as a classpath for an external call, as I have created a crazy but necessary wrapper. When I go to find the plugin in pluginArtifacts, I find that I cannot, and that pluginArtifacts is not populated on MavenProject. Is there metadata I'm missing that I have to set that causes maven to populate this on this.project? you know, the equivalent of @resolveDependencies. Christian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merging maven-plugin-api and maven-plugin-descriptor in trunk
On 06/09/2007, at 4:21 AM, Jason van Zyl wrote: On 4 Sep 07, at 10:50 PM 4 Sep 07, Jason van Zyl wrote: Hi, I would like to make a single module for plugin execution and this is the first step. The motivator is being able to isolate a version of a plugin apis runtime. These modules do not vary independently in practice and they are not useful separately. I really would like people to look at the top-level source tree and easily see the key moving parts. Any objections? Doesn't seem to be, I'm going to merge these now. Sorry, only just got around to this mail. This will introduce a dependency on the plexus container and maven- artifact for every single plugin - is that really desirable? Currently, the plugins can depend on the API without needing the plugin descriptor (which is basically used by tooling and the maven internals). Seems best separated to me. Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-project broken
On 06/09/2007, at 7:11 AM, Carlos Sanchez wrote: Also i can't find the trunk building in Continuum in maven.zones.apache.org, permissions issue? I think Emmanuel removed it because half the modules had been removed from SVN and weren't building - he probably will add it back in again shortly. Emmanuel - is that right? - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedder Configuration Changes
On 9/5/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 5 Sep 07, at 2:49 PM 5 Sep 07, Carlos Sanchez wrote: I don't quite get it, are you talking about the method ConfigurationValidationResult validateConfiguration( Configuration configuration ) in the embedder? I changed it to store the settings (if there is no error) and the exception (if there is). Before there was no way to know what the problem with the settings was. Couple of comments about the other changes made: * ConfigurationValidationResult changed Throwable to Exception, although in other places like MavenExecutionResult Throwable is being used * setters in interfaces Do we really want setters in the interfaces (MavenExecutionRequest, MavenExecutionResult,...). I don't think they should be there, only in the implementations. You can't force people to do: MavenExecutionRequest request = new DefaultMavenExecutionRequest() .setBaseDirectory( baseDirectory ) .setGoals( goals ); and not allow MavenExecutionRequest request = new DefaultMavenExecutionRequest(); request.setBaseDirectory( baseDirectory ); // won't work request.Goals( goals ); // won't work So yes, I do want them. You can do DefaultMavenExecutionRequest request = new DefaultMavenExecutionRequest(); request.setBaseDirectory( baseDirectory ); request.Goals( goals ); and then pass it around as MavenExecutionRequest. The fact that they are needed to create an instance doesn't mean that they are needed in the interface, it should be used to query for information, not to provide it. If for instance you want another implementation of the MavenExecutionRequest with some default values or one that will query other objects for them you are forcing the implementation to have empty setters. what about the other questions? On 9/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: Carlos, Please put back the validation methods. I don't want to catch exception to validation user configuration. I want to be able to know exactly what's wrong. I don't need to throw an exception to find out the specific settings are not present and I'm using all these methods extensively. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-project broken
for some reason my working copy didn't update properly, clean made it work I've tried to add it myself but i get SQL Exception: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'PROJECTGROUP_PK' defined on 'PROJECTGROUP'. I wonder if it's already there wth wrong permissions On 9/5/07, Brett Porter [EMAIL PROTECTED] wrote: On 06/09/2007, at 7:11 AM, Carlos Sanchez wrote: Also i can't find the trunk building in Continuum in maven.zones.apache.org, permissions issue? I think Emmanuel removed it because half the modules had been removed from SVN and weren't building - he probably will add it back in again shortly. Emmanuel - is that right? - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedder Configuration Changes
On 5 Sep 07, at 4:01 PM 5 Sep 07, Carlos Sanchez wrote: You can do DefaultMavenExecutionRequest request = new DefaultMavenExecutionRequest(); request.setBaseDirectory( baseDirectory ); request.Goals( goals ); and then pass it around as MavenExecutionRequest. The fact that they are needed to create an instance doesn't mean that they are needed in the interface, it should be used to query for information, not to provide it. I have already in cases because of coupling, required setting something beyond the requests instantiation. This optimally should not be the case but isn't the case right now. If for instance you want another implementation of the MavenExecutionRequest with some default values or one that will query other objects for them you are forcing the implementation to have empty setters. Do you actually have one? All the use I've seen takes the request object and populates it according to their needs. I'll answer the other questions in another thread. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merging maven-plugin-api and maven-plugin-descriptor in trunk
On 5 Sep 07, at 3:43 PM 5 Sep 07, Brett Porter wrote: On 06/09/2007, at 4:21 AM, Jason van Zyl wrote: On 4 Sep 07, at 10:50 PM 4 Sep 07, Jason van Zyl wrote: Hi, I would like to make a single module for plugin execution and this is the first step. The motivator is being able to isolate a version of a plugin apis runtime. These modules do not vary independently in practice and they are not useful separately. I really would like people to look at the top-level source tree and easily see the key moving parts. Any objections? Doesn't seem to be, I'm going to merge these now. Sorry, only just got around to this mail. This will introduce a dependency on the plexus container and maven- artifact for every single plugin - is that really desirable? No it won't introduce a dependency because they aren't going to be there. Focus on the motivation to isolate the complete runtime, the few files in the descriptor who cares about. No one is going to see them. The descriptor shouldn't be coupled to plexus or maven artifact either but I'm going to remove them. Plugins will still only need to depend on the plugin api which has, and will continue to have, no dependencies. Currently, the plugins can depend on the API without needing the plugin descriptor (which is basically used by tooling and the maven internals). Seems best separated to me. Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merging maven-plugin-api and maven-plugin-descriptor in trunk
On 5 Sep 07, at 3:43 PM 5 Sep 07, Brett Porter wrote: On 06/09/2007, at 4:21 AM, Jason van Zyl wrote: On 4 Sep 07, at 10:50 PM 4 Sep 07, Jason van Zyl wrote: Hi, I would like to make a single module for plugin execution and this is the first step. The motivator is being able to isolate a version of a plugin apis runtime. These modules do not vary independently in practice and they are not useful separately. I really would like people to look at the top-level source tree and easily see the key moving parts. Any objections? Doesn't seem to be, I'm going to merge these now. Sorry, only just got around to this mail. This will introduce a dependency on the plexus container and maven- artifact for every single plugin - is that really desirable? Currently, the plugins can depend on the API without needing the plugin descriptor (which is basically used by tooling and the maven internals). Seems best separated to me. The other way to think about it is the way anno-mojo is where the metadata model is inherently pushed along with the model and they become tied together. I would like the same for the pre java5. This will actually made working with anno-mojo easier. Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-project broken
Best to wait for Emmanuel - I screwed up the last upgrade and he was kindly fixing the database for me - might still be some left overs :) - Brett On 06/09/2007, at 9:04 AM, Carlos Sanchez wrote: for some reason my working copy didn't update properly, clean made it work I've tried to add it myself but i get SQL Exception: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'PROJECTGROUP_PK' defined on 'PROJECTGROUP'. I wonder if it's already there wth wrong permissions On 9/5/07, Brett Porter [EMAIL PROTECTED] wrote: On 06/09/2007, at 7:11 AM, Carlos Sanchez wrote: Also i can't find the trunk building in Continuum in maven.zones.apache.org, permissions issue? I think Emmanuel removed it because half the modules had been removed from SVN and weren't building - he probably will add it back in again shortly. Emmanuel - is that right? - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merging maven-plugin-api and maven-plugin-descriptor in trunk
On 06/09/2007, at 9:18 AM, Jason van Zyl wrote: Doesn't seem to be, I'm going to merge these now. Sorry, only just got around to this mail. This will introduce a dependency on the plexus container and maven- artifact for every single plugin - is that really desirable? No it won't introduce a dependency because they aren't going to be there. Focus on the motivation to isolate the complete runtime, the few files in the descriptor who cares about. No one is going to see them. The descriptor shouldn't be coupled to plexus or maven artifact either but I'm going to remove them. Plugins will still only need to depend on the plugin api which has, and will continue to have, no dependencies. Cool - if you are doing all that in one hit it totally makes sense. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
pluginDependencies resolution
Hi, I tried to send this earlier, but didn't see it show up anywhere. Anyway, I have a plugin where, for reasons too painful to go into, I have to execute a java class in a new JVM and have the calling plugin's .jar in the classpath. I went to find the appropriate approach to get it from the repo (clearly it's there, or the calling code wouldn't be running), but project.getPluginDependencies() was not populated. Is there an attribute or something I need to put down in the mojo to, say resolvePluginDependencies so that is filled? Or is there a better way to get at the .jar artifact from the present plugin in order to add it to the classpath of the called JVM? thanks, Christian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pluginDependencies resolution
Hmm. Sorry, I meant pluginArtifacts, not pluginDependencies. -cg On 9/5/07, Christian Gruber [EMAIL PROTECTED] wrote: Hi, I tried to send this earlier, but didn't see it show up anywhere. Anyway, I have a plugin where, for reasons too painful to go into, I have to execute a java class in a new JVM and have the calling plugin's .jar in the classpath. I went to find the appropriate approach to get it from the repo (clearly it's there, or the calling code wouldn't be running), but project.getPluginDependencies() was not populated. Is there an attribute or something I need to put down in the mojo to, say resolvePluginDependencies so that is filled? Or is there a better way to get at the .jar artifact from the present plugin in order to add it to the classpath of the called JVM? thanks, Christian. -- - Christian Gruber [EMAIL PROTECTED]
Re: resolving pluginArtifacts.
I thought that was available under the parameter expression $
{plugin}, which returns the current plugin's PluginDescriptor
instance...from there, I thought there was an accessor method that
exposed the artifacts used to create that plugin's classpath...
Maybe I'm dreaming, or maybe it's changed...but it might be a place
to start looking.
-john
On Sep 5, 2007, at 6:34 PM, Christian Gruber wrote:
Hey,
I'm trying to use pluginArtifacts to include the current
plugin's jar as a classpath for an external call, as I have created
a crazy but necessary wrapper. When I go to find the plugin in
pluginArtifacts, I find that I cannot, and that pluginArtifacts is
not populated on MavenProject. Is there metadata I'm missing that
I have to set that causes maven to populate this on this.project?
you know, the equivalent of @resolveDependencies.
Christian.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
