Home » Language IDEs » Java Development Tools (JDT) » Handling the configuration of a classpath container
| Handling the configuration of a classpath container [message #251334] |
Mon, 11 February 2008 11:04  |
Eclipse User |
|
|
|
Originally posted by: nicolas.lalevee.anyware-tech.com
Hi,
I am having trouble about supporting the configuration of a classpath
container. I asked some help on eclipse.platform with no success, I didn't
saw that there were a JDT newsgroup.
So here is my first message :
------------------------------------------------------------ -------------
Hi,
The plugin I work on is IvyDE: http://ant.apache.org/ivy/ivyde
I am hitting is an issue when a project is imported, with a .classpath
referencing the IvyDE container, and with
a .settings/org.apache.ivyde.eclipse.prefs containing the Ivy
configuration. But the project preferences attached to IvyDE is not loaded
when the classpath container is created. So the classpath container assume
it should use the default preferences, which can make a lot of errors if
the project preferences are absolutely needed. After that, if I manually
trigger the resolve on the IvyClassPathContainer (via an action), the
preferences are correctly loaded, and everything works fine. In fact the
refresh thread runs too late.
In fact I have exactly the same use case as described here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=139911
I have tried to make a job scheduled by the
IvyClasspathContainerInitializer, made the job a priority BUILD, it still
runs before the refresh job.
The refresh job not having any scheduling rule, I cannot make them conflit.
Is there a way to schedule that resolve job after the refresh one ?
Or should I force the refresh of IvyDE's settings file ?
Or should I store preferences even if there is no preference to store ? So
the container would wait to load until there is actually some preferences
(via listeners).
------------------------------------------------------------ --------------
And a second message
------------------------------------------------------------ --------------
I have looked how the JDT does, how the build tasks manage the preference
loading against the refresh job.
In fact in Project#open, there is:
worspace.beginOperation
startup => trigger the OPEN event which create the classpath containers
refresh
workspace.endOperation => trigger the build
So effectively, the build can launch the preferences safely. Should the
classpath container be populated by a build job ?
------------------------------------------------------------ --------------
Then discussing on a IvyDE issue
(https://issues.apache.org/jira/browse/IVYDE-70)
------------------------------------------------------------ --------------
Then rethinking about how the JDT works, it finally seems that having
preferences to control a class path container is wrong. And in fact IvyDE
has two configuration panes: the one which control the conf to resolve, and
the one which control the ivysettings url, the jar, source, javadocs types,
etc...
Then I browsed the JDT classes and I have found the IClasspathAttribute,
which should be used to store extra configuration about the class path
entry. So it seems that my issues will be resolved properly if I merge the
two confiuration panes, and if we make the current preferences stored as
classpath extra attributes (which will finally get stored into
the .classpath).
------------------------------------------------------------ -------------
After a first attempt, I sucessfully generated a .classpath with:
<classpathentry kind="con"
path=" org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/ivy.xml /* ">
<attributes>
<attribute name="ivySettingsPath"
value=" file:/home/nicolasl/dev/......../tools/1.0/ivyconf-eclipse.x ml "/>
</attributes>
</classpathentry>
But then I started playing with the IvydeContainerPage (implementing
IClasspathContainerPage) which create the IClasspathEntry. So I made it put
some extra attributes in the classpathentry. But the JDT doesn't care and
ignore them...
So using IClasspathAttribute for classpath containers is a bad idea ?
And all the configuration of the classpath container should be kept into the
container's path ?
As the path would be a concatenation of configuration entries, what happend
is one of the configuration is actually a path ?
Thanks in advance for taking time to read my message.
Nicolas
|
|
|
| Re: Handling the configuration of a classpath container [message #251360 is a reply to message #251334] |
Tue, 12 February 2008 15:09  |
| Eclipse User |
|
|
|
Just an idea :
you can get a reference of the refresh job tahnks to IJobManager static
method from your job instance. If having chance to get a reference on
refresh job ou can then add an IJobChangeListener on it, implementing
the done method.
If you cant access that reference, it is just too bad ...
hope this helps !
Anyway, hi to Toulouse Anyware's/Joost crew from me !
Nicolas Lalevée a écrit :
> Hi,
>
> I am having trouble about supporting the configuration of a classpath
> container. I asked some help on eclipse.platform with no success, I didn't
> saw that there were a JDT newsgroup.
>
>
> So here is my first message :
> ------------------------------------------------------------ -------------
> Hi,
>
> The plugin I work on is IvyDE: http://ant.apache.org/ivy/ivyde
>
> I am hitting is an issue when a project is imported, with a .classpath
> referencing the IvyDE container, and with
> a .settings/org.apache.ivyde.eclipse.prefs containing the Ivy
> configuration. But the project preferences attached to IvyDE is not loaded
> when the classpath container is created. So the classpath container assume
> it should use the default preferences, which can make a lot of errors if
> the project preferences are absolutely needed. After that, if I manually
> trigger the resolve on the IvyClassPathContainer (via an action), the
> preferences are correctly loaded, and everything works fine. In fact the
> refresh thread runs too late.
>
> In fact I have exactly the same use case as described here:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=139911
>
> I have tried to make a job scheduled by the
> IvyClasspathContainerInitializer, made the job a priority BUILD, it still
> runs before the refresh job.
>
> The refresh job not having any scheduling rule, I cannot make them conflit.
>
> Is there a way to schedule that resolve job after the refresh one ?
>
> Or should I force the refresh of IvyDE's settings file ?
>
> Or should I store preferences even if there is no preference to store ? So
> the container would wait to load until there is actually some preferences
> (via listeners).
>
> ------------------------------------------------------------ --------------
>
>
> And a second message
> ------------------------------------------------------------ --------------
> I have looked how the JDT does, how the build tasks manage the preference
> loading against the refresh job.
> In fact in Project#open, there is:
> worspace.beginOperation
> startup => trigger the OPEN event which create the classpath containers
> refresh
> workspace.endOperation => trigger the build
>
> So effectively, the build can launch the preferences safely. Should the
> classpath container be populated by a build job ?
> ------------------------------------------------------------ --------------
>
>
>
>
> Then discussing on a IvyDE issue
> (https://issues.apache.org/jira/browse/IVYDE-70)
> ------------------------------------------------------------ --------------
> Then rethinking about how the JDT works, it finally seems that having
> preferences to control a class path container is wrong. And in fact IvyDE
> has two configuration panes: the one which control the conf to resolve, and
> the one which control the ivysettings url, the jar, source, javadocs types,
> etc...
> Then I browsed the JDT classes and I have found the IClasspathAttribute,
> which should be used to store extra configuration about the class path
> entry. So it seems that my issues will be resolved properly if I merge the
> two confiuration panes, and if we make the current preferences stored as
> classpath extra attributes (which will finally get stored into
> the .classpath).
> ------------------------------------------------------------ -------------
>
>
>
> After a first attempt, I sucessfully generated a .classpath with:
>
> <classpathentry kind="con"
> path=" org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/ivy.xml /* ">
> <attributes>
> <attribute name="ivySettingsPath"
> value=" file:/home/nicolasl/dev/......../tools/1.0/ivyconf-eclipse.x ml "/>
> </attributes>
> </classpathentry>
>
>
> But then I started playing with the IvydeContainerPage (implementing
> IClasspathContainerPage) which create the IClasspathEntry. So I made it put
> some extra attributes in the classpathentry. But the JDT doesn't care and
> ignore them...
>
> So using IClasspathAttribute for classpath containers is a bad idea ?
> And all the configuration of the classpath container should be kept into the
> container's path ?
> As the path would be a concatenation of configuration entries, what happend
> is one of the configuration is actually a path ?
>
>
> Thanks in advance for taking time to read my message.
>
> Nicolas
>
|
|
|
| Re: Handling the configuration of a classpath container [message #251440 is a reply to message #251360] |
Fri, 15 February 2008 08:36 |
| Eclipse User |
|
|
|
Originally posted by: nicolas.lalevee.anyware-tech.com
lucas bigeardel wrote:
> Just an idea :
>
> you can get a reference of the refresh job tahnks to IJobManager static
> method from your job instance. If having chance to get a reference on
> refresh job ou can then add an IJobChangeListener on it, implementing
> the done method.
>
> If you cant access that reference, it is just too bad ...
>
> hope this helps !
>
> Anyway, hi to Toulouse Anyware's/Joost crew from me !
Hi Lucas ! Good to read you here ! :)
Thanks for the idea, I will look to it.
cheers,
Nicolas
>
> Nicolas Lalevée a écrit :
>> Hi,
>>
>> I am having trouble about supporting the configuration of a classpath
>> container. I asked some help on eclipse.platform with no success, I
>> didn't saw that there were a JDT newsgroup.
>>
>>
>> So here is my first message :
>> ------------------------------------------------------------ -------------
>> Hi,
>>
>> The plugin I work on is IvyDE: http://ant.apache.org/ivy/ivyde
>>
>> I am hitting is an issue when a project is imported, with a .classpath
>> referencing the IvyDE container, and with
>> a .settings/org.apache.ivyde.eclipse.prefs containing the Ivy
>> configuration. But the project preferences attached to IvyDE is not
>> loaded when the classpath container is created. So the classpath
>> container assume it should use the default preferences, which can make a
>> lot of errors if the project preferences are absolutely needed. After
>> that, if I manually trigger the resolve on the IvyClassPathContainer (via
>> an action), the preferences are correctly loaded, and everything works
>> fine. In fact the refresh thread runs too late.
>>
>> In fact I have exactly the same use case as described here:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=139911
>>
>> I have tried to make a job scheduled by the
>> IvyClasspathContainerInitializer, made the job a priority BUILD, it still
>> runs before the refresh job.
>>
>> The refresh job not having any scheduling rule, I cannot make them
>> conflit.
>>
>> Is there a way to schedule that resolve job after the refresh one ?
>>
>> Or should I force the refresh of IvyDE's settings file ?
>>
>> Or should I store preferences even if there is no preference to store ?
>> So the container would wait to load until there is actually some
>> preferences (via listeners).
>>
>> ------------------------------------------------------------ --------------
>>
>>
>> And a second message
>> ------------------------------------------------------------ --------------
>> I have looked how the JDT does, how the build tasks manage the preference
>> loading against the refresh job.
>> In fact in Project#open, there is:
>> worspace.beginOperation
>> startup => trigger the OPEN event which create the classpath containers
>> refresh
>> workspace.endOperation => trigger the build
>>
>> So effectively, the build can launch the preferences safely. Should the
>> classpath container be populated by a build job ?
>> ------------------------------------------------------------ --------------
>>
>>
>>
>>
>> Then discussing on a IvyDE issue
>> (https://issues.apache.org/jira/browse/IVYDE-70)
>> ------------------------------------------------------------ --------------
>> Then rethinking about how the JDT works, it finally seems that having
>> preferences to control a class path container is wrong. And in fact IvyDE
>> has two configuration panes: the one which control the conf to resolve,
>> and the one which control the ivysettings url, the jar, source, javadocs
>> types, etc...
>> Then I browsed the JDT classes and I have found the IClasspathAttribute,
>> which should be used to store extra configuration about the class path
>> entry. So it seems that my issues will be resolved properly if I merge
>> the two confiuration panes, and if we make the current preferences stored
>> as classpath extra attributes (which will finally get stored into
>> the .classpath).
>> ------------------------------------------------------------ -------------
>>
>>
>>
>> After a first attempt, I sucessfully generated a .classpath with:
>>
>> <classpathentry kind="con"
>> path=" org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/ivy.xml /* ">
>> <attributes>
>> <attribute name="ivySettingsPath"
>> value=" file:/home/nicolasl/dev/......../tools/1.0/ivyconf-eclipse.x ml "/>
>> </attributes>
>> </classpathentry>
>>
>>
>> But then I started playing with the IvydeContainerPage (implementing
>> IClasspathContainerPage) which create the IClasspathEntry. So I made it
>> put some extra attributes in the classpathentry. But the JDT doesn't care
>> and ignore them...
>>
>> So using IClasspathAttribute for classpath containers is a bad idea ?
>> And all the configuration of the classpath container should be kept into
>> the container's path ?
>> As the path would be a concatenation of configuration entries, what
>> happend is one of the configuration is actually a path ?
>>
>>
>> Thanks in advance for taking time to read my message.
>>
>> Nicolas
>>
|
|
|
Goto Forum:
Current Time: Wed Apr 30 04:29:59 EDT 2025
Powered by FUDForum. Page generated in 0.05467 seconds |
Home