|Re: [tycho-user] How to reference/exclude OSGi dependencies specified by MANIFEST|
Hi Christoph,while mailing lists tend to drive interesting discussions, specific questions are sometimes lost on the way. Therefore, please allow me to add a link to stackoverflow regarding the original Tycho question: https://stackoverflow.com/questions/64502221/can-you-reference-osgi-dependencies-resolved-by-tycho-by-groupid-artifactid-and Anyone able to answer the topic of this thread should probably go there to answer it.
Getting back to your proposal, I need to admit I never touched the OSGi framework (apart from using it implicitly via Eclipse), so far. So let me get this right.
- create a product that contains your plugin and its dependencies so it can be build automatically by tycho as a standalone applicationI guess, you are not talking about creation of an "Eclipse product" but merely about a compilation unit. I am sorry to be pedantic here but in an Eclipse context I started to get paranoid about specific terms (like product). My project is an Eclipse plugin and Tycho fetches all dependencies from the MANIFEST. The maven configuration builds all artifacts of the project independently from the CLI tool and independently from Eclipse. So I guess, the first point on your list is fulfilled?
- you can now write a small connector-code for the cli that uses the product output to start a private OSGi Framework inside the CLI process, hand data over to it and after work is done shut the framework down again.If I understand it right you are proposing to add OSGi functionality to the CLI tool. So the OSGi framework would be started from within the CLI tool and my own project would be provided as a bundle and loaded by that framework. Unfortunately, I'd not like to touch the code of the CLI tool. It has a rather complicated build process I do not fully understand and chances are high that I might break something and spend a lot of time I don't really have. Assuming I still would get there, what would be the implications for the overlapping dependency problem? I guess, as I would not have to put dependencies of my project onto the classpath, the CLI tool would only use its own dependency implementations it was compiled with. The dependencies of my project would be managed by OSGi (and a separate classloader) and just used in the context of my projects files, right? I wonder how both parts would work together, then. What about the common API shared by CLI tool and my project? Wouldn't there be two instances of the API?
- start the framework and fetch a service to interact with the "inside-code"I am not sure what you mean by "fetch a service" and what "inside-code" refers to.
Best regards, Stefan On 20.10.2020 14:12, Christoph Läubrich wrote:
Hi John,even though its a bit hard to guess whats really going on I'll try to give some suggestions/thoughts:> I do not have control of the build of the command line tool. Also, it > should be possible to build my own project independently, anyway. I would suggest then from what I have understand the following:- create a product that contains your plugin and its dependencies so it can be build automatically by tycho as a standalone application - you can now write a small connector-code for the cli that uses the product output to start a private OSGi Framework inside the CLI process, hand data over to it and after work is done shut the framework down again.Even though it sounds hard at a first glance it is not that complicated and OSGi is especially made for such use-case. If you product does not involve any special things it boild down to these steps:- get access to the OSGi-Frameworkfactory (that's the only dependency required in the global class-path)- init the framework with basic properties (manly instance/user areas)- install all bundles from your exported product and mark them for start as required - start the framework and fetch a service to interact with the "inside-code"- after that shut down the framework and clear all temporary areas Am 20.10.20 um 13:58 schrieb S. John:Hi everybody, I am coming up with a probably unusual use case. *Context and problem:*I have plugin project which will not be used directly as an Eclipse plugin. Instead, the project is used to manage and bundle content which I intend to feed to a command line tool. To correctly setup the content, however, Eclipse is needed: configuration files need to be specified using an Xtext DSL, they contain executable Java code implementing the API of an Eclipse plugin and EMF models need to be provided.Unfortunately, the dependencies of the command line tool and the project partly overlap. Both reference parts of EMF. Both reference the plugin offering the configuration DSL and also the API implemented by the files in my project. But in my project there are also additional OSGi dependencies which are not already present in the command line tool.The command line tool executes the code provided by my project. Therefore, I need to put any additional dependencies on the classpath when executing the command line tool. My approach so far is, to use maven-dependency-plugin to copy all dependencies of my project (found by Tycho in the MANIFEST) to a folder and put that folder on the classpath. For some of the overlapping dependencies, however, this causes problems. It's also generally not the best idea to have the same classes multiple times on the class path.I do not have control of the build of the command line tool. Also, it should be possible to build my own project independently, anyway.*Tycho question part:*One way of getting rid of duplicates could be to explicitly specify which of the dependencies of my project I want to copy with maven-dependency-plugin. But is there even a way to reference OSGi dependencies discovered by Tycho? I don't know what groupIds, artifactIds and versions Tycho uses for them.Some of the dependencies are merely necessary for working with the project inside the Eclipse environment (the Xtext DSL for example). They are not needed at compile time. Is there a way to tell Tycho in advance to ignore specific OSGi dependencies mentioned in the MANIFEST? That would also speed up the process of resolving dependencies.*General question:*Any suggestions on how to improve the situation are also welcome. I realize that the whole setup is rather brittle. In a perfect world, the command line tool would probably have an OSGi-based plugin system itself and I could just feed in my own project. Or I would have to combine the build process of the command line tool and my own project. Any good alternatives?Best regards, Stefan John _______________________________________________ tycho-user mailing list tycho-user@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-user_______________________________________________ tycho-user mailing list tycho-user@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-user
Back to the top