Re: [jbosstools-dev] Teiid Designer and TP

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