Pax Construct
  1. Pax Construct
  2. PAXCONSTRUCT-137

getArtifacts method in provision does not work the same for maven3

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.5
    • Fix Version/s: 1.6
    • Component/s: maven-pax-plugin
    • Labels:
      None

      Description

      While the getArtifacts method returned only the "direct" artifacts in maven2 now also the childs are returned which leads to a VERY broken behavior

        Activity

        Andreas Pieber created issue -
        mcculls made changes -
        Field Original Value New Value
        Assignee mcculls [ mcculls ]
        Hide
        mcculls added a comment -

        You don't describe what the broken behaviour is or provide an example project, which makes it hard to fix.

        Note "MavenProject.getArtifacts" should always returns both direct and transitive dependencies both in Maven 2 and Maven 3, but there may be a difference between them wrt. which dependencies are resolved at the time of provisioning. This is because Maven 3 honours the @requiresDependencyResolution mojo setting and makes sure the resolved set matches the request, whereas with Maven 2 the visible set of resolved dependencies could vary depending on what plugins ran before your plugin.

        Regardless of the difference between Maven 2 and Maven 3, there was an explicit request to look for bundles in transitive dependencies https://ops4j1.jira.com/browse/PAXCONSTRUCT-123 which means the plugin is currently "working as designed".

        Whether we should provide a switch to only look at direct (non-transitive) dependencies is of course another question...

        Show
        mcculls added a comment - You don't describe what the broken behaviour is or provide an example project, which makes it hard to fix. Note "MavenProject.getArtifacts" should always returns both direct and transitive dependencies both in Maven 2 and Maven 3, but there may be a difference between them wrt. which dependencies are resolved at the time of provisioning. This is because Maven 3 honours the @requiresDependencyResolution mojo setting and makes sure the resolved set matches the request, whereas with Maven 2 the visible set of resolved dependencies could vary depending on what plugins ran before your plugin. Regardless of the difference between Maven 2 and Maven 3, there was an explicit request to look for bundles in transitive dependencies https://ops4j1.jira.com/browse/PAXCONSTRUCT-123 which means the plugin is currently "working as designed". Whether we should provide a switch to only look at direct (non-transitive) dependencies is of course another question...
        Hide
        Andreas Pieber added a comment -

        Hey Stuart,

        Thank's for the fast response and sorry for the missing example. The problem is quite simple:

        1. checkout the following version of pax-wicket
        2. mvn clena install
        3. and add in samples/pom.xml <noDependencies>true</> setting for pax-maven-plugin
        4. mvn pax:provision

        https://github.com/ops4j/org.ops4j.pax.wicket/commit/6221f52c38b88c70e65b547cf8ad8463e0873b47

        This will run felix with all deps (although no-dep is set); then...

        1. checkout the following commit (nothing changed but downgrade to 1.4 of pax-construct)
        2. remove runner folder
        3. run pax:provision again

        https://github.com/ops4j/org.ops4j.pax.wicket/commit/b9de1d96a567f800ed4beed26d23d9b16caab07e

        Only the direct deps are resolved.

        Maybe I missed something but since all deps are resolved although the noDependencies flag is used this sounds rather like a bug to me.

        WDYT?

        Show
        Andreas Pieber added a comment - Hey Stuart, Thank's for the fast response and sorry for the missing example. The problem is quite simple: checkout the following version of pax-wicket mvn clena install and add in samples/pom.xml <noDependencies>true</> setting for pax-maven-plugin mvn pax:provision https://github.com/ops4j/org.ops4j.pax.wicket/commit/6221f52c38b88c70e65b547cf8ad8463e0873b47 This will run felix with all deps (although no-dep is set); then... checkout the following commit (nothing changed but downgrade to 1.4 of pax-construct) remove runner folder run pax:provision again https://github.com/ops4j/org.ops4j.pax.wicket/commit/b9de1d96a567f800ed4beed26d23d9b16caab07e Only the direct deps are resolved. Maybe I missed something but since all deps are resolved although the noDependencies flag is used this sounds rather like a bug to me. WDYT?

          People

          • Assignee:
            Unassigned
            Reporter:
            Andreas Pieber
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development