Community
Participate
Working Groups
Integrate the extensions greclipse has to jdt.core in order to support building of groovy code in AspectJ projects.
I really hope this gets addressed sometime soon. Using Groovy shouldn't give people an excuse not to use aspects for everyday tasks. Please promote the use of aspects!
I need this too
This is a blocker for me preventing me from using AspectJ
Any updates on this issue?
nope, still on the list to look at but never seems to make it to the top priority.
Our case is similar: we have AspectJ + Maven + Eclipse working well integrated. However, we can't add Groovy to existing Maven+AspecJ projects due to this issue. I'll keep an eye on this bug... Thanks,
Do we have any update on the AspectJ+Groovy issue? I hope it has not been zombified :-( I think allowing to mix Eclipse & Groovy with Spring + AspectJ + Maven (even without Groovy pointcutting) will be so beneficial...
I'm afraid there is nothing to report on this as of yet, maybe it is worth looking at alternative solutions that aren't so costly development wise.
That is a shame Andrew, using groovy alongside with aspectJ and spring would be great for many people. I see in your blog you're mainly into aspectj, eclipse but also into groovy. Just a few clarifications if you can : - Do you have any insights whether this is (still?) a priority issue in either the groovy/springsource or the aspectj teams (apart from eclipse that has it as P3 normal) ? - Do you think a custom builder configuration or an ant script could somehow solve this ? - Finally, what do you mean "it is worth looking at alternative solutions that aren't so costly development wise." What do you consider being development costly ?
> That is a shame Andrew, using groovy alongside with aspectJ and spring would be > great for many people. I know, we just have so much work on. > I see in your blog you're mainly into aspectj, eclipse but also into groovy. I own AspectJ and also the patched jdt compiler that integrates groovy compilation (that underpins groovy-eclipse). > - Do you have any insights whether this is (still?) a priority issue in either > the groovy/springsource or the aspectj teams (apart from eclipse that has it as > P3 normal) ? It is one of those things that we're always hoping to get to, but don't seem to find the time. I wouldn't read too much into the importance level for the bug. We have a lot of bugs and can't keep them all prioritized appropriately. You'll know this is dropping off the radar when it has no target milestone. (Having a 1.7.0 target means we would love to fit it in that release but doesn't mean we will definitely manage it) > - Finally, what do you mean "it is worth looking at alternative solutions that > aren't so costly development wise." What do you consider being development > costly ? The initial piece of work is straightforward, just merge the jdt core changes made for groovy into AspectJs modified jdt core. However, there is then the interplay of these features to think about. Not necessarily a lot of coding here but a lot of thought required with a few lines here and there to prevent inadvertent clashes. > - Do you think a custom builder configuration or an ant script could somehow > solve this ? This is one of the alternative options we have considered but haven't put a lot of time into thinking through the details. Having both Java builder and AspectJ builder operating on the same project may enable you to limp along but they'll both be attempting to compile the .java and both think they are the only builder doing that.
unsetting the target field which is currently set for something already released
It's been a while - are we any nearer a chance of this happening? There's an equivalent bug in the Spring Tool Suite JIRA (https://issuetracker.springsource.com/browse/STS-629) so I will prompt there, too - I'm sure SpringSource/Pivotal have enough people to be able to help out here if it's just an issue of finding the time!
