January 2014 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-164) Support encoding property from Maven compiler plugin

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-164?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-164: ---------------------------------- Fix Version/s: 2.1.0 > Support encoding property from Maven compiler plugin > ---------------------------------------------------- > > Key: SHRINKRES-164 > URL: https://issues.jboss.org/browse/SHRINKRES-164 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.2 > Reporter: Thilo Mezger > Assignee: Karel Piwko > Fix For: 2.1.0 > > > I'd like to suggest that org.jboss.shrinkwrap.resolver.impl.maven.archive.plugins.CompilerPluginConfiguration should support the "encoding" property of the maven-compiler-plugin just like it supports "source" and "target". > I know that you can use "compilerArgs" to pass any parameter but that wouldn't be obvious when you have this special "encoding" parameter in maven-compiler-plugin. Everyone would expect that this setting is passed on. > And things can really go wrong in all magic ways if you compile your files with the wrong encoding... -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-164) Support encoding property from Maven compiler plugin

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-164?page=com.atlassian.jira.plu... ] Karel Piwko reassigned SHRINKRES-164: ------------------------------------- Assignee: Karel Piwko (was: Andrew Rubinger) > Support encoding property from Maven compiler plugin > ---------------------------------------------------- > > Key: SHRINKRES-164 > URL: https://issues.jboss.org/browse/SHRINKRES-164 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Reporter: Thilo Mezger > Assignee: Karel Piwko > > I'd like to suggest that org.jboss.shrinkwrap.resolver.impl.maven.archive.plugins.CompilerPluginConfiguration should support the "encoding" property of the maven-compiler-plugin just like it supports "source" and "target". > I know that you can use "compilerArgs" to pass any parameter but that wouldn't be obvious when you have this special "encoding" parameter in maven-compiler-plugin. Everyone would expect that this setting is passed on. > And things can really go wrong in all magic ways if you compile your files with the wrong encoding... -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-164) Support encoding property from Maven compiler plugin

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-164?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-164: ---------------------------------- Affects Version/s: 2.0.2 > Support encoding property from Maven compiler plugin > ---------------------------------------------------- > > Key: SHRINKRES-164 > URL: https://issues.jboss.org/browse/SHRINKRES-164 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.2 > Reporter: Thilo Mezger > Assignee: Karel Piwko > > I'd like to suggest that org.jboss.shrinkwrap.resolver.impl.maven.archive.plugins.CompilerPluginConfiguration should support the "encoding" property of the maven-compiler-plugin just like it supports "source" and "target". > I know that you can use "compilerArgs" to pass any parameter but that wouldn't be obvious when you have this special "encoding" parameter in maven-compiler-plugin. Everyone would expect that this setting is passed on. > And things can really go wrong in all magic ways if you compile your files with the wrong encoding... -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-164) Support encoding property from Maven compiler plugin

by Thilo Mezger (JIRA)

Thilo Mezger created SHRINKRES-164: -------------------------------------- Summary: Support encoding property from Maven compiler plugin Key: SHRINKRES-164 URL: https://issues.jboss.org/browse/SHRINKRES-164 Project: ShrinkWrap Resolvers Issue Type: Feature Request Components: impl-maven Reporter: Thilo Mezger Assignee: Andrew Rubinger I'd like to suggest that org.jboss.shrinkwrap.resolver.impl.maven.archive.plugins.CompilerPluginConfiguration should support the "encoding" property of the maven-compiler-plugin just like it supports "source" and "target". I know that you can use "compilerArgs" to pass any parameter but that wouldn't be obvious when you have this special "encoding" parameter in maven-compiler-plugin. Everyone would expect that this setting is passed on. And things can really go wrong in all magic ways if you compile your files with the wrong encoding... -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-162) Resolved file extension returned instead of packaging type in MavenResolvedArtifact

by Johan Evelönn (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-162?page=com.atlassian.jira.plu... ] Johan Evelönn updated SHRINKRES-162: ------------------------------------ Priority: Major (was: Minor) > Resolved file extension returned instead of packaging type in MavenResolvedArtifact > ----------------------------------------------------------------------------------- > > Key: SHRINKRES-162 > URL: https://issues.jboss.org/browse/SHRINKRES-162 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Affects Versions: 2.0.1 > Reporter: Johan Evelönn > Assignee: Andrew Rubinger > > When declaring a dependency in a pom.xml with the type EJB and then resolving it into a MavenResolvedArtifact the method getCoordinate().getPackagingType() returns PackagingType.JAR instead of PackagingType.EJB. So it seems like it sets the PackagingType to the extension of the resolved file. It works fine when a dependency has type war, since type and extension is the same. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-163) Implements importTestBuildOutput for type JAR

by Karel Piwko (JIRA)

Karel Piwko created SHRINKRES-163: ------------------------------------- Summary: Implements importTestBuildOutput for type JAR Key: SHRINKRES-163 URL: https://issues.jboss.org/browse/SHRINKRES-163 Project: ShrinkWrap Resolvers Issue Type: Bug Components: impl-maven Affects Versions: 2.0.2 Reporter: Karel Piwko While default use case - merging src/main and src/test together might not be seen as useful, there is at least an option that user will be willing to import src/test only. That said, implementing importTestBuildOutput() for a archive of type jar is a valid operation. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-151) Descriptors should generate a common parent for different spec versions

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-151?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-151: -------------------------------------------- Thanks George Cool:-) This helps indeed. I will continue with this. > Descriptors should generate a common parent for different spec versions > ----------------------------------------------------------------------- > > Key: SHRINKDESC-151 > URL: https://issues.jboss.org/browse/SHRINKDESC-151 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Components: api-javaee > Reporter: George Gastaldi > Assignee: Ralf Battenfeld > > This affects only the JavaEE API. Some usecases manipulate descriptors regardless of the version it is currently on. The API could be abstracted to a common interface so that common element types to the supported complex types could be used. > A sample is provided in https://github.com/forge/javaee-descriptors/. The IMPL remains untouched (as generated by the ShrinkWrap generator) and common types are refactored to a super interface: > Super Interface: https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > Sub Interfaces: > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > The generated code doesn't need to change either. The existence of the super interface is what matters most. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-151) Descriptors should generate a common parent for different spec versions

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-151?page=com.atlassian.jira.pl... ] George Gastaldi commented on SHRINKDESC-151: -------------------------------------------- Hi Ralf, Good job on the webApp descriptor subtypes. This is complex indeed. This is an example using the persistenceUnit/properties/property nesting, hope it helps: https://github.com/forge/javaee-descriptors/commit/f278ef8e51f6035bfac045... > Descriptors should generate a common parent for different spec versions > ----------------------------------------------------------------------- > > Key: SHRINKDESC-151 > URL: https://issues.jboss.org/browse/SHRINKDESC-151 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Components: api-javaee > Reporter: George Gastaldi > Assignee: Ralf Battenfeld > > This affects only the JavaEE API. Some usecases manipulate descriptors regardless of the version it is currently on. The API could be abstracted to a common interface so that common element types to the supported complex types could be used. > A sample is provided in https://github.com/forge/javaee-descriptors/. The IMPL remains untouched (as generated by the ShrinkWrap generator) and common types are refactored to a super interface: > Super Interface: https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > Sub Interfaces: > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > The generated code doesn't need to change either. The existence of the super interface is what matters most. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-151) Descriptors should generate a common parent for different spec versions

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-151?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-151: -------------------------------------------- I spent a lot time to find out a way of generating all the common and common sub type classes. I couldn't find a solution for the fact, that we have to generate descriptors in a isolated manner, e.g. JavaEE5 cannot be mixed with JavaEE6 but for an automated way, this is required... Ok, I spent therefore more time in the way of declaring the common types. As you can see, I configured all the webApp descriptor sub types. This should work. I also made it possible to generate a common sub sub type:-) Here you can help me. How do you want to touch such sub sub types? Casting directly from the original sub type? Or do you want to touch it from the common sub type? If yes, then you have to show me how. I am lost in the generics universe :-) > Descriptors should generate a common parent for different spec versions > ----------------------------------------------------------------------- > > Key: SHRINKDESC-151 > URL: https://issues.jboss.org/browse/SHRINKDESC-151 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Components: api-javaee > Reporter: George Gastaldi > Assignee: Ralf Battenfeld > > This affects only the JavaEE API. Some usecases manipulate descriptors regardless of the version it is currently on. The API could be abstracted to a common interface so that common element types to the supported complex types could be used. > A sample is provided in https://github.com/forge/javaee-descriptors/. The IMPL remains untouched (as generated by the ShrinkWrap generator) and common types are refactored to a super interface: > Super Interface: https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > Sub Interfaces: > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > The generated code doesn't need to change either. The existence of the super interface is what matters most. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-162) Resolved file extension returned instead of packaging type in MavenResolvedArtifact

by Johan Evelönn (JIRA)

Johan Evelönn created SHRINKRES-162: --------------------------------------- Summary: Resolved file extension returned instead of packaging type in MavenResolvedArtifact Key: SHRINKRES-162 URL: https://issues.jboss.org/browse/SHRINKRES-162 Project: ShrinkWrap Resolvers Issue Type: Bug Affects Versions: 2.0.1 Reporter: Johan Evelönn Assignee: Andrew Rubinger Priority: Minor When declaring a dependency in a pom.xml with the type EJB and then resolving it into a MavenResolvedArtifact the method getCoordinate().getPackagingType() returns PackagingType.JAR instead of PackagingType.EJB. So it seems like it sets the PackagingType to the extension of the resolved file. It works fine when a dependency has type war, since type and extension is the same. -- 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, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues January 2014