|Re: [virgo-dev] com.springsource.*|
On Feb 13, 2012, at 3:25 PM, Glyn Normington wrote:
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.
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.)
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?