July 2013 - shrinkwrap-issues - Jboss List Archives

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

by Falko M. (JIRA)

Falko M. created SHRINKRES-146: ---------------------------------- Summary: 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 Affects Versions: 2.0.0, 2.0.0-beta-4 Reporter: Falko M. Assignee: Andrew Rubinger Priority: Blocker 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-145) ShrinkWrap Maven Resolver doesn't support Artifactory encryption format

by John Ament (JIRA)

John Ament created SHRINKRES-145: ------------------------------------ Summary: ShrinkWrap Maven Resolver doesn't support Artifactory encryption format Key: SHRINKRES-145 URL: https://issues.jboss.org/browse/SHRINKRES-145 Project: ShrinkWrap Resolvers Issue Type: Bug Components: impl-maven Affects Versions: 2.0.0 Reporter: John Ament Assignee: Andrew Rubinger I am seeing this error when I point to my company's maven repo which is hosted on Artifactory: java.lang.RuntimeException: Could not invoke deployment method: public static org.jboss.shrinkwrap.api.spec.JavaArchive com.sparta.ee.test.authorization.api.AuthorizationAPIITest.createDeployment1() 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) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:525) at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.createInstance(SpiServiceLoader.java:236) at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.createInstances(SpiServiceLoader.java:200) at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.all(SpiServiceLoader.java:79) at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.onlyOne(SpiServiceLoader.java:85) at org.jboss.shrinkwrap.resolver.spi.loader.ServiceRegistry.onlyOne(ServiceRegistry.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.shrinkwrap.resolver.api.ResolverSystemFactory.createFromUserView(ResolverSystemFactory.java:91) at org.jboss.shrinkwrap.resolver.api.ResolverSystemFactory.createFromUserView(ResolverSystemFactory.java:54) at org.jboss.shrinkwrap.resolver.api.Resolvers.use(Resolvers.java:67) at org.jboss.shrinkwrap.resolver.api.maven.Maven.resolver(Maven.java:37) at com.sparta.ee.test.utils.DeploymentUtils.resolveFile(DeploymentUtils.java:51) at com.sparta.ee.test.utils.DeploymentUtils.createFromZip(DeploymentUtils.java:29) at com.sparta.ee.test.utils.DeploymentUtils.importArtifact(DeploymentUtils.java:24) at com.sparta.ee.test.utils.DeploymentUtils.createTwsClient(DeploymentUtils.java:57) at com.sparta.ee.test.authorization.api.AuthorizationAPIITest.createDeployment1(AuthorizationAPIITest.java:45) My password is encrypted as such: <server> <id>sparta-artifactory</id> <username>john.ament</username> <password>{DESede}j8l/KLdrEtMBhwbgsf6cIg==</password> </server> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-114) Support resolution of versions from a specific artifact

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Andrew Rubinger closed SHRINKRES-114. ------------------------------------- Released in 2.1.0-alpha-1. > Support resolution of versions from a specific artifact > ------------------------------------------------------- > > Key: SHRINKRES-114 > URL: https://issues.jboss.org/browse/SHRINKRES-114 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: George Gastaldi > Assignee: Michal Matloka > Fix For: 2.1.0-alpha-1 > > > There are cases where a version of a specific artifact is unknown during test execution. > Aether supports version ranging: > {code}org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest){code} > It would be nice to provide an API in ShrinkWrap Resolver to: > - Resolve the available versions from a specific given range > - From that range, the possibility to retrieve the lowest and the highest version > - Reuse this information to resolve artifacts using the already existing ShrinkWrap Resolver APIs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-114) Support resolution of versions from a specific artifact

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Andrew Rubinger updated SHRINKRES-114: -------------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.0.1 Resolution: Done Upstream in: 405847499d13bd41ecd970919b2818955e66d24c 60beecbb7c01183e39dace2af0bd21dbee8c0b39. Will require a version change to 2.1.0-alpha-1 as this introduces new API elements we'll likely want to bake a bit in the community before locking. > Support resolution of versions from a specific artifact > ------------------------------------------------------- > > Key: SHRINKRES-114 > URL: https://issues.jboss.org/browse/SHRINKRES-114 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: George Gastaldi > Assignee: Michal Matloka > Fix For: 2.0.1 > > > There are cases where a version of a specific artifact is unknown during test execution. > Aether supports version ranging: > {code}org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest){code} > It would be nice to provide an API in ShrinkWrap Resolver to: > - Resolve the available versions from a specific given range > - From that range, the possibility to retrieve the lowest and the highest version > - Reuse this information to resolve artifacts using the already existing ShrinkWrap Resolver APIs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-146) Ability to generate OSGi bundle headers

by John Ament (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-146?page=com.atlassian.jira.pl... ] John Ament commented on SHRINKDESC-146: --------------------------------------- Not sure that a ticket created 10 days ago is a duplicate of a ticket created 3 years ago, or if it's the other way, but you should account for all of these votes in the new ticket if you want to go forward with SHRINKDESC-145. > Ability to generate OSGi bundle headers > --------------------------------------- > > Key: SHRINKDESC-146 > URL: https://issues.jboss.org/browse/SHRINKDESC-146 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Reporter: Pete Muir > > As we control the classpath generating an OSGi bundle header should be straightforward. Introducing an API to customize it is perhaps harder, but should be possible. > May want to look at delegating to BND (http://www.aqute.biz/Code/Bnd). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-146) Ability to generate OSGi bundle headers

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-146?page=com.atlassian.jira.pl... ] Andrew Rubinger moved SHRINKWRAP-139 to SHRINKDESC-146: ------------------------------------------------------- Project: ShrinkWrap Descriptors (was: ShrinkWrap) Key: SHRINKDESC-146 (was: SHRINKWRAP-139) > Ability to generate OSGi bundle headers > --------------------------------------- > > Key: SHRINKDESC-146 > URL: https://issues.jboss.org/browse/SHRINKDESC-146 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Reporter: Pete Muir > > As we control the classpath generating an OSGi bundle header should be straightforward. Introducing an API to customize it is perhaps harder, but should be possible. > May want to look at delegating to BND (http://www.aqute.biz/Code/Bnd). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-114) Support resolution of versions from a specific artifact

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Michal Matloka updated SHRINKRES-114: ------------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/shrinkwrap/resolver/pull/50 (was: https://github.com/shrinkwrap/resolver/pull/45) > Support resolution of versions from a specific artifact > ------------------------------------------------------- > > Key: SHRINKRES-114 > URL: https://issues.jboss.org/browse/SHRINKRES-114 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: George Gastaldi > Assignee: Michal Matloka > > There are cases where a version of a specific artifact is unknown during test execution. > Aether supports version ranging: > {code}org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest){code} > It would be nice to provide an API in ShrinkWrap Resolver to: > - Resolve the available versions from a specific given range > - From that range, the possibility to retrieve the lowest and the highest version > - Reuse this information to resolve artifacts using the already existing ShrinkWrap Resolver APIs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-139) Ability to generate OSGi bundle headers

by John Ament (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-139?page=com.atlassian.jira.pl... ] John Ament commented on SHRINKWRAP-139: --------------------------------------- rawr zombie jira ticket update looming. So, was thinking about this with regard to some fuse/servicemix stuff I'm playing with currently. Having a descriptor to do this makes the most sense. A BundleArchive would only support one thing (e.g. a JAR file w/ manifest), not necessarily a WAR file with that manifest. I don't think introducing a bundle archive fixes that stuff. I do think creating an OSGIDescriptor/OSGIManifest, and potentially a BlueprintDescriptor would help. While right now the descriptors are all reverse engineered based on XSDs, that doesn't mean we can't have one that's not based on an XSD (and as a result, directly coded). > Ability to generate OSGi bundle headers > --------------------------------------- > > Key: SHRINKWRAP-139 > URL: https://issues.jboss.org/browse/SHRINKWRAP-139 > Project: ShrinkWrap > Issue Type: Feature Request > Reporter: Pete Muir > > As we control the classpath generating an OSGi bundle header should be straightforward. Introducing an API to customize it is perhaps harder, but should be possible. > May want to look at delegating to BND (http://www.aqute.biz/Code/Bnd). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-140) Update Aether implementation to org.eclipse.aether one

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-140?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-140: ------------------------------------------ Sure. Here is a partly done migration to aether M2 basing on my previous attempt for M1 https://github.com/mmatloka/resolver/tree/ECLIPSE_AETHER_M2_NOT_WORKING > Update Aether implementation to org.eclipse.aether one > ------------------------------------------------------ > > Key: SHRINKRES-140 > URL: https://issues.jboss.org/browse/SHRINKRES-140 > Project: ShrinkWrap Resolvers > Issue Type: Component Upgrade > Components: impl-maven > Affects Versions: 2.0.0-beta-5 > Reporter: Karel Piwko > Assignee: Michal Matloka > > Aether is now a part of org.eclipse foundation. We should update to newer version when they release first stable version. > Update should not affect user at all, it should comprise of replacing imports with new ones. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-144) Upgrade to Maven 3.1.0

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-144?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-144: ------------------------------------------ Theoretically we can say its a duplicate of SHRINKRES-140. It is not possible to upgrade to maven 3.1.0 without eclipse aether, and its not possible to upgrade to eclipse aether without maven 3.1.0. > Upgrade to Maven 3.1.0 > ---------------------- > > Key: SHRINKRES-144 > URL: https://issues.jboss.org/browse/SHRINKRES-144 > Project: ShrinkWrap Resolvers > Issue Type: Component Upgrade > Affects Versions: 2.0.0 > Reporter: Michal Matloka > Assignee: Michal Matloka > > Maven 3.1.0 was recently released. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues July 2013