ShrinkWrap
  1. ShrinkWrap
  2. SHRINKWRAP-243

Dependencies does not find remote repositories set in settings.xml

    Details

    • Similar Issues:
      Show 10 results 

      Description

      Using activeDefault profiles in settings.xml does not seem to be included in the remote repository resolution in Dependencies.

      e.g.

      .m2/settings.xml

      <profiles>
      <profile>
      <activation>
      <activeByDefault>true</activeByDefault>
      </activation>
      <repositories>
      <repository>
      <id>jboss-public-repository-group</id>
      <name>JBoss Public Repository Group</name>
      <url>http://repository.jboss.org/nexus/content/groups/public/</url>
      <layout>default</layout>
      <releases>
      <enabled>true</enabled>
      <updatePolicy>never</updatePolicy>
      </releases>
      <snapshots>
      <enabled>true</enabled>
      <updatePolicy>never</updatePolicy>
      </snapshots>
      </repository>
      </repositories>
      <pluginRepositories>
      <pluginRepository>
      <id>jboss-public-repository-group</id>
      <name>JBoss Public Repository Group</name>
      <url>http://repository.jboss.org/nexus/content/groups/public/</url>
      <releases>
      <enabled>true</enabled>
      </releases>
      <snapshots>
      <enabled>true</enabled>
      </snapshots>
      </pluginRepository>
      </pluginRepositories>
      </profile>

      </profiles>

        Activity

        Hide
        Karel Piwko
        added a comment -

        Fixed as https://github.com/kpiwko/shrinkwrap/commit/180185a0ca06a4ec53aae521d3a2a00e0798b6b0

        Tracks active profiles by checking both <activation><activeByDefault>true</activeByDefault></activation> flag
        and profiles enumerated in <activeProfiles> in settings.xml

        Show
        Karel Piwko
        added a comment - Fixed as https://github.com/kpiwko/shrinkwrap/commit/180185a0ca06a4ec53aae521d3a2a00e0798b6b0 Tracks active profiles by checking both <activation><activeByDefault>true</activeByDefault></activation> flag and profiles enumerated in <activeProfiles> in settings.xml
        Hide
        Andrew Rubinger
        added a comment -

        Affects and fix versions are incorrect here, guys. Everything is an open issue until pushed into upstream/master, else we'll never keep track of which issues made it into which releases. If this is completed, let's mark where in a comment (as we've done here). We can then set a "fixVersion" when it's in master, and mark resolved then.

        Show
        Andrew Rubinger
        added a comment - Affects and fix versions are incorrect here, guys. Everything is an open issue until pushed into upstream/master, else we'll never keep track of which issues made it into which releases. If this is completed, let's mark where in a comment (as we've done here). We can then set a "fixVersion" when it's in master, and mark resolved then.
        Hide
        Karel Piwko
        added a comment -

        Merged into upstream

        Show
        Karel Piwko
        added a comment - Merged into upstream
        Hide
        jay shaughnessy
        added a comment -

        has the fix version been corrected? I have resolver 1.0.0-beta-7 in my M2 repo yet I seem to be hit by this. Or is perhpas because we encounter the problem only on jenkins runs, which has additional proxy situation described here:

        http://stackoverflow.com/questions/6291146/arquillian-shrinkwrap-mavendependencyresolver-behind-proxy

        To get around this I was able to add resolver.goOffline() at the problem point, because at that point I am assured of the dep being in the local repo. This seems to work.

        Show
        jay shaughnessy
        added a comment - has the fix version been corrected? I have resolver 1.0.0-beta-7 in my M2 repo yet I seem to be hit by this. Or is perhpas because we encounter the problem only on jenkins runs, which has additional proxy situation described here: http://stackoverflow.com/questions/6291146/arquillian-shrinkwrap-mavendependencyresolver-behind-proxy To get around this I was able to add resolver.goOffline() at the problem point, because at that point I am assured of the dep being in the local repo. This seems to work.
        Hide
        Karel Piwko
        added a comment -

        Jay,

        I'm not able to find the commit in the repository, we migrated the project to standalone repo so maybe it was merged. However, it is possible that you hit another error related to settings.xml parsing, such as <mirror> support or activation based on file, etc. added later on. Can you provided more details about your test/settings.xml?

        Version 1.0.0-X as well as 1.1.0-X is obsolete. Can you migrate to 2.0.0-alpha-7 (https://community.jboss.org/wiki/HowToIAddMavenArtifactsToMyShrinkWrapArchives) and see if error still occurs there and if so, file a new jira with more details in SHRINKRES project?

        Show
        Karel Piwko
        added a comment - Jay, I'm not able to find the commit in the repository, we migrated the project to standalone repo so maybe it was merged. However, it is possible that you hit another error related to settings.xml parsing, such as <mirror> support or activation based on file, etc. added later on. Can you provided more details about your test/settings.xml? Version 1.0.0-X as well as 1.1.0-X is obsolete. Can you migrate to 2.0.0-alpha-7 ( https://community.jboss.org/wiki/HowToIAddMavenArtifactsToMyShrinkWrapArchives ) and see if error still occurs there and if so, file a new jira with more details in SHRINKRES project?
        Hide
        jay shaughnessy
        added a comment -

        Karel,

        I upgraded our version to the Arquillian 1.0.3.Final bom, and the problem did not go away. I thought this pulled in the 2.0.0.alpha-7 version of the resolver but looking more closely at the pom, I don't think it does. I will have to play some dependency games in my pom to use the updated resolver. I'll let you know the result...

        Show
        jay shaughnessy
        added a comment - Karel, I upgraded our version to the Arquillian 1.0.3.Final bom, and the problem did not go away. I thought this pulled in the 2.0.0.alpha-7 version of the resolver but looking more closely at the pom, I don't think it does. I will have to play some dependency games in my pom to use the updated resolver. I'll let you know the result...

          People

          • Assignee:
            Karel Piwko
            Reporter:
            Aslak Knutsen
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: