Re: [jbosstools-dev] Teiid Designer and TP
> 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.
This doesn't work unless these libraries work/obey with osgi class loading rules and
don't need to i.e. load classes from your plugins to work (i.e. one of the reasons why
we cant
put hibernate jars into individual bundles is that hibernate dont yet work scalable/nicely
in osgi).
But again, my biggest problem is if we continue architecting the tools and runtime we
build to be tying users to install a new version of the tools for each runtime he uses.
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.
what I don't grok is why our eclipse plugins needs jline.jar, jboss-as-cli.jar etc.
These also overlap with what is Forge tools for example - but here there are a reason -
i.e. it exposes the CLI approach.
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?
Yes in the repository, but that does not help our users using multiple versions of the
runtime.
> 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).
okey.
> 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 ...
Yes, it qualifies for a rename since you/we are not the "owner" of that
package/bundle name.
Same reason why springsource adds com.springsource.* to the bundles to not collide plus to
signal that these bundles are something else than the default ones.
Why Eclipse Orbit dont do the same i've never understood but the fact they do that it
means i.e. once they update to org.mockito 1.9 we would have a similar named and versioned
bundle that would be something different (thats bad)
/max