Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #252800 +++ 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.
The Transaction and Validation components now (as of today's builds) deploy all plug-ins as JARs, including individual source bundles. e.g., http://www.eclipse.org/modeling/emf/news/relnotes.php?project=validation&version=I200811191948 The Query component has no changes since its 1.2.0 release and isn't likely to change in the Galileo timeframe, so it hardly seems useful to publish a new build just to convert to individual source bundles. For one thing, anyone upgrading from Ganymede already has the Query 1.2.0 release with the old style sources, so it's a waste to ask them to download new bundles with the same content. Moreover, it would be another qualifier datestamp of the same Query 1.2.0 release, since only feature meta-data would be changed in CVS (the run-time bundles are unaffected). That would mean that Galileo will produce just another Query 1.2.0 R-build, which looks oddly Orbit-like, and would just confuse people. There would be no basis for calling it a 1.2.1 build, even. So, if there is no objection from the Modeling PMC, I'll just leave Query unchanged from its Ganymede state, and we can consider the trio as compliant to the "esu jars" train requirement.
Recognized for CDO/Net4j.
We have all our plugins jarred, but unfortunately, unless Nick wants to do volunteer work, we don't have the capacity to rework the releng processes to change how the sources are packaged.
Approval is granted by Modeling PMC to exempt the EMF Query component from this requirement until such time as it actually produces a new build in the Galileo stream: -----8<----- Sounds reasonable, to me. Can you please document the situation by copy/pasting what's below into the corresponding bugzilla? Thanks, Rich On 12/3/08 3:00 PM, "Christian W. Damus" <cdamus@zeligsoft.com> wrote: Hello, my PMC, Pursuivant to today's PC call, it is understood that the "Use JARs" requirement does include the adoption of individual source bundles. This is great. As I indicated in comment #1 on http://bugs.eclipse.org/253834, the EMF Query component is not in a good position to do this and would like to request an exemption. This component has not had a build since its Ganymede GA build (1.2.0) and, barring contribution of any enhancements or bug fixes, appears likely to contribute the identical build to Galileo. As individual source bundles do not constitute a functional change and are an SDK concern only, I don't think that EMF Query should push a new build to consumers that already have the 1.2.0 release just to give them source bundles. If, however, a contribution fairy does come along that pushes EMF Query into the Galileo (1.3) development stream, I'll be happy to retrofit it for source bundles at that time. Does this sound reasonable? Thanks, Christian -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@zeligsoft.com _______________________________________________ modeling-pmc mailing list modeling-pmc@eclipse.org https://dev.eclipse.org/mailman/listinfo/modeling-pmc _______________________________________________ modeling-pmc mailing list modeling-pmc@eclipse.org https://dev.eclipse.org/mailman/listinfo/modeling-pmc
(In reply to comment #3) > We have all our plugins jarred, but unfortunately, unless Nick wants to do > volunteer work, we don't have the capacity to rework the releng processes to > change how the sources are packaged. According to Bug 253836 , this is done for GMF. Since we use the same build tools, is this not automatic? Nick?
It's a good question! I'd be happy if it would be done trivially, but as it stands, I haven't got a clue how it works and rely 100% on Nick doing it. Nick, how much work would it be to do this for EMF, Teneo, and CDO? (And XSD to for that matter?) I also haven't got a clue why it matters to anyone in the first place of course. I.e., why is the new improved approach considered improved? How do the clients benefit from it? It would be a nice motivating question to have answered. I.e., we need something to justify the work and hence to justify funding Nick to do it... It's not like we have endlessly deep pockets to justify spending money on mere nice-to-haves so at least we ought to understand why they're so nice to have to make the spending palatable.
(In reply to comment #6) > > I also haven't got a clue why it matters to anyone in the first place of > course. I.e., why is the new improved approach considered improved? How do > the clients benefit from it? [...] > 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 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.
Things like plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20081026/runtime_registry_compatibility.jar are almost as long already so the significant limitations to the leading path will remain regardless... Of course contributions from those who feeling strongly there is significant value in the new improved alternative are encouraged to demonstrate that it's trivial to change the build!
EMF Query, having been forced by the major version increment in ICU4J to produce a Galileo stream build, now uses individual source bundles.
Completed for EMF Core. Source was converted to individual JARed bundles already for this week's build (2.5.0.I200903241800), and cheat sheet changes are committed to CVS, so that they will be JARed in next week's. How about Teneo and CDO? Now that I know what all to do, it's really not hard, so if you guys still need to do this I can give you a recipe.
Hi Dave, Yes if you can provide the 'recipe' then I can try to accomplish this for Teneo, at least for the sources. gr. Martin
Individual JARed Source Bundles Recipe 1. In your releng project, add the following line to builder/all/build.properties: individualSourceBundles=true 2. Check the build.properties in all your features that build source (presumably your SDK features). Currently, there should be a generate.feature line. Add an @exclude for each plug-in in the feature that doesn't need a corresponding source plug-in (i.e. plug-ins without code). For example, here's what I've got for the EMF SDK (this should be all on one line): generate.feature@org.eclipse.emf.source=org.eclipse.emf.sdk, exclude@org.eclipse.emf.doc, exclude@org.eclipse.emf.example.installer, exclude@org.eclipse.emf.mapping.ecore, exclude@org.eclipse.emf.mapping.ecore.editor In this case, doc is obviously our doc plug-in, example.installer just contains our example content for workbench installation (all of the code that installs it is in org.eclipse.emf.common.ui), and mapping.ecore and mapping.ecore.editor are purely branding plug-ins. Note that there should be one branding plug-in that is *not* excluded, because it will generate the branding plug-in for the source feature. In my case, I'm still generating org.eclipse.emf.source from org.eclipse.emf. 3. Check the template content under sourceTemplatePlugin, in the same features. Previously, this content was included in the single plug-in generated for the source. Now, it will only be included in the source feature's branding plug-in. So, you probably shouldn't have to change anything here (I didn't). 4. Back in your releng project, check the zip packaging in buildAll.xml. Because you'll have additional plug-ins, you might have to tweak what is being included and excluded in each package. For example, in my case, because I have a single examples feature for EMF and XSD, that used to result in a single org.eclipse.emf.examples.source plug-in. Now I have several org.eclipse.emf.examples*_source (as well as others that unfortunately don't have "examples" in their names) and org.eclipse.xsd.examples*_source plugins to exclude from my runtime packages. Getting everything correct here was actually fairly tricky for me, and it took several tries, with a build and a careful manual examination of the resulting packages in between each. It should be less of a pain if you've got simpler (less messy) packaging. For example, I believe James didn't have to make any changes for UML. 5. If you have any tests that depend on your source plug-ins, those may fail and need fixing. EMF actually has build tests that check the numbers of source/doc/branding plug-ins and examine their contents. Obviously those needed tweaking. We also have some tools tests that actually extract artifacts from source plug-ins (I know, sketchy eh?). The problem here is that, to avoid doubling the number of plug-ins in every installation, Eclipse actually doesn't install individual source bundles at startup. They just go into the target platform, which is all that's needed to allow the source to be found. So, once I figured this out, I had to add code in our tests to install the relevant source plug-ins. Besides the source stuff, the only other plug-ins that EMF had that weren't JARed were our cheatsheets. Apparently those didn't work as JARed plug-ins in the past, but now they do. So, I just added an unpack="false" attribute to the plugin element for each such plug-in in the containing feature's feature.xml. For example: <plugin id="org.eclipse.emf.cheatsheets" download-size="0" install-size="0" version="0.0.0" unpack="false"/> I also had to do a bit of tweaking of buildAll.xml for these changes, too.
Any update from CDO and Teneo on this? I guess this is the time when we'll be giving our final yes or no on a lot of these things.
Darn it! I overlooked this one in the noise ;-( I guess I thought this is done automatically but I'll work on it NOW! Do I need to respin my M7 builds?
There's so much noise involved in this process, it's amazing anything got done. ;-) I wouldn't respin an M7 at this point. I'd leave it for RC1.
Good! I'll report again when I managed...
Teneo adheres to this bugzilla (incl. source jar files). I hope you are getting more happy now Dave :-)! The only remaining ones are related to Babel PPT and externalizing of strings in the Teneo EclipseLink part. gr. Martin
Any progress Eike? Based on the ramp down policy, I'd expect that if this isn't done for RC1, it won't be done at all. Is that a safe assumption?
(In reply to comment #18) > Any progress Eike? Based on the ramp down policy, I'd expect that if this > isn't done for RC1, it won't be done at all. Is that a safe assumption? > Yes, it was in M7a already. Sorry, forgot to report here!
Great, another one done! Thanks!
Fix available in HEAD: 2.5.0 (R200906151043).
