[jbosstools-dev] Teiid Designer and TP

[phantomjinx]

On 10/08/2012 01:42 PM, Max Rydahl Andersen wrote:
>>>
>>>> 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.
>>>
>>
>> I think clarification of the history of the dependencies is required.
>>
>> 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.

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.

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

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

PGR