Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] How to reference/exclude OSGi dependencies specified by MANIFEST

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
To unsubscribe from this list, visit

Back to the top