Re: Plugins with Annotations ETA
Omission ! I will fix that. Thanks for review and doc fix :-) -- Olivier Le 12 mai 2012 17:22, "Hervé BOUTEMY" a écrit : > great! well done! > > working on documentation, I found something strange: @Component annotation > doesn't provide readonly nor required attributes, that are available in > Mojo > Javadoc Tags. Is this expected or a simple omission? > > Regards, > > Hervé > > Le samedi 12 mai 2012 12:30:31 Olivier Lamy a écrit : > > so all done :-). > > > > 2012/5/12 Olivier Lamy : > > > Update: help generation works now. > > > I have created a branch of compiler plugin using annotations as a > > > sample: > > > > https://svn.apache.org/repos/asf/maven/plugins/branches/maven-compiler- > > > plugin-annotations/ > > > > > > Now my idea is to create a branch 2.x from the current and merge the > > > branch in trunk. > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Plugins with Annotations ETA
great! well done! working on documentation, I found something strange: @Component annotation doesn't provide readonly nor required attributes, that are available in Mojo Javadoc Tags. Is this expected or a simple omission? Regards, Hervé Le samedi 12 mai 2012 12:30:31 Olivier Lamy a écrit : > so all done :-). > > 2012/5/12 Olivier Lamy : > > Update: help generation works now. > > I have created a branch of compiler plugin using annotations as a > > sample: > > https://svn.apache.org/repos/asf/maven/plugins/branches/maven-compiler- > > plugin-annotations/ > > > > Now my idea is to create a branch 2.x from the current and merge the > > branch in trunk. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
so all done :-). 2012/5/12 Olivier Lamy : > Update: help generation works now. > I have created a branch of compiler plugin using annotations as a > sample: > https://svn.apache.org/repos/asf/maven/plugins/branches/maven-compiler-plugin-annotations/ > > Now my idea is to create a branch 2.x from the current and merge the > branch in trunk. > > > > 2012/5/9 Olivier Lamy : >> Hi, >> So I have pushed some stuff on supporting plugin descriptor generation >> from annotations as described here [1]. >> I have added support of having annotations from parent classes even if >> they are not in the same project (from reactors and/or dependencies). >> BTW we still need to do some javadoc parsing for @deprecated, @since >> and comments for class/field description. So if annotations comes from >> reactor module (easy to scan sources) but if comes from a dependency I >> try to get the sources from the artifact with try to resolve the same >> artifact with classifier sources. >> >> All is in the branch [2]. Note version bump to 3.0-SNAPSHOT. >> As the scanning tru asm must be done on compiled classes an extra >> configuration is needed: >> >> >> org.apache.maven.plugins >> maven-plugin-plugin >> 3.0-SNAPSHOT >> >> true >> >> >> >> mojo-descriptor >> process-classes >> >> descriptor >> >> >> >> >> >> You can have a look at the its >> http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/maven-plugin-plugin/src/it/annotation* >> >> I still have an issue to fix for help generation. Currently the help >> java mojo source is generated too early in the lifecycle so the plugin >> descriptor from annotations is not yet available. >> I will probably rewrite the help stuff to have a generic classes which >> simply read the plugin descriptor file so need to have the plugin >> descriptor available. >> >> Comments welcome :-) >> >> Thanks, >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> [1] >> https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins >> [2] http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/ > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
Update: help generation works now. I have created a branch of compiler plugin using annotations as a sample: https://svn.apache.org/repos/asf/maven/plugins/branches/maven-compiler-plugin-annotations/ Now my idea is to create a branch 2.x from the current and merge the branch in trunk. 2012/5/9 Olivier Lamy : > Hi, > So I have pushed some stuff on supporting plugin descriptor generation > from annotations as described here [1]. > I have added support of having annotations from parent classes even if > they are not in the same project (from reactors and/or dependencies). > BTW we still need to do some javadoc parsing for @deprecated, @since > and comments for class/field description. So if annotations comes from > reactor module (easy to scan sources) but if comes from a dependency I > try to get the sources from the artifact with try to resolve the same > artifact with classifier sources. > > All is in the branch [2]. Note version bump to 3.0-SNAPSHOT. > As the scanning tru asm must be done on compiled classes an extra > configuration is needed: > > > org.apache.maven.plugins > maven-plugin-plugin > 3.0-SNAPSHOT > > true > > > > mojo-descriptor > process-classes > > descriptor > > > > > > You can have a look at the its > http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/maven-plugin-plugin/src/it/annotation* > > I still have an issue to fix for help generation. Currently the help > java mojo source is generated too early in the lifecycle so the plugin > descriptor from annotations is not yet available. > I will probably rewrite the help stuff to have a generic classes which > simply read the plugin descriptor file so need to have the plugin > descriptor available. > > Comments welcome :-) > > Thanks, > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > [1] > https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins > [2] http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/ -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
@java.lang.Deprecated misses not only the description text but also a 'since'
field.
It would be really important to know since when a method is deprecated...
LieGrue,
strub
- Original Message -
> From: Olivier Lamy
> To: Maven Developers List
> Cc:
> Sent: Thursday, May 10, 2012 9:34 PM
> Subject: Re: Plugins with Annotations ETA
>
> 2012/5/10 Jesse Glick :
>> On 05/09/2012 12:56 PM, Olivier Lamy wrote:
>>>
>>> we still need to do some javadoc parsing for @deprecated
>>
>>
>> Just look for @Deprecated - the real annotation - instead. (Note that javac
>> will warn you if you have the Javadoc tag without the annotation.)
>>
>>
>>> @since and comments for class/field description. So if annotations
> comes
>>> from
>>> reactor module (easy to scan sources) but if comes from a dependency I
>>> try to get the sources from the artifact with try to resolve the same
>>> artifact with classifier sources.
>>
>>
>> Would be simpler to define true annotations (marked @Documented) for the
>> things you use, e.g. @Since or @Description. Then there is no need to look
>> for sources of binary dependencies, and no need to parse them. You are also
>> insulated against Java language changes, and can interoperate properly with
>> other JVM languages compatible with JSR 175.
>
> I have this idea first too using only annotations but I don't have
> text in this anno @Deprecated("because bla bla")
> Agree on @Since,
> @Description looks nice but I found a bit ugly something like
>
> @Description("
> The role names of mojo extractors to use. If not set, all mojo
> extractors will be used. If set to an empty extractor name, no mojo
> extractors will be used. Example:
>
>
>
>
>
>
>
>
>
>
> bsh
>
> ")
>
> And furthermore published javadoc won't as nice as today :-)
>
> Others ?
>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
2012/5/10 Jesse Glick :
> On 05/09/2012 12:56 PM, Olivier Lamy wrote:
>>
>> we still need to do some javadoc parsing for @deprecated
>
>
> Just look for @Deprecated - the real annotation - instead. (Note that javac
> will warn you if you have the Javadoc tag without the annotation.)
>
>
>> @since and comments for class/field description. So if annotations comes
>> from
>> reactor module (easy to scan sources) but if comes from a dependency I
>> try to get the sources from the artifact with try to resolve the same
>> artifact with classifier sources.
>
>
> Would be simpler to define true annotations (marked @Documented) for the
> things you use, e.g. @Since or @Description. Then there is no need to look
> for sources of binary dependencies, and no need to parse them. You are also
> insulated against Java language changes, and can interoperate properly with
> other JVM languages compatible with JSR 175.
I have this idea first too using only annotations but I don't have
text in this anno @Deprecated("because bla bla")
Agree on @Since,
@Description looks nice but I found a bit ugly something like
@Description("
The role names of mojo extractors to use. If not set, all mojo
extractors will be used. If set to an empty extractor name, no mojo
extractors will be used. Example:
bsh
")
And furthermore published javadoc won't as nice as today :-)
Others ?
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
On 05/09/2012 12:56 PM, Olivier Lamy wrote: we still need to do some javadoc parsing for @deprecated Just look for @Deprecated - the real annotation - instead. (Note that javac will warn you if you have the Javadoc tag without the annotation.) @since and comments for class/field description. So if annotations comes from reactor module (easy to scan sources) but if comes from a dependency I try to get the sources from the artifact with try to resolve the same artifact with classifier sources. Would be simpler to define true annotations (marked @Documented) for the things you use, e.g. @Since or @Description. Then there is no need to look for sources of binary dependencies, and no need to parse them. You are also insulated against Java language changes, and can interoperate properly with other JVM languages compatible with JSR 175. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
Sorry to hear that you have no fun hacking here anymore. But just to share some thoughts about the groovy-maven stuff. I can certainly see that there was lots of bad timing around on both sides in those days. But the argument for _not_ checking this in to maven 1:1 was mainly because this feature a.) doesn't really fit 100% with the declarative approach of maven but is more the old 'imperative' one. The very explicit idea was always to only do imperative tasks in plugins and _not_ in a normal project description. b.) it imo doesn't work out to throw 2 years of outside work onto a COMMUNITY which had no way to make any decisions but should rather 'take it as is or leave it'. This stuff is fairly complex and has lots of dependencies and impact. It would have been needed to do a complete IP sanity check, check all the projects history, identify and rewrite all outside contributions, review the used pattern, build some community, etc etc. I don't like to stress that there would have been better ways to improve maven in this direction, because we all know that there is not always the perfect time for this stuff. Afair our response was exactly that: we would need much more time to incorporate this properly and we will for sure _not_ pull this stuff in 1:1 before we have a detailed clue what it does. You also don't eat stuff where you have no clue what is in it, right? LieGrue, strub - Original Message - > From: Jason van Zyl > To: Maven Developers List > Cc: > Sent: Thursday, May 10, 2012 1:15 AM > Subject: Re: Plugins with Annotations ETA > > > On May 9, 2012, at 3:30 PM, Mark Derricutt wrote: > >> On 10/05/12 7:47 AM, Jason van Zyl wrote: >>> The only thing I would like to sync up on is a couple changes I want to > make to the plugin manager to make sure the current plugin packaging, the > plugin > packaging you're making and the plugin packaging I'm working on in Tesla > all work together without conflicting. Anyone should theoretically be able to > make a toolchain and allow users to take >> Is there any intent to merge any of the etesla stuff back into Apache Maven > core at all? ( I'd really love to see Atom POM in some 'official > blessed' manner ). > > I plan to do the odd patch and help with extensibility for what I would like > to > do in Tesla, but as far as merging the work no plans. Apache nearly expunged > all > my passion for innovating and doing open source in general. I've been happy > again lately hacking with folks like Dhanji and I personally don't plan to > contribute anything significant to Apache ever again. I speak here purely for > myself. The overhead for innovating at Apache is just too high for me. Maven > has > stagnated and I believe that's fairly visible to most users and I can't > really do anything about that from Apache. But I can from Tesla, and I've > enjoyed how Tesla has gone and I plan to continue working this way. I'm > having fun again and I can contribute to the ecosystem when I enjoy what I'm > doing. > > As far as Tesla goes and how it relates to builds it is a set of add-ons to > Maven. I have a couple small patches for the core to contribute back, but if > you > want to take advantage of build stuff in Tesla it's just adding some JARs to > the distribution. But Tesla is not only about builds. I am building > integration > across the build, IDE, repository manager, CI, provisioning and software > delivery in general. My work now I would categorize as being interested in > the > continuity across all the tools and the build is a small part of that. I can > move faster working by myself and selectively working with folks like > Dhanji, > Dain and Jeanfrancois. > > The core of Maven has been modified to the point where it is fully extensible > purely by the addition of JARs. Further to that Igor has created a mechanism > that allows extension by configuration so that upon startup Maven can alter > its > functionality by downloading new extensions on the fly. This Sonatype is > likely > to contribute back and once that is done anyone should be able to extend > Maven > easily whether it be for individual use or for thousands of developers within > a > corporation. > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > the course of true love never did run smooth ... > > -- Shakespeare > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
On May 9, 2012, at 3:30 PM, Mark Derricutt wrote: > On 10/05/12 7:47 AM, Jason van Zyl wrote: >> The only thing I would like to sync up on is a couple changes I want to make >> to the plugin manager to make sure the current plugin packaging, the plugin >> packaging you're making and the plugin packaging I'm working on in Tesla all >> work together without conflicting. Anyone should theoretically be able to >> make a toolchain and allow users to take > Is there any intent to merge any of the etesla stuff back into Apache Maven > core at all? ( I'd really love to see Atom POM in some 'official blessed' > manner ). I plan to do the odd patch and help with extensibility for what I would like to do in Tesla, but as far as merging the work no plans. Apache nearly expunged all my passion for innovating and doing open source in general. I've been happy again lately hacking with folks like Dhanji and I personally don't plan to contribute anything significant to Apache ever again. I speak here purely for myself. The overhead for innovating at Apache is just too high for me. Maven has stagnated and I believe that's fairly visible to most users and I can't really do anything about that from Apache. But I can from Tesla, and I've enjoyed how Tesla has gone and I plan to continue working this way. I'm having fun again and I can contribute to the ecosystem when I enjoy what I'm doing. As far as Tesla goes and how it relates to builds it is a set of add-ons to Maven. I have a couple small patches for the core to contribute back, but if you want to take advantage of build stuff in Tesla it's just adding some JARs to the distribution. But Tesla is not only about builds. I am building integration across the build, IDE, repository manager, CI, provisioning and software delivery in general. My work now I would categorize as being interested in the continuity across all the tools and the build is a small part of that. I can move faster working by myself and selectively working with folks like Dhanji, Dain and Jeanfrancois. The core of Maven has been modified to the point where it is fully extensible purely by the addition of JARs. Further to that Igor has created a mechanism that allows extension by configuration so that upon startup Maven can alter its functionality by downloading new extensions on the fly. This Sonatype is likely to contribute back and once that is done anyone should be able to extend Maven easily whether it be for individual use or for thousands of developers within a corporation. > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: Plugins with Annotations ETA
2012/5/9 Jason van Zyl : > > On May 9, 2012, at 3:23 PM, Olivier Lamy wrote: > >> 2012/5/9 Jason van Zyl : >>> The only thing I might suggest is that you create a hybrid scanner that can >>> deal with the old and new. It looks like you've already looked at [1], but >>> the hybrid scanner is here[2]. >> Thanks but this mix scanning is already implemented in the branch. > > In one gleaner? I didn't see that, where's that? The class JavaAnnotationsMojoDescriptorExtractor has a method called populateDataFromJavadoc which enhance datamodel obtained from annotations scanning > >> Currently the only missing part is the help generation. We probably >> need to think differently than a java source generation from the >> plugin descriptor. > > Agreed. Generating source is not a good idea. Generate a descriptor with > detailed information that can be parsed and utilized by other systems. Tool > tips in IDEs could benefit from this descriptor for showing users how to use > a plugin. > >>> >>> The only thing I would like to sync up on is a couple changes I want to >>> make to the plugin manager to make sure the current plugin packaging, the >>> plugin packaging you're making and the plugin packaging I'm working on in >>> Tesla all work together without conflicting. Anyone should theoretically be >>> able to make a toolchain and allow users to take advantage of whatever they >>> wish, this wouldn't work right now but I'll prepare the necessary patches >>> for review. I am trying to create a more holistic approach to plugins for >>> incremental processing, seamless integration in m2eclipse (write a plugin >>> using the Tesla Plugin API and no need for a configurator), in the Tesla >>> Shell and non-Maven tools. >>> >>> I'll ping you when you're closer to being done and we can work on the >>> plugin manger changes together. >>> >>> [1]: https://github.com/etesla/tesla-plugin-api >>> [2]: >>> https://github.com/etesla/tesla-plugin-api/tree/master/tesla-plugin-tools-api/src/main/java/org/sonatype/maven/plugin/tools/java5/gleaner >>> >>> On May 9, 2012, at 11:56 AM, Olivier Lamy wrote: >>> Hi, So I have pushed some stuff on supporting plugin descriptor generation from annotations as described here [1]. I have added support of having annotations from parent classes even if they are not in the same project (from reactors and/or dependencies). BTW we still need to do some javadoc parsing for @deprecated, @since and comments for class/field description. So if annotations comes from reactor module (easy to scan sources) but if comes from a dependency I try to get the sources from the artifact with try to resolve the same artifact with classifier sources. All is in the branch [2]. Note version bump to 3.0-SNAPSHOT. As the scanning tru asm must be done on compiled classes an extra configuration is needed: org.apache.maven.plugins maven-plugin-plugin 3.0-SNAPSHOT true mojo-descriptor process-classes descriptor You can have a look at the its http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/maven-plugin-plugin/src/it/annotation* I still have an issue to fix for help generation. Currently the help java mojo source is generated too early in the lifecycle so the plugin descriptor from annotations is not yet available. I will probably rewrite the help stuff to have a generic classes which simply read the plugin descriptor file so need to have the plugin descriptor available. Comments welcome :-) Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy [1] https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins [2] http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> - >>> >>> happiness is like a butterfly: the more you chase it, the more it will >>> elude you, but if you turn your attention to other things, it will come >>> and sit softly on your shoulder ... >>> >>> -- Thoreau >>> >>> >>> >>> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> -
Re: Plugins with Annotations ETA
On May 9, 2012, at 3:23 PM, Olivier Lamy wrote: > 2012/5/9 Jason van Zyl : >> The only thing I might suggest is that you create a hybrid scanner that can >> deal with the old and new. It looks like you've already looked at [1], but >> the hybrid scanner is here[2]. > Thanks but this mix scanning is already implemented in the branch. In one gleaner? I didn't see that, where's that? > Currently the only missing part is the help generation. We probably > need to think differently than a java source generation from the > plugin descriptor. Agreed. Generating source is not a good idea. Generate a descriptor with detailed information that can be parsed and utilized by other systems. Tool tips in IDEs could benefit from this descriptor for showing users how to use a plugin. >> >> The only thing I would like to sync up on is a couple changes I want to make >> to the plugin manager to make sure the current plugin packaging, the plugin >> packaging you're making and the plugin packaging I'm working on in Tesla all >> work together without conflicting. Anyone should theoretically be able to >> make a toolchain and allow users to take advantage of whatever they wish, >> this wouldn't work right now but I'll prepare the necessary patches for >> review. I am trying to create a more holistic approach to plugins for >> incremental processing, seamless integration in m2eclipse (write a plugin >> using the Tesla Plugin API and no need for a configurator), in the Tesla >> Shell and non-Maven tools. >> >> I'll ping you when you're closer to being done and we can work on the plugin >> manger changes together. >> >> [1]: https://github.com/etesla/tesla-plugin-api >> [2]: >> https://github.com/etesla/tesla-plugin-api/tree/master/tesla-plugin-tools-api/src/main/java/org/sonatype/maven/plugin/tools/java5/gleaner >> >> On May 9, 2012, at 11:56 AM, Olivier Lamy wrote: >> >>> Hi, >>> So I have pushed some stuff on supporting plugin descriptor generation >>> from annotations as described here [1]. >>> I have added support of having annotations from parent classes even if >>> they are not in the same project (from reactors and/or dependencies). >>> BTW we still need to do some javadoc parsing for @deprecated, @since >>> and comments for class/field description. So if annotations comes from >>> reactor module (easy to scan sources) but if comes from a dependency I >>> try to get the sources from the artifact with try to resolve the same >>> artifact with classifier sources. >>> >>> All is in the branch [2]. Note version bump to 3.0-SNAPSHOT. >>> As the scanning tru asm must be done on compiled classes an extra >>> configuration is needed: >>> >>> >>>org.apache.maven.plugins >>>maven-plugin-plugin >>>3.0-SNAPSHOT >>> >>> true >>> >>> >>> >>>mojo-descriptor >>>process-classes >>> >>> descriptor >>> >>> >>> >>> >>> >>> You can have a look at the its >>> http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/maven-plugin-plugin/src/it/annotation* >>> >>> I still have an issue to fix for help generation. Currently the help >>> java mojo source is generated too early in the lifecycle so the plugin >>> descriptor from annotations is not yet available. >>> I will probably rewrite the help stuff to have a generic classes which >>> simply read the plugin descriptor file so need to have the plugin >>> descriptor available. >>> >>> Comments welcome :-) >>> >>> Thanks, >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> [1] >>> https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins >>> [2] http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/ >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> happiness is like a butterfly: the more you chase it, the more it will >> elude you, but if you turn your attention to other things, it will come >> and sit softly on your shoulder ... >> >> -- Thoreau >> >> >> >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http:
Re: Plugins with Annotations ETA
And btw make changes you need. I have added some its for basic use cases with annotations. 2012/5/9 Olivier Lamy : > 2012/5/9 Jason van Zyl : >> The only thing I might suggest is that you create a hybrid scanner that can >> deal with the old and new. It looks like you've already looked at [1], but >> the hybrid scanner is here[2]. > Thanks but this mix scanning is already implemented in the branch. > Currently the only missing part is the help generation. We probably > need to think differently than a java source generation from the > plugin descriptor. >> >> The only thing I would like to sync up on is a couple changes I want to make >> to the plugin manager to make sure the current plugin packaging, the plugin >> packaging you're making and the plugin packaging I'm working on in Tesla all >> work together without conflicting. Anyone should theoretically be able to >> make a toolchain and allow users to take advantage of whatever they wish, >> this wouldn't work right now but I'll prepare the necessary patches for >> review. I am trying to create a more holistic approach to plugins for >> incremental processing, seamless integration in m2eclipse (write a plugin >> using the Tesla Plugin API and no need for a configurator), in the Tesla >> Shell and non-Maven tools. >> >> I'll ping you when you're closer to being done and we can work on the plugin >> manger changes together. >> >> [1]: https://github.com/etesla/tesla-plugin-api >> [2]: >> https://github.com/etesla/tesla-plugin-api/tree/master/tesla-plugin-tools-api/src/main/java/org/sonatype/maven/plugin/tools/java5/gleaner >> >> On May 9, 2012, at 11:56 AM, Olivier Lamy wrote: >> >>> Hi, >>> So I have pushed some stuff on supporting plugin descriptor generation >>> from annotations as described here [1]. >>> I have added support of having annotations from parent classes even if >>> they are not in the same project (from reactors and/or dependencies). >>> BTW we still need to do some javadoc parsing for @deprecated, @since >>> and comments for class/field description. So if annotations comes from >>> reactor module (easy to scan sources) but if comes from a dependency I >>> try to get the sources from the artifact with try to resolve the same >>> artifact with classifier sources. >>> >>> All is in the branch [2]. Note version bump to 3.0-SNAPSHOT. >>> As the scanning tru asm must be done on compiled classes an extra >>> configuration is needed: >>> >>> >>> org.apache.maven.plugins >>> maven-plugin-plugin >>> 3.0-SNAPSHOT >>> >>> true >>> >>> >>> >>> mojo-descriptor >>> process-classes >>> >>> descriptor >>> >>> >>> >>> >>> >>> You can have a look at the its >>> http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/maven-plugin-plugin/src/it/annotation* >>> >>> I still have an issue to fix for help generation. Currently the help >>> java mojo source is generated too early in the lifecycle so the plugin >>> descriptor from annotations is not yet available. >>> I will probably rewrite the help stuff to have a generic classes which >>> simply read the plugin descriptor file so need to have the plugin >>> descriptor available. >>> >>> Comments welcome :-) >>> >>> Thanks, >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> [1] >>> https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins >>> [2] http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/ >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> happiness is like a butterfly: the more you chase it, the more it will >> elude you, but if you turn your attention to other things, it will come >> and sit softly on your shoulder ... >> >> -- Thoreau >> >> >> >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
On 10/05/12 7:47 AM, Jason van Zyl wrote: The only thing I would like to sync up on is a couple changes I want to make to the plugin manager to make sure the current plugin packaging, the plugin packaging you're making and the plugin packaging I'm working on in Tesla all work together without conflicting. Anyone should theoretically be able to make a toolchain and allow users to take Is there any intent to merge any of the etesla stuff back into Apache Maven core at all? ( I'd really love to see Atom POM in some 'official blessed' manner ). - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
2012/5/9 Jason van Zyl : > The only thing I might suggest is that you create a hybrid scanner that can > deal with the old and new. It looks like you've already looked at [1], but > the hybrid scanner is here[2]. Thanks but this mix scanning is already implemented in the branch. Currently the only missing part is the help generation. We probably need to think differently than a java source generation from the plugin descriptor. > > The only thing I would like to sync up on is a couple changes I want to make > to the plugin manager to make sure the current plugin packaging, the plugin > packaging you're making and the plugin packaging I'm working on in Tesla all > work together without conflicting. Anyone should theoretically be able to > make a toolchain and allow users to take advantage of whatever they wish, > this wouldn't work right now but I'll prepare the necessary patches for > review. I am trying to create a more holistic approach to plugins for > incremental processing, seamless integration in m2eclipse (write a plugin > using the Tesla Plugin API and no need for a configurator), in the Tesla > Shell and non-Maven tools. > > I'll ping you when you're closer to being done and we can work on the plugin > manger changes together. > > [1]: https://github.com/etesla/tesla-plugin-api > [2]: > https://github.com/etesla/tesla-plugin-api/tree/master/tesla-plugin-tools-api/src/main/java/org/sonatype/maven/plugin/tools/java5/gleaner > > On May 9, 2012, at 11:56 AM, Olivier Lamy wrote: > >> Hi, >> So I have pushed some stuff on supporting plugin descriptor generation >> from annotations as described here [1]. >> I have added support of having annotations from parent classes even if >> they are not in the same project (from reactors and/or dependencies). >> BTW we still need to do some javadoc parsing for @deprecated, @since >> and comments for class/field description. So if annotations comes from >> reactor module (easy to scan sources) but if comes from a dependency I >> try to get the sources from the artifact with try to resolve the same >> artifact with classifier sources. >> >> All is in the branch [2]. Note version bump to 3.0-SNAPSHOT. >> As the scanning tru asm must be done on compiled classes an extra >> configuration is needed: >> >> >> org.apache.maven.plugins >> maven-plugin-plugin >> 3.0-SNAPSHOT >> >> true >> >> >> >> mojo-descriptor >> process-classes >> >> descriptor >> >> >> >> >> >> You can have a look at the its >> http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/maven-plugin-plugin/src/it/annotation* >> >> I still have an issue to fix for help generation. Currently the help >> java mojo source is generated too early in the lifecycle so the plugin >> descriptor from annotations is not yet available. >> I will probably rewrite the help stuff to have a generic classes which >> simply read the plugin descriptor file so need to have the plugin >> descriptor available. >> >> Comments welcome :-) >> >> Thanks, >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> [1] >> https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins >> [2] http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
Its great to see this teamwork happening from the outside. Keep it up! manfred On Wed, May 9, 2012 12:47 pm, Jason van Zyl wrote: > The only thing I might suggest is that you create a hybrid scanner that > can deal with the old and new. It looks like you've already looked at [1], > but the hybrid scanner is here[2]. > > The only thing I would like to sync up on is a couple changes I want to > make to the plugin manager to make sure the current plugin packaging, the > plugin packaging you're making and the plugin packaging I'm working on in > Tesla all work together without conflicting. Anyone should theoretically > be able to make a toolchain and allow users to take advantage of whatever > they wish, this wouldn't work right now but I'll prepare the necessary > patches for review. I am trying to create a more holistic approach to > plugins for incremental processing, seamless integration in m2eclipse > (write a plugin using the Tesla Plugin API and no need for a > configurator), in the Tesla Shell and non-Maven tools. > > I'll ping you when you're closer to being done and we can work on the > plugin manger changes together. > > [1]: https://github.com/etesla/tesla-plugin-api > [2]: > https://github.com/etesla/tesla-plugin-api/tree/master/tesla-plugin-tools-api/src/main/java/org/sonatype/maven/plugin/tools/java5/gleaner > > On May 9, 2012, at 11:56 AM, Olivier Lamy wrote: > >> Hi, >> So I have pushed some stuff on supporting plugin descriptor generation >> from annotations as described here [1]. >> I have added support of having annotations from parent classes even if >> they are not in the same project (from reactors and/or dependencies). >> BTW we still need to do some javadoc parsing for @deprecated, @since >> and comments for class/field description. So if annotations comes from >> reactor module (easy to scan sources) but if comes from a dependency I >> try to get the sources from the artifact with try to resolve the same >> artifact with classifier sources. >> >> All is in the branch [2]. Note version bump to 3.0-SNAPSHOT. >> As the scanning tru asm must be done on compiled classes an extra >> configuration is needed: >> >> >>org.apache.maven.plugins >>maven-plugin-plugin >>3.0-SNAPSHOT >> >> true >> >> >> >>mojo-descriptor >>process-classes >> >> descriptor >> >> >> >> >> >> You can have a look at the its >> http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/maven-plugin-plugin/src/it/annotation* >> >> I still have an issue to fix for help generation. Currently the help >> java mojo source is generated too early in the lifecycle so the plugin >> descriptor from annotations is not yet available. >> I will probably rewrite the help stuff to have a generic classes which >> simply read the plugin descriptor file so need to have the plugin >> descriptor available. >> >> Comments welcome :-) >> >> Thanks, >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> [1] >> https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins >> [2] >> http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with Annotations ETA
The only thing I might suggest is that you create a hybrid scanner that can deal with the old and new. It looks like you've already looked at [1], but the hybrid scanner is here[2]. The only thing I would like to sync up on is a couple changes I want to make to the plugin manager to make sure the current plugin packaging, the plugin packaging you're making and the plugin packaging I'm working on in Tesla all work together without conflicting. Anyone should theoretically be able to make a toolchain and allow users to take advantage of whatever they wish, this wouldn't work right now but I'll prepare the necessary patches for review. I am trying to create a more holistic approach to plugins for incremental processing, seamless integration in m2eclipse (write a plugin using the Tesla Plugin API and no need for a configurator), in the Tesla Shell and non-Maven tools. I'll ping you when you're closer to being done and we can work on the plugin manger changes together. [1]: https://github.com/etesla/tesla-plugin-api [2]: https://github.com/etesla/tesla-plugin-api/tree/master/tesla-plugin-tools-api/src/main/java/org/sonatype/maven/plugin/tools/java5/gleaner On May 9, 2012, at 11:56 AM, Olivier Lamy wrote: > Hi, > So I have pushed some stuff on supporting plugin descriptor generation > from annotations as described here [1]. > I have added support of having annotations from parent classes even if > they are not in the same project (from reactors and/or dependencies). > BTW we still need to do some javadoc parsing for @deprecated, @since > and comments for class/field description. So if annotations comes from > reactor module (easy to scan sources) but if comes from a dependency I > try to get the sources from the artifact with try to resolve the same > artifact with classifier sources. > > All is in the branch [2]. Note version bump to 3.0-SNAPSHOT. > As the scanning tru asm must be done on compiled classes an extra > configuration is needed: > > >org.apache.maven.plugins >maven-plugin-plugin >3.0-SNAPSHOT > > true > > > >mojo-descriptor >process-classes > > descriptor > > > > > > You can have a look at the its > http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/maven-plugin-plugin/src/it/annotation* > > I still have an issue to fix for help generation. Currently the help > java mojo source is generated too early in the lifecycle so the plugin > descriptor from annotations is not yet available. > I will probably rewrite the help stuff to have a generic classes which > simply read the plugin descriptor file so need to have the plugin > descriptor available. > > Comments welcome :-) > > Thanks, > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > [1] > https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins > [2] http://svn.apache.org/repos/asf/maven/plugin-tools/branches/MPLUGIN-189/ > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
