Hi Robert In IntelliJ components are not managed by an OSGi container and so the extension of the Eclipse’s Plugin class and the use of OSGi is troublesome.
I managed to create a Stub so that I can use the code from the project but I discovered other usages of the OSGi bundles like in the ArtifactLocatorImpl and probably more. I just started to delve into the issues with using the Sling IDE backend code and there is probably more. For now I can proceed but later we should adjust to a common codebase. I will create a JIRA ticket to keep track of it tomorrow. - Andy > On May 4, 2015, at 3:47 AM, Robert Munteanu <[email protected]> wrote: > > Hi Andy, > > On Tue, 2015-04-28 at 09:02 -0700, Andreas Schaefer Sr. wrote: >> Hi >> >> Most of the backend code inside the tooling project (api, impl >> -resources etc) do not depend on Eclipse with the sole exception of >> impl-vlt which use the Eclipse Plugin class inside the Activator and >> uses the Activator’s getLogger() to obtain the logger inside that >> module. >> >> IntelliJ does not use an OSGi container and even though I could stub >> the Eclipse Plugin class it does not seem right. >> >> Can we split that module into 2 parts where one only contains the >> backend code and the second would contain the Eclipse Plugin service >> code and configuration? >> >> The only sticky issue I see is the call inside classes like >> VltRepository to obtain the Plugin Logger: >> Activator.getDefault().getPluginLogger(). One solution would be to >> create another class like PluginLoggerProvider that has a static >> method like getInstance() which has a setter and getter method for >> the Plugin Logger. >> >> Cheers - Andy > > Yup, mostly likely we need an indirection for obtaining the > PluginLogger. Can you file a JIRA issue for this? > > And just to be sure, from your point of view it's fine that the > Activator exists, it's just the calls to Activator.getDefault() that > are troublesome, right? > > Thanks, > > Robert >
