Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] N-builds and orbit bundles from branches?

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

Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
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.



orbit-dev mailing list

Back to the top