July 2014 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-188) Support installation of an artifact to a local repository

by Tomas Rohovsky (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-188?page=com.atlassian.jira.plu... ] Tomas Rohovsky edited comment on SHRINKRES-188 at 7/31/14 10:14 AM: -------------------------------------------------------------------- My use case is testing of KieContainer in Drools. I assemble an artifact (KieModule) by ShrinkWrap, so I have a JavaArchive. Then I would like to install the artifact to a local repository. It would be nice to just use SWR to install the JavaArchive. Currently, I am doing that by exporting of the archive to a temporary directory and then I am using Runtime.getRuntime().exec( String.format("mvn install:install-file -Dfile=target/%s -DpomFile=src/main/resources/pom.xml", name));. I see three advantages of having installation of the artifact in SWR: 1. The artifact doesn't have to be stored temporarily before installing of it, because SWR already knows what JavaArchive is. 2. exec() does't have to be called. It might be disallowed by a security manager to call it. 3. Maven doesn't have to be installed in an environment. As you said, the name of this project infers that it is primary for resolving of artifacts. So, it is a bit out of scope, but still useful. was (Author: trohovsky): My use case is testing of KieContainer in Drools. I assemble artifact (KieModule) by ShrinkWrap, so I have a JavaArchive. Then I would like to install the artifact to a local repository. It would be nice to just use SWR to install the JavaArchive. Currently, I am doing that by exporting of the archive to a temporary directory and then I am using Runtime.getRuntime().exec( String.format("mvn install:install-file -Dfile=target/%s -DpomFile=src/main/resources/pom.xml", name));. I see three advantages of having installation of the artifact in SWR: 1. The artifact doesn't have to be stored temporarily before installing of it, because SWR already knows what JavaArchive is. 2. exec() does't have to be called. It might be disallowed by a security manager to call it. 3. Maven doesn't have to be installed in an environment. As you said, the name of this project infers that it is primary for resolving of artifacts. So, it is a bit out of scope, but still useful. > Support installation of an artifact to a local repository > --------------------------------------------------------- > > Key: SHRINKRES-188 > URL: https://issues.jboss.org/browse/SHRINKRES-188 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: impl-maven > Affects Versions: 2.2.0-alpha-2 > Reporter: Tomas Rohovsky > > It would be a nice feature to provide installation of an artifact to a local repository. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-188) Support installation of an artifact to a local repository

by Tomas Rohovsky (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-188?page=com.atlassian.jira.plu... ] Tomas Rohovsky commented on SHRINKRES-188: ------------------------------------------ My use case is testing of KieContainer in Drools. I assemble artifact (KieModule) by ShrinkWrap, so I have a JavaArchive. Then I would like to install the artifact to a local repository. It would be nice to just use SWR to install the JavaArchive. Currently, I am doing that by exporting of the archive to a temporary directory and then I am using Runtime.getRuntime().exec( String.format("mvn install:install-file -Dfile=target/%s -DpomFile=src/main/resources/pom.xml", name));. I see three advantages of having installation of the artifact in SWR: 1. The artifact doesn't have to be stored temporarily before installing of it, because SWR already knows what JavaArchive is. 2. exec() does't have to be called. It might be disallowed by a security manager to call it. 3. Maven doesn't have to be installed in an environment. As you said, the name of this project infers that it is primary for resolving of artifacts. So, it is a bit out of scope, but still useful. > Support installation of an artifact to a local repository > --------------------------------------------------------- > > Key: SHRINKRES-188 > URL: https://issues.jboss.org/browse/SHRINKRES-188 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: impl-maven > Affects Versions: 2.2.0-alpha-2 > Reporter: Tomas Rohovsky > > It would be a nice feature to provide installation of an artifact to a local repository. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-188) Support installation of an artifact to a local repository

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-188?page=com.atlassian.jira.plu... ] Andrew Rubinger commented on SHRINKRES-188: ------------------------------------------- Thanks for the request Stefan! To be honest, this seems a bit out of scope for me; the "Resolvers" project, as the name might infer, is intended to perform resolution from a canonical form like a Maven GAV from some repository into a local asset (object). Pushing or writing data isn't a capability I've yet seen by any use case. I could be better convinced if you might present a use case for why pushing releases to repositories is useful. > Support installation of an artifact to a local repository > --------------------------------------------------------- > > Key: SHRINKRES-188 > URL: https://issues.jboss.org/browse/SHRINKRES-188 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: impl-maven > Affects Versions: 2.2.0-alpha-2 > Reporter: Tomas Rohovsky > > It would be a nice feature to provide installation of an artifact to a local repository. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-188) Support installation of an artifact to a local repository

by Stefan Bunciak (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-188?page=com.atlassian.jira.plu... ] Stefan Bunciak commented on SHRINKRES-188: ------------------------------------------ Would be great to support a remote repository as well, specified by url like for the Maven resolver: {code}Maven.configureResolver().withRemoteRepo("my-repository-id", "url://to/my/repository", "layout").... {code} > Support installation of an artifact to a local repository > --------------------------------------------------------- > > Key: SHRINKRES-188 > URL: https://issues.jboss.org/browse/SHRINKRES-188 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: impl-maven > Affects Versions: 2.2.0-alpha-2 > Reporter: Tomas Rohovsky > > It would be a nice feature to provide installation of an artifact to a local repository. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-188) Support installation of an artifact to a local repository

by Stefan Bunciak (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-188?page=com.atlassian.jira.plu... ] Stefan Bunciak edited comment on SHRINKRES-188 at 7/31/14 9:25 AM: ------------------------------------------------------------------- Would be great to support a remote repository for installation as well, specified by url like for the Maven resolver: {code}Maven.configureResolver().withRemoteRepo("my-repository-id", "url://to/my/repository", "layout").... {code} was (Author: sbunciak): Would be great to support a remote repository as well, specified by url like for the Maven resolver: {code}Maven.configureResolver().withRemoteRepo("my-repository-id", "url://to/my/repository", "layout").... {code} > Support installation of an artifact to a local repository > --------------------------------------------------------- > > Key: SHRINKRES-188 > URL: https://issues.jboss.org/browse/SHRINKRES-188 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: impl-maven > Affects Versions: 2.2.0-alpha-2 > Reporter: Tomas Rohovsky > > It would be a nice feature to provide installation of an artifact to a local repository. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-156) Create descriptor for jboss-deployment-structure.xml

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-156?page=com.atlassian.jira.pl... ] George Gastaldi updated SHRINKDESC-156: --------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/descriptors/pull/98 > Create descriptor for jboss-deployment-structure.xml > ---------------------------------------------------- > > Key: SHRINKDESC-156 > URL: https://issues.jboss.org/browse/SHRINKDESC-156 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: api-jboss, impl-jboss > Affects Versions: 2.0.0-alpha-5 > Reporter: Mathieu Lachance > Assignee: Ralf Battenfeld > > I'm using jboss-deployment-structure.xml descriptor and it would be great to create it programatically. > see xsd: > http://www.jboss.org/schema/jbossas/jboss-deployment-structure-1_0.xsd > http://www.jboss.org/schema/jbossas/jboss-deployment-structure-1_1.xsd > http://www.jboss.org/schema/jbossas/jboss-deployment-structure-1_2.xsd -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-184) Shrinkwrap maven local repo resolution not working since ARQ 1.1.4.Final

by Sueleyman Vurucu (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-184?page=com.atlassian.jira.plu... ] Sueleyman Vurucu commented on SHRINKRES-184: -------------------------------------------- No. The deletion of this files has no efect. > Shrinkwrap maven local repo resolution not working since ARQ 1.1.4.Final > ------------------------------------------------------------------------ > > Key: SHRINKRES-184 > URL: https://issues.jboss.org/browse/SHRINKRES-184 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: Maven 3.2.1 > Java 7 64 - bit > Windows 7 64 bit > Reporter: Sueleyman Vurucu > > I update ARQ from 1.1.3.Final to 1.1.4.Final. > After I try to excecute my testsuite I had a Exception that some of the artifacts could not be resolved. After Debugging I see that shrinkwrap looks for that artifacts on our local nexus server. Unfortunately we dont deploy our development artifact on nexus. > The MavenResolverSystem is configured like shown below: > // ARQ 1.1.3.Final > private static MavenResolverSystem getMavenDependencyResolver() { > MavenResolverSystem mavenResolverSystem = Maven.configureResolver().fromFile(pathToSettingsXML); > mavenResolverSystem.offline(); > return mavenResolverSystem; > } > // ARQ 1.1.4.Final > private static ConfigurableMavenResolverSystem getMavenDependencyResolver() { > ConfigurableMavenResolverSystem mavenResolverSystem = Resolvers.configure(ConfigurableMavenResolverSystem.class); > mavenResolverSystem.withClassPathResolution(true); > mavenResolverSystem.fromFile(pathToSettingsXML); > mavenResolverSystem.workOffline(); > return mavenResolverSystem; > } > As you can see I say to MavenResolverSystem that it should work offline. > After deep debugging I see that the resolversystem try to find all the artifacts on our nexus. > //ARQ 1.1.3.Final > DefaultRepositorySystem:367 > com.siemag.base:wms-base-controller:ejb:3.0.0-SNAPSHOT <(compile) > //ARQ 1.1.4.Final > In the class DefaultRepositorySystem:367 > com.siemag.base:wms-base-controller:ejb:3.0.0-SNAPSHOT < [nexus (http://172.16.55.1:8081/nexus/content/groups/public, releases)] -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-191) Refactor project structure - gradle and maven separation

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-191?page=com.atlassian.jira.plu... ] Karel Piwko commented on SHRINKRES-191: --------------------------------------- +1, this makes sense to me. GroupId and ArtifactId can stay and aggregator can actually reference nested modules if that's needed - so we don't have to introduce new aggregators. Or, is the plan those two parts can be compiled completely separately? > Refactor project structure - gradle and maven separation > -------------------------------------------------------- > > Key: SHRINKRES-191 > URL: https://issues.jboss.org/browse/SHRINKRES-191 > Project: ShrinkWrap Resolvers > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Michal Matloka > Assignee: Michal Matloka > > Currently SWR structure contains all modules in main project directory. I propose to seperate maven and gradle modules into seperate subdirectories. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-191) Refactor project structure - gradle and maven separation

by Michal Matloka (JIRA)

Michal Matloka created SHRINKRES-191: ---------------------------------------- Summary: Refactor project structure - gradle and maven separation Key: SHRINKRES-191 URL: https://issues.jboss.org/browse/SHRINKRES-191 Project: ShrinkWrap Resolvers Issue Type: Task Security Level: Public (Everyone can see) Reporter: Michal Matloka Assignee: Michal Matloka Currently SWR structure contains all modules in main project directory. I propose to seperate maven and gradle modules into seperate subdirectories. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-184) Shrinkwrap maven local repo resolution not working since ARQ 1.1.4.Final

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-184?page=com.atlassian.jira.plu... ] Karel Piwko edited comment on SHRINKRES-184 at 7/29/14 6:52 AM: ---------------------------------------------------------------- Arquillian version should be unrelated, it just maintains Resolver version. We are looking for a regression for your test case in SWR 2.0.2 and 2.1.0, since Arquillian 1.1.4.Final 2.1.x is the stream we are using. Just to check whether I'm on the right path, can you search your local repository for "_remote.repositories" files for artifacts you are trying to resolved and delete these files? was (Author: kpiwko): Arquillian version should be unrelated, it just maintains Resolver version. We are looking for a regression for your test case in SWR 2.0.2 and 2.1.0. Just to check whether I'm on the right path, can you search your local repository for "_remote.repositories" files for artifacts you are trying to resolved and delete these files? > Shrinkwrap maven local repo resolution not working since ARQ 1.1.4.Final > ------------------------------------------------------------------------ > > Key: SHRINKRES-184 > URL: https://issues.jboss.org/browse/SHRINKRES-184 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: Maven 3.2.1 > Java 7 64 - bit > Windows 7 64 bit > Reporter: Sueleyman Vurucu > > I update ARQ from 1.1.3.Final to 1.1.4.Final. > After I try to excecute my testsuite I had a Exception that some of the artifacts could not be resolved. After Debugging I see that shrinkwrap looks for that artifacts on our local nexus server. Unfortunately we dont deploy our development artifact on nexus. > The MavenResolverSystem is configured like shown below: > // ARQ 1.1.3.Final > private static MavenResolverSystem getMavenDependencyResolver() { > MavenResolverSystem mavenResolverSystem = Maven.configureResolver().fromFile(pathToSettingsXML); > mavenResolverSystem.offline(); > return mavenResolverSystem; > } > // ARQ 1.1.4.Final > private static ConfigurableMavenResolverSystem getMavenDependencyResolver() { > ConfigurableMavenResolverSystem mavenResolverSystem = Resolvers.configure(ConfigurableMavenResolverSystem.class); > mavenResolverSystem.withClassPathResolution(true); > mavenResolverSystem.fromFile(pathToSettingsXML); > mavenResolverSystem.workOffline(); > return mavenResolverSystem; > } > As you can see I say to MavenResolverSystem that it should work offline. > After deep debugging I see that the resolversystem try to find all the artifacts on our nexus. > //ARQ 1.1.3.Final > DefaultRepositorySystem:367 > com.siemag.base:wms-base-controller:ejb:3.0.0-SNAPSHOT <(compile) > //ARQ 1.1.4.Final > In the class DefaultRepositorySystem:367 > com.siemag.base:wms-base-controller:ejb:3.0.0-SNAPSHOT < [nexus (http://172.16.55.1:8081/nexus/content/groups/public, releases)] -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 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 2014