6:37 a.m.
>> 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