Re: [orbit-dev] N-builds and orbit bundles from branches?

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Eugene wrote on 01/04/2007 11:46:34 AM:
> Jeff McAffer wrote:
> > If you are doing your own thing then well, it is your challenge.
> >  Eclipse provides solutions and support for the expected
workflows and 
> > processes.  That includes the idea that you do not build
everything 
> > that you include in your output.  The build processes you
put together 
> > should accomodate those characteristics.  Take for example
a third 
> > party *bundle* that comes to you signed.  You cannot rebuild
it and 
> > maintain  signatures.  You have to simply consume it
and include it 
> > verbatim.
>   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.

> > 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.

> > 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?  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.

> > 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.

> > 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.

Jeff