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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Eugene wrote on 01/04/2007 01:44:28 PM:
> Jeff McAffer wrote:
>   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.

you are happy with standardizing the repo as long
as it is Maven :-)  What if we decide that it is Update Site format?
 The point is that personally I don't want to be in the position of
making that decision.  I want to leave it open.  More flexible,
more evolvable, ...

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

I am driving at something deeper.  What buttons
on what dialogs etc does the user press to make this happen.  I have
an Eclipse SDK and want to add some Orbit bundles to my Target.  What
do I do?

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

Yes, if you are creating new tools, we can do almost
anything.  I am NOT arguing against that.

> >  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? :-)

I am suggesting that we have to take a bigger picture,
longer term view.  When we adopt tools, processes, formats, ... they
have to viable in the long term.  Adopting, for example, the Maven
repo format is IMHO premature.  That repo structure, in and of itself,
has no particular benefits over any other.  Its benefit is that Maven
users can use it.  To date Maven is does not figure largely in the
Eclipse build world.  That may be changing and as that evolves Eclipse
as a whole should consider how best to facilitate that evolution.  People
who want that today can write a tool that sucks content from the Orbit
site and pushes it to ibibilio for example.  

> > >> 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? :-)

Eugene, you are being extreme.  My point here
is that the issues for Orbit are no different than the issues for people
wanting to consume say WTP.  They don't have a Maven repo either.
 So the issue is wider scoped than Orbit and nay changes that might
be proposed to PDE or Update would have to be set in that larger context.

Jeff