Re: [jbosstools-dev] Teiid Designer and TP
On 10/08/2012 12:24 PM, Max Rydahl Andersen wrote:
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
Yes, that's correct
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
So I am thinking of breaking the plugin into its constituent components. For example, the
jta.jar
has not been updated between teiid versions 7 - 8 so that would be a 'stable'
dependency. It just
happens to be bundled with the teiid download from sf.net. Likewise, I would assume this
to be the
case for staxmapper.jar and jline.jar (although would need to check). The jboss-as could
be
unbundled entirely if a plugin or feature bundled it separately.
Thus, the teiid libraries themselves could be wrapped as their own version which in this
case is
8.1.FINAL. We would simply depend on teiid-plugin [8.0.0-9.0.0). Would that allow multiple
versions
in such a repository?
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 ?
May be due to my downloading of this jar first when upgrading mockito to 1.9.1. This is a
dependency
for mockito and not worth worrying about since mockito is already bundlified in eclipse
orbit and
could be downgraded (see previous email).
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?)
These are the original jars and will simply be wrapped by an osgi plugin. Did not intend
to do
anything more to them. Whether that qualifies for a rename ...
Cheers
PGR
--
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