Re: [cross-project-issues-dev] Indigo checklist "jarred bundles" vs. org

[David M Williams <david_williams@xxxxxxxxxx>]

> 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: 

http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php

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. 

HTH





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

---

Hi,

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?

thanks,
Stephan

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
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev