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

[David M Williams <david_williams@xxxxxxxxxx>]

> ... better then manually downloading and unzipping
those bundles.

I, for one, don't want to give up the current plan
... yet. 
I'm not sure how frequent developers will have to
download and unzip bundles. 
The idea, as I see it, is that if a developer needs
something from Europa 
(such as JDT) then they get the third party code (such
as JUnit) automatically. 
[from the update site where JDT is]. 

If you mean the use case that someone is using the
third party code (such as JUnit) 
in some new way that is independent of the Europa
component (such as they are not 
using JDT) then I think it might be fair to ask them
to download/unzip what they need ... 

unless I'm missing the point

Eugene Kuleshov <eu@xxxxxxxx>
Sent by: orbit-dev-bounces@xxxxxxxxxxx

01/05/2007 12:59 AM

Please respond to
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>

To	Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
cc
Subject	Re: [orbit-dev] N-builds and orbit bundles from branches?

Jeff McAffer wrote:
> In the Eclipse plugin development world Maven is not at all common.
>  Update site yes.  So if the crux of this whole discussion
is that you 
> want to revisit the initial decision to not have an update site, sure
> that is a fine topic to put on the agenda for the next conference
> call.  Focusing on Maven etc perhaps is a distraction.
   We really need something to support reusable/automatically 
downloadable artifacts. So, I think that Update Site is better then nothing.
  I am not insisting on Maven, but it could be a nice option.
> >   You open up an update manager on Orbit update site and
download
> > required bundles. If I am not mistaken same process can be run
from the
> > command line too.
>
> NO.  This adds the bundles to your *current running IDE configuration*
> not your *target*.  That is the problem.  It is dumb I agree
and if it 
> were not the case then the initial discussions around having an update
> site for Orbit would have had a different outcome.  Changing
Update 
> manager to do this differently is non-trivial since managing other
> configuration was not a design point.  As I have been saying
all 
> along, any new provisioning work in Eclipse would need to allow for
> adding to that target (e.g., random configuration) rather than just
> the current running one.  That work has not been done yet.
  Well, then I guess that for command line you stuck with what you
already have. But  it seems like update site is still a good option
for 
development time.
> So in the end it seems that your usecases would be enabled if Orbit
> had an update site. Is that accurate?
  I think so. At least it will be much better then manually downloading
and unzipping those bundles.

  Thanks

  Eugene


_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev