removed public method => latest Intellij doesn't compile groovy

[Alex Tkachman]

Hi!

After on Oct 16th public method JavaStubCompilationUnit.addSourceFile
has been removed the latest Intellij doesn't able to compile groovy
code based on trunk.
Any ideas how we can retun status quo?

Alex

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[HamletDRC]

I hit this same issue and it was a pain.

I got groovy-core running by setting my IDEA facet to 1.6.5,
compiling, then setting it back to 1.7. There don't seem to be too
many issues, but that is _certainly_ no long term fix.

--
Hamlet D'Arcy
hamletdrc@...



On Tue, Oct 27, 2009 at 6:35 AM, Alex Tkachman <alex.tkachman@...> wrote:

> Hi!
>
> After on Oct 16th public method JavaStubCompilationUnit.addSourceFile
> has been removed the latest Intellij doesn't able to compile groovy
> code based on trunk.
> Any ideas how we can retun status quo?
>
> Alex
>
> ---------------------------------------------------------------------
> 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

[Alex Tkachman]

It doesn't work for me as I need latest fixes in compiler
I am trying to return the method back but not sure yet if it will help.

On Tue, Oct 27, 2009 at 1:42 PM, Hamlet D'Arcy <hamletdrc@...> wrote:

> I hit this same issue and it was a pain.
>
> I got groovy-core running by setting my IDEA facet to 1.6.5,
> compiling, then setting it back to 1.7. There don't seem to be too
> many issues, but that is _certainly_ no long term fix.
>
> --
> Hamlet D'Arcy
> hamletdrc@...
>
>
>
> On Tue, Oct 27, 2009 at 6:35 AM, Alex Tkachman <alex.tkachman@...> wrote:
>> Hi!
>>
>> After on Oct 16th public method JavaStubCompilationUnit.addSourceFile
>> has been removed the latest Intellij doesn't able to compile groovy
>> code based on trunk.
>> Any ideas how we can retun status quo?
>>
>> Alex
>>
>> ---------------------------------------------------------------------
>> 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

[Guillaume Laforge-2]

What was the change set that removed that method?

On Tue, Oct 27, 2009 at 12:49, Alex Tkachman <alex.tkachman@...> wrote:

> It doesn't work for me as I need latest fixes in compiler
> I am trying to return the method back but not sure yet if it will help.
>
> On Tue, Oct 27, 2009 at 1:42 PM, Hamlet D'Arcy <hamletdrc@...> wrote:
>> I hit this same issue and it was a pain.
>>
>> I got groovy-core running by setting my IDEA facet to 1.6.5,
>> compiling, then setting it back to 1.7. There don't seem to be too
>> many issues, but that is _certainly_ no long term fix.
>>
>> --
>> Hamlet D'Arcy
>> hamletdrc@...
>>
>>
>>
>> On Tue, Oct 27, 2009 at 6:35 AM, Alex Tkachman <alex.tkachman@...> wrote:
>>> Hi!
>>>
>>> After on Oct 16th public method JavaStubCompilationUnit.addSourceFile
>>> has been removed the latest Intellij doesn't able to compile groovy
>>> code based on trunk.
>>> Any ideas how we can retun status quo?
>>>
>>> Alex
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Alex Tkachman]

18020 I think

On Tue, Oct 27, 2009 at 1:50 PM, Guillaume Laforge
<glaforge@...> wrote:

> What was the change set that removed that method?
>
> On Tue, Oct 27, 2009 at 12:49, Alex Tkachman <alex.tkachman@...> wrote:
>> It doesn't work for me as I need latest fixes in compiler
>> I am trying to return the method back but not sure yet if it will help.
>>
>> On Tue, Oct 27, 2009 at 1:42 PM, Hamlet D'Arcy <hamletdrc@...> wrote:
>>> I hit this same issue and it was a pain.
>>>
>>> I got groovy-core running by setting my IDEA facet to 1.6.5,
>>> compiling, then setting it back to 1.7. There don't seem to be too
>>> many issues, but that is _certainly_ no long term fix.
>>>
>>> --
>>> Hamlet D'Arcy
>>> hamletdrc@...
>>>
>>>
>>>
>>> On Tue, Oct 27, 2009 at 6:35 AM, Alex Tkachman <alex.tkachman@...> wrote:
>>>> Hi!
>>>>
>>>> After on Oct 16th public method JavaStubCompilationUnit.addSourceFile
>>>> has been removed the latest Intellij doesn't able to compile groovy
>>>> code based on trunk.
>>>> Any ideas how we can retun status quo?
>>>>
>>>> Alex
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>>
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>
> ---------------------------------------------------------------------
> 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

[Jason Dillon]

The JavaStubCompilationUnit was only every intended to generate stub  
files for groovy sources.  So I removed the bits which conditonally  
generated sources if there was more than one .java file included.

Was not aware that other folks were using this bit of API so I also  
renamed to methods to addSource().

I can add back a deprecated method for addSourceFile() but the  
behavior of only generating stubs when there is at least one .java  
file will not be restored.  So you can add a billion .java files,  
no .groovy files and it will do nothing.  If you add a billon .groovy  
files and no .java files it will attempt to create a billon+ stubs for  
each .groovy file.

Will that resolve this issue?

--jason


On Oct 27, 2009, at 6:56 PM, Alex Tkachman wrote:

> 18020 I think
>
> On Tue, Oct 27, 2009 at 1:50 PM, Guillaume Laforge
> <glaforge@...> wrote:
>> What was the change set that removed that method?
>>
>> On Tue, Oct 27, 2009 at 12:49, Alex Tkachman  
>> <alex.tkachman@...> wrote:
>>> It doesn't work for me as I need latest fixes in compiler
>>> I am trying to return the method back but not sure yet if it will  
>>> help.
>>>
>>> On Tue, Oct 27, 2009 at 1:42 PM, Hamlet D'Arcy  
>>> <hamletdrc@...> wrote:
>>>> I hit this same issue and it was a pain.
>>>>
>>>> I got groovy-core running by setting my IDEA facet to 1.6.5,
>>>> compiling, then setting it back to 1.7. There don't seem to be too
>>>> many issues, but that is _certainly_ no long term fix.
>>>>
>>>> --
>>>> Hamlet D'Arcy
>>>> hamletdrc@...
>>>>
>>>>
>>>>
>>>> On Tue, Oct 27, 2009 at 6:35 AM, Alex Tkachman <alex.tkachman@...
>>>> > wrote:
>>>>> Hi!
>>>>>
>>>>> After on Oct 16th public method  
>>>>> JavaStubCompilationUnit.addSourceFile
>>>>> has been removed the latest Intellij doesn't able to compile  
>>>>> groovy
>>>>> code based on trunk.
>>>>> Any ideas how we can retun status quo?
>>>>>
>>>>> Alex
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Head of Groovy Development at SpringSource
>> http://www.springsource.com/g2one
>>
>> ---------------------------------------------------------------------
>> 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

[Alex Tkachman]

Truly speaking I have no idea.
Probably IntelliJ guys should be asked. I add Peter Gromov on cc as I
believe he is responsible for this code.

On Tue, Oct 27, 2009 at 2:27 PM, Jason Dillon <jason@...> wrote:

> The JavaStubCompilationUnit was only every intended to generate stub files
> for groovy sources.  So I removed the bits which conditonally generated
> sources if there was more than one .java file included.
>
> Was not aware that other folks were using this bit of API so I also renamed
> to methods to addSource().
>
> I can add back a deprecated method for addSourceFile() but the behavior of
> only generating stubs when there is at least one .java file will not be
> restored.  So you can add a billion .java files, no .groovy files and it
> will do nothing.  If you add a billon .groovy files and no .java files it
> will attempt to create a billon+ stubs for each .groovy file.
>
> Will that resolve this issue?
>
> --jason
>
>
> On Oct 27, 2009, at 6:56 PM, Alex Tkachman wrote:
>
>> 18020 I think
>>
>> On Tue, Oct 27, 2009 at 1:50 PM, Guillaume Laforge
>> <glaforge@...> wrote:
>>>
>>> What was the change set that removed that method?
>>>
>>> On Tue, Oct 27, 2009 at 12:49, Alex Tkachman <alex.tkachman@...>
>>> wrote:
>>>>
>>>> It doesn't work for me as I need latest fixes in compiler
>>>> I am trying to return the method back but not sure yet if it will help.
>>>>
>>>> On Tue, Oct 27, 2009 at 1:42 PM, Hamlet D'Arcy <hamletdrc@...>
>>>> wrote:
>>>>>
>>>>> I hit this same issue and it was a pain.
>>>>>
>>>>> I got groovy-core running by setting my IDEA facet to 1.6.5,
>>>>> compiling, then setting it back to 1.7. There don't seem to be too
>>>>> many issues, but that is _certainly_ no long term fix.
>>>>>
>>>>> --
>>>>> Hamlet D'Arcy
>>>>> hamletdrc@...
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 27, 2009 at 6:35 AM, Alex Tkachman
>>>>> <alex.tkachman@...> wrote:
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> After on Oct 16th public method JavaStubCompilationUnit.addSourceFile
>>>>>> has been removed the latest Intellij doesn't able to compile groovy
>>>>>> code based on trunk.
>>>>>> Any ideas how we can retun status quo?
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Groovy Project Manager
>>> Head of Groovy Development at SpringSource
>>> http://www.springsource.com/g2one
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jason Dillon schrieb:
> The JavaStubCompilationUnit was only every intended to generate stub
> files for groovy sources.  So I removed the bits which conditonally
> generated sources if there was more than one .java file included.
>
> Was not aware that other folks were using this bit of API so I also
> renamed to methods to addSource().

never ever just remove a public method even if it looks like an internal
method. Make it deprecated while keeping the implementation and in the
next major version the method can probably be removed.

> I can add back a deprecated method for addSourceFile() but the behavior
> of only generating stubs when there is at least one .java file will not
> be restored.  So you can add a billion .java files, no .groovy files and
> it will do nothing.  If you add a billon .groovy files and no .java
> files it will attempt to create a billon+ stubs for each .groovy file.
>
> Will that resolve this issue?

partially. The reason we create no stubs if no java file is present was
because if we compile groovy source only we don't need the stubs and the
stubs creation takes away performance big ways. So where is this
controlled now?

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

On Oct 27, 2009, at 8:21 PM, Jochen Theodorou wrote:

> Jason Dillon schrieb:
>> The JavaStubCompilationUnit was only every intended to generate  
>> stub files for groovy sources.  So I removed the bits which  
>> conditonally generated sources if there was more than one .java  
>> file included.
>> Was not aware that other folks were using this bit of API so I also  
>> renamed to methods to addSource().
>
> never ever just remove a public method even if it looks like an  
> internal method. Make it deprecated while keeping the implementation  
> and in the next major version the method can probably be removed.

While normally I would agree, stuff on org.codehaus.groovy is subject  
to change, where groovy.* needs to be held to a much higher standard.

IMO, stuff in groovy.* is the public api, and org.codehaus.groovy is  
internal.  While the internal classes may be public to allow for  
interclass communication it does not mean than between versions that  
those internals will not change.

If you would like to create a groovy.compiler.* API that exposes all  
of these internals for consumption then that API should be very  
seriously considered for removal and deprecation to provide robust  
backwards compatible support.

This is after all one of the main reasons for the groovy.* and  
org.codehaus.groovy package splits... or really any such split between  
a public api and and internal api.

>> I can add back a deprecated method for addSourceFile() but the  
>> behavior of only generating stubs when there is at least one .java  
>> file will not be restored.  So you can add a billion .java files,  
>> no .groovy files and it will do nothing.  If you add a  
>> billon .groovy files and no .java files it will attempt to create a  
>> billon+ stubs for each .groovy file.
>> Will that resolve this issue?
>
> partially. The reason we create no stubs if no java file is present  
> was because if we compile groovy source only we don't need the stubs  
> and the stubs creation takes away performance big ways. So where is  
> this controlled now?

IIRC correctly I added this class to be used only to generate stubs,  
regardless if there were java inputs or not.  So I was surprised to  
discover that when no java sources were in the mix that o stubs were  
generated... since the class only existed to generate stubs for groovy  
sources. (as indicated by the class javadocs).  So I fixed the *bug*  
which was that if you do not add a single .java source that no stubs  
are generated at all.

This was also the goal of the GenerateStubsTask which also behaved  
strangely if no .java sources were given to it.  If something wants to  
only generate stubs if it knows about .java and .groovy sources then  
it should encapsulate that logic in its internals and only call the  
JavaStubCompilationUnit if there are n+.groovy sources and 1>=.java  
sources.

--jason

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

On Oct 27, 2009, at 8:21 PM, Jochen Theodorou wrote:

> Jason Dillon schrieb:
>> The JavaStubCompilationUnit was only every intended to generate  
>> stub files for groovy sources.  So I removed the bits which  
>> conditonally generated sources if there was more than one .java  
>> file included.
>> Was not aware that other folks were using this bit of API so I also  
>> renamed to methods to addSource().
>
> never ever just remove a public method even if it looks like an  
> internal method. Make it deprecated while keeping the implementation  
> and in the next major version the method can probably be removed.

BTW, this is one reason where there are so many turds laying around in  
Groovy (like GroovyLog... aka useless class).  No one wants to nuke it.

Maybe we need to get to a Groovy 2.0 level soon where all known turds  
from 1.x simply go away.

--jason


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Guillaume Laforge-2]

On Tue, Oct 27, 2009 at 14:57, Jason Dillon <jason@...> wrote:
> [...]
> BTW, this is one reason where there are so many turds laying around in
> Groovy (like GroovyLog... aka useless class).  No one wants to nuke it.
>
> Maybe we need to get to a Groovy 2.0 level soon where all known turds from
> 1.x simply go away.

We're diverting towards another topic / thread... but yes, that would
be a good thing to compile all those things :-)

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

Agreed.  I've re-added addSourceFile(File) as a deprecated method on  
JavaStubCompilationUnit that simply calls addSource(File)

--jason


On Oct 27, 2009, at 9:07 PM, Guillaume Laforge wrote:

> On Tue, Oct 27, 2009 at 14:57, Jason Dillon <jason@...>  
> wrote:
>> [...]
>> BTW, this is one reason where there are so many turds laying around  
>> in
>> Groovy (like GroovyLog... aka useless class).  No one wants to nuke  
>> it.
>>
>> Maybe we need to get to a Groovy 2.0 level soon where all known  
>> turds from
>> 1.x simply go away.
>
> We're diverting towards another topic / thread... but yes, that would
> be a good thing to compile all those things :-)
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>
> ---------------------------------------------------------------------
> 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

[Jochen Theodorou]

Jason Dillon schrieb:

> On Oct 27, 2009, at 8:21 PM, Jochen Theodorou wrote:
>> Jason Dillon schrieb:
>>> The JavaStubCompilationUnit was only every intended to generate stub
>>> files for groovy sources.  So I removed the bits which conditonally
>>> generated sources if there was more than one .java file included.
>>> Was not aware that other folks were using this bit of API so I also
>>> renamed to methods to addSource().
>>
>> never ever just remove a public method even if it looks like an
>> internal method. Make it deprecated while keeping the implementation
>> and in the next major version the method can probably be removed.
>
> While normally I would agree, stuff on org.codehaus.groovy is subject to
> change, where groovy.* needs to be held to a much higher standard.

hmm... there is JavaAwareCompilationUnit, which is used by the compiler
and is not affected by your change. And there is
JavaStubCompilationUnit. IMHO the best approach for internal vs. not
internal is to say it in the comment of the class.
JavaStubCompilationUnit is intended to be used only and solely by
GenerateStubsTask and the comment should reflect that. I wonder why the
IntelliJ guys don't use JavaAwareCompilationUnit. Alex added it after
all for the IntelliJ guys while he still was at IntelliJ.

One more thing... JavaStubCompilationUnit uses a fixed ".groovy"
extension, but the CompilerConfiguration has an option to set a
different extension... you should consider changing from using the
constant to using the configuration object.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

On Oct 27, 2009, at 9:13 PM, Jochen Theodorou wrote:

> Jason Dillon schrieb:
>> On Oct 27, 2009, at 8:21 PM, Jochen Theodorou wrote:
>>> Jason Dillon schrieb:
>>>> The JavaStubCompilationUnit was only every intended to generate  
>>>> stub files for groovy sources.  So I removed the bits which  
>>>> conditonally generated sources if there was more than one .java  
>>>> file included.
>>>> Was not aware that other folks were using this bit of API so I  
>>>> also renamed to methods to addSource().
>>>
>>> never ever just remove a public method even if it looks like an  
>>> internal method. Make it deprecated while keeping the  
>>> implementation and in the next major version the method can  
>>> probably be removed.
>> While normally I would agree, stuff on org.codehaus.groovy is  
>> subject to change, where groovy.* needs to be held to a much higher  
>> standard.
>
> hmm... there is JavaAwareCompilationUnit, which is used by the  
> compiler and is not affected by your change. And there is  
> JavaStubCompilationUnit. IMHO the best approach for internal vs. not  
> internal is to say it in the comment of the class.  
> JavaStubCompilationUnit is intended to be used only and solely by  
> GenerateStubsTask and the comment should reflect that.

This is not true, as the name of the class implies the  
JavaStubCompilationUnit is used for anyone who needs to *just*  
generate stubs.  So that means GenerateStubsTask or say the stub  
generator for GMaven using the 1.7 runtime.

So think that every class in org.codehaus.groovy that is only intended  
for internal use to be affixed with some comment?  Isn't that exactly  
the purpose of putting those classes in the org.codehaus.groovy  
package?  Otherwise why does org.codehaus.groovy exist at all? Why  
isn't everything under groovy.*?


> I wonder why the IntelliJ guys don't use JavaAwareCompilationUnit.  
> Alex added it after all for the IntelliJ guys while he still was at  
> IntelliJ.

Probably because IntelliJ, like GMaven, wants to have separate phases  
for stub generation and re-use the existing java compilation which the  
target platform supplies.  But I am only guessing...


> One more thing... JavaStubCompilationUnit uses a fixed ".groovy"  
> extension, but the CompilerConfiguration has an option to set a  
> different extension... you should consider changing from using the  
> constant to using the configuration object.

Okay, must have missed that, can easily augment it to user what is  
given in the configuration.

--jason

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jason Dillon schrieb:
[...]
> So think that every class in org.codehaus.groovy that is only intended
> for internal use to be affixed with some comment?  Isn't that exactly
> the purpose of putting those classes in the org.codehaus.groovy
> package?  Otherwise why does org.codehaus.groovy exist at all? Why isn't
> everything under groovy.*?

there is a difference between the language and the API in that for
example an ant task is in the org.codehaus.groovy package, as it is not
part of the language, but it is part of the API.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Alex Tkachman]

+1

On Tue, Oct 27, 2009 at 4:49 PM, Jochen Theodorou <blackdrag@...> wrote:

> Jason Dillon schrieb:
> [...]
>>
>> So think that every class in org.codehaus.groovy that is only intended for
>> internal use to be affixed with some comment?  Isn't that exactly the
>> purpose of putting those classes in the org.codehaus.groovy package?
>>  Otherwise why does org.codehaus.groovy exist at all? Why isn't everything
>> under groovy.*?
>
> there is a difference between the language and the API in that for example
> an ant task is in the org.codehaus.groovy package, as it is not part of the
> language, but it is part of the API.
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.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

[Jason Dillon]

On Oct 27, 2009, at 9:49 PM, Jochen Theodorou wrote:

> Jason Dillon schrieb:
> [...]
>> So think that every class in org.codehaus.groovy that is only  
>> intended for internal use to be affixed with some comment?  Isn't  
>> that exactly the purpose of putting those classes in the  
>> org.codehaus.groovy package?  Otherwise why does  
>> org.codehaus.groovy exist at all? Why isn't everything under  
>> groovy.*?
>
> there is a difference between the language and the API in that for  
> example an ant task is in the org.codehaus.groovy package, as it is  
> not part of the language, but it is part of the API.

SO if the Ant task is intended to be used outside of the project and  
has no abstraction like a properties file to load the class, then  
perhaps it should be in groovy.ant.

--jason

> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.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

[Jason Dillon]

Sounds like groovy needs a groovyx. for all that non-language stuff  
which is still intended to be public API.

BTW, there is a lot of stuff under groovy.* which is not strictly  
specific to the language.. or even very useful (as mentioned before  
GroovyLog...).

--jason


On Oct 27, 2009, at 9:49 PM, Jochen Theodorou wrote:

> Jason Dillon schrieb:
> [...]
>> So think that every class in org.codehaus.groovy that is only  
>> intended for internal use to be affixed with some comment?  Isn't  
>> that exactly the purpose of putting those classes in the  
>> org.codehaus.groovy package?  Otherwise why does  
>> org.codehaus.groovy exist at all? Why isn't everything under  
>> groovy.*?
>
> there is a difference between the language and the API in that for  
> example an ant task is in the org.codehaus.groovy package, as it is  
> not part of the language, but it is part of the API.
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.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

[Russel Winder-4]

On Tue, 2009-10-27 at 22:08 +0700, Jason Dillon wrote:
> Sounds like groovy needs a groovyx. for all that non-language stuff  
> which is still intended to be public API.

Groovy already has a groovyx package, GPars is in it; cf. groovyx.gpars.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Jason Dillon]

I forgot about those ;-)

Anyways my point is that just like com.sun.* or sun. or sunw.* (etc)  
is intended as a internal API and subject to change w/o notice and  
java.* (and javax.*) is a public api which will adhere to much higher  
standards of backwards compatibility. So should org.codehaus.groovy be  
considered internal and allowed to change with greater freedom that  
groovy.* (or groovyx.*).  Bits from org.codehaus.groovy which are  
intended to be a public api and thus need to adhere to higher  
standards for compat should probably have interfaces implemented from  
groovy.* or be moved to groovy.*

--jason


On Oct 27, 2009, at 10:44 PM, Russel Winder wrote:

> On Tue, 2009-10-27 at 22:08 +0700, Jason Dillon wrote:
>> Sounds like groovy needs a groovyx. for all that non-language stuff
>> which is still intended to be public API.
>
> Groovy already has a groovyx package, GPars is in it; cf.  
> groovyx.gpars.
>
> --
> Russel.
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> Dr Russel Winder      Partner
>                                            xmpp: russel@...
> Concertant LLP        t: [phone], [phone]
> 41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
> London SW11 1EN, UK   m: [phone]   skype: russel_winder

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email