Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Capabilities in Galileo

That's right, the current approach was taken in order to minimize the work
required to be done by each project, particularly w.r.t. changes in their
build/promotion.

Best,
Rich


On 4/20/09 2:20 AM, "David M Williams" <david_williams@xxxxxxxxxx> wrote:

> I like this proposal. It keeps the capabilities "closer to" the projects
> that contribute them and helps fix some of the current problems (e.g. the
> capabilities bundles are not conditioned or signed).
> It should be relatively easy for projects to add their current
> contribution to a new feature, and
> add that to their build and update site.
> 
> As I understand it, the current system was (partially) created because
> some projects did not want to contribute their "capabilities" to their
> main distributions or zip files. I don't recall why that was, but if true,
> that is hopefully still relatively easy to overcome, I hope. If someone
> recalls the history, please let us know.
> 
> Since there has been no other comment or objections, I'd like us to work
> with the assumption that we will work towards this new method and process
> ... assuming Thomas is still willing to do the work. :)
> 
> I've opened bug 272853 to cover further discussions of this and to track
> progress. 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=272853
> 
> As always, if there's issues or questions please let us know.
> 
> Thanks, 
> 
> 
> 
> 
> From:
> Thomas Hallgren <thomas@xxxxxxx>
> To:
> Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
> Date:
> 04/16/2009 04:54 PM
> Subject:
> [cross-project-issues-dev] Capabilities in Galileo
> Sent by:
> cross-project-issues-dev-bounces@xxxxxxxxxxx
> 
> 
> 
> Hi,
> The current way of managing capabilities in Galileo is somewhat external
> to an otherwise very clean and straight forward process. In order to add
> capabilities today, the contributor must:
> 
> 1. Create a capability bundle.
> 2. Add this bundle to the org.eclipse.galileo feature
> 3. Add an entry in a map in the org.eclipse.galileo.build/maps/galileo.map
> 
> The build contribution is not used at all and two new artifacts that are
> foreign to the project are introduced that a contributor must be aware
> of and maintain. The approach also requires that the builder now must
> check things out from various places in CVS and SVN and build them from
> source. That in turn, increases the complexity, the size of the builder,
> and makes the build much slower.
> 
> I have a proposal that will make the build contribution the sole
> interface between the contributor and Galileo, and retain the builder as
> a mean and lean P2 verifier/assembler. Each project would instead do this:
> 
> 1. Create a capability feature that includes the projects capability
> bundle (or bundles). The name of the feature must end with
> ".capabilities".
> 2. Add this feature in the build contribution, just like any other
> feature but without any categories.
> 
> That's it. No map file entries and no need to add anything to the
> org.eclipse.galileo feature.
> Behind the scenes, the Galileo builder will collect everything included
> in the ".capabilities" features and include that in a generated
> "org.eclipse.galileo" feature.
> 
> Does this seem reasonable?
> 
> Regards,
> Thomas Hallgren
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> 
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 



Back to the top