Community
Participate
Working Groups
In order to resolve bug 368582, we're going to need to be able to get ..bundlor ..medic and ..repository from a P2 site somewhere. AFAICT they aren's currently provisioned anywhere. Can someone set this up?
Actually you can find medic and repository in the current Virgo p2 repository. The feature IUs are: org.eclipse.virgo.medic.feature.group org.eclipse.virgo.kernel.feature.group - this one contains "..repository" and a bit more Does that work for you? As for bundlor probably it's best to have its own separate update site?
(In reply to comment #1) > Actually you can find medic and repository in the current Virgo p2 repository. > The feature IUs are: > org.eclipse.virgo.medic.feature.group > org.eclipse.virgo.kernel.feature.group - this one contains "..repository" and a > bit more Yeah I wasn't sure about those two. I would be nice to have those separated, perhaps into util as then we wouldn't have to have a dependency on kernel. That is, ideally it would be nice and clean not to have any dependencies on server bundles at all.
I'm not sure we can do that. Both medic and "..repository" have dependency on util. Also "..repository" has dependency on medic. So in order to have all of these somewhere as low as util we need them all in a single git repository which is against Virgo's practices. I didn't get the dependency on server bundles part - both medic and "..repository" are server bundles?
(In reply to comment #3) > I'm not sure we can do that. Both medic and "..repository" have dependency on > util. > Also "..repository" has dependency on medic. > So in order to have all of these somewhere as low as util we need them all in a > single git repository which is against Virgo's practices. > > I didn't get the dependency on server bundles part - both medic and > "..repository" are server bundles? Well, I just meant that they are coming from the Server runtime side in terms of provisioning. But I really don't care where they come form, I just want to be able to get them. :) Anyway, I'm confusing things. I just need to be able to get bundlor from somewhere. And yeah if that means that the bundlor bundle needs it own update site, that's fine by me as well. :) Actually as we might separate bundlor ui anyway, perhaps that all could go there. Again it doesn't really matter. I think we will have a seperate bundlor or "Manifest generator" feature at some point.
http://download.eclipse.org/virgo/snapshot/BNDLR/1.1.0.BUILD-20120203151719 This is a work in progress but this should provide you with what you need. Chris.
A new milestone has been shipped which includes a published updatesite. Details here, http://www.eclipse.org/virgo/download/milestones.php Updatesite here, http://download.eclipse.org/virgo/milestone/BNDLR/1.1.0.M04/updatesite
Thanks Chris!
Chris, P2 is giving me hassles when I try to grab from either site. I get errors in my target platform like: "The artifact for binary,kernel_resources,1.0.0 is not available." Any ideas?
(In reply to comment #8) > Chris, > > P2 is giving me hassles when I try to grab from either site. I get errors in my > target platform like: > > "The artifact for binary,kernel_resources,1.0.0 is not available." > > Any ideas? What do you mean with trying to grab either site? Provision from it or feed it to tycho?
Hi, I'm new to p2 so it's very possible I got something wrong. I just tried installing the main bundlor feature in to Eclipse and it went fine. Also, there should only be one binary resource, called 'bundlor_resources'. I can't find any reference to 'kernel_resources'. Are you using the milestone update site?
(In reply to comment #9) > What do you mean with trying to grab either site? Provision from it or feed it > to tycho? Either should behave the same. ("Should" not == "does") In this case, I'm attempting to provision a target platform. I should have been clearer. I can install Bundlor as well, but I also need Bundlor Resources. (I think) When I try to provision that, I get the error. Also, I need Utils from the main site. All of these together make for a very unhappy target platform. <winge>It's such a pain to diagnose this as every time I open the dialog, and try to see what is going on or change anything, P2 churns for 3 minutes. :(</woinge> But I've just tried using the regular installer, and naturally everything works fine. FWLIW, I've attached my current TP. I'm trying to get rid of the required byndles dir.
Created attachment 210859 [details] Target platformthat doesn't work yet.
Created attachment 210860 [details] TP that include both Bundlor and Bundlor resources and breaks.
Created attachment 210862 [details] Close but no cigar So here's as close as I can get to a working TP. I can get everything I want -- including Bundlor, Util and Medic -- except for o.e.v.respository. That fails with either a strange dependency error if I try to get it from the 3.5.0M2 site or the binary error I mention above is I try to get it (not sure this is even thr right feature) from BUNDLOR site.
Looks like this is entirely a Libra issue anyway. I was able to resolve this by unselecting the "include required software" option in TP editor.
Ha, I was a few hours away from looking at this again, :) Let me know if there is anything you would like me to look at here, I can happily ask Kaloyan anything about Libra, or just introduce you if you don't know him. (He's the Libra project lead).
Re-opening -- to ask Chris and others a question that just occurred to me: Is there any reason that bundlor cannot be provided in the main update site? We're producing a composite site now, so it's not such a big deal from the consumer POV, but it's still a bit awkward, e.g.: 'http://download.eclipse.org/virgo/milestone/BNDLR/1.1.0.M04/updatesite/' 'http://download.eclipse.org/virgo/updatesite/3.5.0.M03' BTW, Ideally, I guess we'd have a single update site for everything, but OTOH, tooling and runtime probably will continue to have different update sycles for some time to come. (Unless runtime would like to start coordinating.) Alternatively, please see bug 373030 comment 4 -- we could provide this composite site as a generic site for all of the Eclipse IDE side installs.
Hi, Until recently the runtime stuff wasn't in any update site and Glyn and myself still have little idea how to provision it and we aren't consuming update sites at all. Borislav added the p2 support to Virgo for SAP to use, no requirement for it with in VMWare. So in short, you are welcome to make changes to the Bundlor build so that it published to the same update site as the rest of Virgo IDE. My only hesitation is that it's not Virgo specific and it's not runtime so I'm not sure. I leave it to your judgement, I don't know enough about p2. Borislav?
(In reply to comment #18) > Hi, > > Until recently the runtime stuff wasn't in any update site and Glyn and myself > still have little idea how to provision it and we aren't consuming update sites > at all. Borislav added the p2 support to Virgo for SAP to use, no requirement > for it with in VMWare. So in short, you are welcome to make changes to the > Bundlor build so that it published to the same update site as the rest of Virgo > IDE. My only hesitation is that it's not Virgo specific and it's not runtime so > I'm not sure. I leave it to your judgement, I don't know enough about p2. > Borislav? Hmm.. that makes me wonder if we should have a single Virgo maintained update site build that actually built all of the relevant plugins rather than simply aggregating them. I don't know if that makes sense or not but if we're basically the only consumers besides SAP that might make sense..?
We do have some users who are consuming from p2 in order to create a target runtime in Eclipse but I couldn't tell you who they are or how many of them there are.
Hi, Can this issue be closed off or would you like me to do something. I'm not sure what your desired outcome is? Chris.
See comment 17, I just want to see if we couldn't include bundlor in the main update site. (Tooling would still be seperate.)
Hi, Had a discussion about this, we don't want to include it in the main update site as it isn't a part of the runtime. It can either remain on it's own or join the rest of the tooling in that update site. Does that help?
(In reply to comment #23) > Hi, > > Had a discussion about this, we don't want to include it in the main update > site as it isn't a part of the runtime. It can either remain on it's own or > join the rest of the tooling in that update site. Does that help? Yes, but I guess that leaves me wondering if it isn't part of runtime, and it's not part of tooling then what exactly is it? ;)
Hi, I definitely regard it as part of the tooling but not purely Eclipse tooling, it's more general tooling and can be used with Eclipse, Maven or Ant. Chris.
OK, we are provisioning this in an aggregate site, so if you want to point users there, that's no problem. For future reference, if anyone else has to update this, we're hand-editing the relevant composite* files in the tooling update site to keep up to date with the most current milestone locations. We'll also need to have a separate one for release.
