[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orbit-dev] N-builds and orbit bundles from branches?
|
Jeff McAffer wrote:
Eugene wrote on 01/04/2007 07:32:31 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 :-)
>
> I am happy as long as it helps to common support developers and build
> workflows. So, widely adopted format is obviously better. Don't you
think?
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.
I think you should look at how Buckminster could help with this. We can
read Eclipse update sites, Maven repositories, CVS source, and a bunch
of other locations and treat the result in a somewhat uniform way.
> > > 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?
>
> 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.
Using Buckminster you can import from an Update Site directly into your
workspace. I think that would at least partly solve this problem.
> > Yes, if you are creating new tools, we can do almost anything. I am
> > NOT arguing against that.
>
> I hope you are not suggesting that PDE build can't be changed?
My wording should have been "if you are writing new function".
Whether it is in PDE or elsewhere is irrelevant.
So in the end it seems that your usecases would be enabled if Orbit
had an update site. Is that accurate?
We would be more then happy to help Orbit with new functionality that would help resolve
issues like this.
Kind Regards,
Thomas Hallgren
