[
https://issues.apache.org/jira/browse/FELIX-5501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolas Falco updated FELIX-5501:
---------------------------------
Description:
Looking the code (DependencyEmbedder#processDependencies) seems that pom
reduction is not performed when embedding is marked as inline.
Let me explain with use cases.
*Use case 1 (inline)*
I would embed a third party (for example commons-io) dependency inline into my
project P1 means that all commons-io classes are placed into the P1.jar.
Classes are visible throught export package manifest header in a OSGi
environment and to the compiler at compile time (javac).
When I build with maven a project P2 that has P1 as dependency, maven lookup
also P1 dependencies, so in the classpath I have (P1 + commons-io) classes from
P1 jar and commons-io classes again from commons-io jar. _Duplicate classes in
classpath_.
I think that this is the use case that more benefits from pom reduction.
*Use case 2 (not inline)*
I would embed a third party (for example commons-lang) dependency into my
project P1 as jar in a _lib/_ folder that means commons-lang.jar is placed as
nested jar of the P1.jar and it is added to Bundle-Classpath manifest header.
Classes are visible throught export package manifest header in a OSGi
environment but *NO* to the compiler at compile time (javac) because it's a jar
into jar.
When I build with maven a project P2 that has P1 as dependency, maven looks
also for P1 dependencies (empty because stripped by reduction), so I have in
the classpath only P1 classes from P1 jar and no commons-lang classes so build
fails.
So I think that this is the use case that have should no benefit of pom
reduction.
Seems the actual behaviour is reversed or at least should be performed also in
inline use case
was:
Looking the code seems that reduction is not done if embed is marked inline.
Let me explain with use cases.
*Use case 1*
I would embed a third party (for example commons-io) dependency inline into my
project P1 means that all commons-io classes are placed into the P1.jar.
They are visible throught export package manifest header in a OSGi environment
and to the compiler at compile time (javac).
When I build with maven a project P2 that has P1 as dependency, maven looks
also for P1 dependencies, so I have in the classpath (P1 + commons-io) classes
from P1 jar and commons-io classes again from commons-io jar. Similar problem
on copy-dependency-plugin.
I think that this is the use case that have more benefit of pom reduction.
*Use case 2*
I would embed a third party (for example commons-lang) dependency into my
project P1 as jar into _lib/_ folder, means that commons-lang.jar is placed
into lib folder of the P1.jar and it's added to Bundle-Classpath manifest
header.
They are visible throught export package manifest header in a OSGi environment
but *NO* to the compiler at compile time (javac).
When I build with maven a project P2 that has P1 as dependency, maven looks
also for P1 dependencies (empty because stripped by reduction), so I have in
the classpath onyl P1 classes from P1 jar and no commons-lang classes so build
will break.
So I think that this is the use case that have should no benefit of pom
reduction.
The actual behaviour is reversed
> Pom dependency are not reduced when embedding is inline
> -------------------------------------------------------
>
> Key: FELIX-5501
> URL: https://issues.apache.org/jira/browse/FELIX-5501
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-3.2.0
> Environment: Maven 3.3.9
> Windows OS
> Reporter: Nikolas Falco
>
> Looking the code (DependencyEmbedder#processDependencies) seems that pom
> reduction is not performed when embedding is marked as inline.
> Let me explain with use cases.
> *Use case 1 (inline)*
> I would embed a third party (for example commons-io) dependency inline into
> my project P1 means that all commons-io classes are placed into the P1.jar.
> Classes are visible throught export package manifest header in a OSGi
> environment and to the compiler at compile time (javac).
> When I build with maven a project P2 that has P1 as dependency, maven lookup
> also P1 dependencies, so in the classpath I have (P1 + commons-io) classes
> from P1 jar and commons-io classes again from commons-io jar. _Duplicate
> classes in classpath_.
> I think that this is the use case that more benefits from pom reduction.
> *Use case 2 (not inline)*
> I would embed a third party (for example commons-lang) dependency into my
> project P1 as jar in a _lib/_ folder that means commons-lang.jar is placed as
> nested jar of the P1.jar and it is added to Bundle-Classpath manifest header.
> Classes are visible throught export package manifest header in a OSGi
> environment but *NO* to the compiler at compile time (javac) because it's a
> jar into jar.
> When I build with maven a project P2 that has P1 as dependency, maven looks
> also for P1 dependencies (empty because stripped by reduction), so I have in
> the classpath only P1 classes from P1 jar and no commons-lang classes so
> build fails.
> So I think that this is the use case that have should no benefit of pom
> reduction.
> Seems the actual behaviour is reversed or at least should be performed also
> in inline use case
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
