June 2015 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-223) ClasspathWorkspaceReader does not resolve version variables

by Thorsten Meinl (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-223?page=com.atlassian.jira.plu... ] Thorsten Meinl updated SHRINKRES-223: ------------------------------------- Attachment: resolver-bug.zip Here are three project to reproduce the problem. Try to run projectB/Test and it will fail because it cannot resolve com.knime:projectA. The version of com.knime:projectA is a veriable defined in com.knime:config (${com.knime.a.version}). The dependency in com.knime:projectB uses this version variable and it is resolved correctly to 5.2.0-SNAPSHOT. However, the resolution does not resolve in in com.knime:projectA. If you set the version there to the constant "5.2.0-SNAPSHOT" then it works as expected. > ClasspathWorkspaceReader does not resolve version variables > ----------------------------------------------------------- > > Key: SHRINKRES-223 > URL: https://issues.jboss.org/browse/SHRINKRES-223 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: maven > Affects Versions: 2.2.0-beta-2 > Reporter: Thorsten Meinl > Attachments: resolver-bug.zip > > > The ClasspathWorkspaceReader does not resolve variables in artifact versions. We have an artifact whose version is a variable that is defined in its parent pom. "ClasspathWorkspaceReader.createFoundArtifact" reads the variable as-is and does not resolve it to the real version. However, when resolving the dependencies for the "root" artifacts (the one whose pom has been loaded by the resolver via "loadPomFromFile") version variables *are* resolved and therefore there will always be a mismatch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-224) Generated artifacts from workspace are missing directory entries

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-224?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-224: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Generated artifacts from workspace are missing directory entries > ---------------------------------------------------------------- > > Key: SHRINKRES-224 > URL: https://issues.jboss.org/browse/SHRINKRES-224 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: maven > Affects Versions: 2.2.0-beta-2 > Reporter: Karel Piwko > Fix For: 2.2.0-beta-3 > > > In order to able to use spring annotations "component-scan" to bind classes the external jar files HAVE TO contains directory entries. If these entries are not present the automatic scan is not working. > In current version, the zip file build from a workspace project included in arquillian deployment does not contains this entries. > For more infos : http://stackoverflow.com/questions/1242656/spring-annotation-based-contro... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-224) Generated artifacts from workspace are missing directory entries

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-224?page=com.atlassian.jira.plu... ] Karel Piwko commented on SHRINKRES-224: --------------------------------------- Merged from upstream https://github.com/shrinkwrap/resolver/commit/e831f0dd977c2dbf2cc3c9e9512... > Generated artifacts from workspace are missing directory entries > ---------------------------------------------------------------- > > Key: SHRINKRES-224 > URL: https://issues.jboss.org/browse/SHRINKRES-224 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: maven > Affects Versions: 2.2.0-beta-2 > Reporter: Karel Piwko > Fix For: 2.2.0-beta-3 > > > In order to able to use spring annotations "component-scan" to bind classes the external jar files HAVE TO contains directory entries. If these entries are not present the automatic scan is not working. > In current version, the zip file build from a workspace project included in arquillian deployment does not contains this entries. > For more infos : http://stackoverflow.com/questions/1242656/spring-annotation-based-contro... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-224) Generated artifacts from workspace are missing directory entries

by Karel Piwko (JIRA)

Karel Piwko created SHRINKRES-224: ------------------------------------- Summary: Generated artifacts from workspace are missing directory entries Key: SHRINKRES-224 URL: https://issues.jboss.org/browse/SHRINKRES-224 Project: ShrinkWrap Resolvers Issue Type: Bug Components: maven Affects Versions: 2.2.0-beta-2 Reporter: Karel Piwko Fix For: 2.2.0-beta-3 In order to able to use spring annotations "component-scan" to bind classes the external jar files HAVE TO contains directory entries. If these entries are not present the automatic scan is not working. In current version, the zip file build from a workspace project included in arquillian deployment does not contains this entries. For more infos : http://stackoverflow.com/questions/1242656/spring-annotation-based-contro... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-224) Generated artifacts from workspace are missing directory entries

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-224?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-224: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/resolver/pull/83 > Generated artifacts from workspace are missing directory entries > ---------------------------------------------------------------- > > Key: SHRINKRES-224 > URL: https://issues.jboss.org/browse/SHRINKRES-224 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: maven > Affects Versions: 2.2.0-beta-2 > Reporter: Karel Piwko > Fix For: 2.2.0-beta-3 > > > In order to able to use spring annotations "component-scan" to bind classes the external jar files HAVE TO contains directory entries. If these entries are not present the automatic scan is not working. > In current version, the zip file build from a workspace project included in arquillian deployment does not contains this entries. > For more infos : http://stackoverflow.com/questions/1242656/spring-annotation-based-contro... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-223) ClasspathWorkspaceReader does not resolve version variables

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-223?page=com.atlassian.jira.plu... ] Matous Jobanek commented on SHRINKRES-223: ------------------------------------------ Hi, could you provide some reproducer? I followed the steps you mentioned, but in my case all the version variables have been replaced/resolved. > ClasspathWorkspaceReader does not resolve version variables > ----------------------------------------------------------- > > Key: SHRINKRES-223 > URL: https://issues.jboss.org/browse/SHRINKRES-223 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: maven > Affects Versions: 2.2.0-beta-2 > Reporter: Thorsten Meinl > > The ClasspathWorkspaceReader does not resolve variables in artifact versions. We have an artifact whose version is a variable that is defined in its parent pom. "ClasspathWorkspaceReader.createFoundArtifact" reads the variable as-is and does not resolve it to the real version. However, when resolving the dependencies for the "root" artifacts (the one whose pom has been loaded by the resolver via "loadPomFromFile") version variables *are* resolved and therefore there will always be a mismatch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-223) ClasspathWorkspaceReader does not resolve version variables

by Thorsten Meinl (JIRA)

Thorsten Meinl created SHRINKRES-223: ---------------------------------------- Summary: ClasspathWorkspaceReader does not resolve version variables Key: SHRINKRES-223 URL: https://issues.jboss.org/browse/SHRINKRES-223 Project: ShrinkWrap Resolvers Issue Type: Bug Components: maven Affects Versions: 2.2.0-beta-2 Reporter: Thorsten Meinl The ClasspathWorkspaceReader does not resolve variables in artifact versions. We have an artifact whose version is a variable that is defined in its parent pom. "ClasspathWorkspaceReader.createFoundArtifact" reads the variable as-is and does not resolve it to the real version. However, when resolving the dependencies for the "root" artifacts (the one whose pom has been loaded by the resolver via "loadPomFromFile") version variables *are* resolved and therefore there will always be a mismatch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-222) Environment variables are not replaced when using ParsedPomFile.getProperties()

by Falko M. (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-222?page=com.atlassian.jira.plu... ] Falko M. updated SHRINKRES-222: ------------------------------- Description: In Maven you can define properties using environment variables, e.g.: {{<someProp>$\{env.SOME_ENV\}<someProp>}} See also: http://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p... On the command line, those placeholders a replaced as expected. This can be checked via {{mvn help:effective-pom}}. Unfortunately, {{ParsedPomFile.getProperties()}} does *not* replace those placeholders. It returns them "as is" (e.g. {{"$\{env.SOME_ENV\}"}}). was: In Maven you can define properties using environment variables, e.g.: {{<someProp>$\{env.SOME_ENV\}<someProp>}} See also: http://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p... On the command line, those placeholders a replaced as expected. This can be checked via {{mvn help:effective-pom}}. Unfortunately, {{ParsedPomFile.getProperties()}} does *not* replace those placeholders. It returns them "as is" (e.g. {"{$\{env.SOME_ENV\}}"}). > Environment variables are not replaced when using ParsedPomFile.getProperties() > ------------------------------------------------------------------------------- > > Key: SHRINKRES-222 > URL: https://issues.jboss.org/browse/SHRINKRES-222 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: maven > Affects Versions: 2.1.1 > Environment: Windows 7 x64 > Reporter: Falko M. > > In Maven you can define properties using environment variables, e.g.: > {{<someProp>$\{env.SOME_ENV\}<someProp>}} > See also: http://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p... > On the command line, those placeholders a replaced as expected. This can be checked via {{mvn help:effective-pom}}. > Unfortunately, {{ParsedPomFile.getProperties()}} does *not* replace those placeholders. It returns them "as is" (e.g. {{"$\{env.SOME_ENV\}"}}). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-222) Environment variables are not replaced when using ParsedPomFile.getProperties()

by Falko M. (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-222?page=com.atlassian.jira.plu... ] Falko M. updated SHRINKRES-222: ------------------------------- Description: In Maven you can define properties using environment variables, e.g.: {{<someProp>$\{env.SOME_ENV\}<someProp>}} See also: http://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p... On the command line, those placeholders a replaced as expected. This can be checked via {{mvn help:effective-pom}}. Unfortunately, {{ParsedPomFile.getProperties()}} does *not* replace those placeholders. It returns them "as is" (e.g. {"{$\{env.SOME_ENV\}}"}). was: In Maven you can define properties using environment variables, e.g.: {{<someProp>$\{env.SOME_ENV\}<someProp>}} On the command line, those placeholders a replaced as expected. This can be checked via {{mvn help:effective-pom}}. Unfortunately, {{ParsedPomFile.getProperties()}} does *not* replace those placeholders. It returns them "as is" (e.g. {"{$\{env.SOME_ENV\}}"}). > Environment variables are not replaced when using ParsedPomFile.getProperties() > ------------------------------------------------------------------------------- > > Key: SHRINKRES-222 > URL: https://issues.jboss.org/browse/SHRINKRES-222 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: maven > Affects Versions: 2.1.1 > Environment: Windows 7 x64 > Reporter: Falko M. > > In Maven you can define properties using environment variables, e.g.: > {{<someProp>$\{env.SOME_ENV\}<someProp>}} > See also: http://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p... > On the command line, those placeholders a replaced as expected. This can be checked via {{mvn help:effective-pom}}. > Unfortunately, {{ParsedPomFile.getProperties()}} does *not* replace those placeholders. It returns them "as is" (e.g. {"{$\{env.SOME_ENV\}}"}). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-222) Environment variables are not replaced when using ParsedPomFile.getProperties()

by Falko M. (JIRA)

Falko M. created SHRINKRES-222: ---------------------------------- Summary: Environment variables are not replaced when using ParsedPomFile.getProperties() Key: SHRINKRES-222 URL: https://issues.jboss.org/browse/SHRINKRES-222 Project: ShrinkWrap Resolvers Issue Type: Bug Components: maven Affects Versions: 2.1.1 Environment: Windows 7 x64 Reporter: Falko M. In Maven you can define properties using environment variables, e.g.: {{<someProp>$\{env.SOME_ENV\}<someProp>}} On the command line, those placeholders a replaced as expected. This can be checked via {{mvn help:effective-pom}}. Unfortunately, {{ParsedPomFile.getProperties()}} does *not* replace those placeholders. It returns them "as is" (e.g. {"{$\{env.SOME_ENV\}}"}). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues June 2015