relative linkedResources for dsld support

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

relative linkedResources for dsld support

Kaintantzis, Nikolaos

Hi all

 

The users of our product have a file at their workspace located at

.metadata\.plugins\org.eclipse.jdt.core\.org.eclipse.jdt.core.external.folders

containing the dsld support

 

The content is:

 

 <linkedResources>
<link>
<name>.link0</name>
<type>2</type>
<location>//PathToMyHomePath/.groovy/greclipse/global_dsld_support</location>
</link>
<link>
<name>.link1</name>
<type>2</type>
<location>C:/xxx/OurProduct-currentBuildVerisionNumber/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
</link>
</linkedResources>

 

The problem after rolling out a new build is, that the users see an error dialog saying: "Resource '/.org.eclipse.jdt.core.external.folders/.link1' already exists

I think the problem will be solved if the path where relative, like

<location>${ECLIPSE_HOME}/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>

 

 

Is this problem know to someone else and is it solved in a newer version of groovy eclipse? (Or is the problem somewhere else?)

 

Tanks,

Niko

 

Reply | Threaded
Open this post in threaded view
|

Re: relative linkedResources for dsld support

Andrew Eisenberg-2
Can you describe more precisely how you get this error? What do you do to roll out a new version? Using p2?

On Wednesday, December 5, 2012, Kaintantzis, Nikolaos wrote:

Hi all

 

The users of our product have a file at their workspace located at

.metadata\.plugins\org.eclipse.jdt.core\.org.eclipse.jdt.core.external.folders

containing the dsld support

 

The content is:

 

 <linkedResources>
<link>
<name>.link0</name>
<type>2</type>
<location>//PathToMyHomePath/.groovy/greclipse/global_dsld_support</location>
</link>
<link>
<name>.link1</name>
<type>2</type>
<location>C:/xxx/OurProduct-currentBuildVerisionNumber/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
</link>
</linkedResources>

 

The problem after rolling out a new build is, that the users see an error dialog saying: "Resource '/.org.eclipse.jdt.core.external.folders/.link1' already exists

I think the problem will be solved if the path where relative, like

<location>${ECLIPSE_HOME}/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>

 

 

Is this problem know to someone else and is it solved in a newer version of groovy eclipse? (Or is the problem somewhere else?)

 

Tanks,

Niko

 

Reply | Threaded
Open this post in threaded view
|

AW: [groovy-eclipse-plugin-dev] relative linkedResources for dsld support

Kaintantzis, Nikolaos

Hi Andrew

 

Thanks for answering.

 

Our product/application is a companywide used application. Our users are all in-house and employees.

Having a new build/version (after a sprint): We do a full uninstall of the current and a complete install of the new RCP-Product (which includes Groovy Eclipse). Or to be precisely: A company desktop management solution does this automatically for all our users.

The workspaces are outside of the installation path so they can be still used.

 

The users getting the error the first time they start the new version with their workspace. The line

<location>C:/xxx/OurProduct-X.Y.(N)/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>

(for context of the line see my last email) has changed to

<location>C:/xxx/OurProduct-C:/xxx/OurProduct-X.Y.(N+1)/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>

and everything is o.k. for the next usages.

 

 

So I asking myself: Why isn't the location changed without the warning? Or is it possible to use relative paths like ${ECLIPSE_HOME}/...

Is there something I can do or configure?

 

 

Thanks in advance

Niko

 

 

 

 


Von: Andrew Eisenberg [[hidden email]]
Gesendet: Mittwoch, 5. Dezember 2012 18:23
An: [hidden email]
Betreff: Re: [groovy-eclipse-plugin-dev] relative linkedResources for dsld support

Can you describe more precisely how you get this error? What do you do to roll out a new version? Using p2?

On Wednesday, December 5, 2012, Kaintantzis, Nikolaos wrote:

Hi all

 

The users of our product have a file at their workspace located at

.metadata\.plugins\org.eclipse.jdt.core\.org.eclipse.jdt.core.external.folders

containing the dsld support

 

The content is:

 

 <linkedResources>
<link>
<name>.link0</name>
<type>2</type>
<location>//PathToMyHomePath/.groovy/greclipse/global_dsld_support</location>
</link>
<link>
<name>.link1</name>
<type>2</type>
<location>C:/xxx/OurProduct-currentBuildVerisionNumber/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
</link>
</linkedResources>

 

The problem after rolling out a new build is, that the users see an error dialog saying: "Resource '/.org.eclipse.jdt.core.external.folders/.link1' already exists

I think the problem will be solved if the path where relative, like

<location>${ECLIPSE_HOME}/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>

 

 

Is this problem know to someone else and is it solved in a newer version of groovy eclipse? (Or is the problem somewhere else?)

 

Tanks,

Niko

 

Reply | Threaded
Open this post in threaded view
|

Re: relative linkedResources for dsld support

Andrew Eisenberg-2
Apologies for not responding earlier.  I am not seeing this problem
when I upgrade to a new version of groovy-eclipse.  The .project file
in the external folders project is correctly updated for me.  It could
be that your problem comes from not using p2 to do the updates, but
rather just deleting the old install and using a new one.

It's not simple to use a path variable like $ECLIPSE_HOME since we
need the path to the bundle, not to the eclipse installation.
Typically, they are the same, but many setups have the plugins
installed separately from the configuration (eg- in shared instance
situations).

I could create a new path variable, like $ACTIVE_GROOVY_BUNDLE.  I'll
play aroudn with that and see if this can help.

On Wed, Dec 12, 2012 at 6:07 AM, Kaintantzis, Nikolaos <[hidden email]> wrote:

> Hi Andrew
>
>
>
> Do you need more information? or Should I extract something that could help
> and send it to you?
>
> Or should I ask the people in the list again?
>
>
>
> Thanks
>
> Niko
>
>
>
>
>
> ________________________________
> Von: Kaintantzis, Nikolaos
> Gesendet: Donnerstag, 6. Dezember 2012 08:47
> An: [hidden email]
> Betreff: AW: [groovy-eclipse-plugin-dev] relative linkedResources for dsld
> support
>
> Hi Andrew
>
>
>
> Thanks for answering.
>
>
>
> Our product/application is a companywide used application. Our users are all
> in-house and employees.
>
> Having a new build/version (after a sprint): We do a full uninstall of the
> current and a complete install of the new RCP-Product (which includes Groovy
> Eclipse). Or to be precisely: A company desktop management solution does
> this automatically for all our users.
>
> The workspaces are outside of the installation path so they can be still
> used.
>
>
>
> The users getting the error the first time they start the new version with
> their workspace. The line
>
> <location>C:/xxx/OurProduct-X.Y.(N)/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>
> (for context of the line see my last email) has changed to
>
> <location>C:/xxx/OurProduct-C:/xxx/OurProduct-X.Y.(N+1)/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>
> and everything is o.k. for the next usages.
>
>
>
>
>
> So I asking myself: Why isn't the location changed without the warning? Or
> is it possible to use relative paths like ${ECLIPSE_HOME}/...
>
> Is there something I can do or configure?
>
>
>
>
>
> Thanks in advance
>
> Niko
>
>
>
>
>
>
>
>
>
> ________________________________
> Von: Andrew Eisenberg [[hidden email]]
> Gesendet: Mittwoch, 5. Dezember 2012 18:23
> An: [hidden email]
> Betreff: Re: [groovy-eclipse-plugin-dev] relative linkedResources for dsld
> support
>
> Can you describe more precisely how you get this error? What do you do to
> roll out a new version? Using p2?
>
> On Wednesday, December 5, 2012, Kaintantzis, Nikolaos wrote:
>>
>> Hi all
>>
>>
>>
>> The users of our product have a file at their workspace located at
>>
>>
>> .metadata\.plugins\org.eclipse.jdt.core\.org.eclipse.jdt.core.external.folders
>>
>> containing the dsld support
>>
>>
>>
>> The content is:
>>
>>
>>
>>  <linkedResources>
>> <link>
>> <name>.link0</name>
>> <type>2</type>
>>
>> <location>//PathToMyHomePath/.groovy/greclipse/global_dsld_support</location>
>> </link>
>> <link>
>> <name>.link1</name>
>> <type>2</type>
>>
>> <location>C:/xxx/OurProduct-currentBuildVerisionNumber/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>> </link>
>> </linkedResources>
>>
>>
>>
>> The problem after rolling out a new build is, that the users see an error
>> dialog saying: "Resource '/.org.eclipse.jdt.core.external.folders/.link1'
>> already exists
>>
>> I think the problem will be solved if the path where relative, like
>>
>>
>> <location>${ECLIPSE_HOME}/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>>
>>
>>
>>
>>
>> Is this problem know to someone else and is it solved in a newer version
>> of groovy eclipse? (Or is the problem somewhere else?)
>>
>>
>>
>> Tanks,
>>
>> Niko
>>
>>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: relative linkedResources for dsld support

Andrew Eisenberg-2
Unfortunately, my solution is not going to work.  The path variables
only work for folders that are lionked from inside the existing
project.  But, in this case, the linked folder is in the external
folders pseudo-project, which is created implicitly by JDT.

Do you have a stack trace where this occurs?  If this happens anywhere
in greclipse code, then we might be able to avoid it and fix the
problem.

Alternatively, if you have an install script, perhaps you could try
finding the workspace and updating the .project file during the
install.

On Wed, Dec 12, 2012 at 9:25 AM, Andrew Eisenberg
<[hidden email]> wrote:

> Apologies for not responding earlier.  I am not seeing this problem
> when I upgrade to a new version of groovy-eclipse.  The .project file
> in the external folders project is correctly updated for me.  It could
> be that your problem comes from not using p2 to do the updates, but
> rather just deleting the old install and using a new one.
>
> It's not simple to use a path variable like $ECLIPSE_HOME since we
> need the path to the bundle, not to the eclipse installation.
> Typically, they are the same, but many setups have the plugins
> installed separately from the configuration (eg- in shared instance
> situations).
>
> I could create a new path variable, like $ACTIVE_GROOVY_BUNDLE.  I'll
> play aroudn with that and see if this can help.
>
> On Wed, Dec 12, 2012 at 6:07 AM, Kaintantzis, Nikolaos <[hidden email]> wrote:
>> Hi Andrew
>>
>>
>>
>> Do you need more information? or Should I extract something that could help
>> and send it to you?
>>
>> Or should I ask the people in the list again?
>>
>>
>>
>> Thanks
>>
>> Niko
>>
>>
>>
>>
>>
>> ________________________________
>> Von: Kaintantzis, Nikolaos
>> Gesendet: Donnerstag, 6. Dezember 2012 08:47
>> An: [hidden email]
>> Betreff: AW: [groovy-eclipse-plugin-dev] relative linkedResources for dsld
>> support
>>
>> Hi Andrew
>>
>>
>>
>> Thanks for answering.
>>
>>
>>
>> Our product/application is a companywide used application. Our users are all
>> in-house and employees.
>>
>> Having a new build/version (after a sprint): We do a full uninstall of the
>> current and a complete install of the new RCP-Product (which includes Groovy
>> Eclipse). Or to be precisely: A company desktop management solution does
>> this automatically for all our users.
>>
>> The workspaces are outside of the installation path so they can be still
>> used.
>>
>>
>>
>> The users getting the error the first time they start the new version with
>> their workspace. The line
>>
>> <location>C:/xxx/OurProduct-X.Y.(N)/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>>
>> (for context of the line see my last email) has changed to
>>
>> <location>C:/xxx/OurProduct-C:/xxx/OurProduct-X.Y.(N+1)/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>>
>> and everything is o.k. for the next usages.
>>
>>
>>
>>
>>
>> So I asking myself: Why isn't the location changed without the warning? Or
>> is it possible to use relative paths like ${ECLIPSE_HOME}/...
>>
>> Is there something I can do or configure?
>>
>>
>>
>>
>>
>> Thanks in advance
>>
>> Niko
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ________________________________
>> Von: Andrew Eisenberg [[hidden email]]
>> Gesendet: Mittwoch, 5. Dezember 2012 18:23
>> An: [hidden email]
>> Betreff: Re: [groovy-eclipse-plugin-dev] relative linkedResources for dsld
>> support
>>
>> Can you describe more precisely how you get this error? What do you do to
>> roll out a new version? Using p2?
>>
>> On Wednesday, December 5, 2012, Kaintantzis, Nikolaos wrote:
>>>
>>> Hi all
>>>
>>>
>>>
>>> The users of our product have a file at their workspace located at
>>>
>>>
>>> .metadata\.plugins\org.eclipse.jdt.core\.org.eclipse.jdt.core.external.folders
>>>
>>> containing the dsld support
>>>
>>>
>>>
>>> The content is:
>>>
>>>
>>>
>>>  <linkedResources>
>>> <link>
>>> <name>.link0</name>
>>> <type>2</type>
>>>
>>> <location>//PathToMyHomePath/.groovy/greclipse/global_dsld_support</location>
>>> </link>
>>> <link>
>>> <name>.link1</name>
>>> <type>2</type>
>>>
>>> <location>C:/xxx/OurProduct-currentBuildVerisionNumber/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>>> </link>
>>> </linkedResources>
>>>
>>>
>>>
>>> The problem after rolling out a new build is, that the users see an error
>>> dialog saying: "Resource '/.org.eclipse.jdt.core.external.folders/.link1'
>>> already exists
>>>
>>> I think the problem will be solved if the path where relative, like
>>>
>>>
>>> <location>${ECLIPSE_HOME}/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>>>
>>>
>>>
>>>
>>>
>>> Is this problem know to someone else and is it solved in a newer version
>>> of groovy eclipse? (Or is the problem somewhere else?)
>>>
>>>
>>>
>>> Tanks,
>>>
>>> Niko
>>>
>>>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

AW: [groovy-eclipse-plugin-dev] relative linkedResources for dsld support

Kaintantzis, Nikolaos
Hi Andrew

Thank you for your support. I don't get any stacktrace from eclipse. There is also no exception thrown (or my debugger has a problem).
There are some other mysterious thinks happen. When I change the ".project" by hand to reproduce the bug nothing happens (neither the message nor the update of the file)

I will try to clarify the "mysterious thinks" next week. Maybe I'm able to be more specific.

Thanks again
Niko




________________________________________
Von: Andrew Eisenberg [[hidden email]]
Gesendet: Mittwoch, 12. Dezember 2012 20:59
An: Kaintantzis, Nikolaos; [hidden email]
Betreff: Re: [groovy-eclipse-plugin-dev] relative linkedResources for dsld support

Unfortunately, my solution is not going to work.  The path variables
only work for folders that are lionked from inside the existing
project.  But, in this case, the linked folder is in the external
folders pseudo-project, which is created implicitly by JDT.

Do you have a stack trace where this occurs?  If this happens anywhere
in greclipse code, then we might be able to avoid it and fix the
problem.

Alternatively, if you have an install script, perhaps you could try
finding the workspace and updating the .project file during the
install.

On Wed, Dec 12, 2012 at 9:25 AM, Andrew Eisenberg
<[hidden email]> wrote:

> Apologies for not responding earlier.  I am not seeing this problem
> when I upgrade to a new version of groovy-eclipse.  The .project file
> in the external folders project is correctly updated for me.  It could
> be that your problem comes from not using p2 to do the updates, but
> rather just deleting the old install and using a new one.
>
> It's not simple to use a path variable like $ECLIPSE_HOME since we
> need the path to the bundle, not to the eclipse installation.
> Typically, they are the same, but many setups have the plugins
> installed separately from the configuration (eg- in shared instance
> situations).
>
> I could create a new path variable, like $ACTIVE_GROOVY_BUNDLE.  I'll
> play aroudn with that and see if this can help.
>
> On Wed, Dec 12, 2012 at 6:07 AM, Kaintantzis, Nikolaos <[hidden email]> wrote:
>> Hi Andrew
>>
>>
>>
>> Do you need more information? or Should I extract something that could help
>> and send it to you?
>>
>> Or should I ask the people in the list again?
>>
>>
>>
>> Thanks
>>
>> Niko
>>
>>
>>
>>
>>
>> ________________________________
>> Von: Kaintantzis, Nikolaos
>> Gesendet: Donnerstag, 6. Dezember 2012 08:47
>> An: [hidden email]
>> Betreff: AW: [groovy-eclipse-plugin-dev] relative linkedResources for dsld
>> support
>>
>> Hi Andrew
>>
>>
>>
>> Thanks for answering.
>>
>>
>>
>> Our product/application is a companywide used application. Our users are all
>> in-house and employees.
>>
>> Having a new build/version (after a sprint): We do a full uninstall of the
>> current and a complete install of the new RCP-Product (which includes Groovy
>> Eclipse). Or to be precisely: A company desktop management solution does
>> this automatically for all our users.
>>
>> The workspaces are outside of the installation path so they can be still
>> used.
>>
>>
>>
>> The users getting the error the first time they start the new version with
>> their workspace. The line
>>
>> <location>C:/xxx/OurProduct-X.Y.(N)/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>>
>> (for context of the line see my last email) has changed to
>>
>> <location>C:/xxx/OurProduct-C:/xxx/OurProduct-X.Y.(N+1)/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>>
>> and everything is o.k. for the next usages.
>>
>>
>>
>>
>>
>> So I asking myself: Why isn't the location changed without the warning? Or
>> is it possible to use relative paths like ${ECLIPSE_HOME}/...
>>
>> Is there something I can do or configure?
>>
>>
>>
>>
>>
>> Thanks in advance
>>
>> Niko
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ________________________________
>> Von: Andrew Eisenberg [[hidden email]]
>> Gesendet: Mittwoch, 5. Dezember 2012 18:23
>> An: [hidden email]
>> Betreff: Re: [groovy-eclipse-plugin-dev] relative linkedResources for dsld
>> support
>>
>> Can you describe more precisely how you get this error? What do you do to
>> roll out a new version? Using p2?
>>
>> On Wednesday, December 5, 2012, Kaintantzis, Nikolaos wrote:
>>>
>>> Hi all
>>>
>>>
>>>
>>> The users of our product have a file at their workspace located at
>>>
>>>
>>> .metadata\.plugins\org.eclipse.jdt.core\.org.eclipse.jdt.core.external.folders
>>>
>>> containing the dsld support
>>>
>>>
>>>
>>> The content is:
>>>
>>>
>>>
>>>  <linkedResources>
>>> <link>
>>> <name>.link0</name>
>>> <type>2</type>
>>>
>>> <location>//PathToMyHomePath/.groovy/greclipse/global_dsld_support</location>
>>> </link>
>>> <link>
>>> <name>.link1</name>
>>> <type>2</type>
>>>
>>> <location>C:/xxx/OurProduct-currentBuildVerisionNumber/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>>> </link>
>>> </linkedResources>
>>>
>>>
>>>
>>> The problem after rolling out a new build is, that the users see an error
>>> dialog saying: "Resource '/.org.eclipse.jdt.core.external.folders/.link1'
>>> already exists
>>>
>>> I think the problem will be solved if the path where relative, like
>>>
>>>
>>> <location>${ECLIPSE_HOME}/plugins/org.codehaus.groovy_1.8.6.xx-20120301-1300-e36-RELEASE/plugin_dsld_support</location>
>>>
>>>
>>>
>>>
>>>
>>> Is this problem know to someone else and is it solved in a newer version
>>> of groovy eclipse? (Or is the problem somewhere else?)
>>>
>>>
>>>
>>> Tanks,
>>>
>>> Niko
>>>
>>>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

AW: [groovy-eclipse-plugin-dev] relative linkedResources for dsld support

Kaintantzis, Nikolaos
Hi Andrew

I have now a stacktrace
I'm folowing your sugguestion to write a script that fixes the .project file.

Thanks,
Niko

-------
Problem trying to determine classpath of project EASYR_Sandbox:
Java Model Exception: Core Exception [code 367] Resource '/.org.eclipse.jdt.core.external.folders/.link3' already exists.
 at org.eclipse.jdt.internal.core.ExternalFolderChange.updateExternalFoldersIfNecessary(ExternalFolderChange.java:49)
 at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:62)
 at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:110)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
 at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1854)
 at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2705)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2650)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2788)
 at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1920)
 at org.eclipse.jdt.internal.core.ProjectReferenceChange.updateProjectReferencesIfNecessary(ProjectReferenceChange.java:46)
 at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:59)
 at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:110)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
 at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1854)
 at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2705)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2650)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2788)
 at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1920)
 at org.eclipse.jdt.internal.core.ProjectReferenceChange.updateProjectReferencesIfNecessary(ProjectReferenceChange.java:46)
 at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:59)
 at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:110)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
 at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1854)
 at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2705)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2650)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2788)
 at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1920)
 at org.eclipse.jdt.internal.core.ProjectReferenceChange.updateProjectReferencesIfNecessary(ProjectReferenceChange.java:46)
 at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:59)
 at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:110)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
 at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1854)
 at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2705)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2650)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2788)
 at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1953)
 at org.eclipse.jdt.core.util.CompilerUtils.calculateClasspath(CompilerUtils.java:207)
 at org.eclipse.jdt.core.util.CompilerUtils.setGroovyClasspath(CompilerUtils.java:147)
 at org.eclipse.jdt.core.util.CompilerUtils.setGroovyClasspath(CompilerUtils.java:112)
 at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:260)
 at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
 at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515)
 at org.eclipse.jdt.internal.core.BecomeWorkingCopyOperation.executeOperation(BecomeWorkingCopyOperation.java:38)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
 at org.eclipse.jdt.internal.core.CompilationUnit.becomeWorkingCopy(CompilationUnit.java:101)
 at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.createFileInfo(CompilationUnitDocumentProvider.java:990)
 at org.eclipse.ui.editors.text.TextFileDocumentProvider.connect(TextFileDocumentProvider.java:478)
 at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.connect(CompilationUnitDocumentProvider.java:1229)
 at org.eclipse.ui.texteditor.AbstractTextEditor.doSetInput(AbstractTextEditor.java:4056)
 at org.eclipse.ui.texteditor.StatusTextEditor.doSetInput(StatusTextEditor.java:217)
 at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.doSetInput(AbstractDecoratedTextEditor.java:1444)
 at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.internalDoSetInput(JavaEditor.java:2578)
 at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.doSetInput(JavaEditor.java:2551)
 at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSetInput(CompilationUnitEditor.java:1371)
 at org.codehaus.groovy.eclipse.editor.GroovyEditor.doSetInput(GroovyEditor.java:1012)
 at org.eclipse.ui.texteditor.AbstractTextEditor$19.run(AbstractTextEditor.java:3043)
 at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
 at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
 at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:759)
 at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
 at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:756)
 at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2600)
 at org.eclipse.ui.texteditor.AbstractTextEditor.internalInit(AbstractTextEditor.java:3061)
 at org.eclipse.ui.texteditor.AbstractTextEditor.init(AbstractTextEditor.java:3088)
 at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:798)
 at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:647)
 at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465)
 at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
 at org.eclipse.ui.internal.EditorAreaHelper.setVisibleEditor(EditorAreaHelper.java:271)
 at org.eclipse.ui.internal.EditorManager.setVisibleEditor(EditorManager.java:1429)
 at org.eclipse.ui.internal.EditorManager$5.runWithException(EditorManager.java:942)
 at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
 at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
 at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
 at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041)
 at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660)
 at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:803)
 at org.eclipse.ui.internal.Workbench$31.runWithException(Workbench.java:1567)
 at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
 at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
 at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
 at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041)
 at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660)
 at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2548)
 at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
 at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
 at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
 at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
 at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
 at ch.xxx.ide.app.Application.start(Application.java:63)
 at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
 at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
 at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
 at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
Caused by: org.eclipse.core.internal.resources.ResourceException: Resource '/.org.eclipse.jdt.core.external.folders/.link3' already exists.
 at org.eclipse.core.internal.resources.Resource.checkDoesNotExist(Resource.java:305)
 at org.eclipse.core.internal.resources.Resource.assertLinkRequirements(Resource.java:161)
 at org.eclipse.core.internal.resources.Resource.createLink(Resource.java:655)
 at org.eclipse.core.internal.resources.Resource.createLink(Resource.java:629)
 at org.eclipse.jdt.internal.core.ExternalFoldersManager.createLinkFolder(ExternalFoldersManager.java:126)
 at org.eclipse.jdt.internal.core.ExternalFolderChange.updateExternalFoldersIfNecessary(ExternalFolderChange.java:47)
 at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:62)
 at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:110)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
 at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1854)
 at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2705)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2650)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2788)
 at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1920)
 at org.eclipse.jdt.internal.core.ProjectReferenceChange.updateProjectReferencesIfNecessary(ProjectReferenceChange.java:46)
 at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:59)
 at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:110)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
 at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1854)
 at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2705)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2650)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2788)
 at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1920)
 at org.eclipse.jdt.internal.core.ProjectReferenceChange.updateProjectReferencesIfNecessary(ProjectReferenceChange.java:46)
 at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:59)
 at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:110)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
 at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1854)
 at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2705)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2650)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2788)
 at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1920)
 at org.eclipse.jdt.internal.core.ProjectReferenceChange.updateProjectReferencesIfNecessary(ProjectReferenceChange.java:46)
 at org.eclipse.jdt.internal.core.ChangeClasspathOperation.classpathChanged(ChangeClasspathOperation.java:59)
 at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:110)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
 at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1854)
 at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2705)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2650)
 at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2788)
 at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1953)
 at org.eclipse.jdt.core.util.CompilerUtils.calculateClasspath(CompilerUtils.java:207)
 at org.eclipse.jdt.core.util.CompilerUtils.setGroovyClasspath(CompilerUtils.java:147)
 at org.eclipse.jdt.core.util.CompilerUtils.setGroovyClasspath(CompilerUtils.java:112)
 at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.buildStructure(GroovyCompilationUnit.java:260)
 at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
 at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515)
 at org.eclipse.jdt.internal.core.BecomeWorkingCopyOperation.executeOperation(BecomeWorkingCopyOperation.java:38)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
 at org.eclipse.jdt.internal.core.CompilationUnit.becomeWorkingCopy(CompilationUnit.java:101)
 at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.createFileInfo(CompilationUnitDocumentProvider.java:990)
 at org.eclipse.ui.editors.text.TextFileDocumentProvider.connect(TextFileDocumentProvider.java:478)
 at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.connect(CompilationUnitDocumentProvider.java:1229)
 at org.eclipse.ui.texteditor.AbstractTextEditor.doSetInput(AbstractTextEditor.java:4056)
 at org.eclipse.ui.texteditor.StatusTextEditor.doSetInput(StatusTextEditor.java:217)
 at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.doSetInput(AbstractDecoratedTextEditor.java:1444)
 at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.internalDoSetInput(JavaEditor.java:2578)
 at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.doSetInput(JavaEditor.java:2551)
 at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.doSetInput(CompilationUnitEditor.java:1371)
 at org.codehaus.groovy.eclipse.editor.GroovyEditor.doSetInput(GroovyEditor.java:1012)
 at org.eclipse.ui.texteditor.AbstractTextEditor$19.run(AbstractTextEditor.java:3043)
 at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
 at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
 at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:759)
 at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
 at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:756)
 at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2600)
 at org.eclipse.ui.texteditor.AbstractTextEditor.internalInit(AbstractTextEditor.java:3061)
 at org.eclipse.ui.texteditor.AbstractTextEditor.init(AbstractTextEditor.java:3088)
 at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:798)
 at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:647)
 at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465)
 at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
 at org.eclipse.ui.internal.EditorAreaHelper.setVisibleEditor(EditorAreaHelper.java:271)
 at org.eclipse.ui.internal.EditorManager.setVisibleEditor(EditorManager.java:1429)
 at org.eclipse.ui.internal.EditorManager$5.runWithException(EditorManager.java:942)
 at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
 at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
 at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
 at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041)
 at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660)
 at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:803)
 at org.eclipse.ui.internal.Workbench$31.runWithException(Workbench.java:1567)
 at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
 at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
 at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
 at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041)
 at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660)
 at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2548)
 at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
 at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
 at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
 at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
 at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
 at ch.xxx.ide.app.Application.start(Application.java:63)
 at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
 at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
 at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
 at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email