RE: Looking for lifecycle execution reusability (building a corporate pom)
I was told today that profiles defined in the profiles.xml are inherited and can be activated selectively in the child modules. I am skeptical, but it's work a look. -Original Message- From: Wouter Hermeling [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 11:39 PM To: dev@maven.apache.org Subject: Looking for lifecycle execution reusability (building a corporate pom) Hi, To make a long story short, i will begin with the questiom: I'm trying to figure out what is the Maven way to do this. How can i put up standards for different kind of poms types (ejb's, assemblies, ears, etc) in a multimodule environment without using different parents? -- The long story -- I'm migrating an entire build environment from ant to maven2 for a company with many, many projects. The most important thing is the corporate pom. This contains all configuration about how to build ejb's, wars, assemblies. This has been put mainly in the pluginManagement section, to be activated by sub poms. Now i'm working on many multimodule projects. The modules have the multimodule project as parent, so we can define properties and dependency(management) for an entire multimodule project. So far so good. However when i setup de poms for modules i still have to explicitly activate all the plugins it needs. For instance, for an assembly module i have to invoke 5 different plugins (1 * dependency:copy-dependencies, 3 * scm:checkout, 1 * assembly:package). Although, the configuration of these plugins are setup in the corporate pom, i still have to activate the plugins in each module. So i'm basically duplicating plugin invocations for each module. I'm trying a way to solve this. Of course i could create different corporate poms, like: 1. corporate assembly pom 2. corporate ear pom 3. ... and let the modules inherit from that. But this disables the reuse of properties and dependencies on in multimodule projects poms. I've tried to following things: 1. Profiles Put plugin invocations in profiles and let modules activate them. -> This does not work. There is no way to activate a profile (defined in the corporate pom) for a specific module. The profile will be activated for all modules or for none. They only way to activate a profile for a specific module, is to define the entire profile in that module. No option. 2. Create different lifecycle Using plexus, creating a new lifecycle with new phases. If i could create new phases, then i could for instance create specific assembly phases and bind plugins to those phases. The lifecycle should be activated by specifying a new kind of pom packaging. -> Creating new phases is not supported by maven (there is only little documentation about this) 3. Create plugins to alter maven If tried creating plugins like ProfileActivators (which inject profiles in specific conditions). -> This does not work. They entire lifecycle execution seems to have been build up in advance. There seems no way to alter this. 4. Write my own plugins to replace the invocation different plugins. -> This is no good. Since plugins/mojo cannot be reused i end up rewriting a lot of plugin code. And rewriting the scm plugin for instance..., just seems to be a bad thing to me. 5. Use the maven-invoker-plugin to let each module invoke itself with a predefined profile. The only plugin in a module would be the invoker plugin. -> This works, but this will startup a new maven reactor for each module. I'm not facing lifecycle issues YET, but also this seems to be a bad thing. -- So to summarize again: I'm trying to figure out what is the Maven way to do this. How can i put up standards for different kind of poms types (ejb's, assemblies, ears, etc) in a multimodule environment without using different parents? Basically i'm looking for lifecycle execution reusability. Define a set of plugin invocations including configuration in a corporate pom. And activate/reuse this lifecycle execution in a specific module, keeping the pom of the module clean. I've also read Deterministic Lifecycle Planning to come with maven 2.1 (can't wait :)) and i'm trying to figure out if that would solve these issues. Can anybody comment on this? -- View this message in context: http://www.nabble.com/Looking-for-lifecycle-execution-reusability-%28bui lding-a-corporate-pom%29-tp15450774s177p15450774.html Sent from the Maven Developers mailing list archive at Nabble.com. - 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: An Attribute Based POM
Does the refactoring of the XML give us any new functionality besides only 'looking better'? And what is the price we pay? Getting non-compatible with existing poms? Someone already mentioned the forward compatibility once 'new' poms get their way into the repos. There are still many companies working with mvn 2.0.4 and lower, which will need the old poms in the public repos. Do we need own public repos then? If so, this would be more the kind of maven-3.0 then. And for the guys calling for more 'textual' poms: back to make? With all the human readable but highly ambiguous syntax. I personally think this is not a good idea at all. Altough I agree that the attributes would have been better if we got them in 4.0.0 format, i also admit that it's imho simply too late. LieGrü, strub --- Tim O'Brien <[EMAIL PROTECTED]> schrieb: > On Feb 12, 2008, at 10:30 AM, John Casey wrote: > > > FWIW, I think as long as we have a standard format for POMs on a > > single remote repository, it doesn't hurt to accommodate all comers > > WRT format. > > > > XML is okay for developers familiar with it to read, but it was > > always intended to be rendered in some way. If we had rendering > > tools to give the user a decent view on the POM, all of these > > arguments would go away, since we could just provide additional > > renderers along with the different parsers. > > > > Also, if we're going to accommodate multiple XML formats (element- > > oriented vs. attribute-oriented) would it make more sense to give a > > hint of which format we're using via processing instruction at the > > top or something similar? If we do this, there could be 2 XML-based > > parsers, or 2000...as long as the shared data in the remote > > repository has a standard format, what's the difference? We can > > control the standard format on the central repository, for one > > thing, and definitely make sure it's as consumable as possible for > > older Maven versions. Others running their own internal repositories > > will have their own concerns WRT POM format, and can set their > > internal policy as they see fit. > > > > Open it up to all formats, but make sure that people know that if they > decide to use a YAML format, they are on there own. Provide easy > tools that allow someone to convert back to the "blessed" format. > > I'll stop picking fights about this, but I understand people's > preference to keep a strict standard. I'm all for it, but I also > think that if someone comes along with the "reduced text-format", > there should be a way for them to plug in a parser or a pre- > processor. Even though it might make it more difficult for people > building out tool support, if someone wanted to do something like > create a binary format, there's nothing stopping them. > > > > -john > > > > On Feb 12, 2008, at 10:55 AM, Tim O'Brien wrote: > > > >> > >> On Feb 12, 2008, at 9:34 AM, Gilles Scokart wrote: > >> > >>> > >>> > -Original Message- > From: Tim O'Brien [mailto:[EMAIL PROTECTED] > Sent: mardi 12 février 2008 16:03 > To: Maven Developers List > Subject: Re: An Attribute Based POM > > > On Feb 12, 2008, at 3:58 AM, Benjamin Bentmann wrote: > > >> For example, we'd can group groupId/artifactId/version into one > >> attribute > >> like this: > >> > >> > > > > Please don't do this. This would require another parsing step > > after > > the XML > > parsing and introduces further error sources. Use XML to structure > > the data, > > not some proprietary format. Third-party tools dealing with the > > POM > > will > > also appreciate a proper/pure XML representation of the project > > model. > > Consider for instance the pain such string aggregates would cause > > for XSLT > > processing of the POM. Merging different pieces of data into a > > single string > > is in general a bad idea. > > > Couldn't disagree more. Certain data has a native format. > Consider > something like a 24 hour time. Is: > > 23:22:22.003 > > an "undue burden" on different parsers? No, this is reasonable. > This would be unreasonable: > > > > The idea that we have to design data around parsers means that you > sacrifice usability and readability. > > I'd take it one step further than Emmanuel: > > > > > > > Should be: > > > maven-project:2.0.8 > continuum:continuum-model:1.1 > > > XSLT can tokenize strings just fine. > > >>> > >>> > >>> Than why to use XML? Why not have simple text? > >> > >> Giles, why not simple text? People have already been working with > >> POMs in alternative formats that don't involve XML at all. I > >> guess the real question here is, why would it disturb p
Re: An Attribute Based POM
On 13/02/2008, at 7:15 PM, Mark Struberg wrote: Does the refactoring of the XML give us any new functionality besides only 'looking better'? No, but it seems that's reason enough :) The technical underpinnings do give the value of being able to add things to the model now, however, and still parse old POMs effectively. And what is the price we pay? Getting non-compatible with existing poms? Someone already mentioned the forward compatibility once 'new' poms get their way into the repos. There are still many companies working with mvn 2.0.4 and lower, which will need the old poms in the public repos. Do we need own public repos then? If so, this would be more the kind of maven-3.0 then. The repos thing is fine - we just keep publishing the same format as before. It's not really read by humans there. All versions of Maven will continue to interoperate - until you start hitting projects that require Maven 2.1 to build (but that is to be expected, and it doesn't force anyone to upgrade for their own projects). Altough I agree that the attributes would have been better if we got them in 4.0.0 format, i also admit that it's imho simply too late. With regard to the familiarity issue - I don't believe this is a problem, as long as it is evolution (so, we are migrating towards one solution, not allowing it to change on a project-by-project basis). HTH, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[archetype] should the internal catalog list version numbers?
I've currently set the default to match the internal catalog, which is the same as before: RELEASE (ie, the latest release). But all the other archetypes (non-maven) list versions. Should the internal catalog list versions? (Seems much like another discussion on super POMs, I know :D) - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [archetype] should the internal catalog list version numbers?
The catalog file was created from the WIki page which has versions. Regards, Raphaël 2008/2/13, Brett Porter <[EMAIL PROTECTED]>: > I've currently set the default to match the internal catalog, which is > the same as before: RELEASE (ie, the latest release). > > But all the other archetypes (non-maven) list versions. Should the > internal catalog list versions? > > (Seems much like another discussion on super POMs, I know :D) > > - Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: New archetype plugin issues/questions....
Fixed in the latest snapshot (now deployed). Note that you'll now get prompted for the "version" and "package" values, though they have the same defaults as before so you can just enter past them. Cheers, Brett On 13/02/2008, at 2:02 AM, Daniel Kulp wrote: The new archetype plugin seems to have broken the normal instructions on how to create new projects.It doesn't seem to work. For example, according to: http://cwiki.apache.org/confluence/display/CAMEL/Creating+a+new+Spring+based+Camel+Route I should just need to run: mvn archetype:create \ -DarchetypeGroupId=org.apache.camel \ -DarchetypeArtifactId=camel-router \ -DarchetypeVersion=1.1.0 \ -DgroupId=myGroupId \ -DartifactId=myArtifactId That worked last week. Now I get a big list of archetypes to select from and the camel stuff isn't there. So, how the heck is this now supposed to work? If projects have archetypes in central, how are users supposed to use them?I really think we need to get a new version out that allows the previous instructions to work. This really breaks a BUNCH of projects instructions for creating samples/projects. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [archetype] should the internal catalog list version numbers?
The Maven archetypes on that page have no versions - which I presume is why they are RELEASE in the internal catalog. So I'm asking if we should hard code them instead? - Brett On 13/02/2008, at 10:21 PM, Raphaël Piéroni wrote: The catalog file was created from the WIki page which has versions. Regards, Raphaël 2008/2/13, Brett Porter <[EMAIL PROTECTED]>: I've currently set the default to match the internal catalog, which is the same as before: RELEASE (ie, the latest release). But all the other archetypes (non-maven) list versions. Should the internal catalog list versions? (Seems much like another discussion on super POMs, I know :D) - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven artifact work
Hi there, I've been chatting to Jason about making some headway with the maven artifact improvements that have been on the cards for sometime now. I've dug through much of the code on my travels implementing dependency:tree, conflict resolution and integrating maven-artifact 3.x into maven 2.0.x. I believe that Oleg and Ralph have been working on various related matters, so I'd like to discuss the current state of artifact work and what features would be suitable to work on next. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r627125 - /maven/plugins/trunk/maven-compiler-plugin/pom.xml
Thanks, I'll review the reason for that change, and see whether I can put it back down. -john On Feb 12, 2008, at 4:41 PM, Dennis Lundberg wrote: The plexus-utils upgrade will not happen unless you also changes the prerequisites to Maven 2.0.6. [EMAIL PROTECTED] wrote: Author: jdcasey Date: Tue Feb 12 13:34:56 2008 New Revision: 627125 URL: http://svn.apache.org/viewvc?rev=627125&view=rev Log: Bumping to plexus-compiler-* 1.6-SNAPSHOT to accommodate fixes for PLXCOMP-87 and MCOMPILER-59. Modified: maven/plugins/trunk/maven-compiler-plugin/pom.xml Modified: maven/plugins/trunk/maven-compiler-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven- compiler-plugin/pom.xml?rev=627125&r1=627124&r2=627125&view=diff = = --- maven/plugins/trunk/maven-compiler-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-compiler-plugin/pom.xml Tue Feb 12 13:34:56 2008 @@ -49,6 +49,13 @@ + + org.codehaus.plexus + plexus-container-default + 1.0-alpha-9-stable-1 + provided + + org.apache.maven @@ -65,29 +72,29 @@ org.codehaus.plexus plexus-utils - 1.0.4 + 1.4.9 org.codehaus.plexus plexus-compiler-api - 1.5.3 + 1.6-SNAPSHOT org.codehaus.plexus plexus-compiler-manager - 1.5.3 + 1.6-SNAPSHOT org.codehaus.plexus plexus-compiler-javac - 1.5.3 + 1.6-SNAPSHOT runtime org.apache.maven.shared maven-plugin-testing-harness - 1.0-beta-1 + 1.1 test -- Dennis Lundberg - 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 rss: http://feeds.feedburner.com/ejlife/john
Re: Assembly Plugin Status
Hey guys I'm curious, what is the states of the new beta2 release? I'd like to be able to get started on using it from an official release. On Jan 31, 2008 6:32 PM, Paul Gier <[EMAIL PROTECTED]> wrote: > Ok, no problem. Here are a few other issues that should be quick to fix > when > you have a chance. > I think these two are duplicates: > http://jira.codehaus.org/browse/MASSEMBLY-266 > http://jira.codehaus.org/browse/MASSEMBLY-216 > > This one appears to be working as designed (see comments), although I'm > not sure > of the reasoning behind the current behaviour. It should probably be > better > documented as is or fixed to resolve the issue. > http://jira.codehaus.org/browse/MASSEMBLY-256 > > > John Casey wrote: > > I ran out of time last night, but I'm putting it back on my agenda for > > this evening...I'll keep trying until I get it. Sorry for the delay. > > > > - > > > > On Jan 30, 2008, at 9:32 AM, Paul Gier wrote: > > > >> Hey Everyone, > >> I noticed that the assembly plugin has not been released in a while > >> (since last april) and it seems like there are a lot of useful fixes > >> in the current trunk. > >> > >> I also noticed some issues that can probably be resolved easily: > >> http://jira.codehaus.org/browse/MASSEMBLY-188 (this is a duplicate) > >> http://jira.codehaus.org/browse/MASSEMBLY-189 (has a working patch and > >> test and several votes) > >> http://jira.codehaus.org/browse/MASSEMBLY-182 (minor site updates) > >> http://jira.codehaus.org/browse/MASSEMBLY-274 (my issue that I'd like > >> to see fixed ;) > >> > >> What other tasks remain before 2.2-beta-2 can be released? Can some > >> of the current scheduled 2.2-beta-2 issues be pushed to a beta-3 if > >> they are more difficult? > >> > >> Thanks! > >> > >> - > >> 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 > > rss: http://feeds.feedburner.com/ejlife/john > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Justice is nothing more than that which is in the greatest self-interest of the largest portion of the population.
Re: An Attribute Based POM
I don't buy into the objection that simplifying the POM is "too late". If there is not a 4.1, there will be a 5.0. Eventually the POM will change -- if it doesn't happen with attributes, it will be for another reason. The schema dictates what is valid/invalid. If people want verbosity, let them continue to upload 4.0 POMs. If they want attributes, let's them do 4.1POMs. Paul On Feb 13, 2008 2:26 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 13/02/2008, at 7:15 PM, Mark Struberg wrote: > > > Does the refactoring of the XML give us any new functionality > > besides only 'looking better'? > > No, but it seems that's reason enough :) The technical underpinnings > do give the value of being able to add things to the model now, > however, and still parse old POMs effectively. > > > > > And what is the price we pay? Getting non-compatible with existing > > poms? Someone already mentioned > > the forward compatibility once 'new' poms get their way into the > > repos. There are still many > > companies working with mvn 2.0.4 and lower, which will need the old > > poms in the public repos. > > Do we need own public repos then? If so, this would be more the kind > > of maven-3.0 then. > > The repos thing is fine - we just keep publishing the same format as > before. It's not really read by humans there. All versions of Maven > will continue to interoperate - until you start hitting projects that > require Maven 2.1 to build (but that is to be expected, and it doesn't > force anyone to upgrade for their own projects). > > > > > Altough I agree that the attributes would have been better if we got > > them in 4.0.0 format, i also > > admit that it's imho simply too late. > > With regard to the familiarity issue - I don't believe this is a > problem, as long as it is evolution (so, we are migrating towards one > solution, not allowing it to change on a project-by-project basis). > > HTH, > Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Maven and preset plugin versions
This is true, but it might be appropriate for the maven core group to provide a criterion (or criteria) for inclusion of the new version. Some sort of sufficiency of testing, full regression in an isolated integration environment, etc. If the core group can set a baseline of quality that has some criteria that can be objectively verified, then the plugin authors would have a level to shoot for. Certainly, I think that would mean developing a set of canonical projects that would have to be built with the new plugins. Not just in /src/it of the plugin itself, but larger test that would have to be tested against the integrated whole. If the test projects had to be altered to support the new plugin functionality, then that becomes either 1) a regression failure, or 2) non-destructive new features. Either way, the delta forms a great part of a release not on how to update your projects to support the new version. The trick, of course, if finding a "sufficient" project suite to exercise the whole and build it out. Maintaining it should be less heavy, since it IS the canonical project. Christian On 13-Feb-08, at 01:06 , Brian E. Fox wrote: It's really up to the plugin author to document compatibilities rather than Maven core running around and building a list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Benedict Sent: Tuesday, February 12, 2008 5:09 PM To: Maven Developers List Subject: Re: Maven and preset plugin versions Brett, I didn't know that. I never knew that kind of feature existed. Can the minimum recommended version be listed in Maven release notes though? It would be nice to a have a table with what versions should be used with 2.0.8for the best support. Education and visibility on this issue is key, imo. Paul On Feb 12, 2008 5:51 PM, Brett Porter <[EMAIL PROTECTED]> wrote: But this is how it already works, if I'm reading correctly. The minimum version of Maven for a plugin is specified by the plugin itself in the prerequisites tag - if you use an older version of Maven, you will get the last version of the plugin that worked with it. - Brett On 13/02/2008, at 8:22 AM, Paul Benedict wrote: I've been watching the discussions about introducing a fix set of plugin versions per Maven version. I see benefit and drawback to each side of the argument. Here is another proposal which is dear to my pain :-) Provide the minimal compatible version of each plugin (of group org.apache.maven.plugins) in the super pom. For instance, when I upgraded to Maven 2.0.8, it would have been nice (stupendous!) to automatically be bumped to surefire 2.4 because the two truly needed each other in integration testing. I imagine there are other cases when plugins have dependencies on other parts of the Maven core, but I could be wrong. The desire is for children pom to provide the "better" versions if necessary, but Maven should at least provide the minimum versions. Paul -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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: Maven and preset plugin versions
Yes we do have plans for a touchstone build to test against. Getting one made is actually the problem ;-) -Original Message- From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 10:26 AM To: Maven Developers List Subject: Re: Maven and preset plugin versions This is true, but it might be appropriate for the maven core group to provide a criterion (or criteria) for inclusion of the new version. Some sort of sufficiency of testing, full regression in an isolated integration environment, etc. If the core group can set a baseline of quality that has some criteria that can be objectively verified, then the plugin authors would have a level to shoot for. Certainly, I think that would mean developing a set of canonical projects that would have to be built with the new plugins. Not just in /src/it of the plugin itself, but larger test that would have to be tested against the integrated whole. If the test projects had to be altered to support the new plugin functionality, then that becomes either 1) a regression failure, or 2) non-destructive new features. Either way, the delta forms a great part of a release not on how to update your projects to support the new version. The trick, of course, if finding a "sufficient" project suite to exercise the whole and build it out. Maintaining it should be less heavy, since it IS the canonical project. Christian On 13-Feb-08, at 01:06 , Brian E. Fox wrote: > It's really up to the plugin author to document compatibilities rather > than Maven core running around and building a list. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Paul Benedict > Sent: Tuesday, February 12, 2008 5:09 PM > To: Maven Developers List > Subject: Re: Maven and preset plugin versions > > Brett, > > I didn't know that. I never knew that kind of feature existed. Can the > minimum recommended version be listed in Maven release notes though? > It > would be nice to a have a table with what versions should be used with > 2.0.8for the best support. Education and visibility on this issue is > key, imo. > > Paul > > On Feb 12, 2008 5:51 PM, Brett Porter <[EMAIL PROTECTED]> wrote: > >> But this is how it already works, if I'm reading correctly. The >> minimum version of Maven for a plugin is specified by the plugin >> itself in the prerequisites tag - if you use an older version of >> Maven, you will get the last version of the plugin that worked with > it. >> >> - Brett >> >> On 13/02/2008, at 8:22 AM, Paul Benedict wrote: >> >>> I've been watching the discussions about introducing a fix set of >>> plugin >>> versions per Maven version. I see benefit and drawback to each side >>> of the >>> argument. >>> >>> Here is another proposal which is dear to my pain :-) >>> >>> Provide the minimal compatible version of each plugin (of group >>> org.apache.maven.plugins) in the super pom. For instance, when I >>> upgraded to >>> Maven 2.0.8, it would have been nice (stupendous!) to automatically > be >>> bumped to surefire 2.4 because the two truly needed each other in >>> integration testing. I imagine there are other cases when plugins > have >>> dependencies on other parts of the Maven core, but I could be wrong. >>> The >>> desire is for children pom to provide the "better" versions if >>> necessary, >>> but Maven should at least provide the minimum versions. >>> >>> Paul >> >> -- >> Brett Porter >> [EMAIL PROTECTED] >> http://blogs.exist.com/bporter/ >> >> >> - >> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [archetype] should the internal catalog list version numbers?
The wiki scraping is bunk. We need some metadata in the repository to contain this just like we do with the name mappings for plugins. Lets make a metadata.xml somewhere and start recording them (first by hand, later with tools). -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 10:09 AM To: Maven Developers List Subject: Re: [archetype] should the internal catalog list version numbers? We should find the releases, or make them put them in the wiki before the final version. They all have versions somewhere. I just did a quick slurp from source to sink to create the internal catalog because Confluence flakes out on Codehaus so it was grinding away and dying in the eclipse integration. The list should have real versions and shouldn't use the RELEASE or one day it will work one way and differently the next. On 13-Feb-08, at 4:17 AM, Brett Porter wrote: > The Maven archetypes on that page have no versions - which I presume > is why they are RELEASE in the internal catalog. So I'm asking if we > should hard code them instead? > > - Brett > > On 13/02/2008, at 10:21 PM, Raphaël Piéroni wrote: > >> The catalog file was created from the WIki page which has versions. >> >> Regards, >> >> Raphaël >> >> 2008/2/13, Brett Porter <[EMAIL PROTECTED]>: >>> I've currently set the default to match the internal catalog, >>> which is >>> the same as before: RELEASE (ie, the latest release). >>> >>> But all the other archetypes (non-maven) list versions. Should the >>> internal catalog list versions? >>> >>> (Seems much like another discussion on super POMs, I know :D) >>> >>> - Brett >>> >>> -- >>> Brett Porter >>> [EMAIL PROTECTED] >>> http://blogs.exist.com/bporter/ >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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: [archetype] should the internal catalog list version numbers?
We should find the releases, or make them put them in the wiki before the final version. They all have versions somewhere. I just did a quick slurp from source to sink to create the internal catalog because Confluence flakes out on Codehaus so it was grinding away and dying in the eclipse integration. The list should have real versions and shouldn't use the RELEASE or one day it will work one way and differently the next. On 13-Feb-08, at 4:17 AM, Brett Porter wrote: The Maven archetypes on that page have no versions - which I presume is why they are RELEASE in the internal catalog. So I'm asking if we should hard code them instead? - Brett On 13/02/2008, at 10:21 PM, Raphaël Piéroni wrote: The catalog file was created from the WIki page which has versions. Regards, Raphaël 2008/2/13, Brett Porter <[EMAIL PROTECTED]>: I've currently set the default to match the internal catalog, which is the same as before: RELEASE (ie, the latest release). But all the other archetypes (non-maven) list versions. Should the internal catalog list versions? (Seems much like another discussion on super POMs, I know :D) - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and preset plugin versions
How can I help? Seriously. I'd be willing to put some time into it. Christian. On 13-Feb-08, at 13:47 , Brian E. Fox wrote: Yes we do have plans for a touchstone build to test against. Getting one made is actually the problem ;-) -Original Message- From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 10:26 AM To: Maven Developers List Subject: Re: Maven and preset plugin versions This is true, but it might be appropriate for the maven core group to provide a criterion (or criteria) for inclusion of the new version. Some sort of sufficiency of testing, full regression in an isolated integration environment, etc. If the core group can set a baseline of quality that has some criteria that can be objectively verified, then the plugin authors would have a level to shoot for. Certainly, I think that would mean developing a set of canonical projects that would have to be built with the new plugins. Not just in /src/it of the plugin itself, but larger test that would have to be tested against the integrated whole. If the test projects had to be altered to support the new plugin functionality, then that becomes either 1) a regression failure, or 2) non-destructive new features. Either way, the delta forms a great part of a release not on how to update your projects to support the new version. The trick, of course, if finding a "sufficient" project suite to exercise the whole and build it out. Maintaining it should be less heavy, since it IS the canonical project. Christian On 13-Feb-08, at 01:06 , Brian E. Fox wrote: It's really up to the plugin author to document compatibilities rather than Maven core running around and building a list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Benedict Sent: Tuesday, February 12, 2008 5:09 PM To: Maven Developers List Subject: Re: Maven and preset plugin versions Brett, I didn't know that. I never knew that kind of feature existed. Can the minimum recommended version be listed in Maven release notes though? It would be nice to a have a table with what versions should be used with 2.0.8for the best support. Education and visibility on this issue is key, imo. Paul On Feb 12, 2008 5:51 PM, Brett Porter <[EMAIL PROTECTED]> wrote: But this is how it already works, if I'm reading correctly. The minimum version of Maven for a plugin is specified by the plugin itself in the prerequisites tag - if you use an older version of Maven, you will get the last version of the plugin that worked with it. - Brett On 13/02/2008, at 8:22 AM, Paul Benedict wrote: I've been watching the discussions about introducing a fix set of plugin versions per Maven version. I see benefit and drawback to each side of the argument. Here is another proposal which is dear to my pain :-) Provide the minimal compatible version of each plugin (of group org.apache.maven.plugins) in the super pom. For instance, when I upgraded to Maven 2.0.8, it would have been nice (stupendous!) to automatically be bumped to surefire 2.4 because the two truly needed each other in integration testing. I imagine there are other cases when plugins have dependencies on other parts of the Maven core, but I could be wrong. The desire is for children pom to provide the "better" versions if necessary, but Maven should at least provide the minimum versions. Paul -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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] - 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: Maven and preset plugin versions
Absolutely. We simply need a good example of a project that uses various common tools: jars, wars, ears, assemblies, moving resources with dependency, scanning with checkstyle/pmd/cobertura. It should have a simulated corp pom etc. The trouble with most touchstone builds are they are enterprise examples that are closed source and not easy to replicate without time. The touchstone doesn't need tons of source, it's mostly about the structure. -Original Message- From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 11:09 AM To: Maven Developers List Subject: Re: Maven and preset plugin versions How can I help? Seriously. I'd be willing to put some time into it. Christian. On 13-Feb-08, at 13:47 , Brian E. Fox wrote: > Yes we do have plans for a touchstone build to test against. Getting > one > made is actually the problem ;-) > > -Original Message- > From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 13, 2008 10:26 AM > To: Maven Developers List > Subject: Re: Maven and preset plugin versions > > This is true, but it might be appropriate for the maven core group to > provide a criterion (or criteria) for inclusion of the new version. > Some sort of sufficiency of testing, full regression in an isolated > integration environment, etc. If the core group can set a baseline of > quality that has some criteria that can be objectively verified, then > the plugin authors would have a level to shoot for. > > Certainly, I think that would mean developing a set of canonical > projects that would have to be built with the new plugins. Not just > in /src/it of the plugin itself, but larger test that would have to be > tested against the integrated whole. If the test projects had to be > altered to support the new plugin functionality, then that becomes > either 1) a regression failure, or 2) non-destructive new features. > Either way, the delta forms a great part of a release not on how to > update your projects to support the new version. > > The trick, of course, if finding a "sufficient" project suite to > exercise the whole and build it out. Maintaining it should be less > heavy, since it IS the canonical project. > > Christian > > On 13-Feb-08, at 01:06 , Brian E. Fox wrote: > >> It's really up to the plugin author to document compatibilities >> rather >> than Maven core running around and building a list. >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >> On Behalf Of Paul Benedict >> Sent: Tuesday, February 12, 2008 5:09 PM >> To: Maven Developers List >> Subject: Re: Maven and preset plugin versions >> >> Brett, >> >> I didn't know that. I never knew that kind of feature existed. Can >> the >> minimum recommended version be listed in Maven release notes though? >> It >> would be nice to a have a table with what versions should be used >> with >> 2.0.8for the best support. Education and visibility on this issue is >> key, imo. >> >> Paul >> >> On Feb 12, 2008 5:51 PM, Brett Porter <[EMAIL PROTECTED]> wrote: >> >>> But this is how it already works, if I'm reading correctly. The >>> minimum version of Maven for a plugin is specified by the plugin >>> itself in the prerequisites tag - if you use an older version of >>> Maven, you will get the last version of the plugin that worked with >> it. >>> >>> - Brett >>> >>> On 13/02/2008, at 8:22 AM, Paul Benedict wrote: >>> I've been watching the discussions about introducing a fix set of plugin versions per Maven version. I see benefit and drawback to each side of the argument. Here is another proposal which is dear to my pain :-) Provide the minimal compatible version of each plugin (of group org.apache.maven.plugins) in the super pom. For instance, when I upgraded to Maven 2.0.8, it would have been nice (stupendous!) to automatically >> be bumped to surefire 2.4 because the two truly needed each other in integration testing. I imagine there are other cases when plugins >> have dependencies on other parts of the Maven core, but I could be wrong. The desire is for children pom to provide the "better" versions if necessary, but Maven should at least provide the minimum versions. Paul >>> >>> -- >>> Brett Porter >>> [EMAIL PROTECTED] >>> http://blogs.exist.com/bporter/ >>> >>> >>> - >>> 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: Assembly Plugin Status
It's still on my radar, but I haven't had time to get into all the issues slated for that release yet. I think they're mostly patches, but I'll need to set aside some time to apply them and call for the release. Sorry for the delay. -john On Feb 13, 2008, at 11:42 AM, Sejal Patel wrote: Hey guys I'm curious, what is the states of the new beta2 release? I'd like to be able to get started on using it from an official release. On Jan 31, 2008 6:32 PM, Paul Gier <[EMAIL PROTECTED]> wrote: Ok, no problem. Here are a few other issues that should be quick to fix when you have a chance. I think these two are duplicates: http://jira.codehaus.org/browse/MASSEMBLY-266 http://jira.codehaus.org/browse/MASSEMBLY-216 This one appears to be working as designed (see comments), although I'm not sure of the reasoning behind the current behaviour. It should probably be better documented as is or fixed to resolve the issue. http://jira.codehaus.org/browse/MASSEMBLY-256 John Casey wrote: I ran out of time last night, but I'm putting it back on my agenda for this evening...I'll keep trying until I get it. Sorry for the delay. - On Jan 30, 2008, at 9:32 AM, Paul Gier wrote: Hey Everyone, I noticed that the assembly plugin has not been released in a while (since last april) and it seems like there are a lot of useful fixes in the current trunk. I also noticed some issues that can probably be resolved easily: http://jira.codehaus.org/browse/MASSEMBLY-188 (this is a duplicate) http://jira.codehaus.org/browse/MASSEMBLY-189 (has a working patch and test and several votes) http://jira.codehaus.org/browse/MASSEMBLY-182 (minor site updates) http://jira.codehaus.org/browse/MASSEMBLY-274 (my issue that I'd like to see fixed ;) What other tasks remain before 2.2-beta-2 can be released? Can some of the current scheduled 2.2-beta-2 issues be pushed to a beta-3 if they are more difficult? Thanks! --- -- 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 rss: http://feeds.feedburner.com/ejlife/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Justice is nothing more than that which is in the greatest self- interest of the largest portion of the population. --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Re: Maven and preset plugin versions
I have two or three I could abstract down, plus some teeny (project A, Project B) samples I generated to teach people Maven. I would actually suggest not one, but three or four, including at least one that pulls in some common external plugins to see if interaction breaks (says a plugin creator... lol) But I'll try to think through the actual scenarios so we can have enough projects to execute a meaningful suite without too much duplication. Hmm. Maybe I'll through up a table on the wiki to keep track of the case coverage. Christian. On 13-Feb-08, at 14:28 , Brian E. Fox wrote: Absolutely. We simply need a good example of a project that uses various common tools: jars, wars, ears, assemblies, moving resources with dependency, scanning with checkstyle/pmd/cobertura. It should have a simulated corp pom etc. The trouble with most touchstone builds are they are enterprise examples that are closed source and not easy to replicate without time. The touchstone doesn't need tons of source, it's mostly about the structure. -Original Message- From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 11:09 AM To: Maven Developers List Subject: Re: Maven and preset plugin versions How can I help? Seriously. I'd be willing to put some time into it. Christian. On 13-Feb-08, at 13:47 , Brian E. Fox wrote: Yes we do have plans for a touchstone build to test against. Getting one made is actually the problem ;-) -Original Message- From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 10:26 AM To: Maven Developers List Subject: Re: Maven and preset plugin versions This is true, but it might be appropriate for the maven core group to provide a criterion (or criteria) for inclusion of the new version. Some sort of sufficiency of testing, full regression in an isolated integration environment, etc. If the core group can set a baseline of quality that has some criteria that can be objectively verified, then the plugin authors would have a level to shoot for. Certainly, I think that would mean developing a set of canonical projects that would have to be built with the new plugins. Not just in /src/it of the plugin itself, but larger test that would have to be tested against the integrated whole. If the test projects had to be altered to support the new plugin functionality, then that becomes either 1) a regression failure, or 2) non-destructive new features. Either way, the delta forms a great part of a release not on how to update your projects to support the new version. The trick, of course, if finding a "sufficient" project suite to exercise the whole and build it out. Maintaining it should be less heavy, since it IS the canonical project. Christian On 13-Feb-08, at 01:06 , Brian E. Fox wrote: It's really up to the plugin author to document compatibilities rather than Maven core running around and building a list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Benedict Sent: Tuesday, February 12, 2008 5:09 PM To: Maven Developers List Subject: Re: Maven and preset plugin versions Brett, I didn't know that. I never knew that kind of feature existed. Can the minimum recommended version be listed in Maven release notes though? It would be nice to a have a table with what versions should be used with 2.0.8for the best support. Education and visibility on this issue is key, imo. Paul On Feb 12, 2008 5:51 PM, Brett Porter <[EMAIL PROTECTED]> wrote: But this is how it already works, if I'm reading correctly. The minimum version of Maven for a plugin is specified by the plugin itself in the prerequisites tag - if you use an older version of Maven, you will get the last version of the plugin that worked with it. - Brett On 13/02/2008, at 8:22 AM, Paul Benedict wrote: I've been watching the discussions about introducing a fix set of plugin versions per Maven version. I see benefit and drawback to each side of the argument. Here is another proposal which is dear to my pain :-) Provide the minimal compatible version of each plugin (of group org.apache.maven.plugins) in the super pom. For instance, when I upgraded to Maven 2.0.8, it would have been nice (stupendous!) to automatically be bumped to surefire 2.4 because the two truly needed each other in integration testing. I imagine there are other cases when plugins have dependencies on other parts of the Maven core, but I could be wrong. The desire is for children pom to provide the "better" versions if necessary, but Maven should at least provide the minimum versions. Paul -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and preset plugin versions
a project that used the maven-scm plugin and then the embedder (or exec plugin) could snag any number of gruesome open source projects based on tags and make sure they built On Feb 13, 2008 2:37 PM, Christian Edward Gruber < [EMAIL PROTECTED]> wrote: > I have two or three I could abstract down, plus some teeny (project A, > Project B) samples I generated to teach people Maven. > > I would actually suggest not one, but three or four, including at > least one that pulls in some common external plugins to see if > interaction breaks (says a plugin creator... lol) > > But I'll try to think through the actual scenarios so we can have > enough projects to execute a meaningful suite without too much > duplication. Hmm. Maybe I'll through up a table on the wiki to keep > track of the case coverage. > > Christian. > > On 13-Feb-08, at 14:28 , Brian E. Fox wrote: > > > Absolutely. We simply need a good example of a project that uses > > various > > common tools: jars, wars, ears, assemblies, moving resources with > > dependency, scanning with checkstyle/pmd/cobertura. It should have a > > simulated corp pom etc. The trouble with most touchstone builds are > > they > > are enterprise examples that are closed source and not easy to > > replicate > > without time. The touchstone doesn't need tons of source, it's mostly > > about the structure. > > > > -Original Message- > > From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 13, 2008 11:09 AM > > To: Maven Developers List > > Subject: Re: Maven and preset plugin versions > > > > How can I help? Seriously. I'd be willing to put some time into it. > > > > Christian. > > > > On 13-Feb-08, at 13:47 , Brian E. Fox wrote: > > > >> Yes we do have plans for a touchstone build to test against. Getting > >> one > >> made is actually the problem ;-) > >> > >> -Original Message- > >> From: Christian Edward Gruber > >> [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, February 13, 2008 10:26 AM > >> To: Maven Developers List > >> Subject: Re: Maven and preset plugin versions > >> > >> This is true, but it might be appropriate for the maven core group to > >> provide a criterion (or criteria) for inclusion of the new version. > >> Some sort of sufficiency of testing, full regression in an isolated > >> integration environment, etc. If the core group can set a baseline > >> of > >> quality that has some criteria that can be objectively verified, then > >> the plugin authors would have a level to shoot for. > >> > >> Certainly, I think that would mean developing a set of canonical > >> projects that would have to be built with the new plugins. Not just > >> in /src/it of the plugin itself, but larger test that would have to > >> be > >> tested against the integrated whole. If the test projects had to be > >> altered to support the new plugin functionality, then that becomes > >> either 1) a regression failure, or 2) non-destructive new features. > >> Either way, the delta forms a great part of a release not on how to > >> update your projects to support the new version. > >> > >> The trick, of course, if finding a "sufficient" project suite to > >> exercise the whole and build it out. Maintaining it should be less > >> heavy, since it IS the canonical project. > >> > >> Christian > >> > >> On 13-Feb-08, at 01:06 , Brian E. Fox wrote: > >> > >>> It's really up to the plugin author to document compatibilities > >>> rather > >>> than Maven core running around and building a list. > >>> > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] > >>> On Behalf Of Paul Benedict > >>> Sent: Tuesday, February 12, 2008 5:09 PM > >>> To: Maven Developers List > >>> Subject: Re: Maven and preset plugin versions > >>> > >>> Brett, > >>> > >>> I didn't know that. I never knew that kind of feature existed. Can > >>> the > >>> minimum recommended version be listed in Maven release notes though? > >>> It > >>> would be nice to a have a table with what versions should be used > >>> with > >>> 2.0.8for the best support. Education and visibility on this issue is > >>> key, imo. > >>> > >>> Paul > >>> > >>> On Feb 12, 2008 5:51 PM, Brett Porter <[EMAIL PROTECTED]> wrote: > >>> > But this is how it already works, if I'm reading correctly. The > minimum version of Maven for a plugin is specified by the plugin > itself in the prerequisites tag - if you use an older version of > Maven, you will get the last version of the plugin that worked with > >>> it. > > - Brett > > On 13/02/2008, at 8:22 AM, Paul Benedict wrote: > > > I've been watching the discussions about introducing a fix set of > > plugin > > versions per Maven version. I see benefit and drawback to each > > side > > of the > > argument. > > > > Here is another proposal which is dear to my pain :-) > > > > Provide the minimal compatible version of each plugin (of group
Re: Maven and preset plugin versions
Well, I can certainly nail the scm plugin one (though adding it to the maven sources and pointing the scm tag at the right location would also do that). My own plugin uses the invoker, but not the embedder. The exec plugin wouldn't be too hard. Actually, I take back my previous comment about duplication. I think if we have a set of projects with graduated complexity, even though the later ones overlap the functionality, it'll be easier to debug if the simple ones fail and the later ones do as well. But if the simples ones pass and the later ones fail, it's a different sort of error. That provides a quick way to sort the nature of the problem into at least a slightly smaller bucket. Any preferences in location for the wiki edit? I'll have to check if I have an account and access. I have a JIRA account, but I can't remember if I have a confluence one. Christian. On 13-Feb-08, at 15:46 , Jesse McConnell wrote: a project that used the maven-scm plugin and then the embedder (or exec plugin) could snag any number of gruesome open source projects based on tags and make sure they built - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [archetype] should the internal catalog list version numbers?
I started a plexus component for doing this. it is the repository crawler (in the common module) but it is not yet working. Rergards, Raphaël 2008/2/13, Brian E. Fox <[EMAIL PROTECTED]>: > The wiki scraping is bunk. We need some metadata in the repository to contain > this just like we do with the name mappings for plugins. Lets make a > metadata.xml somewhere and start recording them (first by hand, later with > tools). > > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 13, 2008 10:09 AM > To: Maven Developers List > Subject: Re: [archetype] should the internal catalog list version numbers? > > We should find the releases, or make them put them in the wiki before > the final version. They all have versions somewhere. I just did a > quick slurp from source to sink to create the internal catalog because > Confluence flakes out on Codehaus so it was grinding away and dying in > the eclipse integration. > > The list should have real versions and shouldn't use the RELEASE or > one day it will work one way and differently the next. > > On 13-Feb-08, at 4:17 AM, Brett Porter wrote: > > > The Maven archetypes on that page have no versions - which I presume > > is why they are RELEASE in the internal catalog. So I'm asking if we > > should hard code them instead? > > > > - Brett > > > > On 13/02/2008, at 10:21 PM, Raphaël Piéroni wrote: > > > >> The catalog file was created from the WIki page which has versions. > >> > >> Regards, > >> > >> Raphaël > >> > >> 2008/2/13, Brett Porter <[EMAIL PROTECTED]>: > >>> I've currently set the default to match the internal catalog, > >>> which is > >>> the same as before: RELEASE (ie, the latest release). > >>> > >>> But all the other archetypes (non-maven) list versions. Should the > >>> internal catalog list versions? > >>> > >>> (Seems much like another discussion on super POMs, I know :D) > >>> > >>> - Brett > >>> > >>> -- > >>> Brett Porter > >>> [EMAIL PROTECTED] > >>> http://blogs.exist.com/bporter/ > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > > > > -- > > Brett Porter > > [EMAIL PROTECTED] > > http://blogs.exist.com/bporter/ > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > > > - > 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: Maven and preset plugin versions
You can sign up for a confluence one and then edit stuff in the maven-user space. Thanks for offering to do this; it will be a tremendous help as the Its really don't cover as much as we need. -Original Message- From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 1:15 PM To: Maven Developers List Subject: Re: Maven and preset plugin versions Well, I can certainly nail the scm plugin one (though adding it to the maven sources and pointing the scm tag at the right location would also do that). My own plugin uses the invoker, but not the embedder. The exec plugin wouldn't be too hard. Actually, I take back my previous comment about duplication. I think if we have a set of projects with graduated complexity, even though the later ones overlap the functionality, it'll be easier to debug if the simple ones fail and the later ones do as well. But if the simples ones pass and the later ones fail, it's a different sort of error. That provides a quick way to sort the nature of the problem into at least a slightly smaller bucket. Any preferences in location for the wiki edit? I'll have to check if I have an account and access. I have a JIRA account, but I can't remember if I have a confluence one. Christian. On 13-Feb-08, at 15:46 , Jesse McConnell wrote: > a project that used the maven-scm plugin and then the embedder (or > exec > plugin) could snag any number of gruesome open source projects based > on tags > and make sure they built - 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]
atypical plugin use cases
Hi,
I'm trying to document some of the design problems with sort of
exotic plugin use cases, things like aggregation and use of $
{reactorProjects}, that we're running into under the current setup. I
have proposals to address most of the issues, but I'd love to hear
what you would propose...or even tell me about plugin-design issues
that I haven't thought of.
I'd really like to take a whack at the bigger problems for 2.1, but
if that doesn't happen, 2.2 is a fine target for me, as long as we
start the discussion now. We have a lot of experience with what works
and what doesn't from 2.0.x, so let's take advantage of that to see
what we got wrong, and how we can correct it.
The page is here: http://docs.codehaus.org/display/MAVEN/Atypical
+Plugin+Use+Cases
Thanks in advance,
-john
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Re: atypical plugin use cases
John Casey wrote:
I'm trying to document some of the design problems with sort of exotic plugin
use cases, things like aggregation and use of ${reactorProjects}, that we're
running into under the current setup. I have proposals to address most of the
issues, but I'd love to hear what you would propose...or even tell me about
plugin-design issues that I haven't thought of.
This may be quibbling, but it seems weird to me that aggregation would be
an atypical case. IMO, almost every reporting plugin needs to do
aggregation (or at least be able to do it). checkstyle, clover, docck,
javadoc, jxr, pmd, surefire-report all need aggregation somehow or other.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [archetype] should the internal catalog list version numbers?
On 14/02/2008, at 5:09 AM, Jason van Zyl wrote: We should find the releases, or make them put them in the wiki before the final version. Yep, I agree. I've done this for the Maven ones. They all have versions somewhere. I just did a quick slurp from source to sink to create the internal catalog because Confluence flakes out on Codehaus so it was grinding away and dying in the eclipse integration. FWIW, if we use Apache's CWIKI it's faster and it generates static HTML which is even better :) Anyway, the repository metadata is a better solution. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly Plugin Status
Not a problem. Was just worried that it slipped off the radar was all. I understand how things get in the way. Looking forward to using it though. On Feb 13, 2008 3:31 PM, John Casey <[EMAIL PROTECTED]> wrote: > It's still on my radar, but I haven't had time to get into all the > issues slated for that release yet. I think they're mostly patches, > but I'll need to set aside some time to apply them and call for the > release. > > Sorry for the delay. > > -john > > On Feb 13, 2008, at 11:42 AM, Sejal Patel wrote: > > > Hey guys I'm curious, what is the states of the new beta2 release? > > I'd like > > to be able to get started on using it from an official release. > > > > On Jan 31, 2008 6:32 PM, Paul Gier <[EMAIL PROTECTED]> wrote: > > > >> Ok, no problem. Here are a few other issues that should be quick > >> to fix > >> when > >> you have a chance. > >> I think these two are duplicates: > >> http://jira.codehaus.org/browse/MASSEMBLY-266 > >> http://jira.codehaus.org/browse/MASSEMBLY-216 > >> > >> This one appears to be working as designed (see comments), > >> although I'm > >> not sure > >> of the reasoning behind the current behaviour. It should probably be > >> better > >> documented as is or fixed to resolve the issue. > >> http://jira.codehaus.org/browse/MASSEMBLY-256 > >> > >> > >> John Casey wrote: > >>> I ran out of time last night, but I'm putting it back on my > >>> agenda for > >>> this evening...I'll keep trying until I get it. Sorry for the delay. > >>> > >>> - > >>> > >>> On Jan 30, 2008, at 9:32 AM, Paul Gier wrote: > >>> > Hey Everyone, > I noticed that the assembly plugin has not been released in a while > (since last april) and it seems like there are a lot of useful > fixes > in the current trunk. > > I also noticed some issues that can probably be resolved easily: > http://jira.codehaus.org/browse/MASSEMBLY-188 (this is a duplicate) > http://jira.codehaus.org/browse/MASSEMBLY-189 (has a working > patch and > test and several votes) > http://jira.codehaus.org/browse/MASSEMBLY-182 (minor site updates) > http://jira.codehaus.org/browse/MASSEMBLY-274 (my issue that I'd > like > to see fixed ;) > > What other tasks remain before 2.2-beta-2 can be released? Can > some > of the current scheduled 2.2-beta-2 issues be pushed to a beta-3 if > they are more difficult? > > Thanks! > > --- > -- > 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 > >>> rss: http://feeds.feedburner.com/ejlife/john > >>> > >>> > >>> > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > Justice is nothing more than that which is in the greatest self- > > interest of > > the largest portion of the population. > > --- > John Casey > Committer and PMC Member, Apache Maven > mail: jdcasey at commonjava dot org > blog: http://www.ejlife.net/blogs/john > rss: http://feeds.feedburner.com/ejlife/john > > > -- Justice is nothing more than that which is in the greatest self-interest of the largest portion of the population.
