August 2014 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-146) Encrypted password support forces presence of settings-security.xml

by Rafał Gała (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-146?page=com.atlassian.jira.plu... ] Rafał Gała commented on SHRINKRES-146: -------------------------------------- Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven. For example: <password>{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=}</password> and <password>\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\}</password> is not the same hash. > Encrypted password support forces presence of settings-security.xml > ------------------------------------------------------------------- > > Key: SHRINKRES-146 > URL: https://issues.jboss.org/browse/SHRINKRES-146 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0-beta-4, 2.0.0 > Reporter: Falko M. > Assignee: Andrew Rubinger > > This problem is caused by SHRINKRES-38 "Support encrypted passwords for password protected repositories". > As soon {{MavenSettingsBuilder}} finds passwords in the settings file, it apprently assumes that they are encrypted with the master password which is defined in {{settings-security.xml}}. When the file cannot be found an exception is thrown: > {code} > org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Unable to get security configuration from C:\Users\U115417\.m2\settings-security.xml. Please define path to the settings-security.xml file via -Dorg.apache.maven.security-settings, or put it the the default location defined by Maven. > at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.getMaster(MavenSecurityDispatcher.java:171) > at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.decrypt(MavenSecurityDispatcher.java:96) > at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:92) > at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:60) > at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.decryptPasswords(MavenSettingsBuilder.java:223) > at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildSettings(MavenSettingsBuilder.java:186) > at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildDefaultSettings(MavenSettingsBuilder.java:113) > at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.<init>(MavenWorkingSessionImpl.java:123) > at org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemImpl.<init>(MavenResolverSystemImpl.java:43) > ... 80 more > {code} > This is not correct as passwords can be defined without encryption and in this case no {{settings-security.xml}} file is needed. > As we use server-side hashed passwords (without client-side encryption), this is a deal breaker for our project as you cannot work around this problem by just creating an empty file or a dummy password. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-195) activeProfiles element from settings.xml seems to be ignored, property override not working

by Falko M. (JIRA)

Falko M. created SHRINKRES-195: ---------------------------------- Summary: activeProfiles element from settings.xml seems to be ignored, property override not working Key: SHRINKRES-195 URL: https://issues.jboss.org/browse/SHRINKRES-195 Project: ShrinkWrap Resolvers Issue Type: Bug Security Level: Public (Everyone can see) Components: impl-maven Affects Versions: 2.0.2 Environment: Win7 x64 JDK7u51 Reporter: Falko M. Priority: Minor See: http://maven.apache.org/settings.html#Active_Profiles On the command line (mvn), the element is evaluated as expected and the specified profiles are activated but when I load the very same pom.xml via {{Maven.resolver().offline().loadPomFromFile(...)}}, the respective profiles are ignored, as it seems. I came accross this issue when I wanted to override a property from pom.xml in settings.xml and {{ParsedPomFile.getProperties()}} kept returning the non-overriden value. Notes: - the following in settings.xml *does work*: {noformat} <activation> <activeByDefault>true</activeByDefault> </activation> {noformat} - a new property defined in a settings.xml profile also doesn't show up in {{ParsedPomFile.getProperties()}} which seems to prove that the profile is not actived -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-194) Multi-module gradle project support

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-194?page=com.atlassian.jira.plu... ] Michal Matloka updated SHRINKRES-194: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/resolver/pull/69 After SWR release with given feature I will update the https://github.com/mmatloka/arquillian-gradle-sample to depend on appropriate version. Then the multi-module example will work. SWR tests includes inside also a multi-module gradle project with an appropriate test. > Multi-module gradle project support > ----------------------------------- > > Key: SHRINKRES-194 > URL: https://issues.jboss.org/browse/SHRINKRES-194 > Project: ShrinkWrap Resolvers > Issue Type: Requirement > Security Level: Public(Everyone can see) > Reporter: Michal Matloka > Assignee: Michal Matloka > > Issue from github https://github.com/mmatloka/arquillian-gradle-sample/issues/1: > {quote} > Hi, > I'm very glad for your gradle resolver. However, we have multi project setup in which this code fails with an ArrayIndexOutOfBoundException > {code} > final GradleProject gradleProject = projectConnection.getModel(GradleProject.class); > final File buildDir = new File(projectDir, "build"); > final File libsDir = new File(buildDir, "libs"); > final File result = libsDir.listFiles(new FilenameFilter() { > @Override > public boolean accept(final File dir, final String name) { > return name.startsWith(gradleProject.getName()); > } > })[0]; > {code} > This is imho due to the fact that the gradleProject above holds the multi project but the arquillian tests are contained (and should be contained) in the sub project (*server). There the predicate will never be true and the [0] with end up in an exception. > I think you can either do a deep search to also get the sub project jars or more accurately resolve the project the tests are in. If you need help let me know. > Best, > Maik > {quote} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-194) Multi-module gradle project support

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-194?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-194: ------------------------------------------ It seems that when loading gradle project model for given directory, when given directory is a module of bigger project, then gradle automatically loads a model for the root project instead of the sub-project! > Multi-module gradle project support > ----------------------------------- > > Key: SHRINKRES-194 > URL: https://issues.jboss.org/browse/SHRINKRES-194 > Project: ShrinkWrap Resolvers > Issue Type: Requirement > Security Level: Public(Everyone can see) > Reporter: Michal Matloka > Assignee: Michal Matloka > > Issue from github https://github.com/mmatloka/arquillian-gradle-sample/issues/1: > {quote} > Hi, > I'm very glad for your gradle resolver. However, we have multi project setup in which this code fails with an ArrayIndexOutOfBoundException > {code} > final GradleProject gradleProject = projectConnection.getModel(GradleProject.class); > final File buildDir = new File(projectDir, "build"); > final File libsDir = new File(buildDir, "libs"); > final File result = libsDir.listFiles(new FilenameFilter() { > @Override > public boolean accept(final File dir, final String name) { > return name.startsWith(gradleProject.getName()); > } > })[0]; > {code} > This is imho due to the fact that the gradleProject above holds the multi project but the arquillian tests are contained (and should be contained) in the sub project (*server). There the predicate will never be true and the [0] with end up in an exception. > I think you can either do a deep search to also get the sub project jars or more accurately resolve the project the tests are in. If you need help let me know. > Best, > Maik > {quote} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-194) Multi-module gradle project support

by Michal Matloka (JIRA)

Michal Matloka created SHRINKRES-194: ---------------------------------------- Summary: Multi-module gradle project support Key: SHRINKRES-194 URL: https://issues.jboss.org/browse/SHRINKRES-194 Project: ShrinkWrap Resolvers Issue Type: Requirement Security Level: Public (Everyone can see) Reporter: Michal Matloka Assignee: Michal Matloka Issue from github https://github.com/mmatloka/arquillian-gradle-sample/issues/1: {quote} Hi, I'm very glad for your gradle resolver. However, we have multi project setup in which this code fails with an ArrayIndexOutOfBoundException {code} final GradleProject gradleProject = projectConnection.getModel(GradleProject.class); final File buildDir = new File(projectDir, "build"); final File libsDir = new File(buildDir, "libs"); final File result = libsDir.listFiles(new FilenameFilter() { @Override public boolean accept(final File dir, final String name) { return name.startsWith(gradleProject.getName()); } })[0]; {code} This is imho due to the fact that the gradleProject above holds the multi project but the arquillian tests are contained (and should be contained) in the sub project (*server). There the predicate will never be true and the [0] with end up in an exception. I think you can either do a deep search to also get the sub project jars or more accurately resolve the project the tests are in. If you need help let me know. Best, Maik {quote} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-193) Allow resolving only poms without downloading artifacts themselves

by Binod Pant (JIRA)

Binod Pant created SHRINKRES-193: ------------------------------------ Summary: Allow resolving only poms without downloading artifacts themselves Key: SHRINKRES-193 URL: https://issues.jboss.org/browse/SHRINKRES-193 Project: ShrinkWrap Resolvers Issue Type: Feature Request Security Level: Public (Everyone can see) Components: api-maven, impl-maven Affects Versions: 2.1.1 Reporter: Binod Pant See https://community.jboss.org/message/884084#884084 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-186) MavenResolverSystemBase deprecates offline() but JavaDoc refer to wrong new usage

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-186?page=com.atlassian.jira.plu... ] Karel Piwko commented on SHRINKRES-186: --------------------------------------- It's the first ;-) > MavenResolverSystemBase deprecates offline() but JavaDoc refer to wrong new usage > ---------------------------------------------------------------------------------- > > Key: SHRINKRES-186 > URL: https://issues.jboss.org/browse/SHRINKRES-186 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: api-maven > Affects Versions: 2.1.1 > Reporter: Aslak Knutsen > Fix For: 2.2.0-alpha-3 > > > MavenResolverSystemBase deprecates the methods offline() and offline(boolean), but the JavaDoc suggests the new way to set this flag is via ConfigurableMavenResolverSystem#workOffline(). The link is correct, but the suggest path seems off; Maven.resolver().workOffline() > Maven.resolver() will return a MavenResolverSystem, while Maven.configureResolver() returns the ConfigurableMavenResolverSystem which has the new methods.. > Either the JavaDoc needs update, or the Maven.resolver() methods needs to return the new interface? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-73) Improve error message for unsupported type of dependency

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-73?page=com.atlassian.jira.plug... ] Karel Piwko updated SHRINKRES-73: --------------------------------- Fix Version/s: 2.2.0-alpha-3 > Improve error message for unsupported type of dependency > -------------------------------------------------------- > > Key: SHRINKRES-73 > URL: https://issues.jboss.org/browse/SHRINKRES-73 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0-alpha-4 > Reporter: Karel Piwko > Fix For: 2.2.0-alpha-3 > > > <dependency> declaration might contain a type which is not valid at given place, such as import. > We should definitely make exception message better if that happens. > {code} > IllegalArgumentException : Packaging type import is not supported > {code} > As a side note, type can be virtually anything, I'm not sure if we can provide a typesafe enum here. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-190) implements equals and hashCode methods in MavenResolvedArtifactImpl / MavenArtifactInfoImpl

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-190?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-190: ---------------------------------- Fix Version/s: 2.2.0-alpha-3 > implements equals and hashCode methods in MavenResolvedArtifactImpl / MavenArtifactInfoImpl > ------------------------------------------------------------------------------------------- > > Key: SHRINKRES-190 > URL: https://issues.jboss.org/browse/SHRINKRES-190 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.1.1 > Reporter: Mathieu Lachance > Fix For: 2.2.0-alpha-3 > > > I'm currently to find an effective way to filter out many dependencies at once that I could provide within a "dummy" pom.xml. > I'd like to do the following: > {code:java} > public static List<MavenResolvedArtifact> resolveAllTestNonTransitiveDependencies() { > return Arrays.asList( > Maven.resolver() > .loadPomFromFile("pom.xml") > .importTestDependencies().resolve() > .withoutTransitivity() > .asResolvedArtifact()); > } > > public static List<MavenResolvedArtifact> resolveAllArquillianDependencies() { > return Arrays.asList( > Maven.resolver() > .loadPomFromFile("src/test/resources/arquillian.pom.xml") > .importTestDependencies().resolve() > .withoutTransitivity() > .asResolvedArtifact()); > } > > public static List<MavenResolvedArtifact> resolveAllTestNonTransitiveNonArquillianDependencies() { > List<MavenResolvedArtifact> testDependencies = resolveAllTestNonTransitiveDependencies(); > > List<MavenResolvedArtifact> arquillianDependencies = resolveAllArquillianDependencies(); > > List<MavenResolvedArtifact> filteredTestDependencies = new ArrayList<MavenResolvedArtifact>(); > for (MavenResolvedArtifact testDependency : testDependencies) { > if (!arquillianDependencies.contains(testDependency)) { > filteredTestDependencies.add(testDependency); > } > } > return filteredTestDependencies; > } > {code} > The problem is that MavenResolvedArtifactImpl does not implements equals and hashCode needed for using Collection::contains method. > I think it would be safe to delegate MavenResolvedArtifactImpl / MavenArtifactInfoImpl equals and hashCode methods to the one defined in MavenCoordinateImpl > Thanks, -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-186) MavenResolverSystemBase deprecates offline() but JavaDoc refer to wrong new usage

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-186?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-186: ---------------------------------- Fix Version/s: 2.2.0-alpha-3 > MavenResolverSystemBase deprecates offline() but JavaDoc refer to wrong new usage > ---------------------------------------------------------------------------------- > > Key: SHRINKRES-186 > URL: https://issues.jboss.org/browse/SHRINKRES-186 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: api-maven > Affects Versions: 2.1.1 > Reporter: Aslak Knutsen > Fix For: 2.2.0-alpha-3 > > > MavenResolverSystemBase deprecates the methods offline() and offline(boolean), but the JavaDoc suggests the new way to set this flag is via ConfigurableMavenResolverSystem#workOffline(). The link is correct, but the suggest path seems off; Maven.resolver().workOffline() > Maven.resolver() will return a MavenResolverSystem, while Maven.configureResolver() returns the ConfigurableMavenResolverSystem which has the new methods.. > Either the JavaDoc needs update, or the Maven.resolver() methods needs to return the new interface? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues August 2014