[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'?
> 
> 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?

> 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)

>>> 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.

>> 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