Community
Participate
Working Groups
Projects must use jar'ed plug-ins (with unpack=false) unless authorized by the planning council for technical reasons. 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 compiler is not able to handle classpaths that contain nested jars. In case only one nested jar exists, it is often better to expand the contents of that jar into the root folder (i.e. unnest the jar). If a plug-in contains large files that are frequently used (opened and closed), a jar'ed plug-in might degrade performance significantly since the file must be decompressed each time it is opened.
In bug 253844 equinox has the list of launcher fragments that must not be jar'ed when deployed to a runtime. What is the process to get the planning council's approval of our non-jared bundles?
(In reply to comment #1) >What is the process to get the planning council's approval of our non-jared bundles? As discussed on the PC call today, I'd say you're good to go with what you've documented in bug 253844. Thanks.
Does this requirement include deploying source attachments as individual source bundle JARs, which is supported by PDE since 3.4? The description makes reference to dependents of bundles, which presumably isn't an issue with source bundles, as no bundle would ever depend on them.
Good question. I'd like to see the promotion of jar'd individual source bundles. I'll add this to the agenda for the next PC call to see what the consensus is: http://wiki.eclipse.org/Planning_Council/Dec_03_2008
(In reply to comment #4) > I'll add this to the agenda for the next PC call to see what the > consensus is: http://wiki.eclipse.org/Planning_Council/Dec_03_2008 The consensus was that individual source jars are included in the requirement, with the same stipulation that exceptions are allowable if documented.
Copied from Bug 253834 , why source bundles? The Eclipse platform went to source bundles in 3.4 / Galileo. The PDE build has documentation in place and it is supposed to be "trivial" to adopt. The benefit is that it helps solves the long pathname limit issue on windows. In the Microsoft API (with some exceptions), the maximum length for a path is MAX_PATH, which is defined as 260 characters. In Ganymede, there exists the source folder [eclipse]\dropins\plugins\org.eclipse.emf.source_2.4.0.v200806091234\src\org.eclipse.emf.codegen.ecore_2.4.0.v200806091234\src.zip . Because of the path length limit, "C:\Program File\Some Vendor\Some Product\eclipse" may longer be an option to install your Eclipse based development application that includes EMF source. At worst, the length of "Some Vendor\Some Product\eclipse" is significantly limited.
Technology ACTF project wants to use three plug-ins as non jar'ed plug-in (please see bug 258607). How can we get the plannning council's approval?
(In reply to comment #7) Based on the discussion at the Planning Council call today, I closed the bug 258607. Thanks.
We should remember, in future, to clarify in the "jar up bundles" rule that any bundles that change shape also require a version increase, preferably service field, but qualifier-only would also work, as far as I know (and it typically qualifier only in Orbit, since those are third party jars). It is easy to change since traditionally, the change is made in the feature, not the bundle. See bug 275709 for an example of where we forgot to do this. In the future, hopefully, people will move to the "bundle shape" directive, so may not be so easy to forget in those cases.
THis is a routine mass closing of the previous release umbrella tracking bugs.
