[jbosstools-dev] Teiid Designer and TP

[Rob Stryker]

>> Rationalising the teiid jar dependencies, I have noticed that I can depend the teiid_embedded_query
>> plugin on the following. This removes all jboss.as dependencies except for jboss-as-cli.jar
>> 	* org.jboss.ide.eclipse.as.management.as71
> hmm - that sounds wrong - as.management.as71 are not guaranteed to be available/the correct one to use.
>
This *IS* weird, and I suspect it is not the correct way to do things. 
Almost no plugins should ever depend directly on as.management.as71, and 
by almost, i mean exactly none.

They may require the feature (and plugin) be present, but they should 
have no compile time dependencies against the plugin.

The correct way to do this is to depend on org.jboss.ide.eclipse.as.dmr. 
This is a simple wrapper for the DMR jboss-as logic which allows you to 
build remote management requests.

Unfortunately, due to classloading issues, we can't just give the caller 
a ModelNode reference. Actually we can, right now, but if AS-8 or any 
other version of AS ever requires a new management api (and I am QUITE 
sure they will), this will break 100 different ways.

So, the expected thing you should be doing is to depend on 
org.jboss.ide.eclipse.as.dmr, and do something like the following:

     private String createResourceRequest() {
         ModelNode request = new ModelNode();
         request.get(OP).set(READ_RESOURCE_OPERATION);
         // blah blah blah make more model node request
         return request.toJSONString(true);
     }

Once it's available as a JSON string, you should do the following:

         String resultJSON = JBoss7ManagerUtil.executeWithService(new 
JBoss7ManagerUtil.IServiceAware<String>() {
             public String execute(IJBoss7ManagerService service) throws 
Exception {
                 return service.execute(new 
AS7ManagementDetails(getServer()), createResourceRequest());
             }
         }, getServer());

This will require you to have org.jboss.ide.eclipse.as.core on your 
classpath. The as.core plugin will search for a service interface that 
fits the given version of the server (ie for a while we had two 
different implementers, one for as7 and one for as7.1. Appserver team 
eventually fixed the broken backwards compatability and so the other was 
removed.)

If you guys are doing something that doesn't involve wtp IServer objects 
at all, and can't use the constructor for AS7ManagementDetails, you can 
always fill out the interface in your own way via IAS7ManagementDetails

I'll try to get a wiki page up to demonstrate this, and maybe an example 
plugin if possible.
>>>> However, contained in the current TD codebase are the following wrapped plugins, ie. wrapping
>>>> 3rd-party built/released jars:
>>>>
>>>> 	* net.jcip.annotations 		- jcip-annotations.jar
>>>> 	* net.sf.saxon 			- saxon9he.jar
>>>> 	* org.apache.poi		- poi.jar, poi-scratchpad.jar, poi-contrib.jar
>>>> 	* org.jaxen			- jaxen-core.jar, jaxen-jdom.jar, saxpath.jar
>>>> 	* org.mockito			- com.springsource.org.objensis.jar, mockito-core.jar
>>>> 	* org.wsdl4j			- wsdl4j.jar
>>>> 	* teiid_embedded_query		- commons-cli.jar  	jansi.jar		jline.jar  		staxmapper.jar							
>>>> 					  jboss-as-cli.jar	jta.jar       		teiid-api.jar		teiid-engine.jar
>>>> 					  teiid-client.jar	teiid-admin.jar  	teiid-common-core.jar
>>> How many of these are already in eclipse orbit ?
>> * jcip-annotations.jar					NO
>> * saxon9he.jar						NO
>> * poi.jar, poi-scratchpad.jar, poi-contrib.jar		NO
>> * jaxen-core.jar, jaxen-jdom.jar, saxpath.jar		NO
>> * mockito-core.jar, com.springsource.org.objensis.jar	YES/NO - Version in use is 1.9.1 but version
>> 1.8.4 available. Only recently upgraded to 1.9.1 to use 'latest version' so not an issue to
>> downgrade for the moment
>> * wsdl4j.jar						YES/NO - Version in use is 1.4 but both versions 1.5.1 and 1.6.2 are available
> So question is why wsdl4.jar 1.4 is needed ?
>>> The teiid_embedded_query sounds like something that are very version specific ? Does this
>>> have to be matching the target server still ?
>>>
>> With the release of teiid 8, backward compatibility has been broken so I would envisage a teiid
>> versioned features being included and clients import specific versions of the feature/plugins using
>> eclipse plugin functionality, eg. [8.0.0,9.0.0). Going forward, TD 8.0 will be the first application
>> to use teiid 8 plugins and thus this P2 repository so we can set the rules for use?
> okey - this should probably go to another thread - i.e. how are users of Teiid 7 (maintanence) and Teiid 8 (new development)
> supposed to use the tools.
>
>>> Do I read it right above that teiid_embedded_query is simply wrapping those jars and only exposing limited API ?
>>> i.e. commons-cli.jar, jboss-as-cli.jar does sound like things that easily could come problematic if exposed to rest of the eclipse plugin stack.
>> Correct. See my rationalising commment above for reduction of the jboss-as dependencies. If
>> jboss-as-cli could be offered in a plugin then this need not be included either.
> Really need to understand why we are tying us self to these specific *runtime* jars. We cannot keep doing this blindly.
>
>>>> All of these jars are obtained from external websites, including the teiid jars (sf.net/projects/teiid).
>>>>
>>>> Problem:
>>>>
>>>> Everytime, an update of these jars is required, the new set of jars must be downloaded, included in
>>>> the TD codebase and committed to the TD repository.
>>> Yes, you are basically updating the Target Platform.
> Well no - for an "orbit" style you are adding things that can then be used in  a new version/variation of the target platform, right?
>
>>>> Since we fetch the jbosstools and eclipse plugins from the target platform, it would be advantageous
>>>> if these wrapped-plugins could be broken out into their own repository, ideally with no jars
>>>> actually in the code repository then automatically built and served as features in a P2 repository.
>>>> This P2 repository is then used by TD developers and TD build infrastructure.
>>> Yes - a Teiid targetplatform, optimally one that have these jars unified with the other "ontop" tooling set
>>> so we know these can be installed together.
>>>> For example, with the teiid jars, a new release is uploaded to sf.net by the teiid team, downloaded
>>>> by TD dev, fully wrapped as plugin/plugins and added to the P2 repository.
>>> hmm - do you really put a full unique teiid jar into the teiid plugin release s?
>>>
>> At the moment, yes. It seems that the teiid jars are slowly splitting into constituent components,
>> eg. admin-api, common-core, client, engine, but this seems ongoing.
> yes - but exposing these as first-class osgi bundles have issues:
>
> 1) does these jar obey/allow osgi classloading ?
>
> 2) how does the tools work with multiple versions of them (ie. Teiid 7.x, 8.0 and 8.1?) If just one set available this way its crucial the runtime can actually work with them. (for that other thread)
>
> /max
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev