[jbosstools-dev] Teiid Designer and TP

[Max Rydahl Andersen]

> Teiid Designer (TD) comprises part of jboss tools and provides an eclipse UI client interface for
> modelling and deploying virtual databases (vdbs) to a teiid server, which in turn is deployed in jboss.
> 
> I have begun a discussion with mistria this afternoon on the possibility of a 3rd party P2 plugin
> repository that would serve as part of the Teiid Designer target platform.

ok, cool - similar discussions are going on for how we handle this for soa-tooling in general/per part.

Optimally we would like to avoid having a custom P2 repo for every release X every component, but we need to start somewhere :)

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

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

The teiid_embedded_query sounds like something that are very version specific ? Does this
have to be matching the target server still ?

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.

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

> * We agreed that this sounds very much like a jboss version of Eclipse Orbit and considered the use
> of this repository across all jboss projects rather than just TD (an external deps + JBoss.org stuff
> packaged as OSGi bundle in a p2 repo)

Yes, similar idea have come up before.

I see JBoss Tools Orbit as something else than a Target Platform - Orbit would be actual input to the actual target platform and what is later pointed to for updatesites.

> * Unlike Eclipse Orbit, we would wrap existing release jars rather than rebuild project from source

well, depends on the jars I guess - if Eclipse Orbit already have something rebuilt we could consider using that -
but that all depends about matching jars/apis.

> * So a suggestion was made that given a project X normally has additional X.tools and/or X.designer
> projects, the latter should be responsible for shipping X as OSGI bundles

What worries me is the "shipping as osgi bundles" since that is *not* trivial if we start exposing stuff that 
becomes runtime version dependent - just something to be extremely careful about.

its the reason why we refrained from re-bundling dmr.jar/as7 client library as osgi libraries since we needed to be sure
our Server tools could use multiple version of this at the same time from the tools. 

Just something to consider.

> * Need approval since this represents an independent project. However, I would like to limit it at
> first to being a TD focused project until either other's find a use for it and/or it proves itself
> useful

well, we already have plenty of jars that are candidates for this (i.e. mockito.jar) - my main concern is the mix of runtime aspects into tools as osgi
bundles since it  can limit our ability to be multi-runtime compatible.

*that said* i'm all for the creation of a JBoss Tools Orbit project in which we can add content after review that can be shared
and properly versioned.

> * Consider a small independent P2 update site that is built manually and locally at first then move
> to automation when that is working

yes, sounds cool - create it as a standalone github project and we can go to set that up.

> Questions for getting started:
> 
> * The hosting location for this P2 update site. Do I / Is it possible to have access to
> download.jboss.org to upload such a site?

yes - I don't see a problem for that - we just need to figure out the rules/conventions for how this JBoss Tools Orbit should work.

i.e. it would be anything but eclipse plugins. The jars can't modify overall system state (i.e. versions of jboss-modules or was it logging changed system behavior that might be good for one plugin but terrible for others).

But yes, Definitely a big +1 for creation of a JBoss Tools Orbit kind of repo.

/max