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

[Roland Grunberg <rgrunber@xxxxxxxxxx>]

On Thu, 2020-08-13 at 18:23 +0100, Sina Madani wrote:
> 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.

You can manipulate the metadata as needed in the osgi.bnd file. Using
the '!' notation, and can exclude any dependencies from Import-Package, 
or remove it completely. The risk with this is that the project itself
states (via the pom) it has other dependencies. Neglecting to include
them risks various runtime errors 


> 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 think it would take much to automate this since EBR can
generate bundle recipes and the transitive list of dependencies can be
fed to it. Each osgi.bnd file could use Import-Package: * , though this
is generally not ideal because you end up having to verify that the
generated metadata is correct anyways. The problem is there's going to
be cases for which you need to manually adjust things.


> 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.

EBR simply downloads the artifact (containing the .class files) and
generates a manifest (as defined by the osgi.bnd file) to be used with
it. It turns the java library into an OSGi bundle based on some
processing of the library. It doesn't verify that the bundle will
resolve successfully given its metadata or that it will actually work.
It simply generates it.

The aggregation feature combines all the bundles under one feature.
This actually attempts to resolve metadata of all bundles and will fail
if some dependency cannot be located. This often implies some issue
with the metadata generated.

The later phases of the build (that aren't done for gerrit) simply
aggregate all the content into a format that is consumable (eg. an
update site) and do some reporting.

--
Roland Grunberg