[jbosstools-dev] Teiid Designer and TP

[Max Rydahl Andersen]

>>> TD (unreleased version 8) uses a target platform of:
>>> 	* http://download.jboss.org/jbosstools/updates/development/juno (JBT milestone build)
>>> 	* http://download.jboss.org/jbosstools/updates/juno/SR0/ (Eclipse Juno Target Platform)
>>> 
>>> Thus, TD is a consumer of both the jbosstools TP and jbosstools features.
>> 
>> okey - would be cool to know which features TD is using (just out of interest to understand what API's are actually used - remember JBT dont really have any API's outside AS tools currently)
>> 
> 
> Currently, 8.0 development uses
> 	* org.jboss.ide.eclipse.as.serverAdapter.wtp.feature.source.feature.group for access to jboss as7
> API and framework. So according to the TP wizard, this comprises 18 plugins

just to be clear - you should *never* depend on source features in a build - that is purely to be used for those wanting source features.

i.e. your teiid dependencies should *never* refer to an SDK nor source feature.

> Rationalising the teiid jar dependencies, I have noticed that I can depend the teiid_embedded_query
> plugin on the following. This removes all jboss.as dependencies except for jboss-as-cli.jar
> 	* org.jboss.ide.eclipse.as.management.as71

hmm - that sounds wrong - as.management.as71 are not guaranteed to be available/the correct one to use.

why do you need these jars ? dont you just need to call via the non-typed  management which as.core exposes not tying you to specific versions of the underlying AS ?

>>> However, contained in the current TD codebase are the following wrapped plugins, ie. wrapping
>>> 3rd-party built/released jars:
>>> 
>>> 	* net.jcip.annotations 		- jcip-annotations.jar
>>> 	* net.sf.saxon 			- saxon9he.jar
>>> 	* org.apache.poi		- poi.jar, poi-scratchpad.jar, poi-contrib.jar
>>> 	* org.jaxen			- jaxen-core.jar, jaxen-jdom.jar, saxpath.jar
>>> 	* org.mockito			- com.springsource.org.objensis.jar, mockito-core.jar
>>> 	* org.wsdl4j			- wsdl4j.jar
>>> 	* 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
>> 
>> How many of these are already in eclipse orbit ? 
> 
> * jcip-annotations.jar					NO
> * saxon9he.jar						NO
> * poi.jar, poi-scratchpad.jar, poi-contrib.jar		NO
> * jaxen-core.jar, jaxen-jdom.jar, saxpath.jar		NO
> * mockito-core.jar, com.springsource.org.objensis.jar	YES/NO - Version in use is 1.9.1 but version
> 1.8.4 available. Only recently upgraded to 1.9.1 to use 'latest version' so not an issue to
> downgrade for the moment
> * wsdl4j.jar						YES/NO - Version in use is 1.4 but both versions 1.5.1 and 1.6.2 are available

So question is why wsdl4.jar 1.4 is needed ?
> 
>> The teiid_embedded_query sounds like something that are very version specific ? Does this
>> have to be matching the target server still ?
>> 
> 
> With the release of teiid 8, backward compatibility has been broken so I would envisage a teiid
> versioned features being included and clients import specific versions of the feature/plugins using
> eclipse plugin functionality, eg. [8.0.0,9.0.0). Going forward, TD 8.0 will be the first application
> to use teiid 8 plugins and thus this P2 repository so we can set the rules for use?

okey - this should probably go to another thread - i.e. how are users of Teiid 7 (maintanence) and Teiid 8 (new development)
supposed to use the tools.

>> Do I read it right above that teiid_embedded_query is simply wrapping those jars and only exposing limited API ?
>> i.e. commons-cli.jar, jboss-as-cli.jar does sound like things that easily could come problematic if exposed to rest of the eclipse plugin stack.
> 
> Correct. See my rationalising commment above for reduction of the jboss-as dependencies. If
> jboss-as-cli could be offered in a plugin then this need not be included either.

Really need to understand why we are tying us self to these specific *runtime* jars. We cannot keep doing this blindly.

>>> All of these jars are obtained from external websites, including the teiid jars (sf.net/projects/teiid).
>>> 
>>> Problem:
>>> 
>>> Everytime, an update of these jars is required, the new set of jars must be downloaded, included in
>>> the TD codebase and committed to the TD repository.
>> 
>> Yes, you are basically updating the Target Platform.

Well no - for an "orbit" style you are adding things that can then be used in  a new version/variation of the target platform, right?

>>> Since we fetch the jbosstools and eclipse plugins from the target platform, it would be advantageous
>>> if these wrapped-plugins could be broken out into their own repository, ideally with no jars
>>> actually in the code repository then automatically built and served as features in a P2 repository.
>>> This P2 repository is then used by TD developers and TD build infrastructure.
>> 
>> Yes - a Teiid targetplatform, optimally one that have these jars unified with the other "ontop" tooling set
>> so we know these can be installed together.

>>> 
>>> For example, with the teiid jars, a new release is uploaded to sf.net by the teiid team, downloaded
>>> by TD dev, fully wrapped as plugin/plugins and added to the P2 repository.
>> 
>> hmm - do you really put a full unique teiid jar into the teiid plugin release s?
>> 
> 
> At the moment, yes. It seems that the teiid jars are slowly splitting into constituent components,
> eg. admin-api, common-core, client, engine, but this seems ongoing.

yes - but exposing these as first-class osgi bundles have issues:

1) does these jar obey/allow osgi classloading ?

2) how does the tools work with multiple versions of them (ie. Teiid 7.x, 8.0 and 8.1?) If just one set available this way its crucial the runtime can actually work with them. (for that other thread)

/max