ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Goldspink (JIRA)" <j...@apache.org>
Subject [jira] Commented: (IVYDE-43) [PATCH] New resolver allows project linking within the workspace
Date Tue, 27 May 2008 17:12:01 GMT

    [ https://issues.apache.org/jira/browse/IVYDE-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600206#action_12600206
] 

Matt Goldspink commented on IVYDE-43:
-------------------------------------

I've tried the new code that Nicolas submitted but it does not work because of classloader
issues in Eclipse. The problem being that Ivy is loaded in a separate classloader to ivyde
and is not parented to it so it can not see the WorkspaceResolver. I managed to hack it get
it to work in my own eclipse by reverting IvyDE to using a bundled version of Ivy in Eclipse.
This then made me think is it worth allowing separate versions of Ivy to be used on a per-project
basis and have a default version bundled? 

Is there any news on whether the WorkspaceResolver will be bundled in IvyDE? My team has made
a lot of use with when people work on interdependent projects to make sure we don't cause
any api breaks and its solved a lot of headaches.

> [PATCH] New resolver allows project linking within the workspace
> ----------------------------------------------------------------
>
>                 Key: IVYDE-43
>                 URL: https://issues.apache.org/jira/browse/IVYDE-43
>             Project: IvyDE
>          Issue Type: New Feature
>          Components: classpath container
>            Reporter: Eugene Goldfarb
>            Assignee: Xavier Hanin
>         Attachments: IVYDE-43-r641334.patch, ivyde-43.patch, ivyde-example-censored.JPG,
ivyde-example-censored.JPG
>
>
> I've been dreaming and tinkering with this idea for a while, and it finally evolved into
these changes.
> This introduces a new plugin - called WorkspaceResolver.
> DISCLAIMER: These changes should NOT change how IVYDE works unless the new resolver is
set up in the Ivy configuration file.  Therefore, it should be safe to use with any existing
Ivy configuration.  The only potential issue would occur if you are using artifacts of type
"project", since I'm treating those differently.
> When used with my custom IvyClasspathContainer changes, the WorkspaceResolver will link
dependent projects when they are open in the same workspace, allowing full-fledged linked
project functionality Eclipse provides, such as incremental compilation, debugging, mouseover
javadoc pop-ups, and source browsing across projects.
>  
>  The resolver will not work until it is properly configured, see instructions below.
> I attached the patch against IvyDE 1.2 rev. 605.  It also includes the minor console
logging changes I submitted with IVYDE-39.  Please let me know what you think and if there
are any major issues or suggestions.
>  
>  How it works:
>  During a resolve, if the WorkspaceResolver is in the resolve chain (see below how to
set it up), it looks at all open projects in the workspace that have Ivy containers.
>  The first project that publishes the module on which the project being resolved depends,
will be picked and returned as a special type of artifact called "project".
>  The IvyClasspathContainer will recognize the artifact as a project and put the eclipse
project as a dependent project within the classpath container of the parent.  I will attach
the screenshot to show this.
>  
>  If you do not want a project to be linked as a dependency, close it or delete from the
workspace.
>  As soon as you do that, any projects that were linked to it will automatically re-resolve
(using  WorkspaceResourceChangeListener) (if that preference is enabled) and use the standard
Ivy means of finding the dependency.
>  
>  I am also planning to have the WorkspaceResourceChangeListener auto-resolve when a new
project is added or opened, so opening a project will automatically link it into the currently
open projects where necessary.  This has been problematic, since I cannot seem to catch the
right event when a project is open.
>  
> Some limitations and potential issues:
> 1)  Since the resolver is not aware which module revision an eclipse project is publishing
(we never put the version inside the info tag of a project's ivy.xml), it optimistically matches
any revision of the module.
> 2) Since the resolver stops after finding the first open project which matches the module,
having multiple open versions of the same project in the workspace (for example, different
branches) may set the wrong version as a dependency.
>  You are advised to only open the version of the project which you want other projects
in the workspace to depend on.
>  
> 3)  NOTE: Transitive dependencies are not passed from the dependent project to the parent
when projects are linked.  If you find you are missing some transitive dependencies, just
set your dependent eclipse project to export its ivy dependencies.
>    (Project->Properties->Java Build Path->Order and Export-> check the ivy
container)
>    This will only export the configuration(s) that project is using and not what a dependent
project may ask for when it's being resolved.  To do that, this resolver will need to be modified
to pass transitive dependencies along.
>  How to set it up
>  Set up a custom resolver in the resolve chain (see example below),
>  
>    Usage Example:
>  
>    Suppose you have a main ivyconf.xml which sets up all your resolvers to be
>    executed at command-line.
>  
>   1) Create a new file which includes your main ivyconf.xml file
>   2) Define the custom eclipse resolver type.
>   3) Create a simple chain which uses the eclipse resolver first and then
>       the resolver which would normally be used in your config file.
>       It could be the default resolver or any other, depending on your situation.
>   4) (Optional) To optimize, if you know you will only be developing modules
>       in your organization, you may limit the calls to the eclipse resolver
>       to only modules in your organization, by using the module directives.
>  
>       IMPORTANT NOTE: If the main config file already restricts modules in your organization
>       to a specific resolver, you will not be able to override it in your own file.
>      Either completely duplicate the main file and add eclipse resolver there,
>       or have a base file without any org-specific restrictions and then two
>       files which include it: the eclipse config and the main config.
>  
>       (See Ivy manual for your reference).
>    5) In Eclipse preferences, navigate to Ivy preferences and select the
>       new config file just created as your default configuration file.
>  
>    Sample ivyconf-eclipse.xml:
>  
>  <ivyconf>
>  
>  <include file="/path/to/ivyconf.xml"/>
>  
>  <typedef name="eclipse" classname="org.jayasoft.ivyde.eclipse.resolver.WorkspaceResolver"/>
>  
>  <resolvers>
>    <eclipse name="eclipse"/>
>        <chain name="eclipse-chain" returnFirst="true">
>            <resolver ref="eclipse"/>
>            <resolver ref="originalResolver"/>
>        </chain>
>  </resolvers>
>  
>    <modules>
>        <module organisation="myOrg" name="." resolver="eclipse-chain"/>
>    </modules>
>  
>  </ivyconf>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message