Re: [jbosstools-dev] Extending the AS Server View

> The biggest issue we still got is the isolation of dmr.jar - as far as I can see you are putting dmr.jar into the core plugin. Doesn't this mean that when the core plugin actually calls into our as7 services that this dmr.jar content overshadows the dmr.jar found in as7 plugin ? (this becomes important/critical when we get into the situation we were in during as71 dev time - as70 jars didn't work with as71 jars…this specific issue is solved now but once as8 comes we can't be sure). I'm not aware of all details here but I'd doubt that this so "shadowing" would happen. So far the as service bundle would not expose dmr to the outside world and would only use the dmr within its bundle boundaries. I dont see why the internal implementation within the service bundle should get anything different than it's internal dmr bundle.

> Because of this we (Rob and I) was discussing if it would make more sense to repackage/rename dmr (i.e. with something like jarjar) and provide that as the way to create non-conflicting model node strings ? That for sure eliminates any problem of client jars overshadowing - but of course leaves a problem if as8 changes their dmr syntax….but I think that is unlikely. What can change is the actual operation/subsystem names in as8 but that is possible to abstract out in code much easier than abstracting out client jars. Another less "intrusive" approach was to put the dmr.jar into an org.jboss.tools.as.dmr bundle that exports the dmr.jar api directly - but I guess if having dmr.jar in .core overshadows then having it in an external plugin that clients uses will result in same problem ? I'd definitely opt for the dmr-version/bundle approach. That is what osgi was invented for. If using bundles definied requirements properly things should work perfectly well. I still dont see any potential for shadowing. Or what do I miss?