[jbosstools-dev] Teiid Designer and TP

[phantomjinx]

Hi Max,

Thanks for the responses. Find answers to your questions inline below.

Cheers

PGR

>> Background:
>>
>> 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

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

>> 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

> 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?

> 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.

>> 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.
> 
>> 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.

>> Discussion so far:
>>
>> * Mistria introduced me to the maven-dependency-plugin:get goal that could be executed during the
>> generate-resources phase to download release jars build-time
> 
> k
> 
>> * Mistria also pointed out his new maven plugin that can take several platforms as input and produce
>> a single target file
> 
> hmm...which is that ? :)
> 

Not sure ... will gather details as I make progress ;)

<snip>

-- 
Paul Richardson

  * p.g.richardson at phantomjinx.co.uk
  * p.g.richardson at redhat.com
  * pgrichardson at linux.com

"I know exactly who reads the papers ...

  * The Daily Mirror is read by people who think they run the country.
  * The Guardian is read by people who think they ought to run the country.
  * The Times is read by people who do actually run the country.
  * The Daily Mail is read by the wives of the people who run the country.
  * The Financial Times is read by the people who own the country.
  * The Morning Star is read by the people who think the country ought to be run by another country.
  * The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister