Re: [mylar-dev] release status

Mark,

 Apparently my patch introduced build time dependency on Subclipse 
classes which is not acceptable for Mylar. So, we now wonder if you can 
take a contribution of a new (optional) Subclipse feature, that will 
have dependency on Mylar?

 This feature will be responsible for managing Mylar's change sets and 
linking Subclipse's own artifacts (change sets, files and history 
entries) with tasks in Mylar. Basically there is two classes that need 
to be packaged into a separate feature that will have dependencies on 
Mylar and Subclipse will get a build time dependency on Mylar. I and Mik 
can contribute this code, but we'll need your help to integrate it with 
Subclipse's build.

 What do you think?

 regards,
 Eugene

PS: worth to mention that Subversive folks provide such integration on 
their side...


Mik Kersten wrote:
> I tried to apply it and overall the patch looks great.  However, it appears
> to add a direct dependencies on Subclipse, which could cause the
> corresponding class and potentially the mylar.team plug-in to fail to load
> if Subclipse is not installed.  Currently we only have reflectively-invoked
> dependencies on Subclipse and declare the dependency as
> resolution:=optional.
>
> This brings up an important issue.  The mylar.team plug-in should not have a
> dependency on Subclipse, and instead Subclipse should be extending it in a
> similar way to how Subversive is doing this:
> http://wiki.eclipse.org/index.php/Mylar_Integrator_Reference#Integrating_Tea
> m_Providers  
> http://www.polarion.org/index.php?page=mylar&project=subversive  
>
> Eugene: this would also allow the extra dependencies needed by your patch.
> Do you think that you could persuade Subclipse to take this contribution in
> time for 1.0?  If not we can keep this dependency for 1.0, but shortly after
> that we will need to remove it as we move towards not having dependencies
> outside of the SDK and Orbit.
>
> Mik