[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orbit-dev] N-builds and orbit bundles from branches?
|
Jeff McAffer wrote:
> The problem is that neither Orbid or PDE define well structured
> repository that would allow to discover location of the prebuilt
> artifacts based on their identity. It would be beneficial to the
> consumers of Orbit if it would provide something like that. As
> possible implementation I can point to Ivy or Maven tools. They
> both have Ant tasks to fetch artifacts by id from the structured
> repositories, including the custom ones.
Yes, these certainly are possibilities. In the long run it seems
like a repository neutral approach is likely to be the most
promising. Forcing everyone into Maven, Update sites, whatever is
not much fun. Approaches like OBR (OSGi Bundle Repository) are
interesting because they decouple metadata/lookup information from
actual physical storage layout. As an example, all the bundles in
the Callisto update site actaully appear in the OSGi.org OBR
repository metadata but still live in on the eclipse.org servers in
Update site layout. The OBR client can access those just as well as
it can bundles stashed in a Maven repos etc etc cause at that point
it is just sucking content over HTTP.
Hmm. I don't know much about OBR, but I am also not sure why
standardizing repository is a bad thing? I am not sure what tools can
read repository at osgi.org, but I am pretty sure there is bunch of
tools already that can fetch dependencies from Maven or Ivy repositories.
>> The built orbit bundles are (or will be) available on the Orbit
>> download site individually and in an all-inclusive zip. We can
>> certainly create other structures for this but in the absence of
>> driving usecases we elected in the first conference call to go
>> this route to start.
> Well, it is been shown that downloads like that are hard to deal in
> the end-user builds. That is why tools like Ivy or Maven are
> gaining popularity.
Absolutely. We are not disagreeing. I am talking about what *is*
(in the Eclipse world) and you are talking about what *could be*.
Simply making a Maven repo (for example) for Orbit today does not
solve the real problem because the build side does not read Maven
repos. Don't confuse my comments for happiness with the current
state. It is more an observation that the problem is more complex
than just repo formats.
Right. But my point is that it should be quite easy to add support for
fetching stuff from Maven repository to PDE build, which is Ant-based.
As I mentioned before Maven provide convenient Ant tasks for working
with the repository.
That would also allow folks who are not using PDE build to use the
same mechanisms for retrieving dependencies.
>> First, note that this is a different issue from the one
>> originally being discussed. This point is how do people populate
>> a workspace environement with Orbit bundles. As with any Eclipse
>> bundle today, there are roughly two choices, check out the
>> related project from CVS or get the built bundle and put it in
>> your target. The mechanisms for doing that are no different for
>> Orbit or any other Eclipse project.
> It is different, because Orbit does not provide the update site.
Actually it isn't. What workflow would you use if there was an Orbit
update site?
Fetch dependent features from the Orbit's update site, code, run,
debug. Create own update site linked with the Orbit's one for required
dependencies. Done.
Remember, what you are trying to do is add the Orbit
bundles to your *target*. Update manager only adds things to the
running Eclipse (in this case the IDE). So, going to the Update UI
and "installing" some new features is not what you want. You could
of course have an update client that would manipulate a target but
this would likely require hacks to update manager etc because it is
not intended to work that way. As I mentioned, this is one of the
major usecases that needs to be handled in any new provisioning
technology Eclipse might have.
Don't need any of that. See above.
The only exception is when you need to create an offline
bundle/install, but that can be easily resolved with a fetch tool that
would grab required features from the linked update site.
>> Now, is it quite reasonable to observe that the current
>> situation, across the board, is less than optimal. I agree and
>> the PDE team has been working to make better/simpler workflows
>> for adding new bundles to targets. The vision further down the
>> pike is to make this seamlessly integrated with provisoning as a
>> whole but we are not there yet.
> I know, but perhaps PDE could reuse existing open source
> techologies to achieve that seamlessness?
Of course. I never said otherwise. Existing open source
technologies such as Maven are interesting and have alot to offer.
They do however, come with their own set of problems. So it is not
as simple as saying "lets use Maven (or Ivy or, ...)". Fundamentally
we are a lazy bunch and have no desire to invent yet another this or
that. It would be much more fun to have some infrastructure that
allowed for the use of these different structures as the
users/environment require. So, for example, having a provisioning
system that can read, amongst others, Maven repos, Update sites, ...
and add that content to, amongst others, Eclipse configurations,
target platform definitions, ... That is very attractive.
Hmm. I am not quite sure what are you suggesting here? There is not
tool that has zero issues. Why that is a reason to not use any tools at
all? :-)
>> Does that address your concerns?
> I am afraid it raise even more concerns. :-(
Gads, don't be afraid. These are very real issues that need to be
discussed and addressed. I'm sorry if anything I said has made you
feel otherwise. That was not intentional. One thing to consider is
where the discussion should happen. While these things certainly do
impact Orbit, there is very little that the Orbit committers can do
about solving/addressing the issues. I actually don't know if this
is better as an Update discussion or a PDE discussion.
I thought that Orbit project can at least propose and lobby for
additional requirements on PDE and Update, instead of working around
shortcomings of those project in a way that would make all Orbit users
suffer... On the other hand there is always solution not to use Orbit,
but that would defeat the purpose of this project wouldn't it? :-)
regards,
Eugene
