[jbosstools-dev] Teiid Designer and TP

[Max Rydahl Andersen]

btw.

we kind of already have an "orbit" site for eclipes plugins: http://download.jboss.org/jbosstools/updates/requirements/

its not a single site per-se but contains subsites for the appropriate bits (putting them in one big one would be bad to use with Tycho since
then *everything* in here would be considered the target platform).

What is my biggest concern is though how often your dependencies actually needs updating ?

On my first look I see these as "true" stable dependencies:

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


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


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 ?

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


/max

On 05 Oct 2012, at 18:35, Max Rydahl Andersen <max.andersen at redhat.com> wrote:

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