Community
Participate
Working Groups
Now that I've looked at your content types :) I don't see anything that would prevent the bundle from being activated when the content describer was used. Thereby increasing startup time, and, presumably, using at least a little memory and process time. In particular, that start method in JPACore looks hefty with the JPAModelManager start() (thought I really have no idea). But, point is, content type describers _have_ to be instantiated to be put to work, yet for some contexts and users they may never be interested in JPA at all, so to activate the bundle, based on content type, is a "violation" of how to do content type describers. This is somewhat documented in http://dev.eclipse.org/viewcvs/index.cgi/platform-core-home/documents/content_types.html?view=co Lucky for you, there's an easy way, as long as your describer is "self contained" (in one package) because you can exclude packages from causing bundle activation by listing them as 'exclude' on the bundle-activationPolicy directive. Here's the one for one in XML Core (would in your manifest as one long line, or properly formatted for manifest files): Bundle-ActivationPolicy: lazy; exclude:="org.eclipse.wst.xml.core.internal.contenttype"
That is a good catch. Another thing we could do is contribute our content describers to core (or XML core). They're generic and only add a) version testing in one case and b) an "abstract" indeterminate content describer in the second.
We've collapsed our resource models to use only one content type which includes all versions, so we've removed our content describer.
