[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [orbit-dev] N-builds and orbit bundles from branches?
- From: Eugene Kuleshov <eu@xxxxxxxx>
- Date: Thu, 04 Jan 2007 11:46:34 -0500
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 184.108.40.206 (Windows/20061207)
Jeff McAffer wrote:
The problem is that neither Orbid or PDE define well structured
repository that would allow to discover location of the prebuilt
artifacts based on their identity. It would be beneficial to the
consumers of Orbit if it would provide something like that.
> Does that mean using some ant scripts that PDE provide or generate
> under the hood?
Yes, this is a PDE build facility
> What if project is using custom build, maybe even not
> based on Ant? How that build supposed to get or package some particular
> Orbit bundle?
If you are doing your own thing then well, it is your challenge.
Eclipse provides solutions and support for the expected workflows and
processes. That includes the idea that you do not build everything
that you include in your output. The build processes you put together
should accomodate those characteristics. Take for example a third
party *bundle* that comes to you signed. You cannot rebuild it and
maintain signatures. You have to simply consume it and include it
As possible implementation I can point to Ivy or Maven tools. They
both have Ant tasks to fetch artifacts by id from the structured
repositories, including the custom ones.
The built orbit bundles are (or will be) available on the Orbit
download site individually and in an all-inclusive zip. We can
certainly create other structures for this but in the absence of
driving usecases we elected in the first conference call to go this
route to start.
Well, it is been shown that downloads like that are hard to deal in
the end-user builds. That is why tools like Ivy or Maven are gaining
It is different, because Orbit does not provide the update site.
> > As for development in the workspace, you can of course check out the
> > Orbit projects inot your workspace or add the built versions to your
> > target.
> Hmm. You mean that developer would need to manually download, unzip,
> etc those bundles? That seem quite error prone and also quite painful
> when you'll need to configure it on every developer's environment,
> unless I am missing something...
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.
Now, is it quite reasonable to observe that the current situation,
across the board, is less than optimal. I agree and the PDE team has
been working to make better/simpler workflows for adding new bundles
to targets. The vision further down the pike is to make this
seamlessly integrated with provisoning as a whole but we are not there
I know, but perhaps PDE could reuse existing open source techologies
to achieve that seamlessness?
Does that address your concerns?
I am afraid it raise even more concerns. :-(