[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] com.springsource.*

On 14 Feb 2012, at 11:26, Miles Parker wrote:

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?

com.springsource.json v 1.0.1 is used in the Virgo system verification tests here:

http://virgo-opengrok.springsource.org/xref/virgo/org.eclipse.virgo.system-verification-tests/build.versions

Since this is downloaded only at build time, no CQ is required. (I have an email from the IP team on file confirming the general principle of CQs not being required for build-time downloads that are not needed by downstream consumers of Virgo.)

com.springsource.org.antlr-3.0.1.jar is checked in to the system verification tests repo. There is a "works with" CQ 4139 for this, but I don't think that covers checking in the JAR, so there was an oversight there. I've raised bug 371531to correct this.

2. Are they covered under an existing CQ?

See above.

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.

com.springsource.json v 1.0.1 is, I think, 100% SpringSource code:


com.springsource.org.antlr-3.0.1.jar is ANTLR code with the addition of a generated manifest from SpringSource. See:


  c) Where is the source code, and where are the built?

The com.springsource.json v 1.0.1 source code is not available at the above link, but I don't think that's relevant since no CQ is needed.

For ANTLR 3.0.1, see CQ 4139.


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. 

-Miles

But Virgo IDE does indeed use Maven and can more or less do whatever is necessary.

Regards,
Glyn

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 ([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
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev