Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Indigo checklist "jarred bundles" vs. org.eclipse.pde.ui.samples

> I'm stuck at the "jarred bundles" item.

Sorry for the inconvenience, but be sure to go back and read the original source requirements for Indigo:

We've changed some of them ... or, especially the wording. Partially as a result of feedback just such as this from last year.
That requirement now says:

Jarred Bundles. Projects must use jarred plug-ins (with unpack=false) unless there are technical reasons not to do so. Also, nested jars should be avoided if possible since it creates problems for projects that has dependencies to such plug-ins. The OSGi runtime is fine with it but the PDE environment is not able to handle classpaths that contain nested jars. Exceptions to these principles should be documented by the project, so we can learn the reasons and extent of unjarred bundles.

The "tracking" software wasn't updated simply due to too much to do, and too few people to do it ... but, if you see anything really bad (as this appears to have cost you "time") you can open a bug against the Foundation Portal.

Similar for the "capabilities" requirement. It was moved to the "good citizen" section .. and, we just mostly for documentation. As for the specifics you ask about, I'm not sure of the answer ... but the intent is just for you to give some guidance or hints to those who might want to add capabilities for your stuff. If it helps, the current write-up says,

Capabilities. Each project should provide basic capability/activity definitions to allow for their UI contributions to be hidden. These can be provided in a separate plugins and feature to facilitate inclusion and reuse by consumers, or ... as most projects do ... simply document some examples, so adopters can create their own, or reuse via copy/paste. Ideally, projects should also provide triggers to facilitate progressive discovery of functionality (but, not many do, other than the Platform). As with other "good citizen" items, projects are free to document "we don't do this" ... but, then at least it is known and better communicated.


From:        Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        02/28/2011 04:43 PM
Subject:        [cross-project-issues-dev] Indigo checklist "jarred bundles" vs.        org.eclipse.pde.ui.samples
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx


While iterating through the Indigo checklist I'm stuck at
the "jarred bundles" item. The reason is pretty simple:
we provide extensions to org.eclipse.pde.ui.samples
which can't work off a jarred bundle (see bug 332748).

Going by the letter this requires us ask the Tools PMC
to ask the Planning Council for an exception, right?

This feels strange, given that providing a bundle with
samples shouldn't be an exception.  Are we using an
outdated extension point (is there a replacement?)?

Or, positively thinking, should we (you and me) join
forces in order to get the bug fixed?


PS: While I'm at it: I had a hard time making any sense of
the "capabilities" requirement. After reading "hundreds" :)
of bug comments and some blog posts it seems to boil
down to: we need to document a string pattern that will
capture our relevant UI contributions, so that product
builders can use this pattern to specify the capabilities
they like to see configurable, right? If that's the message
I'd love to see the requirement rephrased, or a link to a
simple explanation added.
But still: how can I advise product builders that our
capabilities require, e.g., the Java Development capability
given that "the" Java Development capability doesn't exist,
except in the SDK product. So decoupling capabilities
from projects/artifacts means we have no names for
referring to other project's capabilities. I must  be missing
something, no?

cross-project-issues-dev mailing list

Back to the top