Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Sebastien Blanc
Hi,
We are building our own custom plugin which relies heavily on the Groovy Eclipse Plugin.
Today, I was cleaning the things a bit up to rely on the provided org.eclipse.groovy instead of one of our bundle.
But the bundle org.eclipse.groovy fails to load some classes (from javax.script packages, we must be 1.5 compliant). I've isolated the problem : it's a OSGI/classpath hell problem ;-) . And for me there only one solution : Create a fragment that extends your bundle.

But I would like to mention another option that needs action on your side and it's very trivial : Adding  Eclipse-BuddyPolicy:registered  to the manifest file.
That means that other plugin that declares Eclipse-RegisterBuddy: org.eclipse.groovy authorizes the groovy bundle to access other bundle classpathes.

I hope it was clear,
Best Regards,
Sébastien


Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Andrew Eisenberg
> We are building our own custom plugin which relies heavily on the Groovy
> Eclipse Plugin.
Great.  What is your plugin doing?

> Today, I was cleaning the things a bit up to rely on the provided
> org.eclipse.groovy instead of one of our bundle.
I assume that you mean org.codehaus.groovy since org.eclipse.groovy
does not exist.


> But the bundle org.eclipse.groovy fails to load some classes (from
> javax.script packages, we must be 1.5 compliant). I've isolated the problem
> : it's a OSGI/classpath hell problem ;-) . And for me there only one
> solution : Create a fragment that extends your bundle.
org.codehaus.groovy should also be 1.5 compliant and if it's not, then
that is a problem.  Can you tell me more precisely what is going on?

> But I would like to mention another option that needs action on your side
> and it's very trivial : Adding  Eclipse-BuddyPolicy:registered  to the
> manifest file.
> That means that other plugin that declares Eclipse-RegisterBuddy:
> org.eclipse.groovy authorizes the groovy bundle to access other bundle
> classpathes.
I could consider this, but let me know why you need this
functionality.  My understanding is that using buddy policies in the
wrong way can lead to circular classpath dependencies and hence
possible deadlocks on classloads.  So, I would be cautious about using
this unless you know this is the right way to go.  I would prefer to
avoid the need for this.


>
> I hope it was clear,
> Best Regards,
> Sébastien
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Sebastien Blanc
Hi,
I can not tell to much about the plugin functionnality because of a NDA and it's for internal use. But basically, the user can upload his script to a platform where the script will be executed. Besides that will provides some security checks, bundle the codenarc plugin etc ... (You can also ask Guillaume Laforge, his knows well this project)
But we are planning to open source some "generic" parts of the plugin such as a very nice code completion feature for object representing a xml structure (using annotations and XSD parsing).

Ok, back to business ;-) 

Yes of course I meant org.codehaus.groovy and it works fine with 1.5. But in our case, we are using the JSR 233 Scripting implementation which is included in 1.6 but not in 1.5. So for 1.5, we use an additional jar containing the JSR233 implementation. This jar needs to be on the classpath of Groovy (in our use case). 

In a previous version I had my own bundle with groovy as "regular" jar (not the bundle) and the JSR233 impl and it works fine because they were on the same classpath.

But doing this was redundant because I had a extra groovy jar in my project while the org.codehaus.groovy already provides it. So I modify my bundle to have a dependency on the org.codehaus.groovy bundle. But org.codehaus.groovy has its own classpath which I can't modify and it fails to load classes from my JSR233 jar.

I know the risk of the buddy policies but I think that in my case it really makes sense.

Hope I was clear, it's not that easy to explain this through a email.

Seb

  

On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg <[hidden email]> wrote:
> We are building our own custom plugin which relies heavily on the Groovy
> Eclipse Plugin.
Great.  What is your plugin doing?

> Today, I was cleaning the things a bit up to rely on the provided
> org.eclipse.groovy instead of one of our bundle.
I assume that you mean org.codehaus.groovy since org.eclipse.groovy
does not exist.


> But the bundle org.eclipse.groovy fails to load some classes (from
> javax.script packages, we must be 1.5 compliant). I've isolated the problem
> : it's a OSGI/classpath hell problem ;-) . And for me there only one
> solution : Create a fragment that extends your bundle.
org.codehaus.groovy should also be 1.5 compliant and if it's not, then
that is a problem.  Can you tell me more precisely what is going on?

> But I would like to mention another option that needs action on your side
> and it's very trivial : Adding  Eclipse-BuddyPolicy:registered  to the
> manifest file.
> That means that other plugin that declares Eclipse-RegisterBuddy:
> org.eclipse.groovy authorizes the groovy bundle to access other bundle
> classpathes.
I could consider this, but let me know why you need this
functionality.  My understanding is that using buddy policies in the
wrong way can lead to circular classpath dependencies and hence
possible deadlocks on classloads.  So, I would be cautious about using
this unless you know this is the right way to go.  I would prefer to
avoid the need for this.


>
> I hope it was clear,
> Best Regards,
> Sébastien
>
>

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Andrew Eisenberg
> I can not tell to much about the plugin functionnality because of a NDA and
> it's for internal use. But basically, the user can upload his script to
> a platform where the script will be executed. Besides that will provides
> some security checks, bundle the codenarc plugin etc ... (You can also ask
> Guillaume Laforge, his knows well this project)
> But we are planning to open source some "generic" parts of the plugin such
> as a very nice code completion feature for object representing a xml
> structure (using annotations and XSD parsing).

Very nice.  If this feature is generally useful, you could consider
contributing this into Groovy-Eclipse itself.

> Yes of course I meant org.codehaus.groovy and it works fine with 1.5. But in
> our case, we are using the JSR 233 Scripting implementation which is
> included in 1.6 but not in 1.5. So for 1.5, we use an additional jar
> containing the JSR233 implementation. This jar needs to be on the classpath
> of Groovy (in our use case).
>
> In a previous version I had my own bundle with groovy as "regular" jar (not
> the bundle) and the JSR233 impl and it works fine because they were on the
> same classpath.

I see the problem now.  Thanks for the explanation.  I raised this issue:
http://jira.codehaus.org/browse/GRECLIPSE-1313

Have you tried this out locally and does it work for you?  You can
just import org.codehaus.groovy as a PDE project and make the changes
to the manifest.

>
> But doing this was redundant because I had a extra groovy jar in my project
> while the org.codehaus.groovy already provides it. So I modify my bundle to
> have a dependency on the org.codehaus.groovy bundle. But org.codehaus.groovy
> has its own classpath which I can't modify and it fails to load classes from
> my JSR233 jar.
>
> I know the risk of the buddy policies but I think that in my case it really
> makes sense.
>
> Hope I was clear, it's not that easy to explain this through a email.
>
> Seb
>
>
>
> On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> > We are building our own custom plugin which relies heavily on the Groovy
>> > Eclipse Plugin.
>> Great.  What is your plugin doing?
>>
>> > Today, I was cleaning the things a bit up to rely on the provided
>> > org.eclipse.groovy instead of one of our bundle.
>> I assume that you mean org.codehaus.groovy since org.eclipse.groovy
>> does not exist.
>>
>>
>> > But the bundle org.eclipse.groovy fails to load some classes (from
>> > javax.script packages, we must be 1.5 compliant). I've isolated the
>> > problem
>> > : it's a OSGI/classpath hell problem ;-) . And for me there only one
>> > solution : Create a fragment that extends your bundle.
>> org.codehaus.groovy should also be 1.5 compliant and if it's not, then
>> that is a problem.  Can you tell me more precisely what is going on?
>>
>> > But I would like to mention another option that needs action on your
>> > side
>> > and it's very trivial : Adding  Eclipse-BuddyPolicy:registered  to the
>> > manifest file.
>> > That means that other plugin that declares Eclipse-RegisterBuddy:
>> > org.eclipse.groovy authorizes the groovy bundle to access other bundle
>> > classpathes.
>> I could consider this, but let me know why you need this
>> functionality.  My understanding is that using buddy policies in the
>> wrong way can lead to circular classpath dependencies and hence
>> possible deadlocks on classloads.  So, I would be cautious about using
>> this unless you know this is the right way to go.  I would prefer to
>> avoid the need for this.
>>
>>
>> >
>> > I hope it was clear,
>> > Best Regards,
>> > Sébastien
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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


Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Sebastien Blanc
Thanks Andrew !
I haven't try it locally yet but I will do it tomorrow morning at the office and keep you informed.
Seb


On Tue, Jan 3, 2012 at 8:07 PM, Andrew Eisenberg <[hidden email]> wrote:
> I can not tell to much about the plugin functionnality because of a NDA and
> it's for internal use. But basically, the user can upload his script to
> a platform where the script will be executed. Besides that will provides
> some security checks, bundle the codenarc plugin etc ... (You can also ask
> Guillaume Laforge, his knows well this project)
> But we are planning to open source some "generic" parts of the plugin such
> as a very nice code completion feature for object representing a xml
> structure (using annotations and XSD parsing).

Very nice.  If this feature is generally useful, you could consider
contributing this into Groovy-Eclipse itself.

> Yes of course I meant org.codehaus.groovy and it works fine with 1.5. But in
> our case, we are using the JSR 233 Scripting implementation which is
> included in 1.6 but not in 1.5. So for 1.5, we use an additional jar
> containing the JSR233 implementation. This jar needs to be on the classpath
> of Groovy (in our use case).
>
> In a previous version I had my own bundle with groovy as "regular" jar (not
> the bundle) and the JSR233 impl and it works fine because they were on the
> same classpath.

I see the problem now.  Thanks for the explanation.  I raised this issue:
http://jira.codehaus.org/browse/GRECLIPSE-1313

Have you tried this out locally and does it work for you?  You can
just import org.codehaus.groovy as a PDE project and make the changes
to the manifest.

>
> But doing this was redundant because I had a extra groovy jar in my project
> while the org.codehaus.groovy already provides it. So I modify my bundle to
> have a dependency on the org.codehaus.groovy bundle. But org.codehaus.groovy
> has its own classpath which I can't modify and it fails to load classes from
> my JSR233 jar.
>
> I know the risk of the buddy policies but I think that in my case it really
> makes sense.
>
> Hope I was clear, it's not that easy to explain this through a email.
>
> Seb
>
>
>
> On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> > We are building our own custom plugin which relies heavily on the Groovy
>> > Eclipse Plugin.
>> Great.  What is your plugin doing?
>>
>> > Today, I was cleaning the things a bit up to rely on the provided
>> > org.eclipse.groovy instead of one of our bundle.
>> I assume that you mean org.codehaus.groovy since org.eclipse.groovy
>> does not exist.
>>
>>
>> > But the bundle org.eclipse.groovy fails to load some classes (from
>> > javax.script packages, we must be 1.5 compliant). I've isolated the
>> > problem
>> > : it's a OSGI/classpath hell problem ;-) . And for me there only one
>> > solution : Create a fragment that extends your bundle.
>> org.codehaus.groovy should also be 1.5 compliant and if it's not, then
>> that is a problem.  Can you tell me more precisely what is going on?
>>
>> > But I would like to mention another option that needs action on your
>> > side
>> > and it's very trivial : Adding  Eclipse-BuddyPolicy:registered  to the
>> > manifest file.
>> > That means that other plugin that declares Eclipse-RegisterBuddy:
>> > org.eclipse.groovy authorizes the groovy bundle to access other bundle
>> > classpathes.
>> I could consider this, but let me know why you need this
>> functionality.  My understanding is that using buddy policies in the
>> wrong way can lead to circular classpath dependencies and hence
>> possible deadlocks on classloads.  So, I would be cautious about using
>> this unless you know this is the right way to go.  I would prefer to
>> avoid the need for this.
>>
>>
>> >
>> > I hope it was clear,
>> > Best Regards,
>> > Sébastien
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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



Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Sebastien Blanc
Hi,
I just made a test an it works ! The only little problem is that own my side I have to declare the full bundle name (including the version) of org.codehaus.groovy. Until now I was working on yours snapshots, I will move now to the latest release.

For info in the manifest of org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE 
I added 
Eclipse-BuddyPolicy: registered

On my side FYI :
Eclipse-RegisterBuddy:  org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE 

Regards,
Seb


On Tue, Jan 3, 2012 at 8:51 PM, Sebastien Blanc <[hidden email]> wrote:
Thanks Andrew !
I haven't try it locally yet but I will do it tomorrow morning at the office and keep you informed.
Seb


On Tue, Jan 3, 2012 at 8:07 PM, Andrew Eisenberg <[hidden email]> wrote:
> I can not tell to much about the plugin functionnality because of a NDA and
> it's for internal use. But basically, the user can upload his script to
> a platform where the script will be executed. Besides that will provides
> some security checks, bundle the codenarc plugin etc ... (You can also ask
> Guillaume Laforge, his knows well this project)
> But we are planning to open source some "generic" parts of the plugin such
> as a very nice code completion feature for object representing a xml
> structure (using annotations and XSD parsing).

Very nice.  If this feature is generally useful, you could consider
contributing this into Groovy-Eclipse itself.

> Yes of course I meant org.codehaus.groovy and it works fine with 1.5. But in
> our case, we are using the JSR 233 Scripting implementation which is
> included in 1.6 but not in 1.5. So for 1.5, we use an additional jar
> containing the JSR233 implementation. This jar needs to be on the classpath
> of Groovy (in our use case).
>
> In a previous version I had my own bundle with groovy as "regular" jar (not
> the bundle) and the JSR233 impl and it works fine because they were on the
> same classpath.

I see the problem now.  Thanks for the explanation.  I raised this issue:
http://jira.codehaus.org/browse/GRECLIPSE-1313

Have you tried this out locally and does it work for you?  You can
just import org.codehaus.groovy as a PDE project and make the changes
to the manifest.

>
> But doing this was redundant because I had a extra groovy jar in my project
> while the org.codehaus.groovy already provides it. So I modify my bundle to
> have a dependency on the org.codehaus.groovy bundle. But org.codehaus.groovy
> has its own classpath which I can't modify and it fails to load classes from
> my JSR233 jar.
>
> I know the risk of the buddy policies but I think that in my case it really
> makes sense.
>
> Hope I was clear, it's not that easy to explain this through a email.
>
> Seb
>
>
>
> On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> > We are building our own custom plugin which relies heavily on the Groovy
>> > Eclipse Plugin.
>> Great.  What is your plugin doing?
>>
>> > Today, I was cleaning the things a bit up to rely on the provided
>> > org.eclipse.groovy instead of one of our bundle.
>> I assume that you mean org.codehaus.groovy since org.eclipse.groovy
>> does not exist.
>>
>>
>> > But the bundle org.eclipse.groovy fails to load some classes (from
>> > javax.script packages, we must be 1.5 compliant). I've isolated the
>> > problem
>> > : it's a OSGI/classpath hell problem ;-) . And for me there only one
>> > solution : Create a fragment that extends your bundle.
>> org.codehaus.groovy should also be 1.5 compliant and if it's not, then
>> that is a problem.  Can you tell me more precisely what is going on?
>>
>> > But I would like to mention another option that needs action on your
>> > side
>> > and it's very trivial : Adding  Eclipse-BuddyPolicy:registered  to the
>> > manifest file.
>> > That means that other plugin that declares Eclipse-RegisterBuddy:
>> > org.eclipse.groovy authorizes the groovy bundle to access other bundle
>> > classpathes.
>> I could consider this, but let me know why you need this
>> functionality.  My understanding is that using buddy policies in the
>> wrong way can lead to circular classpath dependencies and hence
>> possible deadlocks on classloads.  So, I would be cautious about using
>> this unless you know this is the right way to go.  I would prefer to
>> avoid the need for this.
>>
>>
>> >
>> > I hope it was clear,
>> > Best Regards,
>> > Sébastien
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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




Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Andrew Eisenberg
OK.  I will make the change.  It is unfortunate that you need to
specify the full version number of the bundle.  This goes against what
the documentation says.  Could it be because we ship with 2
org.codehaus.groovy bundles?  What happens if you remove one of them?

A problem with relying on released versions is that you will have to
wait for the next release before the buddy policy header is in the
bundles.  If you can't find out any other way, I'd recommend that you
grab the latest update site zip from
http://ci.repository.codehaus.org/greclipse/snapshot/e37/old/ and
build against that until an actual release comes out.

I'll let you know when a snapshot is available.

On Wed, Jan 4, 2012 at 2:14 AM, Sebastien Blanc <[hidden email]> wrote:

> Hi,
> I just made a test an it works ! The only little problem is that own my side
> I have to declare the full bundle name (including the version) of
> org.codehaus.groovy. Until now I was working on yours snapshots, I will move
> now to the latest release.
>
> For info in the manifest
> of org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
> I added
> Eclipse-BuddyPolicy: registered
>
> On my side FYI :
> Eclipse-RegisterBuddy:
> org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>
> Regards,
> Seb
>
>
> On Tue, Jan 3, 2012 at 8:51 PM, Sebastien Blanc <[hidden email]> wrote:
>>
>> Thanks Andrew !
>> I haven't try it locally yet but I will do it tomorrow morning at the
>> office and keep you informed.
>> Seb
>>
>>
>> On Tue, Jan 3, 2012 at 8:07 PM, Andrew Eisenberg <[hidden email]>
>> wrote:
>>>
>>> > I can not tell to much about the plugin functionnality because of a NDA
>>> > and
>>> > it's for internal use. But basically, the user can upload his script to
>>> > a platform where the script will be executed. Besides that will
>>> > provides
>>> > some security checks, bundle the codenarc plugin etc ... (You can also
>>> > ask
>>> > Guillaume Laforge, his knows well this project)
>>> > But we are planning to open source some "generic" parts of the plugin
>>> > such
>>> > as a very nice code completion feature for object representing a xml
>>> > structure (using annotations and XSD parsing).
>>>
>>> Very nice.  If this feature is generally useful, you could consider
>>> contributing this into Groovy-Eclipse itself.
>>>
>>> > Yes of course I meant org.codehaus.groovy and it works fine with 1.5.
>>> > But in
>>> > our case, we are using the JSR 233 Scripting implementation which is
>>> > included in 1.6 but not in 1.5. So for 1.5, we use an additional jar
>>> > containing the JSR233 implementation. This jar needs to be on the
>>> > classpath
>>> > of Groovy (in our use case).
>>> >
>>> > In a previous version I had my own bundle with groovy as "regular" jar
>>> > (not
>>> > the bundle) and the JSR233 impl and it works fine because they were on
>>> > the
>>> > same classpath.
>>>
>>> I see the problem now.  Thanks for the explanation.  I raised this issue:
>>> http://jira.codehaus.org/browse/GRECLIPSE-1313
>>>
>>> Have you tried this out locally and does it work for you?  You can
>>> just import org.codehaus.groovy as a PDE project and make the changes
>>> to the manifest.
>>>
>>> >
>>> > But doing this was redundant because I had a extra groovy jar in my
>>> > project
>>> > while the org.codehaus.groovy already provides it. So I modify my
>>> > bundle to
>>> > have a dependency on the org.codehaus.groovy bundle. But
>>> > org.codehaus.groovy
>>> > has its own classpath which I can't modify and it fails to load classes
>>> > from
>>> > my JSR233 jar.
>>> >
>>> > I know the risk of the buddy policies but I think that in my case it
>>> > really
>>> > makes sense.
>>> >
>>> > Hope I was clear, it's not that easy to explain this through a email.
>>> >
>>> > Seb
>>> >
>>> >
>>> >
>>> > On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg <[hidden email]>
>>> > wrote:
>>> >>
>>> >> > We are building our own custom plugin which relies heavily on the
>>> >> > Groovy
>>> >> > Eclipse Plugin.
>>> >> Great.  What is your plugin doing?
>>> >>
>>> >> > Today, I was cleaning the things a bit up to rely on the provided
>>> >> > org.eclipse.groovy instead of one of our bundle.
>>> >> I assume that you mean org.codehaus.groovy since org.eclipse.groovy
>>> >> does not exist.
>>> >>
>>> >>
>>> >> > But the bundle org.eclipse.groovy fails to load some classes (from
>>> >> > javax.script packages, we must be 1.5 compliant). I've isolated the
>>> >> > problem
>>> >> > : it's a OSGI/classpath hell problem ;-) . And for me there only one
>>> >> > solution : Create a fragment that extends your bundle.
>>> >> org.codehaus.groovy should also be 1.5 compliant and if it's not, then
>>> >> that is a problem.  Can you tell me more precisely what is going on?
>>> >>
>>> >> > But I would like to mention another option that needs action on your
>>> >> > side
>>> >> > and it's very trivial : Adding  Eclipse-BuddyPolicy:registered  to
>>> >> > the
>>> >> > manifest file.
>>> >> > That means that other plugin that declares Eclipse-RegisterBuddy:
>>> >> > org.eclipse.groovy authorizes the groovy bundle to access other
>>> >> > bundle
>>> >> > classpathes.
>>> >> I could consider this, but let me know why you need this
>>> >> functionality.  My understanding is that using buddy policies in the
>>> >> wrong way can lead to circular classpath dependencies and hence
>>> >> possible deadlocks on classloads.  So, I would be cautious about using
>>> >> this unless you know this is the right way to go.  I would prefer to
>>> >> avoid the need for this.
>>> >>
>>> >>
>>> >> >
>>> >> > I hope it was clear,
>>> >> > Best Regards,
>>> >> > Sébastien
>>> >> >
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> 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


Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Sebastien Blanc
yes,
Might be because of the 1.7 and 1.8 cohabiting. I have to dig a bit more what is really happening but thanks for the hint using the zip update site. 

On Wed, Jan 4, 2012 at 5:55 PM, Andrew Eisenberg <[hidden email]> wrote:
OK.  I will make the change.  It is unfortunate that you need to
specify the full version number of the bundle.  This goes against what
the documentation says.  Could it be because we ship with 2
org.codehaus.groovy bundles?  What happens if you remove one of them?

A problem with relying on released versions is that you will have to
wait for the next release before the buddy policy header is in the
bundles.  If you can't find out any other way, I'd recommend that you
grab the latest update site zip from
http://ci.repository.codehaus.org/greclipse/snapshot/e37/old/ and
build against that until an actual release comes out.

I'll let you know when a snapshot is available.

On Wed, Jan 4, 2012 at 2:14 AM, Sebastien Blanc <[hidden email]> wrote:
> Hi,
> I just made a test an it works ! The only little problem is that own my side
> I have to declare the full bundle name (including the version) of
> org.codehaus.groovy. Until now I was working on yours snapshots, I will move
> now to the latest release.
>
> For info in the manifest
> of org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
> I added
> Eclipse-BuddyPolicy: registered
>
> On my side FYI :
> Eclipse-RegisterBuddy:
> org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>
> Regards,
> Seb
>
>
> On Tue, Jan 3, 2012 at 8:51 PM, Sebastien Blanc <[hidden email]> wrote:
>>
>> Thanks Andrew !
>> I haven't try it locally yet but I will do it tomorrow morning at the
>> office and keep you informed.
>> Seb
>>
>>
>> On Tue, Jan 3, 2012 at 8:07 PM, Andrew Eisenberg <[hidden email]>
>> wrote:
>>>
>>> > I can not tell to much about the plugin functionnality because of a NDA
>>> > and
>>> > it's for internal use. But basically, the user can upload his script to
>>> > a platform where the script will be executed. Besides that will
>>> > provides
>>> > some security checks, bundle the codenarc plugin etc ... (You can also
>>> > ask
>>> > Guillaume Laforge, his knows well this project)
>>> > But we are planning to open source some "generic" parts of the plugin
>>> > such
>>> > as a very nice code completion feature for object representing a xml
>>> > structure (using annotations and XSD parsing).
>>>
>>> Very nice.  If this feature is generally useful, you could consider
>>> contributing this into Groovy-Eclipse itself.
>>>
>>> > Yes of course I meant org.codehaus.groovy and it works fine with 1.5.
>>> > But in
>>> > our case, we are using the JSR 233 Scripting implementation which is
>>> > included in 1.6 but not in 1.5. So for 1.5, we use an additional jar
>>> > containing the JSR233 implementation. This jar needs to be on the
>>> > classpath
>>> > of Groovy (in our use case).
>>> >
>>> > In a previous version I had my own bundle with groovy as "regular" jar
>>> > (not
>>> > the bundle) and the JSR233 impl and it works fine because they were on
>>> > the
>>> > same classpath.
>>>
>>> I see the problem now.  Thanks for the explanation.  I raised this issue:
>>> http://jira.codehaus.org/browse/GRECLIPSE-1313
>>>
>>> Have you tried this out locally and does it work for you?  You can
>>> just import org.codehaus.groovy as a PDE project and make the changes
>>> to the manifest.
>>>
>>> >
>>> > But doing this was redundant because I had a extra groovy jar in my
>>> > project
>>> > while the org.codehaus.groovy already provides it. So I modify my
>>> > bundle to
>>> > have a dependency on the org.codehaus.groovy bundle. But
>>> > org.codehaus.groovy
>>> > has its own classpath which I can't modify and it fails to load classes
>>> > from
>>> > my JSR233 jar.
>>> >
>>> > I know the risk of the buddy policies but I think that in my case it
>>> > really
>>> > makes sense.
>>> >
>>> > Hope I was clear, it's not that easy to explain this through a email.
>>> >
>>> > Seb
>>> >
>>> >
>>> >
>>> > On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg <[hidden email]>
>>> > wrote:
>>> >>
>>> >> > We are building our own custom plugin which relies heavily on the
>>> >> > Groovy
>>> >> > Eclipse Plugin.
>>> >> Great.  What is your plugin doing?
>>> >>
>>> >> > Today, I was cleaning the things a bit up to rely on the provided
>>> >> > org.eclipse.groovy instead of one of our bundle.
>>> >> I assume that you mean org.codehaus.groovy since org.eclipse.groovy
>>> >> does not exist.
>>> >>
>>> >>
>>> >> > But the bundle org.eclipse.groovy fails to load some classes (from
>>> >> > javax.script packages, we must be 1.5 compliant). I've isolated the
>>> >> > problem
>>> >> > : it's a OSGI/classpath hell problem ;-) . And for me there only one
>>> >> > solution : Create a fragment that extends your bundle.
>>> >> org.codehaus.groovy should also be 1.5 compliant and if it's not, then
>>> >> that is a problem.  Can you tell me more precisely what is going on?
>>> >>
>>> >> > But I would like to mention another option that needs action on your
>>> >> > side
>>> >> > and it's very trivial : Adding  Eclipse-BuddyPolicy:registered  to
>>> >> > the
>>> >> > manifest file.
>>> >> > That means that other plugin that declares Eclipse-RegisterBuddy:
>>> >> > org.eclipse.groovy authorizes the groovy bundle to access other
>>> >> > bundle
>>> >> > classpathes.
>>> >> I could consider this, but let me know why you need this
>>> >> functionality.  My understanding is that using buddy policies in the
>>> >> wrong way can lead to circular classpath dependencies and hence
>>> >> possible deadlocks on classloads.  So, I would be cautious about using
>>> >> this unless you know this is the right way to go.  I would prefer to
>>> >> avoid the need for this.
>>> >>
>>> >>
>>> >> >
>>> >> > I hope it was clear,
>>> >> > Best Regards,
>>> >> > Sébastien
>>> >> >
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> 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



Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Andrew Eisenberg
Let me know what you find out.  The change should now be available
from the snapshot update site (and from a zipped archive).

On Thu, Jan 5, 2012 at 4:02 AM, Sebastien Blanc <[hidden email]> wrote:

> yes,
> Might be because of the 1.7 and 1.8 cohabiting. I have to dig a bit more
> what is really happening but thanks for the hint using the zip update site.
>
>
> On Wed, Jan 4, 2012 at 5:55 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> OK.  I will make the change.  It is unfortunate that you need to
>> specify the full version number of the bundle.  This goes against what
>> the documentation says.  Could it be because we ship with 2
>> org.codehaus.groovy bundles?  What happens if you remove one of them?
>>
>> A problem with relying on released versions is that you will have to
>> wait for the next release before the buddy policy header is in the
>> bundles.  If you can't find out any other way, I'd recommend that you
>> grab the latest update site zip from
>> http://ci.repository.codehaus.org/greclipse/snapshot/e37/old/ and
>> build against that until an actual release comes out.
>>
>> I'll let you know when a snapshot is available.
>>
>> On Wed, Jan 4, 2012 at 2:14 AM, Sebastien Blanc <[hidden email]>
>> wrote:
>> > Hi,
>> > I just made a test an it works ! The only little problem is that own my
>> > side
>> > I have to declare the full bundle name (including the version) of
>> > org.codehaus.groovy. Until now I was working on yours snapshots, I will
>> > move
>> > now to the latest release.
>> >
>> > For info in the manifest
>> > of org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>> > I added
>> > Eclipse-BuddyPolicy: registered
>> >
>> > On my side FYI :
>> > Eclipse-RegisterBuddy:
>> > org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>> >
>> > Regards,
>> > Seb
>> >
>> >
>> > On Tue, Jan 3, 2012 at 8:51 PM, Sebastien Blanc <[hidden email]>
>> > wrote:
>> >>
>> >> Thanks Andrew !
>> >> I haven't try it locally yet but I will do it tomorrow morning at the
>> >> office and keep you informed.
>> >> Seb
>> >>
>> >>
>> >> On Tue, Jan 3, 2012 at 8:07 PM, Andrew Eisenberg <[hidden email]>
>> >> wrote:
>> >>>
>> >>> > I can not tell to much about the plugin functionnality because of a
>> >>> > NDA
>> >>> > and
>> >>> > it's for internal use. But basically, the user can upload his script
>> >>> > to
>> >>> > a platform where the script will be executed. Besides that will
>> >>> > provides
>> >>> > some security checks, bundle the codenarc plugin etc ... (You can
>> >>> > also
>> >>> > ask
>> >>> > Guillaume Laforge, his knows well this project)
>> >>> > But we are planning to open source some "generic" parts of the
>> >>> > plugin
>> >>> > such
>> >>> > as a very nice code completion feature for object representing a xml
>> >>> > structure (using annotations and XSD parsing).
>> >>>
>> >>> Very nice.  If this feature is generally useful, you could consider
>> >>> contributing this into Groovy-Eclipse itself.
>> >>>
>> >>> > Yes of course I meant org.codehaus.groovy and it works fine with
>> >>> > 1.5.
>> >>> > But in
>> >>> > our case, we are using the JSR 233 Scripting implementation which is
>> >>> > included in 1.6 but not in 1.5. So for 1.5, we use an additional jar
>> >>> > containing the JSR233 implementation. This jar needs to be on the
>> >>> > classpath
>> >>> > of Groovy (in our use case).
>> >>> >
>> >>> > In a previous version I had my own bundle with groovy as "regular"
>> >>> > jar
>> >>> > (not
>> >>> > the bundle) and the JSR233 impl and it works fine because they were
>> >>> > on
>> >>> > the
>> >>> > same classpath.
>> >>>
>> >>> I see the problem now.  Thanks for the explanation.  I raised this
>> >>> issue:
>> >>> http://jira.codehaus.org/browse/GRECLIPSE-1313
>> >>>
>> >>> Have you tried this out locally and does it work for you?  You can
>> >>> just import org.codehaus.groovy as a PDE project and make the changes
>> >>> to the manifest.
>> >>>
>> >>> >
>> >>> > But doing this was redundant because I had a extra groovy jar in my
>> >>> > project
>> >>> > while the org.codehaus.groovy already provides it. So I modify my
>> >>> > bundle to
>> >>> > have a dependency on the org.codehaus.groovy bundle. But
>> >>> > org.codehaus.groovy
>> >>> > has its own classpath which I can't modify and it fails to load
>> >>> > classes
>> >>> > from
>> >>> > my JSR233 jar.
>> >>> >
>> >>> > I know the risk of the buddy policies but I think that in my case it
>> >>> > really
>> >>> > makes sense.
>> >>> >
>> >>> > Hope I was clear, it's not that easy to explain this through a
>> >>> > email.
>> >>> >
>> >>> > Seb
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg
>> >>> > <[hidden email]>
>> >>> > wrote:
>> >>> >>
>> >>> >> > We are building our own custom plugin which relies heavily on the
>> >>> >> > Groovy
>> >>> >> > Eclipse Plugin.
>> >>> >> Great.  What is your plugin doing?
>> >>> >>
>> >>> >> > Today, I was cleaning the things a bit up to rely on the provided
>> >>> >> > org.eclipse.groovy instead of one of our bundle.
>> >>> >> I assume that you mean org.codehaus.groovy since org.eclipse.groovy
>> >>> >> does not exist.
>> >>> >>
>> >>> >>
>> >>> >> > But the bundle org.eclipse.groovy fails to load some classes
>> >>> >> > (from
>> >>> >> > javax.script packages, we must be 1.5 compliant). I've isolated
>> >>> >> > the
>> >>> >> > problem
>> >>> >> > : it's a OSGI/classpath hell problem ;-) . And for me there only
>> >>> >> > one
>> >>> >> > solution : Create a fragment that extends your bundle.
>> >>> >> org.codehaus.groovy should also be 1.5 compliant and if it's not,
>> >>> >> then
>> >>> >> that is a problem.  Can you tell me more precisely what is going
>> >>> >> on?
>> >>> >>
>> >>> >> > But I would like to mention another option that needs action on
>> >>> >> > your
>> >>> >> > side
>> >>> >> > and it's very trivial : Adding
>> >>> >> >  Eclipse-BuddyPolicy:registered  to
>> >>> >> > the
>> >>> >> > manifest file.
>> >>> >> > That means that other plugin that declares Eclipse-RegisterBuddy:
>> >>> >> > org.eclipse.groovy authorizes the groovy bundle to access other
>> >>> >> > bundle
>> >>> >> > classpathes.
>> >>> >> I could consider this, but let me know why you need this
>> >>> >> functionality.  My understanding is that using buddy policies in
>> >>> >> the
>> >>> >> wrong way can lead to circular classpath dependencies and hence
>> >>> >> possible deadlocks on classloads.  So, I would be cautious about
>> >>> >> using
>> >>> >> this unless you know this is the right way to go.  I would prefer
>> >>> >> to
>> >>> >> avoid the need for this.
>> >>> >>
>> >>> >>
>> >>> >> >
>> >>> >> > I hope it was clear,
>> >>> >> > Best Regards,
>> >>> >> > Sébastien
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >> ---------------------------------------------------------------------
>> >>> >> 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


Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Sebastien Blanc
Excellent !
I will try it tomorrow with the snapshot repo.
Just because I'm curious : how are building the groovy eclipse plugin? Custom build ? Through Eclipse ?
I've managed to automatise the whole build process with Maven with the help of the Tycho plugin  and some custom tweaks ;-) . If one day you need advice on the "maven" build process I will be glad to help you.
Seb


On Thu, Jan 5, 2012 at 5:40 PM, Andrew Eisenberg <[hidden email]> wrote:
Let me know what you find out.  The change should now be available
from the snapshot update site (and from a zipped archive).

On Thu, Jan 5, 2012 at 4:02 AM, Sebastien Blanc <[hidden email]> wrote:
> yes,
> Might be because of the 1.7 and 1.8 cohabiting. I have to dig a bit more
> what is really happening but thanks for the hint using the zip update site.
>
>
> On Wed, Jan 4, 2012 at 5:55 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> OK.  I will make the change.  It is unfortunate that you need to
>> specify the full version number of the bundle.  This goes against what
>> the documentation says.  Could it be because we ship with 2
>> org.codehaus.groovy bundles?  What happens if you remove one of them?
>>
>> A problem with relying on released versions is that you will have to
>> wait for the next release before the buddy policy header is in the
>> bundles.  If you can't find out any other way, I'd recommend that you
>> grab the latest update site zip from
>> http://ci.repository.codehaus.org/greclipse/snapshot/e37/old/ and
>> build against that until an actual release comes out.
>>
>> I'll let you know when a snapshot is available.
>>
>> On Wed, Jan 4, 2012 at 2:14 AM, Sebastien Blanc <[hidden email]>
>> wrote:
>> > Hi,
>> > I just made a test an it works ! The only little problem is that own my
>> > side
>> > I have to declare the full bundle name (including the version) of
>> > org.codehaus.groovy. Until now I was working on yours snapshots, I will
>> > move
>> > now to the latest release.
>> >
>> > For info in the manifest
>> > of org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>> > I added
>> > Eclipse-BuddyPolicy: registered
>> >
>> > On my side FYI :
>> > Eclipse-RegisterBuddy:
>> > org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>> >
>> > Regards,
>> > Seb
>> >
>> >
>> > On Tue, Jan 3, 2012 at 8:51 PM, Sebastien Blanc <[hidden email]>
>> > wrote:
>> >>
>> >> Thanks Andrew !
>> >> I haven't try it locally yet but I will do it tomorrow morning at the
>> >> office and keep you informed.
>> >> Seb
>> >>
>> >>
>> >> On Tue, Jan 3, 2012 at 8:07 PM, Andrew Eisenberg <[hidden email]>
>> >> wrote:
>> >>>
>> >>> > I can not tell to much about the plugin functionnality because of a
>> >>> > NDA
>> >>> > and
>> >>> > it's for internal use. But basically, the user can upload his script
>> >>> > to
>> >>> > a platform where the script will be executed. Besides that will
>> >>> > provides
>> >>> > some security checks, bundle the codenarc plugin etc ... (You can
>> >>> > also
>> >>> > ask
>> >>> > Guillaume Laforge, his knows well this project)
>> >>> > But we are planning to open source some "generic" parts of the
>> >>> > plugin
>> >>> > such
>> >>> > as a very nice code completion feature for object representing a xml
>> >>> > structure (using annotations and XSD parsing).
>> >>>
>> >>> Very nice.  If this feature is generally useful, you could consider
>> >>> contributing this into Groovy-Eclipse itself.
>> >>>
>> >>> > Yes of course I meant org.codehaus.groovy and it works fine with
>> >>> > 1.5.
>> >>> > But in
>> >>> > our case, we are using the JSR 233 Scripting implementation which is
>> >>> > included in 1.6 but not in 1.5. So for 1.5, we use an additional jar
>> >>> > containing the JSR233 implementation. This jar needs to be on the
>> >>> > classpath
>> >>> > of Groovy (in our use case).
>> >>> >
>> >>> > In a previous version I had my own bundle with groovy as "regular"
>> >>> > jar
>> >>> > (not
>> >>> > the bundle) and the JSR233 impl and it works fine because they were
>> >>> > on
>> >>> > the
>> >>> > same classpath.
>> >>>
>> >>> I see the problem now.  Thanks for the explanation.  I raised this
>> >>> issue:
>> >>> http://jira.codehaus.org/browse/GRECLIPSE-1313
>> >>>
>> >>> Have you tried this out locally and does it work for you?  You can
>> >>> just import org.codehaus.groovy as a PDE project and make the changes
>> >>> to the manifest.
>> >>>
>> >>> >
>> >>> > But doing this was redundant because I had a extra groovy jar in my
>> >>> > project
>> >>> > while the org.codehaus.groovy already provides it. So I modify my
>> >>> > bundle to
>> >>> > have a dependency on the org.codehaus.groovy bundle. But
>> >>> > org.codehaus.groovy
>> >>> > has its own classpath which I can't modify and it fails to load
>> >>> > classes
>> >>> > from
>> >>> > my JSR233 jar.
>> >>> >
>> >>> > I know the risk of the buddy policies but I think that in my case it
>> >>> > really
>> >>> > makes sense.
>> >>> >
>> >>> > Hope I was clear, it's not that easy to explain this through a
>> >>> > email.
>> >>> >
>> >>> > Seb
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg
>> >>> > <[hidden email]>
>> >>> > wrote:
>> >>> >>
>> >>> >> > We are building our own custom plugin which relies heavily on the
>> >>> >> > Groovy
>> >>> >> > Eclipse Plugin.
>> >>> >> Great.  What is your plugin doing?
>> >>> >>
>> >>> >> > Today, I was cleaning the things a bit up to rely on the provided
>> >>> >> > org.eclipse.groovy instead of one of our bundle.
>> >>> >> I assume that you mean org.codehaus.groovy since org.eclipse.groovy
>> >>> >> does not exist.
>> >>> >>
>> >>> >>
>> >>> >> > But the bundle org.eclipse.groovy fails to load some classes
>> >>> >> > (from
>> >>> >> > javax.script packages, we must be 1.5 compliant). I've isolated
>> >>> >> > the
>> >>> >> > problem
>> >>> >> > : it's a OSGI/classpath hell problem ;-) . And for me there only
>> >>> >> > one
>> >>> >> > solution : Create a fragment that extends your bundle.
>> >>> >> org.codehaus.groovy should also be 1.5 compliant and if it's not,
>> >>> >> then
>> >>> >> that is a problem.  Can you tell me more precisely what is going
>> >>> >> on?
>> >>> >>
>> >>> >> > But I would like to mention another option that needs action on
>> >>> >> > your
>> >>> >> > side
>> >>> >> > and it's very trivial : Adding
>> >>> >> >  Eclipse-BuddyPolicy:registered  to
>> >>> >> > the
>> >>> >> > manifest file.
>> >>> >> > That means that other plugin that declares Eclipse-RegisterBuddy:
>> >>> >> > org.eclipse.groovy authorizes the groovy bundle to access other
>> >>> >> > bundle
>> >>> >> > classpathes.
>> >>> >> I could consider this, but let me know why you need this
>> >>> >> functionality.  My understanding is that using buddy policies in
>> >>> >> the
>> >>> >> wrong way can lead to circular classpath dependencies and hence
>> >>> >> possible deadlocks on classloads.  So, I would be cautious about
>> >>> >> using
>> >>> >> this unless you know this is the right way to go.  I would prefer
>> >>> >> to
>> >>> >> avoid the need for this.
>> >>> >>
>> >>> >>
>> >>> >> >
>> >>> >> > I hope it was clear,
>> >>> >> > Best Regards,
>> >>> >> > Sébastien
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >> ---------------------------------------------------------------------
>> >>> >> 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



Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Andrew Eisenberg
We use a standard PDE build, but we have a few hacks to get the groovy
code compiling.  You can see the scripts that we use over here:
https://svn.codehaus.org/groovy/eclipse/trunk/ide/org.codehaus.groovy.eclipse.pluginbuilder

Headless building of Eclipse plugins is a bit of a black art.  It has
taken us a while to get the current build running smoothly and one of
our other projects uses Tycho for its build (and there have been a few
pain points getting it to work properly).  So, at this point I don't
want to fix something that isn't broken.  :)

If you're interested, the build server is here:
http://bamboo.ci.codehaus.org/browse/GRECLIPSE

On Thu, Jan 5, 2012 at 9:41 AM, Sebastien Blanc <[hidden email]> wrote:

> Excellent !
> I will try it tomorrow with the snapshot repo.
> Just because I'm curious : how are building the groovy eclipse plugin?
> Custom build ? Through Eclipse ?
> I've managed to automatise the whole build process with Maven with the help
> of the Tycho plugin  and some custom tweaks ;-) . If one day you need advice
> on the "maven" build process I will be glad to help you.
> Seb
>
>
> On Thu, Jan 5, 2012 at 5:40 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> Let me know what you find out.  The change should now be available
>> from the snapshot update site (and from a zipped archive).
>>
>> On Thu, Jan 5, 2012 at 4:02 AM, Sebastien Blanc <[hidden email]>
>> wrote:
>> > yes,
>> > Might be because of the 1.7 and 1.8 cohabiting. I have to dig a bit more
>> > what is really happening but thanks for the hint using the zip update
>> > site.
>> >
>> >
>> > On Wed, Jan 4, 2012 at 5:55 PM, Andrew Eisenberg <[hidden email]>
>> > wrote:
>> >>
>> >> OK.  I will make the change.  It is unfortunate that you need to
>> >> specify the full version number of the bundle.  This goes against what
>> >> the documentation says.  Could it be because we ship with 2
>> >> org.codehaus.groovy bundles?  What happens if you remove one of them?
>> >>
>> >> A problem with relying on released versions is that you will have to
>> >> wait for the next release before the buddy policy header is in the
>> >> bundles.  If you can't find out any other way, I'd recommend that you
>> >> grab the latest update site zip from
>> >> http://ci.repository.codehaus.org/greclipse/snapshot/e37/old/ and
>> >> build against that until an actual release comes out.
>> >>
>> >> I'll let you know when a snapshot is available.
>> >>
>> >> On Wed, Jan 4, 2012 at 2:14 AM, Sebastien Blanc <[hidden email]>
>> >> wrote:
>> >> > Hi,
>> >> > I just made a test an it works ! The only little problem is that own
>> >> > my
>> >> > side
>> >> > I have to declare the full bundle name (including the version) of
>> >> > org.codehaus.groovy. Until now I was working on yours snapshots, I
>> >> > will
>> >> > move
>> >> > now to the latest release.
>> >> >
>> >> > For info in the manifest
>> >> > of org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>> >> > I added
>> >> > Eclipse-BuddyPolicy: registered
>> >> >
>> >> > On my side FYI :
>> >> > Eclipse-RegisterBuddy:
>> >> > org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>> >> >
>> >> > Regards,
>> >> > Seb
>> >> >
>> >> >
>> >> > On Tue, Jan 3, 2012 at 8:51 PM, Sebastien Blanc <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> Thanks Andrew !
>> >> >> I haven't try it locally yet but I will do it tomorrow morning at
>> >> >> the
>> >> >> office and keep you informed.
>> >> >> Seb
>> >> >>
>> >> >>
>> >> >> On Tue, Jan 3, 2012 at 8:07 PM, Andrew Eisenberg
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >>>
>> >> >>> > I can not tell to much about the plugin functionnality because of
>> >> >>> > a
>> >> >>> > NDA
>> >> >>> > and
>> >> >>> > it's for internal use. But basically, the user can upload his
>> >> >>> > script
>> >> >>> > to
>> >> >>> > a platform where the script will be executed. Besides that will
>> >> >>> > provides
>> >> >>> > some security checks, bundle the codenarc plugin etc ... (You can
>> >> >>> > also
>> >> >>> > ask
>> >> >>> > Guillaume Laforge, his knows well this project)
>> >> >>> > But we are planning to open source some "generic" parts of the
>> >> >>> > plugin
>> >> >>> > such
>> >> >>> > as a very nice code completion feature for object representing a
>> >> >>> > xml
>> >> >>> > structure (using annotations and XSD parsing).
>> >> >>>
>> >> >>> Very nice.  If this feature is generally useful, you could consider
>> >> >>> contributing this into Groovy-Eclipse itself.
>> >> >>>
>> >> >>> > Yes of course I meant org.codehaus.groovy and it works fine with
>> >> >>> > 1.5.
>> >> >>> > But in
>> >> >>> > our case, we are using the JSR 233 Scripting implementation which
>> >> >>> > is
>> >> >>> > included in 1.6 but not in 1.5. So for 1.5, we use an additional
>> >> >>> > jar
>> >> >>> > containing the JSR233 implementation. This jar needs to be on the
>> >> >>> > classpath
>> >> >>> > of Groovy (in our use case).
>> >> >>> >
>> >> >>> > In a previous version I had my own bundle with groovy as
>> >> >>> > "regular"
>> >> >>> > jar
>> >> >>> > (not
>> >> >>> > the bundle) and the JSR233 impl and it works fine because they
>> >> >>> > were
>> >> >>> > on
>> >> >>> > the
>> >> >>> > same classpath.
>> >> >>>
>> >> >>> I see the problem now.  Thanks for the explanation.  I raised this
>> >> >>> issue:
>> >> >>> http://jira.codehaus.org/browse/GRECLIPSE-1313
>> >> >>>
>> >> >>> Have you tried this out locally and does it work for you?  You can
>> >> >>> just import org.codehaus.groovy as a PDE project and make the
>> >> >>> changes
>> >> >>> to the manifest.
>> >> >>>
>> >> >>> >
>> >> >>> > But doing this was redundant because I had a extra groovy jar in
>> >> >>> > my
>> >> >>> > project
>> >> >>> > while the org.codehaus.groovy already provides it. So I modify my
>> >> >>> > bundle to
>> >> >>> > have a dependency on the org.codehaus.groovy bundle. But
>> >> >>> > org.codehaus.groovy
>> >> >>> > has its own classpath which I can't modify and it fails to load
>> >> >>> > classes
>> >> >>> > from
>> >> >>> > my JSR233 jar.
>> >> >>> >
>> >> >>> > I know the risk of the buddy policies but I think that in my case
>> >> >>> > it
>> >> >>> > really
>> >> >>> > makes sense.
>> >> >>> >
>> >> >>> > Hope I was clear, it's not that easy to explain this through a
>> >> >>> > email.
>> >> >>> >
>> >> >>> > Seb
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg
>> >> >>> > <[hidden email]>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> > We are building our own custom plugin which relies heavily on
>> >> >>> >> > the
>> >> >>> >> > Groovy
>> >> >>> >> > Eclipse Plugin.
>> >> >>> >> Great.  What is your plugin doing?
>> >> >>> >>
>> >> >>> >> > Today, I was cleaning the things a bit up to rely on the
>> >> >>> >> > provided
>> >> >>> >> > org.eclipse.groovy instead of one of our bundle.
>> >> >>> >> I assume that you mean org.codehaus.groovy since
>> >> >>> >> org.eclipse.groovy
>> >> >>> >> does not exist.
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> > But the bundle org.eclipse.groovy fails to load some classes
>> >> >>> >> > (from
>> >> >>> >> > javax.script packages, we must be 1.5 compliant). I've
>> >> >>> >> > isolated
>> >> >>> >> > the
>> >> >>> >> > problem
>> >> >>> >> > : it's a OSGI/classpath hell problem ;-) . And for me there
>> >> >>> >> > only
>> >> >>> >> > one
>> >> >>> >> > solution : Create a fragment that extends your bundle.
>> >> >>> >> org.codehaus.groovy should also be 1.5 compliant and if it's
>> >> >>> >> not,
>> >> >>> >> then
>> >> >>> >> that is a problem.  Can you tell me more precisely what is going
>> >> >>> >> on?
>> >> >>> >>
>> >> >>> >> > But I would like to mention another option that needs action
>> >> >>> >> > on
>> >> >>> >> > your
>> >> >>> >> > side
>> >> >>> >> > and it's very trivial : Adding
>> >> >>> >> >  Eclipse-BuddyPolicy:registered  to
>> >> >>> >> > the
>> >> >>> >> > manifest file.
>> >> >>> >> > That means that other plugin that
>> >> >>> >> > declares Eclipse-RegisterBuddy:
>> >> >>> >> > org.eclipse.groovy authorizes the groovy bundle to access
>> >> >>> >> > other
>> >> >>> >> > bundle
>> >> >>> >> > classpathes.
>> >> >>> >> I could consider this, but let me know why you need this
>> >> >>> >> functionality.  My understanding is that using buddy policies in
>> >> >>> >> the
>> >> >>> >> wrong way can lead to circular classpath dependencies and hence
>> >> >>> >> possible deadlocks on classloads.  So, I would be cautious about
>> >> >>> >> using
>> >> >>> >> this unless you know this is the right way to go.  I would
>> >> >>> >> prefer
>> >> >>> >> to
>> >> >>> >> avoid the need for this.
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> >
>> >> >>> >> > I hope it was clear,
>> >> >>> >> > Best Regards,
>> >> >>> >> > Sébastien
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> ---------------------------------------------------------------------
>> >> >>> >> 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
>>
>>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Sebastien Blanc
Hi,
I just had time to give the snapshot a test but I realized you put the wrong instruction in the manifest :
You have :
Eclipse-RegisterBuddy: registered
But it should be :
Eclipse-BuddyPolicy: registered

I hope I report that in time before the next release.

Regards,
Seb

On Thu, Jan 5, 2012 at 7:59 PM, Andrew Eisenberg <[hidden email]> wrote:
We use a standard PDE build, but we have a few hacks to get the groovy
code compiling.  You can see the scripts that we use over here:
https://svn.codehaus.org/groovy/eclipse/trunk/ide/org.codehaus.groovy.eclipse.pluginbuilder

Headless building of Eclipse plugins is a bit of a black art.  It has
taken us a while to get the current build running smoothly and one of
our other projects uses Tycho for its build (and there have been a few
pain points getting it to work properly).  So, at this point I don't
want to fix something that isn't broken.  :)

If you're interested, the build server is here:
http://bamboo.ci.codehaus.org/browse/GRECLIPSE

On Thu, Jan 5, 2012 at 9:41 AM, Sebastien Blanc <[hidden email]> wrote:
> Excellent !
> I will try it tomorrow with the snapshot repo.
> Just because I'm curious : how are building the groovy eclipse plugin?
> Custom build ? Through Eclipse ?
> I've managed to automatise the whole build process with Maven with the help
> of the Tycho plugin  and some custom tweaks ;-) . If one day you need advice
> on the "maven" build process I will be glad to help you.
> Seb
>
>
> On Thu, Jan 5, 2012 at 5:40 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> Let me know what you find out.  The change should now be available
>> from the snapshot update site (and from a zipped archive).
>>
>> On Thu, Jan 5, 2012 at 4:02 AM, Sebastien Blanc <[hidden email]>
>> wrote:
>> > yes,
>> > Might be because of the 1.7 and 1.8 cohabiting. I have to dig a bit more
>> > what is really happening but thanks for the hint using the zip update
>> > site.
>> >
>> >
>> > On Wed, Jan 4, 2012 at 5:55 PM, Andrew Eisenberg <[hidden email]>
>> > wrote:
>> >>
>> >> OK.  I will make the change.  It is unfortunate that you need to
>> >> specify the full version number of the bundle.  This goes against what
>> >> the documentation says.  Could it be because we ship with 2
>> >> org.codehaus.groovy bundles?  What happens if you remove one of them?
>> >>
>> >> A problem with relying on released versions is that you will have to
>> >> wait for the next release before the buddy policy header is in the
>> >> bundles.  If you can't find out any other way, I'd recommend that you
>> >> grab the latest update site zip from
>> >> http://ci.repository.codehaus.org/greclipse/snapshot/e37/old/ and
>> >> build against that until an actual release comes out.
>> >>
>> >> I'll let you know when a snapshot is available.
>> >>
>> >> On Wed, Jan 4, 2012 at 2:14 AM, Sebastien Blanc <[hidden email]>
>> >> wrote:
>> >> > Hi,
>> >> > I just made a test an it works ! The only little problem is that own
>> >> > my
>> >> > side
>> >> > I have to declare the full bundle name (including the version) of
>> >> > org.codehaus.groovy. Until now I was working on yours snapshots, I
>> >> > will
>> >> > move
>> >> > now to the latest release.
>> >> >
>> >> > For info in the manifest
>> >> > of org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>> >> > I added
>> >> > Eclipse-BuddyPolicy: registered
>> >> >
>> >> > On my side FYI :
>> >> > Eclipse-RegisterBuddy:
>> >> > org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>> >> >
>> >> > Regards,
>> >> > Seb
>> >> >
>> >> >
>> >> > On Tue, Jan 3, 2012 at 8:51 PM, Sebastien Blanc <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> Thanks Andrew !
>> >> >> I haven't try it locally yet but I will do it tomorrow morning at
>> >> >> the
>> >> >> office and keep you informed.
>> >> >> Seb
>> >> >>
>> >> >>
>> >> >> On Tue, Jan 3, 2012 at 8:07 PM, Andrew Eisenberg
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >>>
>> >> >>> > I can not tell to much about the plugin functionnality because of
>> >> >>> > a
>> >> >>> > NDA
>> >> >>> > and
>> >> >>> > it's for internal use. But basically, the user can upload his
>> >> >>> > script
>> >> >>> > to
>> >> >>> > a platform where the script will be executed. Besides that will
>> >> >>> > provides
>> >> >>> > some security checks, bundle the codenarc plugin etc ... (You can
>> >> >>> > also
>> >> >>> > ask
>> >> >>> > Guillaume Laforge, his knows well this project)
>> >> >>> > But we are planning to open source some "generic" parts of the
>> >> >>> > plugin
>> >> >>> > such
>> >> >>> > as a very nice code completion feature for object representing a
>> >> >>> > xml
>> >> >>> > structure (using annotations and XSD parsing).
>> >> >>>
>> >> >>> Very nice.  If this feature is generally useful, you could consider
>> >> >>> contributing this into Groovy-Eclipse itself.
>> >> >>>
>> >> >>> > Yes of course I meant org.codehaus.groovy and it works fine with
>> >> >>> > 1.5.
>> >> >>> > But in
>> >> >>> > our case, we are using the JSR 233 Scripting implementation which
>> >> >>> > is
>> >> >>> > included in 1.6 but not in 1.5. So for 1.5, we use an additional
>> >> >>> > jar
>> >> >>> > containing the JSR233 implementation. This jar needs to be on the
>> >> >>> > classpath
>> >> >>> > of Groovy (in our use case).
>> >> >>> >
>> >> >>> > In a previous version I had my own bundle with groovy as
>> >> >>> > "regular"
>> >> >>> > jar
>> >> >>> > (not
>> >> >>> > the bundle) and the JSR233 impl and it works fine because they
>> >> >>> > were
>> >> >>> > on
>> >> >>> > the
>> >> >>> > same classpath.
>> >> >>>
>> >> >>> I see the problem now.  Thanks for the explanation.  I raised this
>> >> >>> issue:
>> >> >>> http://jira.codehaus.org/browse/GRECLIPSE-1313
>> >> >>>
>> >> >>> Have you tried this out locally and does it work for you?  You can
>> >> >>> just import org.codehaus.groovy as a PDE project and make the
>> >> >>> changes
>> >> >>> to the manifest.
>> >> >>>
>> >> >>> >
>> >> >>> > But doing this was redundant because I had a extra groovy jar in
>> >> >>> > my
>> >> >>> > project
>> >> >>> > while the org.codehaus.groovy already provides it. So I modify my
>> >> >>> > bundle to
>> >> >>> > have a dependency on the org.codehaus.groovy bundle. But
>> >> >>> > org.codehaus.groovy
>> >> >>> > has its own classpath which I can't modify and it fails to load
>> >> >>> > classes
>> >> >>> > from
>> >> >>> > my JSR233 jar.
>> >> >>> >
>> >> >>> > I know the risk of the buddy policies but I think that in my case
>> >> >>> > it
>> >> >>> > really
>> >> >>> > makes sense.
>> >> >>> >
>> >> >>> > Hope I was clear, it's not that easy to explain this through a
>> >> >>> > email.
>> >> >>> >
>> >> >>> > Seb
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg
>> >> >>> > <[hidden email]>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> > We are building our own custom plugin which relies heavily on
>> >> >>> >> > the
>> >> >>> >> > Groovy
>> >> >>> >> > Eclipse Plugin.
>> >> >>> >> Great.  What is your plugin doing?
>> >> >>> >>
>> >> >>> >> > Today, I was cleaning the things a bit up to rely on the
>> >> >>> >> > provided
>> >> >>> >> > org.eclipse.groovy instead of one of our bundle.
>> >> >>> >> I assume that you mean org.codehaus.groovy since
>> >> >>> >> org.eclipse.groovy
>> >> >>> >> does not exist.
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> > But the bundle org.eclipse.groovy fails to load some classes
>> >> >>> >> > (from
>> >> >>> >> > javax.script packages, we must be 1.5 compliant). I've
>> >> >>> >> > isolated
>> >> >>> >> > the
>> >> >>> >> > problem
>> >> >>> >> > : it's a OSGI/classpath hell problem ;-) . And for me there
>> >> >>> >> > only
>> >> >>> >> > one
>> >> >>> >> > solution : Create a fragment that extends your bundle.
>> >> >>> >> org.codehaus.groovy should also be 1.5 compliant and if it's
>> >> >>> >> not,
>> >> >>> >> then
>> >> >>> >> that is a problem.  Can you tell me more precisely what is going
>> >> >>> >> on?
>> >> >>> >>
>> >> >>> >> > But I would like to mention another option that needs action
>> >> >>> >> > on
>> >> >>> >> > your
>> >> >>> >> > side
>> >> >>> >> > and it's very trivial : Adding
>> >> >>> >> >  Eclipse-BuddyPolicy:registered  to
>> >> >>> >> > the
>> >> >>> >> > manifest file.
>> >> >>> >> > That means that other plugin that
>> >> >>> >> > declares Eclipse-RegisterBuddy:
>> >> >>> >> > org.eclipse.groovy authorizes the groovy bundle to access
>> >> >>> >> > other
>> >> >>> >> > bundle
>> >> >>> >> > classpathes.
>> >> >>> >> I could consider this, but let me know why you need this
>> >> >>> >> functionality.  My understanding is that using buddy policies in
>> >> >>> >> the
>> >> >>> >> wrong way can lead to circular classpath dependencies and hence
>> >> >>> >> possible deadlocks on classloads.  So, I would be cautious about
>> >> >>> >> using
>> >> >>> >> this unless you know this is the right way to go.  I would
>> >> >>> >> prefer
>> >> >>> >> to
>> >> >>> >> avoid the need for this.
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> >
>> >> >>> >> > I hope it was clear,
>> >> >>> >> > Best Regards,
>> >> >>> >> > Sébastien
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> ---------------------------------------------------------------------
>> >> >>> >> 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
>>
>>
>

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a Eclipse Buddy Policy on the the bundle org.eclipse.groovy bundle

Andrew Eisenberg
OK.  I'll make the change.  2.6.1 will be out in late-February.  I'll
let you know when the change is available.

On Thu, Jan 26, 2012 at 5:03 AM, Sebastien Blanc <[hidden email]> wrote:

> Hi,
> I just had time to give the snapshot a test but I realized you put the wrong
> instruction in the manifest :
> You have :
> Eclipse-RegisterBuddy: registered
> But it should be :
> Eclipse-BuddyPolicy: registered
>
> I hope I report that in time before the next release.
>
> Regards,
> Seb
>
> On Thu, Jan 5, 2012 at 7:59 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> We use a standard PDE build, but we have a few hacks to get the groovy
>> code compiling.  You can see the scripts that we use over here:
>>
>> https://svn.codehaus.org/groovy/eclipse/trunk/ide/org.codehaus.groovy.eclipse.pluginbuilder
>>
>> Headless building of Eclipse plugins is a bit of a black art.  It has
>> taken us a while to get the current build running smoothly and one of
>> our other projects uses Tycho for its build (and there have been a few
>> pain points getting it to work properly).  So, at this point I don't
>> want to fix something that isn't broken.  :)
>>
>> If you're interested, the build server is here:
>> http://bamboo.ci.codehaus.org/browse/GRECLIPSE
>>
>> On Thu, Jan 5, 2012 at 9:41 AM, Sebastien Blanc <[hidden email]>
>> wrote:
>> > Excellent !
>> > I will try it tomorrow with the snapshot repo.
>> > Just because I'm curious : how are building the groovy eclipse plugin?
>> > Custom build ? Through Eclipse ?
>> > I've managed to automatise the whole build process with Maven with the
>> > help
>> > of the Tycho plugin  and some custom tweaks ;-) . If one day you need
>> > advice
>> > on the "maven" build process I will be glad to help you.
>> > Seb
>> >
>> >
>> > On Thu, Jan 5, 2012 at 5:40 PM, Andrew Eisenberg <[hidden email]>
>> > wrote:
>> >>
>> >> Let me know what you find out.  The change should now be available
>> >> from the snapshot update site (and from a zipped archive).
>> >>
>> >> On Thu, Jan 5, 2012 at 4:02 AM, Sebastien Blanc <[hidden email]>
>> >> wrote:
>> >> > yes,
>> >> > Might be because of the 1.7 and 1.8 cohabiting. I have to dig a bit
>> >> > more
>> >> > what is really happening but thanks for the hint using the zip update
>> >> > site.
>> >> >
>> >> >
>> >> > On Wed, Jan 4, 2012 at 5:55 PM, Andrew Eisenberg
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> OK.  I will make the change.  It is unfortunate that you need to
>> >> >> specify the full version number of the bundle.  This goes against
>> >> >> what
>> >> >> the documentation says.  Could it be because we ship with 2
>> >> >> org.codehaus.groovy bundles?  What happens if you remove one of
>> >> >> them?
>> >> >>
>> >> >> A problem with relying on released versions is that you will have to
>> >> >> wait for the next release before the buddy policy header is in the
>> >> >> bundles.  If you can't find out any other way, I'd recommend that
>> >> >> you
>> >> >> grab the latest update site zip from
>> >> >> http://ci.repository.codehaus.org/greclipse/snapshot/e37/old/ and
>> >> >> build against that until an actual release comes out.
>> >> >>
>> >> >> I'll let you know when a snapshot is available.
>> >> >>
>> >> >> On Wed, Jan 4, 2012 at 2:14 AM, Sebastien Blanc
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> > I just made a test an it works ! The only little problem is that
>> >> >> > own
>> >> >> > my
>> >> >> > side
>> >> >> > I have to declare the full bundle name (including the version) of
>> >> >> > org.codehaus.groovy. Until now I was working on yours snapshots, I
>> >> >> > will
>> >> >> > move
>> >> >> > now to the latest release.
>> >> >> >
>> >> >> > For info in the manifest
>> >> >> > of org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>> >> >> > I added
>> >> >> > Eclipse-BuddyPolicy: registered
>> >> >> >
>> >> >> > On my side FYI :
>> >> >> > Eclipse-RegisterBuddy:
>> >> >> > org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE
>> >> >> >
>> >> >> > Regards,
>> >> >> > Seb
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Jan 3, 2012 at 8:51 PM, Sebastien Blanc
>> >> >> > <[hidden email]>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Thanks Andrew !
>> >> >> >> I haven't try it locally yet but I will do it tomorrow morning at
>> >> >> >> the
>> >> >> >> office and keep you informed.
>> >> >> >> Seb
>> >> >> >>
>> >> >> >>
>> >> >> >> On Tue, Jan 3, 2012 at 8:07 PM, Andrew Eisenberg
>> >> >> >> <[hidden email]>
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> > I can not tell to much about the plugin functionnality because
>> >> >> >>> > of
>> >> >> >>> > a
>> >> >> >>> > NDA
>> >> >> >>> > and
>> >> >> >>> > it's for internal use. But basically, the user can upload his
>> >> >> >>> > script
>> >> >> >>> > to
>> >> >> >>> > a platform where the script will be executed. Besides that
>> >> >> >>> > will
>> >> >> >>> > provides
>> >> >> >>> > some security checks, bundle the codenarc plugin etc ... (You
>> >> >> >>> > can
>> >> >> >>> > also
>> >> >> >>> > ask
>> >> >> >>> > Guillaume Laforge, his knows well this project)
>> >> >> >>> > But we are planning to open source some "generic" parts of the
>> >> >> >>> > plugin
>> >> >> >>> > such
>> >> >> >>> > as a very nice code completion feature for object representing
>> >> >> >>> > a
>> >> >> >>> > xml
>> >> >> >>> > structure (using annotations and XSD parsing).
>> >> >> >>>
>> >> >> >>> Very nice.  If this feature is generally useful, you could
>> >> >> >>> consider
>> >> >> >>> contributing this into Groovy-Eclipse itself.
>> >> >> >>>
>> >> >> >>> > Yes of course I meant org.codehaus.groovy and it works fine
>> >> >> >>> > with
>> >> >> >>> > 1.5.
>> >> >> >>> > But in
>> >> >> >>> > our case, we are using the JSR 233 Scripting implementation
>> >> >> >>> > which
>> >> >> >>> > is
>> >> >> >>> > included in 1.6 but not in 1.5. So for 1.5, we use an
>> >> >> >>> > additional
>> >> >> >>> > jar
>> >> >> >>> > containing the JSR233 implementation. This jar needs to be on
>> >> >> >>> > the
>> >> >> >>> > classpath
>> >> >> >>> > of Groovy (in our use case).
>> >> >> >>> >
>> >> >> >>> > In a previous version I had my own bundle with groovy as
>> >> >> >>> > "regular"
>> >> >> >>> > jar
>> >> >> >>> > (not
>> >> >> >>> > the bundle) and the JSR233 impl and it works fine because they
>> >> >> >>> > were
>> >> >> >>> > on
>> >> >> >>> > the
>> >> >> >>> > same classpath.
>> >> >> >>>
>> >> >> >>> I see the problem now.  Thanks for the explanation.  I raised
>> >> >> >>> this
>> >> >> >>> issue:
>> >> >> >>> http://jira.codehaus.org/browse/GRECLIPSE-1313
>> >> >> >>>
>> >> >> >>> Have you tried this out locally and does it work for you?  You
>> >> >> >>> can
>> >> >> >>> just import org.codehaus.groovy as a PDE project and make the
>> >> >> >>> changes
>> >> >> >>> to the manifest.
>> >> >> >>>
>> >> >> >>> >
>> >> >> >>> > But doing this was redundant because I had a extra groovy jar
>> >> >> >>> > in
>> >> >> >>> > my
>> >> >> >>> > project
>> >> >> >>> > while the org.codehaus.groovy already provides it. So I modify
>> >> >> >>> > my
>> >> >> >>> > bundle to
>> >> >> >>> > have a dependency on the org.codehaus.groovy bundle. But
>> >> >> >>> > org.codehaus.groovy
>> >> >> >>> > has its own classpath which I can't modify and it fails to
>> >> >> >>> > load
>> >> >> >>> > classes
>> >> >> >>> > from
>> >> >> >>> > my JSR233 jar.
>> >> >> >>> >
>> >> >> >>> > I know the risk of the buddy policies but I think that in my
>> >> >> >>> > case
>> >> >> >>> > it
>> >> >> >>> > really
>> >> >> >>> > makes sense.
>> >> >> >>> >
>> >> >> >>> > Hope I was clear, it's not that easy to explain this through a
>> >> >> >>> > email.
>> >> >> >>> >
>> >> >> >>> > Seb
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > On Tue, Jan 3, 2012 at 6:15 PM, Andrew Eisenberg
>> >> >> >>> > <[hidden email]>
>> >> >> >>> > wrote:
>> >> >> >>> >>
>> >> >> >>> >> > We are building our own custom plugin which relies heavily
>> >> >> >>> >> > on
>> >> >> >>> >> > the
>> >> >> >>> >> > Groovy
>> >> >> >>> >> > Eclipse Plugin.
>> >> >> >>> >> Great.  What is your plugin doing?
>> >> >> >>> >>
>> >> >> >>> >> > Today, I was cleaning the things a bit up to rely on the
>> >> >> >>> >> > provided
>> >> >> >>> >> > org.eclipse.groovy instead of one of our bundle.
>> >> >> >>> >> I assume that you mean org.codehaus.groovy since
>> >> >> >>> >> org.eclipse.groovy
>> >> >> >>> >> does not exist.
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >> > But the bundle org.eclipse.groovy fails to load some
>> >> >> >>> >> > classes
>> >> >> >>> >> > (from
>> >> >> >>> >> > javax.script packages, we must be 1.5 compliant). I've
>> >> >> >>> >> > isolated
>> >> >> >>> >> > the
>> >> >> >>> >> > problem
>> >> >> >>> >> > : it's a OSGI/classpath hell problem ;-) . And for me there
>> >> >> >>> >> > only
>> >> >> >>> >> > one
>> >> >> >>> >> > solution : Create a fragment that extends your bundle.
>> >> >> >>> >> org.codehaus.groovy should also be 1.5 compliant and if it's
>> >> >> >>> >> not,
>> >> >> >>> >> then
>> >> >> >>> >> that is a problem.  Can you tell me more precisely what is
>> >> >> >>> >> going
>> >> >> >>> >> on?
>> >> >> >>> >>
>> >> >> >>> >> > But I would like to mention another option that needs
>> >> >> >>> >> > action
>> >> >> >>> >> > on
>> >> >> >>> >> > your
>> >> >> >>> >> > side
>> >> >> >>> >> > and it's very trivial : Adding
>> >> >> >>> >> >  Eclipse-BuddyPolicy:registered  to
>> >> >> >>> >> > the
>> >> >> >>> >> > manifest file.
>> >> >> >>> >> > That means that other plugin that
>> >> >> >>> >> > declares Eclipse-RegisterBuddy:
>> >> >> >>> >> > org.eclipse.groovy authorizes the groovy bundle to access
>> >> >> >>> >> > other
>> >> >> >>> >> > bundle
>> >> >> >>> >> > classpathes.
>> >> >> >>> >> I could consider this, but let me know why you need this
>> >> >> >>> >> functionality.  My understanding is that using buddy policies
>> >> >> >>> >> in
>> >> >> >>> >> the
>> >> >> >>> >> wrong way can lead to circular classpath dependencies and
>> >> >> >>> >> hence
>> >> >> >>> >> possible deadlocks on classloads.  So, I would be cautious
>> >> >> >>> >> about
>> >> >> >>> >> using
>> >> >> >>> >> this unless you know this is the right way to go.  I would
>> >> >> >>> >> prefer
>> >> >> >>> >> to
>> >> >> >>> >> avoid the need for this.
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >> >
>> >> >> >>> >> > I hope it was clear,
>> >> >> >>> >> > Best Regards,
>> >> >> >>> >> > Sébastien
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >> ---------------------------------------------------------------------
>> >> >> >>> >> 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
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> 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