[ https://issues.jboss.org/browse/JBIDE-18678?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18678: ------------------------------------- There's another possibility, but it's a bit of a workaround. We could have 3 plugins: 1) org.jboss.tools.usage 2) org.jboss.tools.usage.api 3) org.jboss.tools.usage.impl Plugin 1) would be practically empty, and have two hard dependencies, pulling in both the api and the impl Plugin 2) Could be used by plugins who want to migrate to JUST api. So in this case, - astools/server for example would still depend on org.jboss.tools.usage, which pulls in both api and impl - cordova / browser sim plugins could make the following changes: 1) depend only on api 2) Update feature.xml to pull in the impl In this way, our projects can slowly migrate away from a dependency on o.j.t.usage (empty stub with 2 deps) to just the api plugin, and, at the same time, update their feature xml's to drag in the impl. Package names would not need to be changed for the api, and the o.j.t.usage plugin could simply re-export the api only, but still depend on the impl. This may be a bit confusing, bc to find an api named "org.jboss.tools.usage.SomeClass', they would have to browse to the api plugin. It wouldn't be intuitive, but it *is* a possible solution. Aside from having to know where to find the code, I don't see any problem with this idea. -- This message was sent by Atlassian JIRA (v6.3.11#6341)