On Feb 14, 2012, at 1:29 AM, Glyn Normington wrote:
Makes sense. My only additional clarification is to stress that we don't check bundles into git, only their Ivy coordinates referring to the EBR.
Yeah re: the server runtime build, that makes sense. My concern was that these actually *are* in the IDE git commits. See e.g.:
So the big IP Engineering question remaining -- and this is a blocker for Virgo IDE release -- is whether we can do with those two jars:
1. Are com.springsource.json or com.springsource.org.antlr used *anywhere* else in Virgo builds or deployments?
2. Are they covered under an existing CQ?
3. If not, can they be?
a) Probably not, given that ANTLR3 can not be approved for Eclipse IP and the relevant com.json stuff relies on it. The runtime *can* be approved but this probably is not runtime only. To the extent it is, we would literally have to refactor and parse the source code in com.springsource.. to excise the non-runtime stuff we didn't need.
b) What is the provenance for this code? Doe the com.springsource.json contain springsource code and/or org.json code? When I explode jar, there is no license information in the jar itself.
c) Where is the source code, and where are the built?
If the answer to 3 is indeed "no" -- and I'm having the sinking feeling that it is -- then we need to do some significant re-engineering of manifest.core and at least one down-stream project. :( If the answer to 1 is "yes", then we want to make sure that the rest of the Virgo team is aware of this issue.
But Virgo IDE does indeed use Maven and can more or less do whatever is necessary.
On 13 Feb 2012, at 17:57, Miles Parker wrote:
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 (), 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?
virgo-dev mailing list
virgo-dev mailing list