April 2012 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKWRAP-400) Confusing exception when filename string passed to DescriptorImporter.from(...)

by Craig Ringer (JIRA)

Craig Ringer created SHRINKWRAP-400: --------------------------------------- Summary: Confusing exception when filename string passed to DescriptorImporter.from(...) Key: SHRINKWRAP-400 URL: https://issues.jboss.org/browse/SHRINKWRAP-400 Project: ShrinkWrap Issue Type: Feature Request Components: api, ext-descriptors Affects Versions: 1.0.0 Reporter: Craig Ringer Descriptors 2.0.0.alpha2 It's too easy to write: {code} BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class) .from("src/main/webapp/WEB-INF/beans.xml"); {code} when you really meant: {code} BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class) .from(new File("src/main/webapp/WEB-INF/beans.xml")); {code} The incorrect code reads fine, and the exception thrown doesn't make it at all obvious what's happening: {code} java.lang.RuntimeException: Could not invoke deployment method: public static org.jboss.shrinkwrap.api.spec.JavaArchive com.example.shrinkwraptestsk eleton.DemoTest.createDeployment() .... Caused by: java.lang.reflect.InvocationTargetException .... Caused by: org.jboss.shrinkwrap.descriptor.api.DescriptorImportException: Could not import XML from stream .... Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Content is not allowed in prolog. .... {code} I'd like to replace ".from(String)" with ".fromString(...)" and ".fromFile(...)". The unqualified .from() could continue to accept an InputStream or Reader, just not String. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
7
0 / 0

[JBoss JIRA] Created: (SHRINKDESC-21) descriptor read-only mode

by Dan Allen (JIRA)

descriptor read-only mode ------------------------- Key: SHRINKDESC-21 URL: https://jira.jboss.org/browse/SHRINKDESC-21 Project: ShrinkWrap Descriptors Issue Type: Feature Request Components: api Affects Versions: 1.0.0-alpha-1 Reporter: Dan Allen The import procedure should support a read-only mode. The returned descriptor type would only have the read methods and none of the fluent modifier methods. This would be useful in a framework that is providing access to a descriptor for inspection only (such as a framework consuming a descriptor for the purpose of configuration). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
4
0 / 0

[JBoss JIRA] (SHRINKDESC-117) Scoped artifacts in ShrinkWrap Descriptors BOM

by Karel Piwko (JIRA)

Karel Piwko created SHRINKDESC-117: -------------------------------------- Summary: Scoped artifacts in ShrinkWrap Descriptors BOM Key: SHRINKDESC-117 URL: https://issues.jboss.org/browse/SHRINKDESC-117 Project: ShrinkWrap Descriptors Issue Type: Bug Components: api Affects Versions: 2.0.0-alpha-2 Reporter: Karel Piwko Assignee: Andrew Rubinger Priority: Blocker Fix For: 2.0.0-alpha-3 ShrinkWrap Descriptor BOM contains scoped artifacts. When bom is imported into <dependencyManagement> that scope is activated and overrides test scope, resulting with "runtime" dependencies being included as a part of resulting JAR/WAR/EAR archive. This is a serious usability flaw and therefore marking as Blocker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
1
0 / 0

[JBoss JIRA] (SHRINKWRAP-401) Scoped artifacts in ShrinkWrap BOM

by Karel Piwko (JIRA)

Karel Piwko created SHRINKWRAP-401: -------------------------------------- Summary: Scoped artifacts in ShrinkWrap BOM Key: SHRINKWRAP-401 URL: https://issues.jboss.org/browse/SHRINKWRAP-401 Project: ShrinkWrap Issue Type: Bug Components: build Affects Versions: 1.0.0 Reporter: Karel Piwko Assignee: Andrew Rubinger Priority: Blocker Attachments: Screenshot-Java EE - kitchensink-search-ispn-slave-pom.xml - Eclipse .png ShrinkWrap BOM contains scoped artifacts. When bom is imported into <dependencyManagement> that scope is activated and overrides test scope, resulting with "runtime" dependencies being included as a part of resulting JAR/WAR/EAR archive. This is a serious usability flaw and therefore marking as Blocker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
9
0 / 0

[JBoss JIRA] (SHRINKRES-32) Enable dependency resolver to be cached for time-sensitive environments

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-32?page=com.atlassian.jira.plug... ] Karel Piwko resolved SHRINKRES-32. ---------------------------------- Resolution: Done Pushed upstream in https://github.com/shrinkwrap/resolver/commit/fb48072d4b614de35526f308e01... > Enable dependency resolver to be cached for time-sensitive environments > ----------------------------------------------------------------------- > > Key: SHRINKRES-32 > URL: https://issues.jboss.org/browse/SHRINKRES-32 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-alpha-1 > Reporter: Galder Zamarreño > Assignee: Karel Piwko > Fix For: 2.0.0-alpha-2 > > > In time sensitive environments, caching DependencyResolvers.use(classOf[MavenDependencyResolver]) would be very useful to avoid all the rewiring of plexus/aether/guice internals. So, once resolveAsXYZ() is has been called, it would be handy to do some cleanup, so that further artifacts can be resolved without the need to recreate the resolver. Here's an IRC chat: > {code}[10:17] <galderz> over last few days I discovered that DependencyResolvers.use(classOf[MavenDependencyResolver]) cannot be cached and reused > [10:17] <galderz> once you've resolved an artifact, that's somehow cached and new resolutions don't work > [10:18] <galderz> not being able to cache it sucks cos there's a lot of useless rewiring related to plexus/aether/guice that happens whenever DependencyResolvers.use(classOf[MavenDependencyResolver]) is called > [10:18] <galderz> kpiwko, any plans to improve this? > [10:18] <galderz> my use case of DependencyResolvers.use(classOf[MavenDependencyResolver]) is to use it when apps of a particular type are deployed, so time's gold :) > [10:19] <kpiwko> galderz: I see > [10:19] * maeste (~maeste4@redhat/jboss/maeste) has joined #jbosstesting > [10:19] <kpiwko> galderz: I was not thinking of such usage at all > [10:20] <galderz> kpiwko, i thought so, not the usual stuff > [10:20] <kpiwko> but it might be reasonable to clean the internal state after resolveAsXYZ() is called > [10:20] <kpiwko> however, the question here is, how far do you want to go with cleanup > [10:20] <galderz> in fact kpiwko, runnin SW resolver as a jboss module is not straightforward > [10:20] <galderz> u need to do some magic so that the plexus components.xml is found > [10:21] <galderz> kpiwko, yeah, i was thinking of smth like that > [10:21] <galderz> kpiwko, well, the cleanup should go as far as the maven artifcast/files that's it's resolved > [10:21] <galderz> i would not change any pom xml settings or anything > [10:21] <kpiwko> I see > [10:21] <kpiwko> can you file a jira about that? > [10:21] <galderz> kpiwko, think about: resolve library: x.y.z:1.1 and then, resolve: a.b.c.1.2.3 > [10:22] <kpiwko> I think that your approach make sense > [10:22] <galderz> kpiwko, sure > [10:22] * paul_dijou (51fcf764(a)gateway/web/freenode/ip.81.252.247.100) has joined #jbosstesting > [10:22] <galderz> kpiwko, https://issues.jboss.org/browse/SHRINKRES ? > [10:22] <kpiwko> yep{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-328) MavenDependencyResolver configureFrom should allow specifying properties for profile activation

by Marek Schmidt (JIRA)

MavenDependencyResolver configureFrom should allow specifying properties for profile activation ----------------------------------------------------------------------------------------------- Key: SHRINKWRAP-328 URL: https://issues.jboss.org/browse/SHRINKWRAP-328 Project: ShrinkWrap Issue Type: Feature Request Components: ext-resolver Reporter: Marek Schmidt also, profiles activated by negative property should be activated if there is no such property, or, alternatively, allow to explicitly select profiles to be activated, overriding the activation element. without such feature, profiles activated by a property or by a lack of property cannot be used from settings.xml https://github.com/shrinkwrap/resolver/blob/master/impl-maven/src/main/ja... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
6
0 / 0

[JBoss JIRA] (SHRINKRES-32) Enable dependency resolver to be cached for time-sensitive environments

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-32?page=com.atlassian.jira.plug... ] Galder Zamarreño commented on SHRINKRES-32: ------------------------------------------- This is not crucial any more since I'm now using Maven Aether directly when I need to only resolve dependencies. Less dependencies...etc. > Enable dependency resolver to be cached for time-sensitive environments > ----------------------------------------------------------------------- > > Key: SHRINKRES-32 > URL: https://issues.jboss.org/browse/SHRINKRES-32 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-alpha-1 > Reporter: Galder Zamarreño > Assignee: Karel Piwko > Fix For: 2.0.0-alpha-2 > > > In time sensitive environments, caching DependencyResolvers.use(classOf[MavenDependencyResolver]) would be very useful to avoid all the rewiring of plexus/aether/guice internals. So, once resolveAsXYZ() is has been called, it would be handy to do some cleanup, so that further artifacts can be resolved without the need to recreate the resolver. Here's an IRC chat: > {code}[10:17] <galderz> over last few days I discovered that DependencyResolvers.use(classOf[MavenDependencyResolver]) cannot be cached and reused > [10:17] <galderz> once you've resolved an artifact, that's somehow cached and new resolutions don't work > [10:18] <galderz> not being able to cache it sucks cos there's a lot of useless rewiring related to plexus/aether/guice that happens whenever DependencyResolvers.use(classOf[MavenDependencyResolver]) is called > [10:18] <galderz> kpiwko, any plans to improve this? > [10:18] <galderz> my use case of DependencyResolvers.use(classOf[MavenDependencyResolver]) is to use it when apps of a particular type are deployed, so time's gold :) > [10:19] <kpiwko> galderz: I see > [10:19] * maeste (~maeste4@redhat/jboss/maeste) has joined #jbosstesting > [10:19] <kpiwko> galderz: I was not thinking of such usage at all > [10:20] <galderz> kpiwko, i thought so, not the usual stuff > [10:20] <kpiwko> but it might be reasonable to clean the internal state after resolveAsXYZ() is called > [10:20] <kpiwko> however, the question here is, how far do you want to go with cleanup > [10:20] <galderz> in fact kpiwko, runnin SW resolver as a jboss module is not straightforward > [10:20] <galderz> u need to do some magic so that the plexus components.xml is found > [10:21] <galderz> kpiwko, yeah, i was thinking of smth like that > [10:21] <galderz> kpiwko, well, the cleanup should go as far as the maven artifcast/files that's it's resolved > [10:21] <galderz> i would not change any pom xml settings or anything > [10:21] <kpiwko> I see > [10:21] <kpiwko> can you file a jira about that? > [10:21] <galderz> kpiwko, think about: resolve library: x.y.z:1.1 and then, resolve: a.b.c.1.2.3 > [10:22] <kpiwko> I think that your approach make sense > [10:22] <galderz> kpiwko, sure > [10:22] * paul_dijou (51fcf764(a)gateway/web/freenode/ip.81.252.247.100) has joined #jbosstesting > [10:22] <galderz> kpiwko, https://issues.jboss.org/browse/SHRINKRES ? > [10:22] <kpiwko> yep{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-36) Update ShrinkWrap core to 1.0.0

by Karel Piwko (JIRA)

Karel Piwko created SHRINKRES-36: ------------------------------------ Summary: Update ShrinkWrap core to 1.0.0 Key: SHRINKRES-36 URL: https://issues.jboss.org/browse/SHRINKRES-36 Project: ShrinkWrap Resolvers Issue Type: Component Upgrade Reporter: Karel Piwko Assignee: Andrew Rubinger Update ShrinkWrap Core dependency to 1.0.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
2
0 / 0

[JBoss JIRA] (SHRINKRES-38) Support encrypted passwords for password protected repositories

by Karel Piwko (JIRA)

Karel Piwko created SHRINKRES-38: ------------------------------------ Summary: Support encrypted passwords for password protected repositories Key: SHRINKRES-38 URL: https://issues.jboss.org/browse/SHRINKRES-38 Project: ShrinkWrap Resolvers Issue Type: Feature Request Components: impl-maven Affects Versions: 2.0.0-alpha-1 Reporter: Karel Piwko Assignee: Andrew Rubinger settings.xml can contain encrypted password together with master password encrypted in a standalone file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-32) Enable dependency resolver to be cached for time-sensitive environments

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-32?page=com.atlassian.jira.plug... ] Andrew Rubinger reassigned SHRINKRES-32: ---------------------------------------- Assignee: Karel Piwko (was: Andrew Rubinger) Assigning internals work to Karel; we can jostle this around as needed. > Enable dependency resolver to be cached for time-sensitive environments > ----------------------------------------------------------------------- > > Key: SHRINKRES-32 > URL: https://issues.jboss.org/browse/SHRINKRES-32 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-alpha-1 > Reporter: Galder Zamarreño > Assignee: Karel Piwko > Fix For: 2.0.0-alpha-2 > > > In time sensitive environments, caching DependencyResolvers.use(classOf[MavenDependencyResolver]) would be very useful to avoid all the rewiring of plexus/aether/guice internals. So, once resolveAsXYZ() is has been called, it would be handy to do some cleanup, so that further artifacts can be resolved without the need to recreate the resolver. Here's an IRC chat: > {code}[10:17] <galderz> over last few days I discovered that DependencyResolvers.use(classOf[MavenDependencyResolver]) cannot be cached and reused > [10:17] <galderz> once you've resolved an artifact, that's somehow cached and new resolutions don't work > [10:18] <galderz> not being able to cache it sucks cos there's a lot of useless rewiring related to plexus/aether/guice that happens whenever DependencyResolvers.use(classOf[MavenDependencyResolver]) is called > [10:18] <galderz> kpiwko, any plans to improve this? > [10:18] <galderz> my use case of DependencyResolvers.use(classOf[MavenDependencyResolver]) is to use it when apps of a particular type are deployed, so time's gold :) > [10:19] <kpiwko> galderz: I see > [10:19] * maeste (~maeste4@redhat/jboss/maeste) has joined #jbosstesting > [10:19] <kpiwko> galderz: I was not thinking of such usage at all > [10:20] <galderz> kpiwko, i thought so, not the usual stuff > [10:20] <kpiwko> but it might be reasonable to clean the internal state after resolveAsXYZ() is called > [10:20] <kpiwko> however, the question here is, how far do you want to go with cleanup > [10:20] <galderz> in fact kpiwko, runnin SW resolver as a jboss module is not straightforward > [10:20] <galderz> u need to do some magic so that the plexus components.xml is found > [10:21] <galderz> kpiwko, yeah, i was thinking of smth like that > [10:21] <galderz> kpiwko, well, the cleanup should go as far as the maven artifcast/files that's it's resolved > [10:21] <galderz> i would not change any pom xml settings or anything > [10:21] <kpiwko> I see > [10:21] <kpiwko> can you file a jira about that? > [10:21] <galderz> kpiwko, think about: resolve library: x.y.z:1.1 and then, resolve: a.b.c.1.2.3 > [10:22] <kpiwko> I think that your approach make sense > [10:22] <galderz> kpiwko, sure > [10:22] * paul_dijou (51fcf764(a)gateway/web/freenode/ip.81.252.247.100) has joined #jbosstesting > [10:22] <galderz> kpiwko, https://issues.jboss.org/browse/SHRINKRES ? > [10:22] <kpiwko> yep{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues April 2012