GMaven Rewrite
Locked
12
12
GMaven Rewrite
 
|
Hello,
Sorry if this is the wrong list (it didn't look like [hidden email] was really used). I've been working on a rewrite of GMaven (http://github.com/keeganwitt/GMavenPlus). Some of the main goals of this project are: * Simplify the project for ease of future maintenance * Don't depend on any particular version of Groovy (so it can be as flexible as groovyc and also less needed maintenance) * Allow access to GroovyDoc tool through the plugin * Support for Groovy 1.8 * Breathe new life into an abandoned project that I feel is still very important It's not ready to release just yet (I welcome any feedback you might have), but it's far enough along now that I'd like to make you aware of it. If Jason Dillon isn't going to work on this anymore, would you be opposed to letting me pick up the GMaven project and release this as GMaven 2.0 when it's ready? -Keegan |
Re: GMaven Rewrite
|
Hi Keegan,
Great to know someone's picking up the flag! I think Jason's not working anymore on the project, so if a new maintainer is in sight, there's no reason why we wouldn't let him pick up the project and take care of it!
Looking forward to it! Guillaume
On Fri, Sep 9, 2011 at 07:28, Keegan Witt <[hidden email]> wrote: Hello, Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one |
Re: GMaven Rewrite
|
On Fri, 2011-09-09 at 08:45 +0200, Guillaume Laforge wrote:
> Hi Keegan, > > > Great to know someone's picking up the flag! > I think Jason's not working anymore on the project, so if a new > maintainer is in sight, there's no reason why we wouldn't let him pick > up the project and take care of it! > > > Looking forward to it! > > > Guillaume > development happening via GitHub. And any last vestiges in the Subversion repository deleted so as to avoid confusion. (It remain in Subversion of course, just not visible in HEAD. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[hidden email] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [hidden email] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder |
signature.asc (205 bytes)
Re: GMaven Rewrite
|
|
It can be there, it can be elsewhere, I don't mind too much.
The key thing is that I'd like the maintainer to feel at ease, otherwise, the maintainer might stop if he things a particular requirement that we'd impose would be preventing them from contributing actively.
On Fri, Sep 9, 2011 at 09:49, Russel Winder <[hidden email]> wrote:
Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one |
Re: GMaven Rewrite
|
|
On Fri, 2011-09-09 at 09:53 +0200, Guillaume Laforge wrote:
> It can be there, it can be elsewhere, I don't mind too much. > The key thing is that I'd like the maintainer to feel at ease, > otherwise, the maintainer might stop if he things a particular > requirement that we'd impose would be preventing them from > contributing actively. > There are a number of issues here, somewhat inter-related. If all the Groovy infrastructure is dispersed willy-nilly, then there is no focus of Groovy activity, and hence less community. Also it means there is no one place that people can go to for resources. Findability of things is crucial here to create a snowball of activity. There being a default expectation of core Groovy infrastructure being based in the core Groovy development sphere contributes to the community. Nothing wrong with there being activity outside this, but there needs to be a clean and simple way of registering that activity in the core sphere so that it is easily findable. The Go language team have this well in hand evolving their use of a wiki into explicit use of goinstall and a registry. SCons is trying to dead down this route for tools based on Mercurial/BitBucket. As you say, it has to be about support for activity, but this and community building by support at the centre (albeit with a few constraints) are not in conflict. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[hidden email] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [hidden email] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder |
Re: GMaven Rewrite
|
|
Here, we were speaking of where the source code is situated.
It's just a matter to link to that particular place. But the GMaven doco, support, etc, can stay on Groovy's wiki, on Groovy's mailing-list, etc, so as to keep the community and interest in the usual place.
On Fri, Sep 9, 2011 at 10:15, Russel Winder <[hidden email]> wrote:
Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one |
Re: GMaven Rewrite
|
|
Thanks for your thoughtfulness Guillaume, but I think it makes sense to put under the Codehaus banner. This way it's easy to find, and under the control of the organization rather than an individual. I only put it on GitHub because it was an expedient way to get started. I like Russel's idea of deleting the old stuff but not deleting the repo so everything is still accessible for posterity's sake.
Obviously I'd also like to update the wiki, and Jira needs triaging pretty badly. Do I need to contact Jason for access? I couldn't find any documentation on the procedure for requesting developer access to a project. |
Re: GMaven Rewrite
|
|
Hi,
On Fri, Sep 9, 2011 at 16:34, keeganwitt <[hidden email]> wrote: Thanks for your thoughtfulness Guillaume, but I think it makes sense to put Cool :-) Closer to home is better, but I didn't want to impose that on you. Obviously I'd also like to update the wiki, and Jira needs triaging pretty You can always contact him to see what he thinks of all this, or if he still wants to contribute, etc. It's more polite to ask :-)
I couldn't find any The sources are there:
Which means this is part of the GMaven top-level project. You'll have to signup on the Xircles admin interface: http://xircles.codehaus.org/signup
And request membership here: http://xircles.codehaus.org/projects/gmaven That said, as I'm not a "despot", I can't moderate applications, so only Jason Dillon can do that.
But if he doesn't, we can make that happen with Codehaus' admins' help. Guillaume
Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one |
Re: GMaven Rewrite
|
In reply to this post by keeganwitt
I just wanted to add that I recently get more and more requests
for an up-to-date version of GMaven, sometimes even considered a must-have feature for adopting Groovy in the enterprise. So, I'm very glad to see progress on this front. Go for it! cheers Dierk --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: GMaven Rewrite
|
|
In reply to this post by Guillaume Laforge
Keegan, perhaps you could add a few words on the GMaven pages to tell that there's new work done in this area?
And point at your current fork? (till the day you take over the GMaven Codehaus project and put your changes there). Guillaume
On Fri, Sep 9, 2011 at 17:18, Guillaume Laforge <[hidden email]> wrote: Hi, Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one |
Re: GMaven Rewrite
|
|
In reply to this post by Guillaume Laforge
Thank you for explaining. I'm talking to Jason about this now.
-Keegan
|
Re: GMaven Rewrite
|
Sorry Ive not really been reading this list for a while now.
Anyways, I see you've put in a xircles request and I've accepted it. There is also "Ben Tilford" request... any idea who that is? So you now should have developer access to all gmaven bits. * * * BTW, I'm not really sure that your use of reflection is really a good idea. IMO its fragile and will be difficult to adapt to actually api changes. Part of the reason the runtime's existed was that there were incompatible API changes between versions (though IIRC it was mostly a different between old 1.0 and the newer releases). Anyway, the runtime was just an common abstraction layer to allow integration to be done for a specific Groovy release using its native API and allow Maven to invoke it. This was novel for a while, but IMO ended up being a PITA to debug/reproduce users problems. GMaven 2.+ was planned to have support for a single major version of Groovy per version of the plugin (very similar to how the GWT maven plugin works)... but alas I got way to frustrated with things to continue active development (though I still use gmaven from time to time). As you have found out the major issue with GMaven is the integration of stub-compilation. The Groovy stub-compiler simply does not always generate proper .java sources. Groovyc doesn't seem to have any problem with this, and thus the mindset of the main compiler developers is/was that it was not broken. Another point of contention was control over the .java comilation, which groovyc wants to have control over, but where in Maven, the maven-compiler-plugin handle this (and there is configuration for that plugin which would then have to be duplicated and maintained with the groovyc java compiler integration which makes it undesirable to use). If the groovy-eclipse-compiler stuff is working, then that would probably be the best option for compilation: http://groovier.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven It may be that gmaven could integrate ^^^ and then simplify its configuration/use... but I've not looked into this compiler extension much. Last I checked it needed some Eclipse artifacts which were not published anywhere... maybe thats fixed now. Hopefully it doesn't need to download the world-of-Eclipse-artifacts either (but then again this is Maven so that is almost expected). Another key issue with the stub-compiler, was the ability to use Groovy to write Maven plugins. Last I checked, Maven still needs stupid javadoc annotations on sources to wire up plugin components. The stub-compiler was critical to this effort, and was modified to allow the Javadocs on the original .groovy sources to be retained in the output .java sources. So, even if you were not using mixed java + groovy, you'd still need to have the stub-compiler configured, so that the .java sources would generate so that the Maven plugin tooling could figure out how to wire up the plugin's components. Looks like the only option here for this is the additional work in the GMaven stub-compiler (for the 1.6+ runtime IIRC which uses the core stub-compiler w/some changes) as the core stub-compiler and the groovy-eclipse-compiler won't get the .groovy -> .java w/javadocs. In retrospect, it would have probably been easier to make proper annotations and implement the tooling required to use those... but then again some of this stuff was started long ago when 1.5 and @Annotations were not even readily available for use in Maven (and using them could mean that many folks on <1.5 couldn't use it). Anyways finally now in Maven3 we can use Java5 features, though I still don't think anyone has gotten to official java5 annotation support (though I recall seeing something about that somewhere sometime ago). Some of my initial reasons for writing GMaven was to all me to write Maven plugins with Groovy, and implement small little build hacks here and there with Groovy. W/so many issues with the stub-compiler and really no one on the core compiler team to help resolve these (if you look at the archive you can see threads of us spinning over and over and going nowhere). Now with Maven3 I think that using source-based annotations is a HUGE PITA especially with all of the issues with the stub-compiler. So if the groovy-eclipse-compiler works for normal compilation, then its probably worth using that, and then implement real annotations to hook up the Maven plugins support... and live with Maven 3+ (which is a good thing anyways IMO). --jason On Sep 12, 2011, at 11:48 AM, keeganwitt wrote: > Thank you for explaining. I'm talking to Jason about this now. > > -Keegan > > > > Guillaume Laforge wrote: >> >> Hi, >> >> On Fri, Sep 9, 2011 at 16:34, keeganwitt <[hidden email]> >> wrote: >> >>> Thanks for your thoughtfulness Guillaume, but I think it makes sense to >>> put >>> under the Codehaus banner. This way it's easy to find, and under the >>> control of the organization rather than an individual. I only put it on >>> GitHub because it was an expedient way to get started. I like Russel's >>> idea >>> of deleting the old stuff but not deleting the repo so everything is >>> still >>> accessible for posterity's sake. >>> >> >> Cool :-) >> Closer to home is better, but I didn't want to impose that on you. >> >> Obviously I'd also like to update the wiki, and Jira needs triaging pretty >>> badly. Do I need to contact Jason for access? >> >> >> You can always contact him to see what he thinks of all this, or if he >> still >> wants to contribute, etc. >> It's more polite to ask :-) >> >> >>> I couldn't find any >>> documentation on the procedure for requesting developer access to a >>> project. >>> >> >> The sources are there: >> http://svn.codehaus.org/gmaven/ >> Which means this is part of the GMaven top-level project. >> You'll have to signup on the Xircles admin interface: >> http://xircles.codehaus.org/signup >> And request membership here: http://xircles.codehaus.org/projects/gmaven >> That said, as I'm not a "despot", I can't moderate applications, so only >> Jason Dillon can do that. >> But if he doesn't, we can make that happen with Codehaus' admins' help. >> >> Guillaume >> >> >> >>> >>> -- >>> View this message in context: >>> http://groovy.329449.n5.nabble.com/GMaven-Rewrite-tp4785090p4786572.html >>> Sent from the groovy - dev mailing list archive at Nabble.com. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >> >> >> -- >> Guillaume Laforge >> Groovy Project Manager >> Head of Groovy Development at SpringSource >> http://www.springsource.com/g2one >> > > > -- > View this message in context: http://groovy.329449.n5.nabble.com/GMaven-Rewrite-tp4785090p4795412.html > Sent from the groovy - dev mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: GMaven Rewrite
|
I've been keeping quiet on this topic, but since Jason mentioned some
stuff that I have worked, I'll chime in. Yes, the groovy-eclipse-compiler has been available for a while and is being used by quite a few people. There are advantages and disadvantages to both approaches (groovy-eclipse-compiler and gmaven) and they are summarized here: http://groovier.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven#Groovy-EclipsecompilerpluginforMaven-WhyanotherGroovycompilerforMaven%3FWhataboutGMaven%3F The primary advantage of groovy-eclipse-compiler is the lack of stub generation, which means that compilation is faster and you don't get any arcane stub errors. The main disadvantage is the inability to drop in any compiler version you like (you are stuck with 1.7.10 or 1.8.0 right now). These are fundamental differences that are built into the architecture of the two approaches. The other limitations of groovy-eclipse-compiler are mostly around because we haven't had time to implement them (eg- groovy-doc generation, and groovy mojos etc). The choice on which groovy-maven integration is best is really something that the community as a whole should be making. In my opinion, however, having two approaches is not optimal and is confusing for newcomers. I originally created the groovy-eclipse-compiler in response to the stub problems that gmaven was having. And I am more than happy to help if someone is willing to work on some of the current limitations of the groovy-eclipse-compiler. On Sat, Sep 17, 2011 at 1:30 PM, Jason Dillon <[hidden email]> wrote: > Sorry Ive not really been reading this list for a while now. > > Anyways, I see you've put in a xircles request and I've accepted it. There is also "Ben Tilford" request... any idea who that is? > > So you now should have developer access to all gmaven bits. > > * * * > > BTW, I'm not really sure that your use of reflection is really a good idea. IMO its fragile and will be difficult to adapt to actually api changes. Part of the reason the runtime's existed was that there were incompatible API changes between versions (though IIRC it was mostly a different between old 1.0 and the newer releases). Anyway, the runtime was just an common abstraction layer to allow integration to be done for a specific Groovy release using its native API and allow Maven to invoke it. This was novel for a while, but IMO ended up being a PITA to debug/reproduce users problems. GMaven 2.+ was planned to have support for a single major version of Groovy per version of the plugin (very similar to how the GWT maven plugin works)... but alas I got way to frustrated with things to continue active development (though I still use gmaven from time to time). > > As you have found out the major issue with GMaven is the integration of stub-compilation. The Groovy stub-compiler simply does not always generate proper .java sources. Groovyc doesn't seem to have any problem with this, and thus the mindset of the main compiler developers is/was that it was not broken. Another point of contention was control over the .java comilation, which groovyc wants to have control over, but where in Maven, the maven-compiler-plugin handle this (and there is configuration for that plugin which would then have to be duplicated and maintained with the groovyc java compiler integration which makes it undesirable to use). > > If the groovy-eclipse-compiler stuff is working, then that would probably be the best option for compilation: > > http://groovier.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven > > It may be that gmaven could integrate ^^^ and then simplify its configuration/use... but I've not looked into this compiler extension much. Last I checked it needed some Eclipse artifacts which were not published anywhere... maybe thats fixed now. Hopefully it doesn't need to download the world-of-Eclipse-artifacts either (but then again this is Maven so that is almost expected). > > Another key issue with the stub-compiler, was the ability to use Groovy to write Maven plugins. Last I checked, Maven still needs stupid javadoc annotations on sources to wire up plugin components. The stub-compiler was critical to this effort, and was modified to allow the Javadocs on the original .groovy sources to be retained in the output .java sources. So, even if you were not using mixed java + groovy, you'd still need to have the stub-compiler configured, so that the .java sources would generate so that the Maven plugin tooling could figure out how to wire up the plugin's components. Looks like the only option here for this is the additional work in the GMaven stub-compiler (for the 1.6+ runtime IIRC which uses the core stub-compiler w/some changes) as the core stub-compiler and the groovy-eclipse-compiler won't get the .groovy -> .java w/javadocs. > > In retrospect, it would have probably been easier to make proper annotations and implement the tooling required to use those... but then again some of this stuff was started long ago when 1.5 and @Annotations were not even readily available for use in Maven (and using them could mean that many folks on <1.5 couldn't use it). Anyways finally now in Maven3 we can use Java5 features, though I still don't think anyone has gotten to official java5 annotation support (though I recall seeing something about that somewhere sometime ago). > > Some of my initial reasons for writing GMaven was to all me to write Maven plugins with Groovy, and implement small little build hacks here and there with Groovy. W/so many issues with the stub-compiler and really no one on the core compiler team to help resolve these (if you look at the archive you can see threads of us spinning over and over and going nowhere). > > Now with Maven3 I think that using source-based annotations is a HUGE PITA especially with all of the issues with the stub-compiler. So if the groovy-eclipse-compiler works for normal compilation, then its probably worth using that, and then implement real annotations to hook up the Maven plugins support... and live with Maven 3+ (which is a good thing anyways IMO). > > --jason > > > On Sep 12, 2011, at 11:48 AM, keeganwitt wrote: > >> Thank you for explaining. I'm talking to Jason about this now. >> >> -Keegan >> >> >> >> Guillaume Laforge wrote: >>> >>> Hi, >>> >>> On Fri, Sep 9, 2011 at 16:34, keeganwitt <[hidden email]> >>> wrote: >>> >>>> Thanks for your thoughtfulness Guillaume, but I think it makes sense to >>>> put >>>> under the Codehaus banner. This way it's easy to find, and under the >>>> control of the organization rather than an individual. I only put it on >>>> GitHub because it was an expedient way to get started. I like Russel's >>>> idea >>>> of deleting the old stuff but not deleting the repo so everything is >>>> still >>>> accessible for posterity's sake. >>>> >>> >>> Cool :-) >>> Closer to home is better, but I didn't want to impose that on you. >>> >>> Obviously I'd also like to update the wiki, and Jira needs triaging pretty >>>> badly. Do I need to contact Jason for access? >>> >>> >>> You can always contact him to see what he thinks of all this, or if he >>> still >>> wants to contribute, etc. >>> It's more polite to ask :-) >>> >>> >>>> I couldn't find any >>>> documentation on the procedure for requesting developer access to a >>>> project. >>>> >>> >>> The sources are there: >>> http://svn.codehaus.org/gmaven/ >>> Which means this is part of the GMaven top-level project. >>> You'll have to signup on the Xircles admin interface: >>> http://xircles.codehaus.org/signup >>> And request membership here: http://xircles.codehaus.org/projects/gmaven >>> That said, as I'm not a "despot", I can't moderate applications, so only >>> Jason Dillon can do that. >>> But if he doesn't, we can make that happen with Codehaus' admins' help. >>> >>> Guillaume >>> >>> >>> >>>> >>>> -- >>>> View this message in context: >>>> http://groovy.329449.n5.nabble.com/GMaven-Rewrite-tp4785090p4786572.html >>>> Sent from the groovy - dev mailing list archive at Nabble.com. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this list, please visit: >>>> >>>> http://xircles.codehaus.org/manage_email >>>> >>>> >>>> >>> >>> >>> -- >>> Guillaume Laforge >>> Groovy Project Manager >>> Head of Groovy Development at SpringSource >>> http://www.springsource.com/g2one >>> >> >> >> -- >> View this message in context: http://groovy.329449.n5.nabble.com/GMaven-Rewrite-tp4785090p4795412.html >> Sent from the groovy - dev mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: GMaven Rewrite
|
|
On the issue of Groovy-Maven integration options: While I'm not necessarily opposed to the use of the groovy-eclipse-compiler as the primary means of integrating Groovy with Maven, I think it whatever method is selected, it would be preferable to have a single way of compiling Groovy (be it through Maven, Ant, or some other build tool).
It'd probably work best if this would be a separate artifact any tool could use (possibly based on groovy-eclipse), so that users get a uniform experience regardless of their choice of build tool and making it easy for other build tools to add Groovy support. I think Jason suggested this idea in the past (something like a groovy.compiler.* API) in another thread (http://groovy.329449.n5.nabble.com/removed-public-method-gt-latest-Intellij-doesn-t-compile-groovy-td387362.html). I think that'd be cool. Do you think it'd be possible to refactor out the compiling parts of Groovy into a separate artifact and then use reflection or some other means to get the GroovyClassloader from the version of Groovy you're using the compilation API against? That way a single API can be used against multiple Groovy versions. Do the maintainers of the core compiler classes have an opinion on this? While on that topic of a separate compilation jar, shouldn't the ant stuff not be included in the Groovy jar and instead be its own jar? (like groovy-ant or something?) It doesn't seem to make much sense to have people using other build tools pull in the Ant dependencies too. On the topic of reflection, I agree that this increases the chances of a runtime error occurring that might have been mitigated at compile time had reflection not been used. My motivation was to allow the user the control over what version of Groovy their sourcecode is compiled with. Though in practice, I'm don't know whether this granularity of control is necessary. I guess that would depend on if there were ever any methods deleted or had their signatures changed in a point release (or if one of the point releases broke something in the compilation classes but that seems unlikely). Yes, there have been some incompatible API changes. I haven't done much testing with Groovy prior to 1.5, so there were only a couple of differences I had to account for. But it looks like there will be pretty significant differences for getting stub generation to work. Currently, the compiler is silently not producing my stubs when I use any Groovy older than 1.7.0. If everyone is convinced that this is a really bad idea, and can confirm that it doesn't really matter if people aren't able to compile wit the same point release they are using at runtime, I'd be willing to rewrite this again in the way Jason has suggested. The only other concern I had with that approach is you'd then have to basically maintain a completely separate plugin for each of the Groovy branches, which is a bit of a pain. Thank you for pointing out the issue of the stub generator not including Javadoc for Maven plugins, I caught that in my testing yet. If the official stub compiler doesn't do this, shouldn't your changes be ported upstream? One thing I don't understand is how it is that groovyc doesn't seem to have the same stub generation issues that gmaven has. Aren't these using basically the same code to do the generation (at least starting with 1.7)? I've not really looked at what the groovy-eclipse-compiler is doing either. Maybe before proceeding further with my rewrite, I should evaluate whether we should expand groovy-eclipse rather than having a separate project (I'd also like to look a bit at how hard it'd be to separate the tooling from the rest of Groovy, but I don't know that'd I'd be the most qualified person to do that). To get me started, is the fact that Groovy compiler arguments aren't passed through to the compiler something that can be fixed? Or is that a limitation of the architecture? In the end, I still feel that we've got tooling that is working around issues with the core compiler, and these should be fixed upstream rather than being worked around. In the mean time, should we do a 1.4 release of gmaven? Since at this point in time, gmaven still seems to be the only way to make Groovy mojos and there are people (I think perhaps a lot of people) still using gmaven. And if so, do you mind if I also update the documentation and triage Jira a bit? -Keegan |
Re: GMaven Rewrite
|
|
OK...there's a lot in this, so I will take this piecemeal below.
On Sun, Sep 18, 2011 at 5:49 PM, keeganwitt <[hidden email]> wrote: > On the issue of Groovy-Maven integration options: While I'm not necessarily > opposed to the use of the groovy-eclipse-compiler as the primary means of > integrating Groovy with Maven, I think it whatever method is selected, it > would be preferable to have a single way of compiling Groovy (be it through > Maven, Ant, or some other build tool). Yes. It is possible to call groovy-eclipse-compiler from ant (although I haven't kept this up to date primarily because no one has asked me). See here: http://contraptionsforprogramming.blogspot.com/2010/09/where-are-all-my-stubs.html I also worked with the gradle team to create an experimental way of calling it from within gradle, but again, I haven't fully pursued this to make it production quality. > It'd probably work best if this would be a separate artifact any tool could > use (possibly based on groovy-eclipse), so that users get a uniform > experience regardless of their choice of build tool and making it easy for > other build tools to add Groovy support. I think Jason suggested this idea > in the past (something like a groovy.compiler.* API) in another thread > (http://groovy.329449.n5.nabble.com/removed-public-method-gt-latest-Intellij-doesn-t-compile-groovy-td387362.html). We (the groovy-eclipse team) have talked about doing something like this before, but it is far, far, far from trivial. And adding such a layer of indirection will make any compiler operation more expensive, which is an important consideration when doing UI operations. That being said, in my ideal world, this would already have been done since this kind of abstraction would make it possible to drop in multiple compilers inside of a single Eclipse workspace. One of the biggest challenges here is determining what is API (and hence requires backwards compatibility), and what is mutable across versions. One thing that has served Groovy well in the past is to make breaking changes (even though it makes my job as a tool writer more difficult). A simpler task (although still non-trivial) is to create a compatibility layer that abstracts across versions. I think this is what you are saying below. Any such solution requires someone with intimate knowledge of the compiler and with loads of free time to work on this. > I think that'd be cool. Yes. I agree. > Do you think it'd be possible to refactor out the compiling parts of Groovy > into a separate artifact and then use reflection or some other means to get > the GroovyClassloader from the version of Groovy you're using the > compilation API against? That way a single API can be used against multiple > Groovy versions. Do the maintainers of the core compiler classes have an > opinion on this? There has been talk about modularizing groovy-core, but I don't think this has gotten very far. See here: http://docs.codehaus.org/display/GROOVY/Groovy+1.8+modularization ... > I've not really looked at what the groovy-eclipse-compiler is doing either. > Maybe before proceeding further with my rewrite, I should evaluate whether > we should expand groovy-eclipse rather than having a separate project (I'd > also like to look a bit at how hard it'd be to separate the tooling from the > rest of Groovy, but I don't know that'd I'd be the most qualified person to > do that). To get me started, is the fact that Groovy compiler arguments > aren't passed through to the compiler something that can be fixed? Or is > that a limitation of the architecture? There is no reason why general groovy compiler arguments can't be passed in. It's just not something I have implemented yet. My general approach to groovy-eclipse-compiler has been to respond to the needs of the community (ie- when someone asks for it, I implement it...and no one has asked for this yet, or at least not in some place that i have seen). Of course, in my heavily biased view groovy-eclipse-compiler's approach is preferable to gmaven's. My understanding is that any sufficiently large Groovy-Java gmaven project will have arcane stub generation problems that will require equally arcane workarounds in the code. My opinion is that it's generally not a good idea to be tailoring your source code to limitations of your build system (and I don't think this is too controversial). There is still work to be done on the groovy-eclipse-compiler, but this is not hard work. It's just work. Well...that's not exactly true. If the ability to drop in any compiler version is important, this would first require a compatibility layer, and then some major rewriting of our Groovy-JDT integration (but really, if the latest point releases are supported, but not snapshots that is sufficient for 95% of people out there). > In the end, I still feel that we've got tooling that is working around > issues with the core compiler, and these should be fixed upstream rather > than being worked around. Yes. Groovy-Eclipse ships with a patch for Groovy-core that we maintain and that includes all the fixes we need to get our things working. We are trying to move this patch into groovy-core but for various reasons this is moving slowly. > In the mean time, should we do a 1.4 release of gmaven? Since at this point > in time, gmaven still seems to be the only way to make Groovy mojos and > there are people (I think perhaps a lot of people) still using gmaven. And > if so, do you mind if I also update the documentation and triage Jira a bit? Sure...go ahead, from my point of view seems like a good idea. Ideally, I'd love to see the groovy-eclipse-compiler supporting this as well, but I haven't been able to work on this. Perhaps parts of gmaven can be borrowed to implement this. --a > -Keegan > > -- > View this message in context: http://groovy.329449.n5.nabble.com/GMaven-Rewrite-tp4785090p4817387.html > Sent from the groovy - dev mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: GMaven Rewrite
|
|
In reply to this post by keeganwitt
On Sep 18, 2011, at 5:49 PM, keeganwitt wrote:
> On the issue of Groovy-Maven integration options: While I'm not necessarily > opposed to the use of the groovy-eclipse-compiler as the primary means of > integrating Groovy with Maven, I think it whatever method is selected, it > would be preferable to have a single way of compiling Groovy (be it through > Maven, Ant, or some other build tool). Good luck ;-) From my experience the groovy compiler folks believe that tool is "groovyc" (including the api bits that back it up). I've tried a few times to explain why this won't work for other tooling, even had others chime in and help explain, but still went nowhere to remedy the general problem. Maybe you will have better luck :-) > It'd probably work best if this would be a separate artifact any tool could > use (possibly based on groovy-eclipse), so that users get a uniform > experience regardless of their choice of build tool and making it easy for > other build tools to add Groovy support. I think Jason suggested this idea > in the past (something like a groovy.compiler.* API) in another thread > (http://groovy.329449.n5.nabble.com/removed-public-method-gt-latest-Intellij-doesn-t-compile-groovy-td387362.html). > I think that'd be cool. > Do you think it'd be possible to refactor out the compiling parts of Groovy > into a separate artifact and then use reflection or some other means to get > the GroovyClassloader from the version of Groovy you're using the > compilation API against? That way a single API can be used against multiple > Groovy versions. Do the maintainers of the core compiler classes have an > opinion on this? Wasn't there some common java compiler api that cam out of jsr/standards/whatever? I think that really if you want to make something that could compile groovy in whatever tooling/environment w/support for interop with any other java-compiled language then it would have to be integrated in some standard way into the java compiler. If everyone used the eclipse-compiler, then that would be a good choice, but I don't believe that is the case. > While on that topic of a separate compilation jar, shouldn't the ant stuff > not be included in the Groovy jar and instead be its own jar? (like > groovy-ant or something?) It doesn't seem to make much sense to have people > using other build tools pull in the Ant dependencies too. The groovy folks are very Ant oriented and IMO a bit schizophrenic when it comes to build system integration. Last I looked there was an ant build, a mvn build, and a graddle build. No clue if they all do the same thing, if they are all maintained at the same level, though I assume the Ant build is definitive? But I really have no clue anymore. Talk about modularization of the codebase has been years in the making and by making I mean talk that basically went nowhere. I've even implemented modularization of the project (years ago now) which did split up all of this stuff into separate isolated artifacts. That resulted in lots of talk and no movement. > On the topic of reflection, I agree that this increases the chances of a > runtime error occurring that might have been mitigated at compile time had > reflection not been used. My motivation was to allow the user the control > over what version of Groovy their sourcecode is compiled with. Though in > practice, I'm don't know whether this granularity of control is necessary. With the gmaven runtime you could choose the version as well, you just also had to pick the runtime provider which was compatible with that version. With the providers using the api you'll find out about specific problems at compile time, instead of running into problems (difficult to debug and explain problems I'd imagine) at runtime when an incompatible version is used. Programming by reflection is also very verbose and has some overhead. This is why I choose to create an abstraction layer (basically a set of interfaces) then dynamically load the implementation (this is done via reflection) of those interfaces which was compatible with the groovy version which was used. What is there now isn't perfect and certainly could be improved/simplified, but I think that replacing all of that with reflection is a big step backwards. IMO the big issue with GMaven is the integration with stub-compilation. This stems directly from the compiler teams "it works with groovyc" blinders and lack of experience with Maven (or really much other than basic single-module Ant)... and lack of willingness to compromise. I think I've explained the problem many times over now, others have even chimed in to help explain (so its not just me being crazy/insane or insane/crazy). > If everyone is convinced that this is a really bad idea, and can confirm that > it doesn't really matter if people aren't able to compile wit the same point > release they are using at runtime, I'd be willing to rewrite this again in > the way Jason has suggested. The only other concern I had with that > approach is you'd then have to basically maintain a completely separate > plugin for each of the Groovy branches, which is a bit of a pain. Its no more pain than having to maintain several branches for groovy itself for supported releases. Its slightly less painful than having different versions of a plugin working with different versions of groovy configured in different ways by different users. I found that while this is (IMO) technically more elegant (the way gmaven is now with its plugins and providers) that in practice this was a huge PITA to debug specific user problems. No matter how you roll it, if you have different versions of groovy that need slightly (or not so slightly) different integration, then you can't avoid having different branches to maintain that codebase. The key is to limit the number of concurrent branches which are actively supported, and to keep the changes between those branches wrt framework minimized so that its easy to port new versions/fixes. > Thank you for pointing out the issue of the stub generator not including > Javadoc for Maven plugins, I caught that in my testing yet. If the official > stub compiler doesn't do this, shouldn't your changes be ported upstream? I recall talk about having the compiler become aware/capture/save javadocs for awhile. Last I checked it again went nowhere. > One thing I don't understand is how it is that groovyc doesn't seem to have > the same stub generation issues that gmaven has. Aren't these using > basically the same code to do the generation (at least starting with 1.7)? It sorta does, in that groovyc will generate some stubs into its temporary location, but simply not invoke the java compiler on them because it doesn't need to (java files never referenced that groovy class/stub or whatever). Groovyc just generates the bogus .java and then deletes it. I've found this to be the case before in my testing (last time I looked into this problem) and reported it to the community. I believe the response was something like, there is no way to fully generate stubs for every thing in groovy and groovyc doesn't need it anyways, so it doesn't matter... or something to that effect. > In the mean time, should we do a 1.4 release of gmaven? Sure, if one is needed. > Since at this point > in time, gmaven still seems to be the only way to make Groovy mojos and > there are people (I think perhaps a lot of people) still using gmaven. I've no idea who uses it really. > And if so, do you mind if I also update the documentation and triage Jira a bit? Nope, go ahead... you should have access to it all now. --jason --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: GMaven Rewrite
|
|
In reply to this post by Andrew Eisenberg
> Of course, in my heavily biased view groovy-eclipse-compiler's
> approach is preferable to gmaven's. My understanding is that any > sufficiently large Groovy-Java gmaven project will have arcane stub > generation problems that will require equally arcane workarounds in > the code. My opinion is that it's generally not a good idea to be > tailoring your source code to limitations of your build system (and I > don't think this is too controversial). I'm in favor of using the eclipse compiler (maven compiler plugin-based) integration... this is IMO the _right_ way to hook up custom compilation support into Maven. I'm not 100% sure that it will work with various other tooling (say you need to have groovy and scala and java all compiling together), but that is more the fault of the maven-compiler-plugin (and its components/api) than of the groovy-eclipse implementation. I'm curious though, how do you get around the issue with the Groovy stub-compiler generating invalid .java files? Has that problem been fixed in the core? Or does groovy-eclipse also simply ignore those .java files from compilation because the other .java classes didn't reference them and thus there was no reason to compile them to resolve dependencies before the .groovy compile kicked in? If the groovy-eclipse compiler integration can: a) allow the groovy version to be specified (due to all of the fancy ast stuff going on, changes to the groovy version could affect the compiled output + other compiler-related fixes that go into point releases) b) work with other language integration issues "well enough" ... then I think it probably should be used as the default way to compile in Maven. The javadoc/maven-mojo thing... well that is another issue, but IMO the right way to solve that is to get the Maven folks to build/finish tooling for real Java5 annotations. > There is still work to be done on the groovy-eclipse-compiler, but > this is not hard work. It's just work. Well...that's not exactly > true. If the ability to drop in any compiler version is important, > this would first require a compatibility layer, and then some major > rewriting of our Groovy-JDT integration (but really, if the latest > point releases are supported, but not snapshots that is sufficient for > 95% of people out there). > >> In the end, I still feel that we've got tooling that is working around >> issues with the core compiler, and these should be fixed upstream rather >> than being worked around. > > Yes. Groovy-Eclipse ships with a patch for Groovy-core that we > maintain and that includes all the fixes we need to get our things > working. We are trying to move this patch into groovy-core but for > various reasons this is moving slowly. This sort of required patch maintained outside of the core, should really be fixed. I understand the need to do this, but I also understand that the need arises out of a general process issue wrt compiler changes needed to support build environments. --jason --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: GMaven Rewrite
|
In reply to this post by Jason Dillon
For us (kuali rice project), joint compilation of java/groovy projects with maven is vitally important. We have been bitten by stub issues on multiple occasions. Now we are dealing with some strange bug on *nix machines related to the javadoc plugin & gmaven.
Anyway, we are currently investigating switching to the groovy-eclipse-maven plugin but it would certainly be helpful to have a bugfix release of gmaven. After that I think it would be awesome to consolidate our effort into one maven groovy compiler to rule them all. Just one man's opinion ;-) ~Travis On Mon, Sep 19, 2011 at 4:22 PM, Jason Dillon <[hidden email]> wrote:
|
Re: GMaven Rewrite
|
|
In reply to this post by Jason Dillon
On Mon, Sep 19, 2011 at 1:37 PM, Jason Dillon <[hidden email]> wrote:
>> Of course, in my heavily biased view groovy-eclipse-compiler's >> approach is preferable to gmaven's. My understanding is that any >> sufficiently large Groovy-Java gmaven project will have arcane stub >> generation problems that will require equally arcane workarounds in >> the code. My opinion is that it's generally not a good idea to be >> tailoring your source code to limitations of your build system (and I >> don't think this is too controversial). > > I'm in favor of using the eclipse compiler (maven compiler plugin-based) integration... this is IMO the _right_ way to hook up custom compilation support into Maven. I'm not 100% sure that it will work with various other tooling (say you need to have groovy and scala and java all compiling together), but that is more the fault of the maven-compiler-plugin (and its components/api) than of the groovy-eclipse implementation. > > I'm curious though, how do you get around the issue with the Groovy stub-compiler generating invalid .java files? Has that problem been fixed in the core? Or does groovy-eclipse also simply ignore those .java files from compilation because the other .java classes didn't reference them and thus there was no reason to compile them to resolve dependencies before the .groovy compile kicked in? There are no stubs on disk. Groovy-Eclipse creates in-memory bindings for groovy files to make the JDT compiler happy. Since we create the bindings, we only need to create the parts of the bindings that are relevant for compiling against the Java classes. Thus we side-step all of the invalid stub issues. > > If the groovy-eclipse compiler integration can: > > a) allow the groovy version to be specified (due to all of the fancy ast stuff going on, changes to the groovy version could affect the compiled output + other compiler-related fixes that go into point releases) As I said, as long as there is a patched version of groovy-core that is packaged the proper way, this will work. You can choose any of the versions available. Right now, however, I only have 1.7.10 and 1.8.0 available. (This will not work for 1.6.x since we no longer support that version, and will not work for 1.9.x until we create a patch for that version). > b) work with other language integration issues "well enough" In theory, yes as long as the other languages keep to their own source folders and don't try to use a maven-compiler-plugin themselves (two big caveats). If there is a way to apply different maven-compiler-plugins to different source folders, then this wouldn't be a problem, but my knowledge of maven doesn't go that deep. > ... then I think it probably should be used as the default way to compile in Maven. > > The javadoc/maven-mojo thing... well that is another issue, but IMO the right way to solve that is to get the Maven folks to build/finish tooling for real Java5 annotations. Well, you work for sonatype...get at it. :-) More realistically, that is not likely to change any time soon. My understanding is that gmaven does this reasonably well. What are the limitations with the current approach. > > >> There is still work to be done on the groovy-eclipse-compiler, but >> this is not hard work. It's just work. Well...that's not exactly >> true. If the ability to drop in any compiler version is important, >> this would first require a compatibility layer, and then some major >> rewriting of our Groovy-JDT integration (but really, if the latest >> point releases are supported, but not snapshots that is sufficient for >> 95% of people out there). >> >>> In the end, I still feel that we've got tooling that is working around >>> issues with the core compiler, and these should be fixed upstream rather >>> than being worked around. >> >> Yes. Groovy-Eclipse ships with a patch for Groovy-core that we >> maintain and that includes all the fixes we need to get our things >> working. We are trying to move this patch into groovy-core but for >> various reasons this is moving slowly. > > This sort of required patch maintained outside of the core, should really be fixed. I understand the need to do this, but I also understand that the need arises out of a general process issue wrt compiler changes needed to support build environments. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: GMaven Rewrite
|
|
>> a) allow the groovy version to be specified (due to all of the fancy ast stuff going on, changes to the groovy version could affect the compiled output + other compiler-related fixes that go into point releases)
> > As I said, as long as there is a patched version of groovy-core that > is packaged the proper way, this will work. You can choose any of the > versions available. Right now, however, I only have 1.7.10 and 1.8.0 > available. (This will not work for 1.6.x since we no longer support > that version, and will not work for 1.9.x until we create a patch for > that version). Are the patches so large/incompatible with the mainline codebase to not get integrated? If not I don't see why the community wouldn't want to merge this in and avoid needing patched artifacts to support compilation in specific environments. This seems like an obvious no brainer to fix. >> b) work with other language integration issues "well enough" > > In theory, yes as long as the other languages keep to their own source > folders and don't try to use a maven-compiler-plugin themselves (two > big caveats). If there is a way to apply different > maven-compiler-plugins to different source folders, then this wouldn't > be a problem, but my knowledge of maven doesn't go that deep. Yup, though I don't think many folks actually replace the compiler plugin's components... as its not terribly flexible. Most integration are done via plugins contributing additional goals to run bound the phases (as how gmaven works now). I had considered implementing a compiler plugin a while ago and never did it, since it was almost never done (in any project I've ever seen) that required additional language compilation. So its probably a safe-ish move. Assuming that the groovy-eclipse compiler plugin is compatible with the latest compiler plugin. I don't recall that stuff changing very much as of recent, but I've not looked too hard. >> ... then I think it probably should be used as the default way to compile in Maven. >> >> The javadoc/maven-mojo thing... well that is another issue, but IMO the right way to solve that is to get the Maven folks to build/finish tooling for real Java5 annotations. > > Well, you work for sonatype...get at it. :-) Right... um, it doesn't work that way unfortunately... and its a sore subject I'd rather not discuss in public :-[ > More realistically, that is not likely to change any time soon. My > understanding is that gmaven does this reasonably well. GMaven doesn't really do anything specific to this (other than include javadocs in the stubs). Everything else is done via the normal tooling. At one point I did have a custom parser and plugins to the maven-plugin-plugin bits to support .java and .groovy sources. But that was a bunch of highly duplicated code, hard to maintain when new things were added to the maven plugin model. So at the time it was easier to simply get the stub-generation to include javadocs, then let the normal Maven stuff take over. > What are the limitations with the current approach. Its limited to a having functional stub-generator... that always produces valid .java files on disk, with the javadocs on the correct elements. --jason --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
«
Return to groovy - dev
|
1 view|%1 views
Loading...
| Powered by Nabble | See how NAML generates this page |
