> ... better then manually downloading and unzipping
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>
Re: [orbit-dev] N-builds and orbit bundles
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
> > required bundles. If I am not mistaken same process can be run
> > 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
> manager to do this differently is non-trivial since managing other
> configuration was not a design point. As I have been saying
> 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
> 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