October 2015 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-163: -------------------------------------------- Or better, you have then the choice between having three descriptors or one:-) > Deal with descriptors with multiple possible roots better > --------------------------------------------------------- > > Key: SHRINKDESC-163 > URL: https://issues.jboss.org/browse/SHRINKDESC-163 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Affects Versions: 2.0.0-alpha-8 > Reporter: Toby Crawley > > When implementing SHRINKDESC-162, I created three different > descriptors for module.xml ({{ModuleDescriptor}}, > {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to > the three root elements listed in the xsd ({{module}}, {{module-alias}}, > {{module-absent}}). This works fine if you are generating a module.xml, > but if you are loading in an existing file, you don't know without > looking at the file contents to know which type to instantiate. > It would be swell if there was a way for descriptors to support > multiple roots and do the correct thing. Or does that already exist > and I missed it? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-163: -------------------------------------------- I was checking some other possibilities but at the end, if believe the only 'real' solution is that we support multi root elements in a descriptor. If you all agree then I will work on this. It will take a little time to implement it. This solution will then replace the three module descriptors by one descriptor. You then can load an XML file and navigate through the top level methods in order to find which flavor of the module.xml you have loaded. Does that make sense? > Deal with descriptors with multiple possible roots better > --------------------------------------------------------- > > Key: SHRINKDESC-163 > URL: https://issues.jboss.org/browse/SHRINKDESC-163 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Affects Versions: 2.0.0-alpha-8 > Reporter: Toby Crawley > > When implementing SHRINKDESC-162, I created three different > descriptors for module.xml ({{ModuleDescriptor}}, > {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to > the three root elements listed in the xsd ({{module}}, {{module-alias}}, > {{module-absent}}). This works fine if you are generating a module.xml, > but if you are loading in an existing file, you don't know without > looking at the file contents to know which type to instantiate. > It would be swell if there was a way for descriptors to support > multiple roots and do the correct thing. Or does that already exist > and I missed it? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-163: -------------------------------------------- I agree absolutely. Changing the XSD is not an option at all. I have an idea that may solves this but I need little time to check it:-) > Deal with descriptors with multiple possible roots better > --------------------------------------------------------- > > Key: SHRINKDESC-163 > URL: https://issues.jboss.org/browse/SHRINKDESC-163 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Affects Versions: 2.0.0-alpha-8 > Reporter: Toby Crawley > > When implementing SHRINKDESC-162, I created three different > descriptors for module.xml ({{ModuleDescriptor}}, > {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to > the three root elements listed in the xsd ({{module}}, {{module-alias}}, > {{module-absent}}). This works fine if you are generating a module.xml, > but if you are loading in an existing file, you don't know without > looking at the file contents to know which type to instantiate. > It would be swell if there was a way for descriptors to support > multiple roots and do the correct thing. Or does that already exist > and I missed it? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better

by Bob McWhirter (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ] Bob McWhirter commented on SHRINKDESC-163: ------------------------------------------ I believe jboss-modules, which normally consumes these, uses a StAX parser and makes decisions based upon the elements it finds. https://github.com/jboss-modules/jboss-modules/blob/master/src/main/java/... As far as changing the XSD, I think that's a non-starter, as the number of files that'd require changing, for no particular value to the primary consumers of it (the WildFly/EAP team and customers). > Deal with descriptors with multiple possible roots better > --------------------------------------------------------- > > Key: SHRINKDESC-163 > URL: https://issues.jboss.org/browse/SHRINKDESC-163 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Affects Versions: 2.0.0-alpha-8 > Reporter: Toby Crawley > > When implementing SHRINKDESC-162, I created three different > descriptors for module.xml ({{ModuleDescriptor}}, > {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to > the three root elements listed in the xsd ({{module}}, {{module-alias}}, > {{module-absent}}). This works fine if you are generating a module.xml, > but if you are loading in an existing file, you don't know without > looking at the file contents to know which type to instantiate. > It would be swell if there was a way for descriptors to support > multiple roots and do the correct thing. Or does that already exist > and I missed it? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-163: -------------------------------------------- Hmm, I see the three root elements. I am right, your problem is that you have first to analyze the file content in order to find out which of the three module descriptors is the right one? If yes, how does the wildfly implementation tackle this problem? For me, it looks that this is more a modeling issue, I mean, the module.xsd could have one root element and three nested elements as choices for example. But besides this, I will think what we can do from the descriptor implementation side. The module.xsd will not be changed just because of this JIRA:-) I will have some time over the weekend. Regards, Ralf > Deal with descriptors with multiple possible roots better > --------------------------------------------------------- > > Key: SHRINKDESC-163 > URL: https://issues.jboss.org/browse/SHRINKDESC-163 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Affects Versions: 2.0.0-alpha-8 > Reporter: Toby Crawley > > When implementing SHRINKDESC-162, I created three different > descriptors for module.xml ({{ModuleDescriptor}}, > {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to > the three root elements listed in the xsd ({{module}}, {{module-alias}}, > {{module-absent}}). This works fine if you are generating a module.xml, > but if you are loading in an existing file, you don't know without > looking at the file contents to know which type to instantiate. > It would be swell if there was a way for descriptors to support > multiple roots and do the correct thing. Or does that already exist > and I missed it? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-163: -------------------------------------------- I will have a look if you don't mind > Deal with descriptors with multiple possible roots better > --------------------------------------------------------- > > Key: SHRINKDESC-163 > URL: https://issues.jboss.org/browse/SHRINKDESC-163 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Affects Versions: 2.0.0-alpha-8 > Reporter: Toby Crawley > > When implementing SHRINKDESC-162, I created three different > descriptors for module.xml ({{ModuleDescriptor}}, > {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to > the three root elements listed in the xsd ({{module}}, {{module-alias}}, > {{module-absent}}). This works fine if you are generating a module.xml, > but if you are loading in an existing file, you don't know without > looking at the file contents to know which type to instantiate. > It would be swell if there was a way for descriptors to support > multiple roots and do the correct thing. Or does that already exist > and I missed it? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better

by Bob McWhirter (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ] Bob McWhirter commented on SHRINKDESC-163: ------------------------------------------ Additionally, for the 3 Module*Descriptor classes, a common BaseModuleDescriptor that has the common bits would be great. If not, at least something that makes it easier to stuff them into a List<BaseModuleDescriptor> instead of just a List<Object>. > Deal with descriptors with multiple possible roots better > --------------------------------------------------------- > > Key: SHRINKDESC-163 > URL: https://issues.jboss.org/browse/SHRINKDESC-163 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Affects Versions: 2.0.0-alpha-8 > Reporter: Toby Crawley > > When implementing SHRINKDESC-162, I created three different > descriptors for module.xml ({{ModuleDescriptor}}, > {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to > the three root elements listed in the xsd ({{module}}, {{module-alias}}, > {{module-absent}}). This works fine if you are generating a module.xml, > but if you are loading in an existing file, you don't know without > looking at the file contents to know which type to instantiate. > It would be swell if there was a way for descriptors to support > multiple roots and do the correct thing. Or does that already exist > and I missed it? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better

by Toby Crawley (JIRA)

Toby Crawley created SHRINKDESC-163: --------------------------------------- Summary: Deal with descriptors with multiple possible roots better Key: SHRINKDESC-163 URL: https://issues.jboss.org/browse/SHRINKDESC-163 Project: ShrinkWrap Descriptors Issue Type: Feature Request Affects Versions: 2.0.0-alpha-8 Reporter: Toby Crawley When implementing SHRINKDESC-162, I created three different descriptors for module.xml ({{ModuleDescriptor}}, {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to the three root elements listed in the xsd ({{module}}, {{module-alias}}, {{module-absent}}). This works fine if you are generating a module.xml, but if you are loading in an existing file, you don't know without looking at the file contents to know which type to instantiate. It would be swell if there was a way for descriptors to support multiple roots and do the correct thing. Or does that already exist and I missed it? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-227) ShrinkWrap Maven Resolver doesn't support env vars in settings.xml

by Ioannis Canellos (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-227?page=com.atlassian.jira.plu... ] Ioannis Canellos commented on SHRINKRES-227: -------------------------------------------- I think that in the 2.2.0 its fixed. Need to do some more testing on that. > ShrinkWrap Maven Resolver doesn't support env vars in settings.xml > ------------------------------------------------------------------ > > Key: SHRINKRES-227 > URL: https://issues.jboss.org/browse/SHRINKRES-227 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: maven > Reporter: James Rawlings > > I get the stacktrace below when using this code on a jenkins instance that uses env vars in the settings.xml > {code} > return ShrinkWrap.create(WebArchive.class) > .addClasses(StringToURL.class, URLToConnection.class, NestingFactoryBean.class, ServiceStringBean.class, ServiceUrlBean.class, ClientProducer.class) > .addClasses(DeltaspikeTestBase.getDeltaSpikeHolders()) > .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")) > .addAsLibraries(Maven.resolver().loadPomFromFile("pom.xml") > .resolve( > "org.apache.deltaspike.core:deltaspike-core-impl", > "com.google.mockwebserver:mockwebserver" > ) > .withTransitivity().as(File.class)); > {code} > Stacktrace.. > {code} > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.fabric8.cdi.weld.ExtensionTest > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.51 sec <<< FAILURE! - in io.fabric8.cdi.weld.ExtensionTest > io.fabric8.cdi.weld.ExtensionTest Time elapsed: 0.51 sec <<< ERROR! > java.lang.RuntimeException: Could not invoke deployment method: public static org.jboss.shrinkwrap.api.spec.WebArchive io.fabric8.cdi.weld.ExtensionTest.createDeployment() > 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:136) > at org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemImpl.<init>(MavenResolverSystemImpl.java:44) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.createInstance(SpiServiceLoader.java:244) > at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.createInstances(SpiServiceLoader.java:208) > 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:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.shrinkwrap.resolver.api.Invokable.invokeMethod(Invokable.java:100) > at org.jboss.shrinkwrap.resolver.api.ResolverSystemFactory.createFromUserView(ResolverSystemFactory.java:91) > at org.jboss.shrinkwrap.resolver.api.ResolverSystemFactory.createFromUserView(ResolverSystemFactory.java:53) > at org.jboss.shrinkwrap.resolver.api.Resolvers.use(Resolvers.java:68) > at org.jboss.shrinkwrap.resolver.api.maven.Maven.resolver(Maven.java:36) > at io.fabric8.cdi.weld.ExtensionTest.createDeployment(ExtensionTest.java:49) > {code} > This error is similar to issue https://issues.jboss.org/browse/SHRINKRES-145 however I cannot escape the values in my settings.xml as they need to resolve to env vars. > Example snippet of my settings.xml.. > {code:xml} > <servers> > <server> > <id>local-nexus</id> > <username>${env.NEXUS_USERNAME}</username> > <password>${env.NEXUS_PASSWORD}</password> > </server> > <server> > <id>nexus</id> > <username>${env.NEXUS_USERNAME}</username> > <password>${env.NEXUS_PASSWORD}</password> > </server> > <server> > <id>docker-registry</id> > <username>${env.DOCKER_REGISTRY_USERNAME}</username> > <password>${env.DOCKER_REGISTRY_PASSWORD}</password> > </server> > </servers> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-227) ShrinkWrap Maven Resolver doesn't support env vars in settings.xml

by Ioannis Canellos (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-227?page=com.atlassian.jira.plu... ] Ioannis Canellos edited comment on SHRINKRES-227 at 10/8/15 5:47 AM: --------------------------------------------------------------------- Hi Matous, In the current master, the issue seems fixed. In 2.x version of shrinkwrap, the linked test case only works if the default settings.xml doesn't contain env property placeholders. When I debugged the issue, I saw again the ${env.username} not being substituted and eventually breaking MavenPlexusCipher. P.S: We don't use encrypted passwords, no! We just use a lot of ${env.XXXXX} stuff was (Author: iocanel): Hi Matous, In the current master, the issue seems fixed. In 2.x version of shrinkwrap, the linked test case only works if the default settings.xml doesn't contain env property placeholders. When I debugged the issue, I saw again the ${env.username} not being substituted and eventually breaking MavenPlexusCipher. > ShrinkWrap Maven Resolver doesn't support env vars in settings.xml > ------------------------------------------------------------------ > > Key: SHRINKRES-227 > URL: https://issues.jboss.org/browse/SHRINKRES-227 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: maven > Reporter: James Rawlings > > I get the stacktrace below when using this code on a jenkins instance that uses env vars in the settings.xml > {code} > return ShrinkWrap.create(WebArchive.class) > .addClasses(StringToURL.class, URLToConnection.class, NestingFactoryBean.class, ServiceStringBean.class, ServiceUrlBean.class, ClientProducer.class) > .addClasses(DeltaspikeTestBase.getDeltaSpikeHolders()) > .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")) > .addAsLibraries(Maven.resolver().loadPomFromFile("pom.xml") > .resolve( > "org.apache.deltaspike.core:deltaspike-core-impl", > "com.google.mockwebserver:mockwebserver" > ) > .withTransitivity().as(File.class)); > {code} > Stacktrace.. > {code} > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.fabric8.cdi.weld.ExtensionTest > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.51 sec <<< FAILURE! - in io.fabric8.cdi.weld.ExtensionTest > io.fabric8.cdi.weld.ExtensionTest Time elapsed: 0.51 sec <<< ERROR! > java.lang.RuntimeException: Could not invoke deployment method: public static org.jboss.shrinkwrap.api.spec.WebArchive io.fabric8.cdi.weld.ExtensionTest.createDeployment() > 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:136) > at org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemImpl.<init>(MavenResolverSystemImpl.java:44) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.createInstance(SpiServiceLoader.java:244) > at org.jboss.shrinkwrap.resolver.spi.loader.SpiServiceLoader.createInstances(SpiServiceLoader.java:208) > 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:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.shrinkwrap.resolver.api.Invokable.invokeMethod(Invokable.java:100) > at org.jboss.shrinkwrap.resolver.api.ResolverSystemFactory.createFromUserView(ResolverSystemFactory.java:91) > at org.jboss.shrinkwrap.resolver.api.ResolverSystemFactory.createFromUserView(ResolverSystemFactory.java:53) > at org.jboss.shrinkwrap.resolver.api.Resolvers.use(Resolvers.java:68) > at org.jboss.shrinkwrap.resolver.api.maven.Maven.resolver(Maven.java:36) > at io.fabric8.cdi.weld.ExtensionTest.createDeployment(ExtensionTest.java:49) > {code} > This error is similar to issue https://issues.jboss.org/browse/SHRINKRES-145 however I cannot escape the values in my settings.xml as they need to resolve to env vars. > Example snippet of my settings.xml.. > {code:xml} > <servers> > <server> > <id>local-nexus</id> > <username>${env.NEXUS_USERNAME}</username> > <password>${env.NEXUS_PASSWORD}</password> > </server> > <server> > <id>nexus</id> > <username>${env.NEXUS_USERNAME}</username> > <password>${env.NEXUS_PASSWORD}</password> > </server> > <server> > <id>docker-registry</id> > <username>${env.DOCKER_REGISTRY_USERNAME}</username> > <password>${env.DOCKER_REGISTRY_PASSWORD}</password> > </server> > </servers> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues October 2015