Extending the maven dependency support in bnd 4.2.0.

[Michael Lipp]

Hi,

I like the generation of maven dependencies with "-pom" in bnd 4.2.1. It's only with this feature that the approach to managing repositories as described here makes sense.

However, the approach is insufficient if you want to do your publications with gradle instead of bnd, because the dependency information is not "fed back" to gradle. I've succeeded in getting the information back by extracting and merging. But this is a bit awkward.

I think the best approach (if possible) would be to configure the compile configuration in gradle "properly". I.e. instead of setting the classpath dependencies to the resolved files, use dependencies on the maven coordinates when possible (should be possible for everything in the classpath that currently already triggers the generation of a dependency in the pom).

Second best would be to somehow enable the access to the dependency information using the bndproject's API. Thus it would at least not be necessary to extract this information from the generated jar when merging it in the gradle script.

 -  Michael Lipp

[BJ Hargrave]

On Sun, Mar 10, 2019 at 10:27 AM Michael Lipp <m...@mnl.de> wrote:
>
> Hi,
>
> I like the generation of maven dependencies with "-pom" in bnd 4.2.1. It's only with this feature that the approach to managing repositories as described here makes sense.
>
> However, the approach is insufficient if you want to do your publications with gradle instead of bnd, because the dependency information is not "fed back" to gradle. I've succeeded in getting the information back by extracting and merging. But this is a bit awkward.

If you want to use gradle publication, gradle makes the pom.

>
> I think the best approach (if possible) would be to configure the compile configuration in gradle "properly". I.e. instead of setting the classpath dependencies to the resolved files, use dependencies on the maven coordinates when possible (should be possible for everything in the classpath that currently already triggers the generation of a dependency in the pom).

There are not known maven coordinates for Bnd to pass to gradle. (This
is assuming Bnd Workspace model builds.) Bnd gets the classpath from
`-buildpath` in the bnd file which are bsn/version tuples that are
resolved by Bnd repositories into files. It does not make sense to try
and then back that into maven coordinates for gradle since you must
also configure repositories into gradle and Bnd repositories are not
necessarily maven shaped repositories.

>
> Second best would be to somehow enable the access to the dependency information using the bndproject's API. Thus it would at least not be necessary to extract this information from the generated jar when merging it in the gradle script.

At the Bnd API level, the artifacts are identified by bsn/version
tuples and are necessarily mapable onto maven coordinates in a maven
shaped repository.

If you want to use gradle publication to publish, I would suggest you
use a non-Bnd workspace build.

>
> - Michael Lipp
>
> --
> You received this message because you are subscribed to the Google Groups "bndtools-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--

BJ