[jbosstools-dev] Teiid Designer and TP

[Max Rydahl Andersen]

>>> So, the teiid-embedded zip archive from sf.net/projects/teiid includes these jars since client devs
>>> / users will be using teiid in a non-eclipse environment, ie. building their own standalone java
>>> app. Thus, teiid have added in these jars to ensure the java classpath is satisfied.
>> 
>> okey - thats fine - if the plugin is considered an "repackaging" of teiid-embedded.zip then it makes sense.
>> 
>> But if you want to create something else where it is osgi compatible then that is not the case.
>> 
> 
> Sorry not sure what you mean as regards 'create something else'?

just to be clear here:

If teiid designer team decides that all the jars within the teiid runtime distribution should be distributed as a set of osgi bundles ('create something else' than just a plugin with a set of jars for the runtime) then the following should be considered:

1) Can these jars actually run/work if loaded within eclipse OSGI ? 

2) Will the bundle names conflict with possible other teams distributing these osgi jars ? Then better prefix them to avoid unwanted collisions (this is similar to you why you should not be releasing your own versino of mockito into the maven repository under the same name as whoever manages the mockito libraries)

3) does it have any benefits ? (i.e. if these jars are best considered closed/local to teiid designer then it might just be much simpler to stay with one jar. but this of course have challenges if/when you need to coexist with other libraries that might include/declare similar packages - i.e. if this teiid jars exports org.jline.* stuff - it would conflict with those who might decide to export org.jline from a real jline library. 

Its all a balance act but some common sense and careful dependency management should be able to allow us to navigate it.

/max