Community
Participate
Working Groups
I20070529-0010 Importing the javax.servlet plug-in as source gives compile errors. .classpath must be changed to something like this for successful compilation: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry excluding="src/share/|examples/WEB-INF/classes/|examples/WEB-INF/classes/" kind="src" path="src"/> <classpathentry kind="src" path="src/src/share"/> <classpathentry kind="src" path="src/examples/WEB-INF/classes"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath>
There are more compiler problems when importing orbit plug-ins as source. I wonder if it's a good idea to import orbit plug-ins as source at all. It would maybe be easier if they would just be imported as binary (as it e.g. used to be the case for org.junit). Further problems: - source plug-ins must set the singleton directive in the Manifest.mf - org.apache.commons.logging does not compile since not all required libraries are available in the SDK - org.apache.jasper does not compile because of unresolved references in JDTCompiler (- not orbit problems: apt does not compile, see bug 188105)
>source plug-ins must set the singleton directive in the Manifest.mf This is something that we decided to do explicitly because if they were marked singleton then at runtime the bundles for which multiple version exist would not get resolved and therefore source would be missing.
> >source plug-ins must set the singleton directive in the Manifest.mf > This is something that we decided to do explicitly because if they were > marked singleton then at runtime the bundles for which multiple version exist > would not get resolved and therefore source would be missing. Does that mean that the compile error "Plug-ins declaring extensions or extension points must set the singleton directive to true" in MANIFEST.MF is wrong and that the extension to ext.pt. org.eclipse.pde.core.source works?
There is no sense in which the source for Orbit bundles will be able to be imported and compiled correctly. Almost by definition Orbit bundle content comes to us as binary. Any source we may happen to be able to get may require all manner of other environment settings and context to be compiled. The source is there for browsing and debugging purposes. Treat these like elements of the JRE.
re comment 3. Yes and no. There are certain cases in which non-singletons can contribute extensions to the registry. I'm not sure that these code paths have been verified (since we have always assumed singleton ness). The singleton-ness was put in place to maintain the integrity of the extension registry namespace which, for better or worse, was originally based on plugin ids (bundle symbolic names now). For anonymous extensions (ones without an id) it seems that this namespace issue is, well, not an issue. Similarly, as of 3.2 we are able to contribute extensions in namespaces other than that of the supplying bundle. Having said all that, there is an underlying notion of "contributor" that we use to map between extensions and their supplying bundle (the contributor). This may not be setup to handle multiple versions. In any event, for 3.3 nothing in the space can be done. Comment 1 is the most apt. It does not make sense to import orbit bundles as source.
We'll still have problems if there is any expectation of being able to recompile especially for bundles like commons logging where the build-time dependencies might be different from what we want to support at runtime. I'll reshape the src.zip for the javax.servlet so that at least the classpath issues are gone. I think if there's more to discuss on the larger source-bundle issues the dev-list is the place or if we can pin down problems in a separate bug. If there are similar class-path problems with other bundles they should be logged.
Fixed in HEAD
I've filed bug 189972 for the rest.
