groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: GROOVY-8527: Enhance import aliasing to an alias with a package name
Date Thu, 05 Apr 2018 14:07:21 GMT
Yes, the statements I made are a bit exaggerated.  That was to bring out a little more discussion
on balance of maintenance vs enhancement.

In my case, I am suggesting fixes because I have groovy-eclipse setup and this gives me a
chance to make some small patches to groovy-core and see if they fix the problems I run into.
 For me to submit a PR to groovy-core, I would need to get that entire project setup and get
familiarized with the build and test cycle.  And then how would I decide how much time to
spend trying to improve groovy-eclipse vs. groovy-core.  I felt that reporting issues and
submitting diffs/patches would be sufficient.

Here are my top 3 from my bugs list:
GROOVY-8509 error for call to protected method from same package
GROOVY-8063 Type annotation value referencing inner class is not properly scoped
GROOVY-7975 Use of static final field in an annotation element causes compile errors

-----Original Message-----
From: Jochen Theodorou [] 
Sent: Wednesday, April 04, 2018 7:37 PM
Subject: Re: GROOVY-8527: Enhance import aliasing to an alias with a package name

On 04.04.2018 21:38, wrote:
>>> [...]I have submitted over 20 bugs in the past months for existing 
>>> features that do not mix well with eachother or are not completely 
>>> implemented and yet I feel the core development thrust is not in 
>>> fixing bugs for existing features but in adding new features for the 
>>> sake of new features.
>> not many are eager to spend their spare time after working hours on fixing complicated
bugs and going through the whole process and discussions.
> If the incentive for fixing bugs was enticing enough, wouldn't there be eager developers?

Do you have a recipe of how to give an enticing incentive? Actually, from looking at your
issues you are suggesting solutions in some places, but you seem not be motivated enough to
make a pull request for example. 
Why is that?

> What then is the point of adding new features onto an unhealthy, under-supported language?

I think you exaggerate. But the point is attracting new people. If you do not move, people
move away. Annoying, long standing bugs can have the same effect of course

>  If this is truly the state of the union, then I would vote NO on all new feature development.

We need to find the right balance. The new parser for example does not exist because we wanted
a new parser. It exists because the old parser started to become a problem for fixing bugs.
Of course once you have a new parser, that is more maintainable and a person that understands
it very well, you will also see features from other languages and see them with the eyes of
a parser guy that is wondering if this brings any benefit to Groovy. That is natural.

Anyway... the static compiler is a deep resource of bugs and will stay being it a long time.
Inner classes in all variants contain new surprises time over time. But excluding those two
topics what are your top 3 of open bugs in jira entered by you where existing features do
not mix well with eachother or are not completely implemented?

bye Jochen
View raw message