[rt-pmc] [CQ 3932] activation-1.1.jar Version: duplication of package (P

[emo-ip-team@xxxxxxxxxxx]

http://dev.eclipse.org/ipzilla/show_bug.cgi?id=3932





--- Comment #4 from Glyn Normington <gnormington@xxxxxxxxxx>  2010-04-13 09:38:23 ---
Hi Jesse

(In reply to comment #3)
> Couple of questions on this CQ
> 
> 1) Is there any reason that the actual activation 1.1 bundle in orbit could not
> be used in place of this bundle?  This bundle contains both com.sun and
> javax.activation source in it...is it modified from its original version in
> some way that would prevent the reuse?

The bundle in the EBR has a manifest that we trust since it was generated using
our bundlor tool. In this particular case, the manifest is pretty trivial, but
that's far from the case for many of our 3rd party dependency bundles.

To reach a baseline release of Virgo, we want to disrupt the existing build
strategy as little as possible and that means Ant/Ivy needs to download the
dependency bundles from the EBR.

We want to minimise the number of changes between dm Server 2.0 and the
baseline release of Virgo in order to maximise migration of dm Server users to
Virgo. Maintaining the same 3rd party bundles will help in this respect as
customer applications may have formed dependencies on those bundles which could
break if we used alternative bundles. For example, the EBR documents (in
http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.javax.activation&version=1.1.0&searchType=bundlesByName&searchQuery=activation)
that customers can use this bundle by coding:

Import-Bundle: com.springsource.javax.activation;version="[1.1.0,1.1.0]"

Inevitably many of our dependencies will not already be in Orbit. We are
looking to move the EBR to Eclipse and somehow reconcile EBR and Orbit.

For these reasons, I am putting off any point-wise changes of dependencies from
EBR to Orbit until we have a stable baseline build.

> 
> 2) what namespace would you be using this under?  talking with jeff this
> morning he mentioned that the spring source strategy has been to bundle these
> sorts of things under a new namespace, but the eclipse way has been to bundle
> in place and be happy if the originator started producing bundles...  I believe
> this means that ideally virgo would use the bundle javax.activation in this
> case as opposed to com.springsource.javax.activation

The bundle symbolic name is com.springsource.javax.activation.

> 
> So is there a technical reason behind requiring this CQ, like modification of
> the source or a bugfix or is there another reason preventing usage of the
> original javax.activation bundles?

If we migrate to a bundle symbolic name of javax.activation, we may break
customer applications which is contrary to the philosophy of the Virgo baseline
release. The objective of the baseline release is migration of dm Server 2.0
users to Virgo with minimal impact.

> 
> cheers!
> jesse
> 

Regards,
Glyn


-- 
Configure CQmail: http://dev.eclipse.org/ipzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the CQ.