[jbosstools-dev] Teiid Designer and TP

[phantomjinx]

On 10/08/2012 04:08 PM, Max Rydahl Andersen wrote:
>>>> 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'?
>>
>> Essentially, TD is about providing a graphical client for deploying stuff to a teiid server. So I
>> want to
>> a) create a teiid client plugin that does this
>> b) locate the plugin separately from the TD codebase since it is part of TD's platform rather than
>> working code
>> c) automate the assemblage and provision of the plugin so developers can easily update to the next
>> version without needing to commit it to the codebase.
> 
> Yes, for the teiid runtime parts I believe this fits best the model we currently got on Forge.
> 
> see http://anonsvn.jboss.org/repos/jbosstools/trunk/forge/plugins/org.jboss.tools.forge.runtime and its pom.xml for this.
> 
> The remainder plugins seem to be different "beasts", i.e. the mockito jar is not for the actual release site, but just for tests, correct?
> 

Right. mockito is just for tests but others such as wsdl4j are used at runtime.

>> So if 3rd-party teiid libraries like jline need to be bundle with the teiid plugin then I'm good
>> with that.
>>
>>>> Looking at the source teiid-admin.jar requires jboss-as-cli.
>>>
>>> but teiid-admin.jar is for running some client app on the shell - not needed by the tools or ?
>>>
>>
>> So looking at how jboss-as-cli is used. It is required by the teiid AdminFactory class. This is
>> responsible (unsurprisingly) for creating an implementation of their Admin interface. This is
>> responsible for all command usecases, eg. deploy(VDB), undeploy(VDB), getDeployedVDB() etc... This
>> is the only class that it is used in (essential class tho!) and it may be the case that this
>> dependency could be modified since these are the classes it uses:
>>
>> import org.jboss.as.cli.Util;
>> import org.jboss.as.cli.operation.OperationFormatException;
>> import org.jboss.as.cli.operation.impl.DefaultOperationRequestAddress;
>> import org.jboss.as.cli.operation.impl.DefaultOperationRequestBuilder;
>> import org.jboss.as.controller.client.ModelControllerClient;
>>
>> Anyway, that would require an issue be raised against teiid. At this point, it appears necessary.
> 
> so it uses the CLI utility code - not the actual jline stuff (at least that is how it seems)
> 

hmmm ... cannot find any references to jline in the 8.2.Alpha2 codebase so it may be unnecessary now
in teiid 8.2. Will check further on this. Either way, I understand that such a library would be
essential to the internal workings of the plugin but should not have its packages exported.

>>>> If jline.jar is in the TP somewhere then it can be changed to a plugin dependency as well.
>>>
>>> I think you are missing my point ;) We deliberately avoid exposing runtime stuff as osgi jars because
>>>
>>> A) the jars often don't work well in osgi land or even an eclipse plugin world (i.e. anything that loads native code, i.e. jline.jar or custom classes i.e. logging/spring/cdi/hibernate etc.)
>>>
>>> B) having tools plugins depend on runtime jars hardens their dependency on runtime versions making it very userunfriendly (i.e. users dont normally need to install a new and old IDE to work with Java 6 and 7 at the same time).
>>>
>>
>> Have been ignorant of this up until now so learning slowly ;)
>>
>> Totally understand what you are saying and finding it difficult to come up with a solution to TD's
>> problem as a consequence :)
> 
> yeah I know - Its been a long standing request Teiid Designer would stop being so version dependent - I was hoping Teiid 8 would at least
> made *some* improvements on this.
> 

Will need to explore this further with the TD team.

>>> It might be the case for teiid that this cannot be avoided but then Teiid needs to be packaged/distributed in a way that allows easy installation and uninstallation to switch between these versions IMO.
>>
>> Sounds clunky ... and I have learnt that if its clunky / bodge / hack then something underlying
>> needs changing to make it elegant.
> 
> 
> Yes agreed - but seems Teiid at is core depends on something that enforces this...
> 
> /max
> 

PGR

-- 
Paul Richardson

  * p.g.richardson at phantomjinx.co.uk
  * p.g.richardson at redhat.com
  * pgrichardson at 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