[jira] [Updated] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated VELOCITY-970: Fix Version/s: 2.4 > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Assignee: Michael Osipov >Priority: Major > Fix For: 2.4 > > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-970: - Description: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since its package is renamed (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as a regular transitive dependency. was: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since its package is renamed (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mortagne updated VELOCITY-970: - Description: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since its package is renamed (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. was: commons-io is embedded in velocity-engine-core, which is OK from Java point of view since it's weaved (not causing any dependency problems). The problem is that it contains the commons-io Maven descriptors at the standard location (/META-INF/maven/commons-io/commons-io/), which is a problem when you analyze JAR files to find what's in it because it ends up being identified as a JAR exposing commons-io (which is not the case since it's weaved). Honestly, it feels very strange to embed commons-io in the first place given that commons-lang for example is a transitive dependency, so I feel like the simplest would just be to remove all the plumbing to embed and weave commons-io and simply keep it as transitive dependency. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
