6:23 a.m.
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(a)phantomjinx.co.uk
* p.g.richardson(a)redhat.com
* pgrichardson(a)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