On Feb 13, 2012, at 3:25 PM, Glyn Normington wrote:
Virgo depends on certain 3rd party open source JARs which are not provided as bundles by their source projects. So these JARs were converted to bundles in the SpringSource Enterprise Bundle Repository ([1]), a.k.a. the EBR. SpringSource adopted the policy of prefixing bundle symbolic names with com.springsource to make it clear that the source projects did not provide a bundle manifest. So it is quite legitimate for Virgo, including Virgo IDE, to have dependencies on such bundles.
OK, thanks for the explanation. Naturally if possible I'd like to be only dependent on 3rd party bars provided as separate bundles. If nothing else, a big concern for potential consumers is that as these packages are re-exported, consumers with virgo dependencies could end up using our repackaged versions of these jars w/o knowing it.
(A little more background on build seems necessary…
The EBR makes its bundles available via Ant/Ivy and Maven. Virgo obtains these dependencies via Ant/Ivy.
So the process for a new dependency in Virgo is to get it approved via a CQ and then check in the dependency EBR coordinates.
Ahah. That explains why they're in git for the most part -- you've got to have them available somewhere, right? But does that mean that the only alternative is to re-provide them as embedded jars? (If that's the case, I wonder if we could get approval to have them packaged as binary plugin projects.) And most important question, does that mean that all of the jars w/in git, e.g. including com.spring.. have in fact been IP approved?
If not, one of these is a real concern, as I would be surprised to see it get through CQ from experience of XText project. See 371434: remove antlr dependency
https://bugs.eclipse.org/bugs/show_bug.cgi?id=371434 I don't know is this is being used anywhere else. Of course there are other ways to parse JSON which is all that seems to be going on here, but doing the replacement on that will be significant work.
The other one, JSON seems to be ok. There is an existing orbit on that so we can piggyback on it. (You've probably already got a strategy for this or solved it altogether, but IIRC the deadline for CQ submissions for Juno has passed.)
This is in line with Virgo's primary build system being Ant/Ivy. Very recently, we have started to use p2 in the build in order to support p2 provisioning of Virgo and applications, but that doesn't change the essential Ant/Ivy bias.)
Back to the com.springsource dependencies question. It is not clear that you need to get rid of these. However, if you want to switch some of these dependencies to be from Orbit, that's ok in principle, but in general there is the issue that Virgo can't build from Orbit using Ant/Ivy (or Maven for that matter) as there is no guarantee that the contents of Orbit are available (e.g. on
maven.eclipse.org) - see bug 364469.
OK, that bug completely lost me. I think I've had enough of build systems for this lifetime. :) But I think I get the gist of the impact. In any case, I thought the tooling build was using Maven? And since the rest of Virgo has no dependencies on IDE, it seems safe to not rely on Ivy components if we can build w/o it. If that's the case, then my feeling is that we should follow the common Eclipse plugin packaging and build conventions unless we really can't do it any other way. Does that make sense to everyone?
-Miles
