[jira] [Updated] (FELIX-5501) Pom dependency are not reduced when embedding is inline

["Nikolas Falco (JIRA)" <ji...@apache.org>]

     [ 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)