[jbosstools-dev] Teiid Designer and TP

[Max Rydahl Andersen]

>> And then this looks like something very often updated runtime component which is better managed within teiid project
>> similar to how we got a org.jbosstools.forge.runtime bundle in Forge to allow bundling a specific runtime for ease-of-use.
>> 
>>>> 	* teiid_embedded_query		- commons-cli.jar  	jansi.jar		jline.jar  		staxmapper.jar							
>>>> 					  jboss-as-cli.jar	jta.jar       		teiid-api.jar		teiid-engine.jar
>>>> 					  teiid-client.jar	teiid-admin.jar  	teiid-common-core.jar
> 
> So I am thinking of breaking the plugin into its constituent components.

This doesn't work unless these libraries work/obey with osgi class loading rules and don't need to i.e. load classes from your plugins to work (i.e. one of the reasons why we cant
put hibernate jars into individual bundles is that hibernate dont yet work scalable/nicely in osgi).

But again, my biggest problem is if we continue architecting the tools and runtime we build to be tying users to install a new version of the tools for each runtime he uses.
 
> For example, the jta.jar
> has not been updated between teiid versions 7 - 8 so that would be a 'stable' dependency. It just
> happens to be bundled with the teiid download from sf.net. Likewise, I would assume this to be the
> case for staxmapper.jar and jline.jar (although would need to check). The jboss-as could be
> unbundled entirely if a plugin or feature bundled it separately.

what I don't grok is why our eclipse plugins needs jline.jar, jboss-as-cli.jar etc.  These also overlap with what is Forge tools for example - but here there are a reason - i.e. it exposes the CLI approach.

> Thus, the teiid libraries themselves could be wrapped as their own version which in this case is
> 8.1.FINAL. We would simply depend on teiid-plugin [8.0.0-9.0.0). Would that allow multiple versions
> in such a repository?

Yes in the repository, but that does not help our users using multiple versions of the runtime.

>> Two additional questions from me after thinking about this over the weekend is:
>> 
>> 1) What is "com.springsource.org.objensis.jar" ? why is this osgi jar in the mockito plugin and not the original jar from http://code.google.com/p/objenesis/downloads/list ?
> 
> May be due to my downloading of this jar first when upgrading mockito to 1.9.1. This is a dependency
> for mockito and not worth worrying about since mockito is already bundlified in eclipse orbit and
> could be downgraded (see previous email).

okey.

>> 2) if these are not just the original jar rebuilt for osgi should we not be giving these unique names ? i.e. org.jbosstools.orbit.org.jaxen or similar ? (just like springsource does for their own repackaging?)
> 
> These are the original jars and will simply be wrapped by an osgi plugin. Did not intend to do
> anything more to them. Whether that qualifies for a rename ...

Yes, it qualifies for a rename since you/we are not the "owner" of that package/bundle name.

Same reason why springsource adds com.springsource.* to the bundles to not collide plus to signal that these bundles are something else than the default ones.

Why Eclipse Orbit dont do the same i've never understood but the fact they do that it means i.e. once they update to org.mockito 1.9 we would have a similar named and versioned bundle that would be something different (thats bad)

/max