[virgo-dev] Coordinating Server / IDE dependencies Re: Where art thou, B

[Miles Parker <miles.parker@xxxxxxxxxxx>]

OK,I think the next question is, "where are these provisioned?" Specifically, we're looking for a recent version of org.eclipse.virgo.kernel.tools.jar. I haven't been able to find that one anywhere.

There is a broader issue here that Leo and I were discussing and I thought we should bring up with broader group for ideas and coordination. Right now, Virgo IDE tooling is re-providing a number jars that are built by other virgo components or by tooling itself. There are a couple of interesting cases:

1. o.e.v.ide.manifest.core includes and re-provides libs for o.e.v.kernel.artifact, o.e.v.kernel.tools as well as their source. http://git.eclipse.org/c/virgo/org.eclipse.virgo.ide.git/tree/org.eclipse.virgo.ide.manifest.core/lib These are then reexported to downstream dependencies. We're thinking that this is was set up this way because these projects are not PDE projects so the dependencies can't be consumed directly. Perhaps there is some element of preserving backward API compatibility here, but if so that is an anti-pattern.) This creates a number of (probably obvious) issues including maintainability and performance. In fact, that maintenance issue is exactly what is driving this email, because we've has a lot of challenges simply getting the build working against the latest API as we try to re-factor the required bundles out. https://bugs.eclipse.org/bugs/show_bug.cgi?id=368582

What we'd like to do is figure out a way to package and/or consume these as regular Eclipse OSGi bundles and provision them from p2.

a) Would it be reasonable to have these simply packaged as PDE (or less ideally as other Eclipse OSGi bundled) projects in their host projects? As plugins can of course be consumed as jars but I could see where that would create a lot of work and potential deployment problems for the server side team, but it would be an idea solution for us. It's not even clear to me that there are other consumers of some of these tools.
b) Failing that, perhaps there are some minimal common elements that *could* be packaged into such projects and consumed by both server and IDE.
c) Another option would be to setup some automated way to repackage the produced artifacts as Eclipse binary plugin jar projects. But this option seems to have the most engineering risk and time of all.
d) At the least, copy the artifacts over at build-time rather than development time to ensure that in the worst case we're actually provisioning artifacts that match up with the actual 
d) Better options ??
e) Do nothing.

As mentioned above we also just need to figure out where and how we can get these from Hudson as it is currently set up. The latestArtifacts workspace locations seem to only have test classes in them, and while I can find ..artifact (I think), I can't find org.eclipse.virgo.kernel.tools.jar. And there appear to be issues with the binary for o.e.v.reources bundle. https://bugs.eclipse.org/bugs/show_bug.cgi?id=369864#c14

2. o.e.v.ide.runtime.core has a more compelling problem to try to resolve. It includes the entire built o.e.vi.ide.management.remote plugin itself! http://git.eclipse.org/c/virgo/org.eclipse.virgo.ide.git/tree/org.eclipse.virgo.ide.runtime.core After puzzling this out for a while, Leo and I came up with the theory that this was actually a payload that ide.runtime.core is injecting into the Virgo server at build time. That's pretty neat, but the current setup presents similar issues to the above. Some possible solutions:

a) Provision the plugin from an update site and/or simple download location; *not* from the local plugin install. This is inline with some other possible automated user and testing environment setup that we've loosely discussed.
b) Simply include the management remote plugin in the server distribution, though that makes things more heavy-weight and introduces dependencies and interactions where there don't need to be any in the common case where no IDE tooling needs to interact with a running server. Not to mention that it would break support for older Virgo server.
c) At the least, figure out a way to copy the latest built jar to the runtime.core plugin *and* update the project references. But this creates a nasty wicked little boot-strapping issues.
c) Do nothing. 

I hope this is all somewhat clear. As obviously a lot of thought and maintenance work has gone into how all of the various repositories and dependencies are structured, I realize that these aren't trivial issues for the Server team to address, but perhaps we can all figure out some good solutions that won't cause too much churn.

cheers,

Miles


On Feb 10, 2012, at 5:15 PM, Dmitry Sklyut wrote:

> Miles,
> 
> Take a look in org.eclipse.virgo.kernel-tools.git repository. (http://git.eclipse.org/c/virgo/org.eclipse.virgo.kernel-tools.git/tree)
> 
> http://git.eclipse.org/c/virgo/org.eclipse.virgo.kernel-tools.git/tree/org.eclipse.virgo.kernel.tools/src/main/java/org/eclipse/virgo/kernel/repository
> 
> I found them there.
> 
> Regards,
> Dmitry
> 
> On Feb 10, 2012, at 8:12 PM, Miles Parker wrote:
> 
>> 
>> I don't think this is important enough to lose any sleep over. :D When Monday comes around, perhaps you can share ideas of where the plugin itself might be provisioned from. I'll look around in the current builds, but there doesn't seem to be a specific kernel-tools one.
>> 
>> I didn't even remember there *was* a kernel-tools repository and didn't have it on local git. Thanks for the tip. GROK looks really cool. We were just googling for it and the only place we could find it was on the old Spring servers.
>> 
>> thanks!
>> 
>> Miles
>> 
>> On Feb 10, 2012, at 4:44 PM, Chris Frost wrote:
>> 
>>> Hi,
>>> 
>>> So it's late here and I'm in bed so this is just what occurred to me off the top of my head, I'll apply a more awake brain to this on Monday.
>>> 
>>> Have you tried using GROK?
>>> 
>>> This seems to find something.
>>> 
>>> http://virgo-opengrok.springsource.org/search?q=BundleDefinition&defs=&refs=&path=&hist=
>>> 
>>> Have a play with the search fields, it's fairly simple to use. http://virgo-opengrok.springsource.org/
>>> 
>>> Chris.
>>> 
>>> ----- Original Message -----
>>> From: "Miles Parker" <miles.parker@xxxxxxxxxxx>
>>> To: "Virgo Project" <virgo-dev@xxxxxxxxxxx>
>>> Sent: Saturday, 11 February, 2012 12:20:15 AM
>>> Subject: [virgo-dev] Where art thou, BundleDefinition?
>>> 
>>> 
>>> OK, so leo and I have spent the last hour or so for a dependency. This was discovered as we were trying to unwrap some virgo dependencies that are actually included as lib within the consuming plugin itself. (o.e.v.ide.manifest.core). We'd like to turn these into regular plugin dependencies but have made some guesses about why that can't be / wasn't done before; having to do with downstream platform dependencies that can't be shared. But that's a story for another day, the big mystery right now, is what happened to the following classes? We can find them in Spring virgo pre-donation, but we can't find them anywhere in the virgo trees. There isn't even a log record of org.eclipse.virgo.kernel.repository having existed in ..kernel. Anyone know a) where these went, and b) if the answer is *away* what we might replace them with or if we could get them back?
>>> 
>>> import org.eclipse.virgo.kernel.osgi.provisioning.tools.DependencyLocationException;
>>> import org.eclipse.virgo.kernel.repository.BundleDefinition;
>>> import org.eclipse.virgo.kernel.repository.LibraryDefinition;
>>> 
>>> cheers,
>>> 
>>> Miles and Leo (intrepid git explorers)
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev