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