static libraries and transitive dependency

[GregDomjan]

For a while now I've been trying to work out the best way to deal with static libraries and transitive dependency.

I was thinking at one stage that the static dependencies should be marked with <optional> but turns out that when including static lib as dependency

• in another static might be true , but not really useful
• in a shared lib or executable isn't useful at all.

Similarly another option might be to mark static libs as <scope>provided when including static lib as dependency only in a shared lib or executable. While it is useful this leaves the dependency information visible in deployed pom which may not be necessary or desirable. It's not really expected to be provided at runtime.

I've noticed more recently the way maven-shade-plugin works in merging a dependency with the final output and removing that dependency from the dependency list in the final pom.
Seems to me a similar description of merging a static archive with final shared or executable binary.

Would something like shade manipulation be appropriate in prepare/package step of nar to remove static libs from the deployed pom, perhaps with some configuration to include/exclude static libs?

[ctrueden]

Manipulating the POM a la shade, while complex, does make sense here in my mind.

Personally, I have very little stake in how static libs work with NAR. I prefer dynamic libs in basically every case, since they map better to the Maven paradigm.

Anyway, this sounds like a fair amount of work. But if you need it, go for it.

[00datman]

Along the lines of static library dependencies, I've started wondering if NAR should be using the whole archive options, to make things work more smoothly / Maven-like? Every time I have to reshuffle the order of my dependencies for a linker error, it just frankly irritates me...

Food for thought, if nothing else. Also letting you know that others also use static libs :-D