ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Some small patches for IvyDE
Date Sat, 10 Nov 2012 15:18:38 GMT

Le 9 nov. 2012 à 10:01, a écrit :

> Hi Nicolas,
> thanks for the quick response. I would indeed be interested in the reason 
> for having the project name in the
> classpath container configuration. I don't know any other classpath 
> container that does that.

I have documented the reason in the code:

Implementation note about why the project is serialized in the path. This is related to

For some reason, when we add a project to the source path of a launch configuration, any IvyDE
container involved of that project lose its reference to its project. Then when the JDT call
the IvyDERuntimeClasspathEntryResolver to resolve the source of that container, the IRuntimeClasspathEntry
doesn't reference a Java project. In most case, an IvyDE classpath container reference an
ivy.xml relatively to the project. So in that context, the classpath cannot be resolved without
a reference to the project in the path of the container.
Another reason for having the project in the path of the container, is to make the path unique.
Again the source path in a launch configuration would consider two containers with exactly
the configurations the same, even if the IRuntimeClasspathEntry reference different projects.

To reproduce the issue, some test project is available and configured accordingly.
See in the test folder of the IvyDE project, check out the project 'jetty' and 'jetty-webapp'.

> AFAICS, there is a single place where the project is read from the 
> container path, and that is the second 
> constructor of IvyClasspathContainerConfiguration: 
>    public IvyClasspathContainerConfiguration(IJavaProject javaProject, 
> IPath path,
>            boolean editing, IClasspathAttribute[] attributes) {
>        this.javaProject = javaProject;
>        IvyClasspathContainerConfAdapter.load(this, path, attributes);
>    }
> So exactly before the project is read from the container via load(), the 
> project is already set.

The important call is in IvyDERuntimeClasspathEntryResolver line 64. For some reason (this
might deserve a report in JDT's bugzilla), project is null while resolving the source path
whereas the path is from a classpath container from a project.


> Best wishes
> Carsten
> From:
> Nicolas Lalevée <>
> To:
> "Ant Developers List" <>, 
> Date:
> 08.11.2012 23:01
> Subject:
> Re: Some small patches for IvyDE
> Le 8 nov. 2012 à 22:32, a écrit :
>> Hi,
>> I'm evaluating the use of Ivy and IvyDE and found some small problems 
> that 
>> I would like to get addressed.
>> I already submitted Jira tickets with attachments to them, but I'm not 
>> sure they will get any attention without
>> a default assignee. So that's why I'm here :-)
> There is no assignee so that there no particular committer which need to 
> process them, any committer can be involved. And every committer is 
> supposed to have subscribed to ant-notification mailing list, so everybody 
> gets it. But not every committer knows about IvyDE internals or even 
> features.
> But you did good coming here ping us since we are not particularly 
> responsive :)
>> The issues are
>> 1) IVYDE-326 "Support for variables in the retrieve pattern"
>> 2) IVYDE-328 "Do not save the project name in the classpath container 
>> configuration"
>> and (much less important) 3) IVYDE-327 "Problem when exporting the 
>> eclipse-plugins (compiler target 1.2)"
>> Any feedback would be greatly appreciated.
> And thank you Carsten for your patches. They did get my attention.
> Particularly IVYDE-328 which I know I will refuse but I need to find again 
> the reason why I did it. There was some messing up in the JDT, the source 
> attachment and the Java launching. And I would need to document it so I 
> won't have hard time remember why I did this :)
> I'll process then soon.
> cheers,
> Nicolas
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message