Re: Abolishing Extensions in 2.1
Hi Jason, How would you implement the XWiki use case, namely the ability to add XAR file format support? Right now it's using an extension to: 1) define a lifecycle 2) define an Archiver format implementation Thanks -Vincent On Sep 4, 2007, at 11:34 AM, Jason van Zyl wrote: After trying to chase down a problem with extensions it became very clear to me that we have mixed concerns with extensions and it just makes the core crappy. The biggest offender are providers posing as extensions: wagon- webdav is not an extension, it is a dependency required by the deploy plugin. In the exact same way you would specify an SCM provider as dependency of the release plugin if you needed, say, ClearCase support. These are not general extensions they are specifically required by certain plugins and should be defined as such to scope their use. Dumping wagon-webdav into the core is not very bright considering it's use is limited to the deploy plugin. People have also used extensions to make available certain resources like checkstyle rules. Are these also not dependencies of a given plugin? Finally, the only things that in my opinion count as extensions are addition components that augment core functionality: artifact resolvers, version conflict resolvers, profile activator, project builders and the like. These should have an element like coreExtensions/ or something like it. Look at the extensions element and it begs the questions and extension to what exactly. For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? 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: Abolishing Extensions in 2.1
On Sep 20, 2007, at 9:30 AM, Vincent Massol wrote: Hi Jason, How would you implement the XWiki use case, namely the ability to add XAR file format support? Right now it's using an extension to: 1) define a lifecycle 2) define an Archiver format implementation ooops... sorry I spoke too fast. You provided the answer: Finally, the only things that in my opinion count as extensions are addition components that augment core functionality: artifact resolvers, version conflict resolvers, profile activator, project builders and the like. These should have an element like coreExtensions/ or something like it. Look at the extensions element and it begs the questions and extension to what exactly. Sorry for the noise. -Vincent On Sep 4, 2007, at 11:34 AM, Jason van Zyl wrote: After trying to chase down a problem with extensions it became very clear to me that we have mixed concerns with extensions and it just makes the core crappy. The biggest offender are providers posing as extensions: wagon- webdav is not an extension, it is a dependency required by the deploy plugin. In the exact same way you would specify an SCM provider as dependency of the release plugin if you needed, say, ClearCase support. These are not general extensions they are specifically required by certain plugins and should be defined as such to scope their use. Dumping wagon-webdav into the core is not very bright considering it's use is limited to the deploy plugin. People have also used extensions to make available certain resources like checkstyle rules. Are these also not dependencies of a given plugin? Finally, the only things that in my opinion count as extensions are addition components that augment core functionality: artifact resolvers, version conflict resolvers, profile activator, project builders and the like. These should have an element like coreExtensions/ or something like it. Look at the extensions element and it begs the questions and extension to what exactly. For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? 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: Abolishing Extensions in 2.1
I might have another usecase in toolchains (http://docs.codehaus.org/display/MAVEN/Toolchains) A toolchain definition that is not part of the default set needs to be added as extension to the build. It's accessed by multiple plugins and therefore it's rather impractical to add it as dependency to each plugin that uses it. Milos On 9/4/07, John Casey [EMAIL PROTECTED] wrote: On Sep 4, 2007, at 5:34 AM, Jason van Zyl wrote: The biggest offender are providers posing as extensions: wagon- webdav is not an extension, it is a dependency required by the deploy plugin. In the exact same way you would specify an SCM provider as dependency of the release plugin if you needed, say, ClearCase support. These are not general extensions they are specifically required by certain plugins and should be defined as such to scope their use. Dumping wagon-webdav into the core is not very bright considering it's use is limited to the deploy plugin. This is an oversimplification. Wagons are also used in resolving artifacts, and while this is not a useful example WRT webdav, the ftp or scp wagons could easily be required for resolving dependencies...which is not a plugin task. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abolishing Extensions in 2.1
I've been thinking about this more, and I really think it's a bad idea to scrap extensions completely. The more work I do on conversions, etc. the more I see that there is a need to tweak Maven here and there for certain projects. A great case-in-point here is profile activators...without extensions, it would be impossible to write a custom profile activator and have any hope of getting it included in the Maven build environment. I think that rather than conflating implementation problems with design problems, we should be thinking about how to fix the implementation and make it intuitive. I'd actually be much more in favor of making the extension mechanism more rich, rather than removing it, so we can support custom components in this component- oriented system. There are legitimate cases where using the plugin as a vector for bringing in extensions is simply inaccurate. Also, it's not a great option to modify the Maven installation itself (I'm sure we all cringed when I said that just now)...so extensions are all that's left to us in many cases. I'm definitely -1 for this, the more I think about it. If they don't work for someone, we could probably look more closely at some sort of policy enforcement that would prohibit the use of extensions...but ironically, this would probably have to be carried out via an extension of some sort (barring the enforcer-plugin, which would have to have its own dedicated lifecycle phase to be absolutely sure nothing executed in the build ahead of it). -john On Sep 20, 2007, at 3:40 AM, Milos Kleint wrote: I might have another usecase in toolchains (http://docs.codehaus.org/display/MAVEN/Toolchains) A toolchain definition that is not part of the default set needs to be added as extension to the build. It's accessed by multiple plugins and therefore it's rather impractical to add it as dependency to each plugin that uses it. Milos On 9/4/07, John Casey [EMAIL PROTECTED] wrote: On Sep 4, 2007, at 5:34 AM, Jason van Zyl wrote: The biggest offender are providers posing as extensions: wagon- webdav is not an extension, it is a dependency required by the deploy plugin. In the exact same way you would specify an SCM provider as dependency of the release plugin if you needed, say, ClearCase support. These are not general extensions they are specifically required by certain plugins and should be defined as such to scope their use. Dumping wagon-webdav into the core is not very bright considering it's use is limited to the deploy plugin. This is an oversimplification. Wagons are also used in resolving artifacts, and while this is not a useful example WRT webdav, the ftp or scp wagons could easily be required for resolving dependencies...which is not a plugin task. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john - 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
Abolishing Extensions in 2.1
After trying to chase down a problem with extensions it became very clear to me that we have mixed concerns with extensions and it just makes the core crappy. The biggest offender are providers posing as extensions: wagon-webdav is not an extension, it is a dependency required by the deploy plugin. In the exact same way you would specify an SCM provider as dependency of the release plugin if you needed, say, ClearCase support. These are not general extensions they are specifically required by certain plugins and should be defined as such to scope their use. Dumping wagon-webdav into the core is not very bright considering it's use is limited to the deploy plugin. People have also used extensions to make available certain resources like checkstyle rules. Are these also not dependencies of a given plugin? Finally, the only things that in my opinion count as extensions are addition components that augment core functionality: artifact resolvers, version conflict resolvers, profile activator, project builders and the like. These should have an element like coreExtensions/ or something like it. Look at the extensions element and it begs the questions and extension to what exactly. For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? 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: Abolishing Extensions in 2.1
On 04/09/2007, at 7:34 PM, Jason van Zyl wrote: After trying to chase down a problem with extensions it became very clear to me that we have mixed concerns with extensions and it just makes the core crappy. The biggest offender are providers posing as extensions: wagon- webdav is not an extension, it is a dependency required by the deploy plugin. In the exact same way you would specify an SCM provider as dependency of the release plugin if you needed, say, ClearCase support. These are not general extensions they are specifically required by certain plugins and should be defined as such to scope their use. Dumping wagon-webdav into the core is not very bright considering it's use is limited to the deploy plugin. Agree - but currently the thing that uses those wagons is in the core I think (the artifact deployer) - so that would need to be separated into a dependency only used by the deploy plugin. The case is the same for wagon-ssh - though in that case it can be used to download so would need to be in the core. People have also used extensions to make available certain resources like checkstyle rules. Are these also not dependencies of a given plugin? Yeah, and that's definitely recommended - I think they've only ever wound up as extensions to work around bugs in the plugin dependencies. Finally, the only things that in my opinion count as extensions are addition components that augment core functionality: artifact resolvers, version conflict resolvers, profile activator, project builders and the like. These should have an element like coreExtensions/ or something like it. Look at the extensions element and it begs the questions and extension to what exactly. Agreed For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? I don't see a need to rush - for now, I would go with a deprecation on extensions / instead of dropping it. Once active collections are in place then there should be no more need for them since as I understand it you basically have nothing in the core then and just pull them in where they are needed for wagons and scm providers. So we could look at dropping them out in the next version. 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: Abolishing Extensions in 2.1
On Sep 4, 2007, at 5:34 AM, Jason van Zyl wrote: The biggest offender are providers posing as extensions: wagon- webdav is not an extension, it is a dependency required by the deploy plugin. In the exact same way you would specify an SCM provider as dependency of the release plugin if you needed, say, ClearCase support. These are not general extensions they are specifically required by certain plugins and should be defined as such to scope their use. Dumping wagon-webdav into the core is not very bright considering it's use is limited to the deploy plugin. This is an oversimplification. Wagons are also used in resolving artifacts, and while this is not a useful example WRT webdav, the ftp or scp wagons could easily be required for resolving dependencies...which is not a plugin task. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
RE: Abolishing Extensions in 2.1
+1 -Original Message- SNIP For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abolishing Extensions in 2.1
What are the impacts of plugins with use extensions as a way to override the default build lifecycle? ie ( pde-maven-plugin, native-maven-plugin ) -D On 9/4/07, Brian E. Fox [EMAIL PROTECTED] wrote: +1 -Original Message- SNIP For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? 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] - 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: Abolishing Extensions in 2.1
On 4 Sep 07, at 11:55 AM 4 Sep 07, Dan Tran wrote: What are the impacts of plugins with use extensions as a way to override the default build lifecycle? ie ( pde-maven-plugin, native-maven- plugin ) There's another use case and that should also be made more clear, but ideally plugin metadata should say a contribution is being made and then we can act accordingly. So again another example of how extensions are generally confusing, I forgot about that use case. -D On 9/4/07, Brian E. Fox [EMAIL PROTECTED] wrote: +1 -Original Message- SNIP For 2.1 I would like to use providers stated as dependencies which they are (easy to do in corporate builds), and the rest are core components. John has been working on some active collections, and I think they can be finished so that we could clarify how the system is augmented by 2.1-alpha-2. Anyone have any problems with this clarification? 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] - 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] 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]
