Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Bug with automated bundle creation process?

Hi Gunnar and Roland,

 

Thank you for the prompt response and the information. It appears the version in Epsilon contains only a subset and none of the dependencies, and it’s working fine for our needs. I assumed it was a simple library to add but clearly I was wrong. I suppose Orbit isn’t a good for for this, since presumably I can’t just add “our” com.google.gdata_1.47.1 (I didn’t add that library to Epsilon, so I have no idea what specific parts of it are required) without spending days creating OSGi dependencies using EBR and getting them approved if they’re not already on ClearlyDefined.

 

I use mvnrepository.com to find Maven plugins and that site also lists compile-time dependencies, but they’re clearly incomplete since the errors I’m getting and the dependency tree output of Maven (see Roland’s email) are different from what the build failure is telling me.

 

I think I’ll abandon this change given that EBR can’t automate transitive dependencies. I’m wondering if in the future this will be possible? Because for me the issue is that following the instructions on the README.md works fine, and I get the false impression that just because mvn -U clean package -DdirtyWorkingTree=warning is successful, that it’s all working.

I don’t understand what EBR actually does and why the local build succeeds but the aggregationfeature (I.e. the CI build) fails. I’m guessing the actually OSGi bundle isn’t built (as per instructions in the README.md) and so I’m left wondering why we need that command in the first place given that it doesn’t appear to actually build anything.

 

Thanks,

Sina

 

From: Gunnar Wagenknecht
Sent: 13 August 2020 18:02
To: Orbit Developer discussion
Subject: Re: [orbit-dev] Bug with automated bundle creation process?

 

Hi Sina,

 

Are you using EBR to create the bundle? It should print out a list of dependencies that are also needed as OSGi bundles. Did you see that output?

 

It's the price developers need to pay when "using" a library. Maven makes it easy and hides all the transitives dependencies but OSGi is much more explicit about them. But I'm wondering why this is the first time you are running into this. Didn't you discover all those dependencies before when putting the library into the Epsilon repo?

 

-Gunnar

 

--

Gunnar Wagenknecht

gunnar@xxxxxxxxxxxxxxx, http://guw.io/

 

 

> On Aug 13, 2020, at 17:13, Sina Madani <sinadoom@xxxxxxxxxxxxxx> wrote:

>

> Hi again,

> It seems every library I want to add that isn’t Apache Commons has this issue. I spent a whole afternoon manually chasing dependencies for com.google.gdata and ended up with the mess in [1] and still the build is failing. I’m wondering if it’s supposed to be this difficult, or if I’m just trying to put extremely complex libraries on Orbit? For example, the library we have in our local repo is in [2] and all I wanted to do is put it on Orbit (so we can delete it from our repo) but I can’t figure out why it’s such a pain, and why I have to manually chase down every single transitive dependency. Any further clarification on the process would be appreciated!

> Thanks,

> Sina Madani

> [1] https://git.eclipse.org/r/c/orbit/orbit-recipes/+/167664

> [2] https://git.eclipse.org/c/epsilon/org.eclipse.epsilon.git/tree/plugins/com.google.gdata_1.47.1

> From: Roland Grunberg

> Sent: 07 August 2020 16:14

> To: Orbit Developer discussion

> Subject: Re: [orbit-dev] Bug with automated bundle creation process?

> On Fri, 2020-08-07 at 15:42 +0100, Sina Madani wrote:

> > Hi,

> > 

> > I’ve been trying to add some bundles recently and I’ve noticed the

> > build fails because of some supposedly missing dependency. However

> > when doing mvn dependency:tree and looking on the project websites,

> > mvnrepository.com etc. I find that there are no dependencies, or at

> > least they must be included already. The mvn -U clean package

> > -DdirtyWorkingTree=warning succeeds, but when building the

> > aggregationfeature it fails.

> > 

> > For example, I’m adding PlantUML which supposedly has no

> > dependencies, but the build fails with the message: 

> > “Missing requirement: net.sourceforge.plantuml 1.2019.0.v20200807-

> > 1315 requires 'java.package; ch.braincell.viz 0.0.0' but it could not

> > be found”

> > 

> > I suspect there must be some setting that ignores files which don’t

> > contain the same package name as the bundle? Any clarification would

> > be appreciated.

> The package ends up in the set of Import-Packages of the generated

> bundle and if nothing else provides it, the build will fail.

> In this case, the build seems to actually be catching reflection

> usage :

> net/sourceforge/plantuml/vizjs/VizJsEngine.java:                       final Class classVizJS = Class.forName("ch.braincell.viz.VizJS");

> net/sourceforge/plantuml/vizjs/VizJsEngine.java:              final Class classVizJS = Class.forName("ch.braincell.viz.VizJS");

> If you're sure this usage would never come up (eg. optional) then you

> can add something like '!ch.braincell.viz' to the Import-Package

> statement. Otherwise, you'll need to contribute this bundle as well.

> Cheers,

> --

> Roland Grunberg

> _______________________________________________

> orbit-dev mailing list

> orbit-dev@xxxxxxxxxxx

> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orbit-dev

> _______________________________________________

> orbit-dev mailing list

> orbit-dev@xxxxxxxxxxx

> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orbit-dev

 

_______________________________________________

orbit-dev mailing list

orbit-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orbit-dev

 


Back to the top