Community
Participate
Working Groups
I am wondering what the reasoning is behind including the .classpath and other files in the source build (build.properties) for the EMF plugins. On import, PDE will create, from a source plugin, the required .classpath file and include the source zip as a referenced library: <classpathentry exported="true" kind="lib" path="org.eclipse.emf.ant_2.3.0.v200705110650.jar" sourcepath="org.eclipse.emf.ant_2.3.0.v200705110650src.zip"/> By including the .classpath file in the build.properties for the source build, PDE does not generate one, and consequently on import, there exists a error associated with the classpath file because of an entry that expects the src/ folder. Ideally this should behave like core eclipse plugins and include only the bare minimum necessary for a plugin to me imported and built properly in the workbench. A plugin such as org.eclipse.core.runtime would only include: src.zip, about.html and the schema directory.
This is the counter-argument to bug 170001, as also discussed in bug 106804 comment 42. Closing as duplicate -- please file subsequent comments in bug 170001. *** This bug has been marked as a duplicate of bug 170001 ***
I'll add Marcelo to the CC list since I'm not sure of the reason for the changes made via https://bugs.eclipse.org/bugs/show_bug.cgi?id=170001. It seems to me that Wassim has stated we should not do this, so until I have a good reason to fly in the face of that advice, then I think we need this bugzilla to put it back the way it way. One issue with not including the .project file is that we have projects with a JET Nature and without that, those projects can't regenerate their templates.
Back in January someone either on the newsgroup or from IBM asked me to do the changes described on bugzilla 170001. The motivation was to make it easier for users to reproduce our development environment. After making the changes, I tested it and all the plug-ins that I've imported were placed in the workspace exactly as I was expecting. Adding this to the fact that I've used the PDE editor to modify the build.properties and got no warnings, I've committed the changes and forgot the issue. Now, after reading that this is causing some problems, I've just imported a full EMF/SDO/XSD build into a clean 3.3RC2 workspace. The plug-ins that have multiple source folders and the cheatsheets are indeed broken (7 out of 63). Btw, this is what I did: 1. Extract 3.3RC2 2. Unzip the EMF/SDO/XSD zip on top of (1) 3. Start Eclipse and do Import->Plug-ins and Fragments 4. Select "Projects with source folders", next 5. Add all *emf* and *xsd* plug-ins, finish So now that we all know the why and what is happening ;-) I would like to ask a few questions: - Why is this a bad design? The motivation seems very reasonable to me... - If this is indeed wrong, should the PDE editor warn the users that they are about to do something bad? -Could the PDE importer do something different when the configuration files are available? Just to be clear, I don't mind reverting this. I just would like to understand what is going on ;-)
Executive Summary: The metadata files in question (.classpath, .project, build.properties) must not be shipped as part of the source distribution of EMF. Reasoning: 1. Bad hygiene (bug 106804 comment 42). This purely esthetic and least important reason. 2. Eclipse projects should have one source packaging story that everybody sticks to. When the story changes in the future, everybody changes. No need to set a precedent and no need to create a schism ;) If some EMF user wants to duplicate the EMF setup, he can check out the EMF projects from CVS. 3. Now for the technical reason: The .classpath that you are shipping, in fact, does not correspond the packaged source that you are shipping, so it is virtually impossible to reverse engineer the shape of what the project looked in CVS based on these two files. Take the jdt.core plug-in for example. It has multiple source folders, with packages split all over the place. Its packaged source, on the other hand, shows all .java files at the root of the ZIP file. How can PDE determing how the code is split, we can't of course. What you are doing with the .classpath file makes sense only if you packaged the plug-in as it appears in the workspace (ie. if you just zipped up your workspace plug-in) Then, and only then, can the structure be preserved. This is, of course, not how we ship our plug-ins.
The following files have been purged from the 'src.includes' of the build.properties files in EMF, SDO, XSD: .classpath, .project, .settings, .cvsignore, .jetproperties, build/, build.properties and *.launch Note that I DID NOT make any changes to examples and tests plugins. However, there's a few places where additional files need to be discussed. These include: bin: model/, models/, schema/, rose/, test/, cheatsheets/, archive*/ datagraph.xsd src: examples/, readme.html So, for the following plugins, I've assumed that these files should live in bin or src as indicated in case they're needed at runtime or because I've assumed they're NOT needed at runtime. If they ought to be moved (or copied), please let me know and I'll make it so. emf.commonj.sdo emf.ecore emf.importer emf.importer.rose emf.importer.java emf.common.ui emf.importer.ecore emf.codegen emf.exporter emf.ant xsd.ecore emf.codegen.ecore emf.edit emf.cheatsheets FYI, once the Search CVS database is updated, the list of changes and which files contain which of the aforementioned questionable files will be noted here: http://www.eclipse.org/modeling/emf/searchcvs.php?q=189741
Spoke with Ed and there's no complaints; I'm moving this to Assigned so it'll appear in the release notes for Wed morning's build. You have 24 hrs to object or suggest changes before it's published in a build for verification.
Fixed in I200706061821.
looks fine.
