[jira] [Comment Edited] (MNG-6276) Support reproducible builds
[
https://issues.apache.org/jira/browse/MNG-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143241#comment-16143241
]
Hervé Boutemy edited comment on MNG-6276 at 8/28/17 5:45 AM:
-
I like these 2 ideas:
- {{idempotent}} name, which gives {{project.build.idempotent}} property to
activate
- an annotation to mark plugins that are idempotent aware
the only drawback is that "reproducible builds" is the term that is widely used
and defined in https://reproducible-builds.org/
Notice that a search in Wikipedia gave me "deterministic compilation"
https://en.wikipedia.org/wiki/Deterministic_compilation
Perhaps "deterministic build" would be easier for normal people ("idempotent"
may be harder to understand)
was (Author: hboutemy):
I like these 2 ideas:
- {{idempotent}} name, which gives {{project.build.idempotent}} property to
activate
- an annotation to mark plugins that are idempotent aware
> Support reproducible builds
> ---
>
> Key: MNG-6276
> URL: https://issues.apache.org/jira/browse/MNG-6276
> Project: Maven
> Issue Type: New Feature
> Components: core, General
>Reporter: Paolo Sacconier
>
> A venerable build system like maven should support full build reproduibilty
> (i.e. producing bit a bit identical binaries from the same source).
> As initiatives like https://reproducible-builds.org gain traction and the
> news of the recent Debian policy change to mandate this build behavior (see
> https://reproducible.alioth.debian.org/blog/posts/121/), this seems a feature
> that needs to be considered for inclusion into maven core.
> There is an indipendent ongoing effort to support this feature and the author
> stated that he has found interest from maven project to integrate his work:
> https://github.com/Zlika/reproducible-build-maven-plugin/issues/6#issuecomment-325005883
> I hope this issue helps kickstart the effort.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6276) Support reproducible builds
[
https://issues.apache.org/jira/browse/MNG-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143241#comment-16143241
]
Hervé Boutemy commented on MNG-6276:
I like these 2 ideas:
- {{idempotent}} name, which gives {{project.build.idempotent}} property to
activate
- an annotation to mark plugins that are idempotent aware
> Support reproducible builds
> ---
>
> Key: MNG-6276
> URL: https://issues.apache.org/jira/browse/MNG-6276
> Project: Maven
> Issue Type: New Feature
> Components: core, General
>Reporter: Paolo Sacconier
>
> A venerable build system like maven should support full build reproduibilty
> (i.e. producing bit a bit identical binaries from the same source).
> As initiatives like https://reproducible-builds.org gain traction and the
> news of the recent Debian policy change to mandate this build behavior (see
> https://reproducible.alioth.debian.org/blog/posts/121/), this seems a feature
> that needs to be considered for inclusion into maven core.
> There is an indipendent ongoing effort to support this feature and the author
> stated that he has found interest from maven project to integrate his work:
> https://github.com/Zlika/reproducible-build-maven-plugin/issues/6#issuecomment-325005883
> I hope this issue helps kickstart the effort.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6276) Support reproducible builds
[
https://issues.apache.org/jira/browse/MNG-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143172#comment-16143172
]
Robert Scholte commented on MNG-6276:
-
I think {{idempotent}} is a better term, because is clearly states that its
result should be unchanged when executed multiple times. And maybe this is can
be handled the same way as threadsafety: introduce an annotation which states
that the plugin in idempotent aware.
> Support reproducible builds
> ---
>
> Key: MNG-6276
> URL: https://issues.apache.org/jira/browse/MNG-6276
> Project: Maven
> Issue Type: New Feature
> Components: core, General
>Reporter: Paolo Sacconier
>
> A venerable build system like maven should support full build reproduibilty
> (i.e. producing bit a bit identical binaries from the same source).
> As initiatives like https://reproducible-builds.org gain traction and the
> news of the recent Debian policy change to mandate this build behavior (see
> https://reproducible.alioth.debian.org/blog/posts/121/), this seems a feature
> that needs to be considered for inclusion into maven core.
> There is an indipendent ongoing effort to support this feature and the author
> stated that he has found interest from maven project to integrate his work:
> https://github.com/Zlika/reproducible-build-maven-plugin/issues/6#issuecomment-325005883
> I hope this issue helps kickstart the effort.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-6276) Support reproducible builds
[
https://issues.apache.org/jira/browse/MNG-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143124#comment-16143124
]
Hervé Boutemy edited comment on MNG-6276 at 8/27/17 2:39 PM:
-
Hi [~Zlika],
Good to see you there after Devoxx FR 2016 (already more than 1 year ago...):
thanks [~psacc] for bringing the issue here :)
As discussed with [~Zlika] at Devoxx, reproducible builds brings some
advantages but break "tagging" features that were intended: then it should
probably be opt-in, since one will have to choose between 2 interesting
behaviours (reproducible build vs intentionally tagged build: that is a matter
of taste)
And this op-in feature will have to be supported by many plugins: then we'll
need to define a convention to enable/disable this feature and get plugins to
implement it (Maven core plugins and also non-core plugins)
Defining this as a property with a conventional name seems the way to go. We
already have such conventional properties, like
{{project.build.sourceEncoding}} for source file encoding as documented in
https://cwiki.apache.org/confluence/display/MAVEN/POM+Element+for+Source+File+Encoding
The first step will be to define a name and document it, for example in Maven
Wiki like source encoding.
Then we'll have to see what plugins require to be modified to support this
option: like source encoding, we can maintain a list in the wiki with pointers.
Ok for everybody?
First is the property name: something like {{project.build.reproducible}}?
Should it be a boolean? With default value as false, and requires {{true}} to
activate: that would be quite natural.
Should it be a timestamp, since a lot of plugins will have to set a timestamps
to files, and you'll need a way to define the conventional timestamp value for
a build (or let any build have the same timestamp).
Any preference from people who have already worked on the topic?
was (Author: hboutemy):
Hi [~Zlika],
Good to see you there after Devoxx FR 2016 (already more than 1 year ago...):
thanks [~psacc] for bringing the issue here :)
As discussed with [~Zlika] at Devoxx, reproducible builds have advantages
breaks "tagging" features that were intended: then it should probably be
opt-in, since one will have to choose between 2 interesting behaviours
(reproducible build vs intentionally tagged build)
And this op-in feature will have to be supported by many plugins: then we'll
need to define a convention to enable/disable this feature and get plugins to
implement it (Maven core plugins and also non-core plugins)
Defining this as a property with a conventional name seems the way to go. We
already have such conventional properties, like
{{project.build.sourceEncoding}} for source file encoding as documented in
https://cwiki.apache.org/confluence/display/MAVEN/POM+Element+for+Source+File+Encoding
The first step will be to define a name and document it, for example in Maven
Wiki like source encoding.
Then we'll have to see what plugins require to be modified to support this
option: like source encoding, we can maintain a list in the wiki with pointers.
Ok for everybody?
First is the property name: something like {{project.build.reproducible}}?
Should it be a boolean? With default value as false, and requires {{true}} to
activate: that would be quite natural.
Should it be a timestamp, since a lot of plugins will have to set a timestamps
to files, and you'll need a way to define the conventional timestamp value for
a build (or let any build have the same timestamp).
Any preference from people who have already worked on the topic?
> Support reproducible builds
> ---
>
> Key: MNG-6276
> URL: https://issues.apache.org/jira/browse/MNG-6276
> Project: Maven
> Issue Type: New Feature
> Components: core, General
>Reporter: Paolo Sacconier
>
> A venerable build system like maven should support full build reproduibilty
> (i.e. producing bit a bit identical binaries from the same source).
> As initiatives like https://reproducible-builds.org gain traction and the
> news of the recent Debian policy change to mandate this build behavior (see
> https://reproducible.alioth.debian.org/blog/posts/121/), this seems a feature
> that needs to be considered for inclusion into maven core.
> There is an indipendent ongoing effort to support this feature and the author
> stated that he has found interest from maven project to integrate his work:
> https://github.com/Zlika/reproducible-build-maven-plugin/issues/6#issuecomment-325005883
> I hope this issue helps kickstart the effort.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6276) Support reproducible builds
[
https://issues.apache.org/jira/browse/MNG-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143124#comment-16143124
]
Hervé Boutemy commented on MNG-6276:
Hi [~Zlika],
Good to see you there after Devoxx FR 2016 (already more than 1 year ago...):
thanks [~psacc] for bringing the issue here :)
As discussed with [~Zlika] at Devoxx, reproducible builds have advantages
breaks "tagging" features that were intended: then it should probably be
opt-in, since one will have to choose between 2 interesting behaviours
(reproducible build vs intentionally tagged build)
And this op-in feature will have to be supported by many plugins: then we'll
need to define a convention to enable/disable this feature and get plugins to
implement it (Maven core plugins and also non-core plugins)
Defining this as a property with a conventional name seems the way to go. We
already have such conventional properties, like
{{project.build.sourceEncoding}} for source file encoding as documented in
https://cwiki.apache.org/confluence/display/MAVEN/POM+Element+for+Source+File+Encoding
The first step will be to define a name and document it, for example in Maven
Wiki like source encoding.
Then we'll have to see what plugins require to be modified to support this
option: like source encoding, we can maintain a list in the wiki with pointers.
Ok for everybody?
First is the property name: something like {{project.build.reproducible}}?
Should it be a boolean? With default value as false, and requires {{true}} to
activate: that would be quite natural.
Should it be a timestamp, since a lot of plugins will have to set a timestamps
to files, and you'll need a way to define the conventional timestamp value for
a build (or let any build have the same timestamp).
Any preference from people who have already worked on the topic?
> Support reproducible builds
> ---
>
> Key: MNG-6276
> URL: https://issues.apache.org/jira/browse/MNG-6276
> Project: Maven
> Issue Type: New Feature
> Components: core, General
>Reporter: Paolo Sacconier
>
> A venerable build system like maven should support full build reproduibilty
> (i.e. producing bit a bit identical binaries from the same source).
> As initiatives like https://reproducible-builds.org gain traction and the
> news of the recent Debian policy change to mandate this build behavior (see
> https://reproducible.alioth.debian.org/blog/posts/121/), this seems a feature
> that needs to be considered for inclusion into maven core.
> There is an indipendent ongoing effort to support this feature and the author
> stated that he has found interest from maven project to integrate his work:
> https://github.com/Zlika/reproducible-build-maven-plugin/issues/6#issuecomment-325005883
> I hope this issue helps kickstart the effort.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MEAR-248) Support lookup-name in env-entry section
[
https://issues.apache.org/jira/browse/MEAR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143119#comment-16143119
]
Hudson commented on MEAR-248:
-
SUCCESS: Integrated in Jenkins build maven-plugins #9079 (See
[https://builds.apache.org/job/maven-plugins/9079/])
[MEAR-248] Support lookup-name in env-entry section
o Added lookup-name in env-entry section. (khmarbaise:
[http://svn.apache.org/viewvc/?view=rev&rev=1806368])
* (edit)
maven-ear-plugin/src/main/java/org/apache/maven/plugins/ear/EnvEntry.java
* (edit)
maven-ear-plugin/src/main/java/org/apache/maven/plugins/ear/GenerateApplicationXmlMojo.java
* (edit)
maven-ear-plugin/src/site/apt/examples/specifying-env-entries-for-the-generated-application-xml.apt.vm
* (edit)
maven-ear-plugin/src/test/java/org/apache/maven/plugins/ear/EnvEntryTest.java
> Support lookup-name in env-entry section
>
>
> Key: MEAR-248
> URL: https://issues.apache.org/jira/browse/MEAR-248
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.10.1
>Reporter: Thomas Seidel
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> Add support for lookup-name tag in env-entry section to support JNDI lookup.
> Currently, this tag is ignored in generated application.xml.
> Example:
> The pom.xml snippet
> {code:xml}
>
>
> ExampleString
> java.lang.String
> java:global/Example
>
>
> {code}
> should generate application.xml with
> {code:xml}
> ExampleString
> java.lang.String
> java:global/Example
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MEAR-230) Using App Client Example
[
https://issues.apache.org/jira/browse/MEAR-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MEAR-230.
Resolution: Not A Problem
Assignee: Karl Heinz Marbaise
Fix Version/s: (was: 3.0.0)
The reason is simply cause the maven-acr-plugin defines it own packaging type
{{app-client}} which means the usage of {{extentions}} is mandatory. So no
problem here.
> Using App Client Example
>
>
> Key: MEAR-230
> URL: https://issues.apache.org/jira/browse/MEAR-230
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.10.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
>
> The example
> https://maven.apache.org/plugins/maven-ear-plugin/examples/using-app-client.html
> should be checked and why it uses extensions true for maven-acr-plugin
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MEAR-248) Support lookup-name in env-entry section
[
https://issues.apache.org/jira/browse/MEAR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MEAR-248.
Resolution: Fixed
Done in [r1806368|https://svn.apache.org/r1806368]
> Support lookup-name in env-entry section
>
>
> Key: MEAR-248
> URL: https://issues.apache.org/jira/browse/MEAR-248
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.10.1
>Reporter: Thomas Seidel
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> Add support for lookup-name tag in env-entry section to support JNDI lookup.
> Currently, this tag is ignored in generated application.xml.
> Example:
> The pom.xml snippet
> {code:xml}
>
>
> ExampleString
> java.lang.String
> java:global/Example
>
>
> {code}
> should generate application.xml with
> {code:xml}
> ExampleString
> java.lang.String
> java:global/Example
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MEAR-247) resource-ref in generated application.xml
[ https://issues.apache.org/jira/browse/MEAR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143107#comment-16143107 ] Hudson commented on MEAR-247: - SUCCESS: Integrated in Jenkins build maven-plugins #9078 (See [https://builds.apache.org/job/maven-plugins/9078/]) [MEAR-247] resource-ref in generated application.xml o Added the generation of resource-ref entries in application.xml (khmarbaise: [http://svn.apache.org/viewvc/?view=rev&rev=1806364]) * (edit) maven-ear-plugin/src/main/java/org/apache/maven/plugins/ear/ApplicationXmlWriter.java * (edit) maven-ear-plugin/src/main/java/org/apache/maven/plugins/ear/ApplicationXmlWriterContext.java * (edit) maven-ear-plugin/src/main/java/org/apache/maven/plugins/ear/GenerateApplicationXmlMojo.java * (add) maven-ear-plugin/src/main/java/org/apache/maven/plugins/ear/ResourceRef.java * (add) maven-ear-plugin/src/site/apt/examples/specifying-resource-ref-entries-for-the-generated-application-xml.apt.vm * (edit) maven-ear-plugin/src/site/apt/index.apt.vm > resource-ref in generated application.xml > - > > Key: MEAR-247 > URL: https://issues.apache.org/jira/browse/MEAR-247 > Project: Maven Ear Plugin > Issue Type: New Feature >Reporter: Yannick Majoros >Assignee: Karl Heinz Marbaise > Fix For: 3.0.0 > > > It seems more people would like to have that. > I have 5 applications sharing the same persistence module and needing some > resource-ref to have different db connections (dba requirement :-( ). > Seems more people would want it: > http://stackoverflow.com/questions/26113079/resource-ref-in-maven-generated-application-descriptor > http://stackoverflow.com/questions/33520956/generate-resource-env-ref-entries-in-maven-ear-plugin-generated-application-xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MEAR-248) Support lookup-name in env-entry section
[
https://issues.apache.org/jira/browse/MEAR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MEAR-248:
-
Fix Version/s: 3.0.0
> Support lookup-name in env-entry section
>
>
> Key: MEAR-248
> URL: https://issues.apache.org/jira/browse/MEAR-248
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.10.1
>Reporter: Thomas Seidel
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> Add support for lookup-name tag in env-entry section to support JNDI lookup.
> Currently, this tag is ignored in generated application.xml.
> Example:
> The pom.xml snippet
> {code:xml}
>
>
> ExampleString
> java.lang.String
> java:global/Example
>
>
> {code}
> should generate application.xml with
> {code:xml}
> ExampleString
> java.lang.String
> java:global/Example
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MEAR-248) Support lookup-name in env-entry section
[
https://issues.apache.org/jira/browse/MEAR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MEAR-248:
Assignee: Karl Heinz Marbaise
> Support lookup-name in env-entry section
>
>
> Key: MEAR-248
> URL: https://issues.apache.org/jira/browse/MEAR-248
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.10.1
>Reporter: Thomas Seidel
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> Add support for lookup-name tag in env-entry section to support JNDI lookup.
> Currently, this tag is ignored in generated application.xml.
> Example:
> The pom.xml snippet
> {code:xml}
>
>
> ExampleString
> java.lang.String
> java:global/Example
>
>
> {code}
> should generate application.xml with
> {code:xml}
> ExampleString
> java.lang.String
> java:global/Example
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MEAR-248) Support lookup-name in env-entry section
[
https://issues.apache.org/jira/browse/MEAR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143106#comment-16143106
]
Karl Heinz Marbaise commented on MEAR-248:
--
The first thing is your example is not correct cause it must look like this(see
docs):
{code:xml}
ExampleString
java.lang.String
java:global/Example
{code}
Apart from that yes you are right {{lookup-name}} is not supported yet. This
can be achieved easily.
> Support lookup-name in env-entry section
>
>
> Key: MEAR-248
> URL: https://issues.apache.org/jira/browse/MEAR-248
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.10.1
>Reporter: Thomas Seidel
> Fix For: 3.0.0
>
>
> Add support for lookup-name tag in env-entry section to support JNDI lookup.
> Currently, this tag is ignored in generated application.xml.
> Example:
> The pom.xml snippet
> {code:xml}
>
>
> ExampleString
> java.lang.String
> java:global/Example
>
>
> {code}
> should generate application.xml with
> {code:xml}
> ExampleString
> java.lang.String
> java:global/Example
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MEAR-247) resource-ref in generated application.xml
[ https://issues.apache.org/jira/browse/MEAR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MEAR-247. Resolution: Fixed Done in [r1806364|https://svn.apache.org/r1806364] > resource-ref in generated application.xml > - > > Key: MEAR-247 > URL: https://issues.apache.org/jira/browse/MEAR-247 > Project: Maven Ear Plugin > Issue Type: New Feature >Reporter: Yannick Majoros >Assignee: Karl Heinz Marbaise > Fix For: 3.0.0 > > > It seems more people would like to have that. > I have 5 applications sharing the same persistence module and needing some > resource-ref to have different db connections (dba requirement :-( ). > Seems more people would want it: > http://stackoverflow.com/questions/26113079/resource-ref-in-maven-generated-application-descriptor > http://stackoverflow.com/questions/33520956/generate-resource-env-ref-entries-in-maven-ear-plugin-generated-application-xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MEAR-247) resource-ref in generated application.xml
[ https://issues.apache.org/jira/browse/MEAR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MEAR-247: - Fix Version/s: 3.0.0 > resource-ref in generated application.xml > - > > Key: MEAR-247 > URL: https://issues.apache.org/jira/browse/MEAR-247 > Project: Maven Ear Plugin > Issue Type: New Feature >Reporter: Yannick Majoros >Assignee: Karl Heinz Marbaise > Fix For: 3.0.0 > > > It seems more people would like to have that. > I have 5 applications sharing the same persistence module and needing some > resource-ref to have different db connections (dba requirement :-( ). > Seems more people would want it: > http://stackoverflow.com/questions/26113079/resource-ref-in-maven-generated-application-descriptor > http://stackoverflow.com/questions/33520956/generate-resource-env-ref-entries-in-maven-ear-plugin-generated-application-xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MEAR-247) resource-ref in generated application.xml
[ https://issues.apache.org/jira/browse/MEAR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MEAR-247: Assignee: Karl Heinz Marbaise > resource-ref in generated application.xml > - > > Key: MEAR-247 > URL: https://issues.apache.org/jira/browse/MEAR-247 > Project: Maven Ear Plugin > Issue Type: New Feature >Reporter: Yannick Majoros >Assignee: Karl Heinz Marbaise > Fix For: 3.0.0 > > > It seems more people would like to have that. > I have 5 applications sharing the same persistence module and needing some > resource-ref to have different db connections (dba requirement :-( ). > Seems more people would want it: > http://stackoverflow.com/questions/26113079/resource-ref-in-maven-generated-application-descriptor > http://stackoverflow.com/questions/33520956/generate-resource-env-ref-entries-in-maven-ear-plugin-generated-application-xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MEAR-249) Maven EAR plugin - two libraries with a same ArtifactId
[ https://issues.apache.org/jira/browse/MEAR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MEAR-249: - Affects Version/s: waiting-for-feedback > Maven EAR plugin - two libraries with a same ArtifactId > --- > > Key: MEAR-249 > URL: https://issues.apache.org/jira/browse/MEAR-249 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: waiting-for-feedback >Reporter: Tomas Tulka > > When an EAR module has two (or more) dependencies with a same artifactId, > Maven copy those into the /lib directory and one rewrites the other. In the > end there is only one library in the EAR. > This is not what I would expect, because it is correct to have such > dependencies. The plugin should deal with it or print a warning (it's a > tricky issue when it is about transitive dependencies). > > com.group1 > same-artifact > > > com.group2 > same-artifact > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MEAR-226) bundleFileName functionality for the acr plugin
[ https://issues.apache.org/jira/browse/MEAR-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143090#comment-16143090 ] Hudson commented on MEAR-226: - SUCCESS: Integrated in Jenkins build maven-plugins #9077 (See [https://builds.apache.org/job/maven-plugins/9077/]) [MEAR-226] bundleFileName functionality for the acr plugin o Added AcrModule implementation to make bundleFileName configuration possible. (khmarbaise: [http://svn.apache.org/viewvc/?view=rev&rev=1806351]) * (add) maven-ear-plugin/src/main/java/org/apache/maven/plugins/ear/AcrModule.java > bundleFileName functionality for the acr plugin > --- > > Key: MEAR-226 > URL: https://issues.apache.org/jira/browse/MEAR-226 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.10.1 >Reporter: Sud Ramasamy >Assignee: Karl Heinz Marbaise > Fix For: 3.0.0 > > > We'd have a need to rename the Java EE Application Client jar that is > packaged in our EAR using the acr plugin. The canonical way to do this is > perhaps along the following lines: > >com.mine >test >myrenamed.jar > > But this is not supported. I'd be happy to contribute this change if I can > receive some pointers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MEAR-249) Maven EAR plugin - two libraries with a same ArtifactId
[
https://issues.apache.org/jira/browse/MEAR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143089#comment-16143089
]
Karl Heinz Marbaise commented on MEAR-249:
--
After rechecking this with version 2.10.1 which already produces WARNING's in
such cases:
{code}
[INFO] --- maven-ear-plugin:2.10.1:ear (default-ear) @ app ---
[WARNING] The artifactId service:3.4.6-SNAPSHOT exists more than once in the
modules list.
[WARNING] --> com.soebes.examples.j2ee:service:ejb:3.4.6-SNAPSHOT (ejb)
[WARNING] --> com.soebes.examples:service:ejb:3.4.6-SNAPSHOT (ejb)
[WARNING] HINT: This can be simply solved by using the
full
{code}
Based on the published date of maven-ear-plugin:2.10.1 (2015-06-27) I assume
this is related to the last released version...
The question is: Printing out a warning is done...What do you have in mind by
"The plugin should deal with it..."?
I think it's a good time to make this WARNING into an error, cause the result
can't be correct in the end. This means changing the behaviour to fail the
build in such cases.
> Maven EAR plugin - two libraries with a same ArtifactId
> ---
>
> Key: MEAR-249
> URL: https://issues.apache.org/jira/browse/MEAR-249
> Project: Maven Ear Plugin
> Issue Type: Bug
>Reporter: Tomas Tulka
>
> When an EAR module has two (or more) dependencies with a same artifactId,
> Maven copy those into the /lib directory and one rewrites the other. In the
> end there is only one library in the EAR.
> This is not what I would expect, because it is correct to have such
> dependencies. The plugin should deal with it or print a warning (it's a
> tricky issue when it is about transitive dependencies).
>
> com.group1
> same-artifact
>
>
> com.group2
> same-artifact
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MEAR-212) Failed to initialize ear modules: Unknown artifact type[mar] for addressing
[
https://issues.apache.org/jira/browse/MEAR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143087#comment-16143087
]
Karl Heinz Marbaise commented on MEAR-212:
--
If we really need this we have to find out how a {{MAR}} file looks like and
create a separate plugin to create such kind of files and afterwards we can
enhance maven-ear-plugin accordingly.
> Failed to initialize ear modules: Unknown artifact type[mar] for addressing
> ---
>
> Key: MEAR-212
> URL: https://issues.apache.org/jira/browse/MEAR-212
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.10
>Reporter: David Hoffer
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I'm trying to generate and ear file but I'm getting the following message:
> Failed to initialize ear modules: Unknown artifact type[mar] for addressing
> (full debug stack trace is below)
> However I don't have any mar artifacts in my dependencies. What I do have is
> a war that has 4 mar files added as resources and I'm making a ear with the
> skinny war feature.
> Why would the ear plugin give this error when it has no nothing to do with
> the mar resources in the war...or perhaps this error has nothing to do with
> those resources, not sure.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project coreservices-ear: Failed to
> initialize ear modules: Unknown artifact type[mar] for addressing -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project coreservices-ear: Failed to
> initialize ear modules
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
> initialize ear modules
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:260)
> at
> org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:162)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown
> artifact type[mar] for addressing
> at
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
> ... 22 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MEAR-226) bundleFileName functionality for the acr plugin
[ https://issues.apache.org/jira/browse/MEAR-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MEAR-226. Resolution: Fixed Done in [r1806351|https://svn.apache.org/r1806351] > bundleFileName functionality for the acr plugin > --- > > Key: MEAR-226 > URL: https://issues.apache.org/jira/browse/MEAR-226 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.10.1 >Reporter: Sud Ramasamy >Assignee: Karl Heinz Marbaise > Fix For: 3.0.0 > > > We'd have a need to rename the Java EE Application Client jar that is > packaged in our EAR using the acr plugin. The canonical way to do this is > perhaps along the following lines: > >com.mine >test >myrenamed.jar > > But this is not supported. I'd be happy to contribute this change if I can > receive some pointers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MEAR-226) bundleFileName functionality for the acr plugin
[ https://issues.apache.org/jira/browse/MEAR-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MEAR-226: - Fix Version/s: 3.0.0 > bundleFileName functionality for the acr plugin > --- > > Key: MEAR-226 > URL: https://issues.apache.org/jira/browse/MEAR-226 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.10.1 >Reporter: Sud Ramasamy > Fix For: 3.0.0 > > > We'd have a need to rename the Java EE Application Client jar that is > packaged in our EAR using the acr plugin. The canonical way to do this is > perhaps along the following lines: > >com.mine >test >myrenamed.jar > > But this is not supported. I'd be happy to contribute this change if I can > receive some pointers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MEAR-226) bundleFileName functionality for the acr plugin
[ https://issues.apache.org/jira/browse/MEAR-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MEAR-226: Assignee: Karl Heinz Marbaise > bundleFileName functionality for the acr plugin > --- > > Key: MEAR-226 > URL: https://issues.apache.org/jira/browse/MEAR-226 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.10.1 >Reporter: Sud Ramasamy >Assignee: Karl Heinz Marbaise > Fix For: 3.0.0 > > > We'd have a need to rename the Java EE Application Client jar that is > packaged in our EAR using the acr plugin. The canonical way to do this is > perhaps along the following lines: > >com.mine >test >myrenamed.jar > > But this is not supported. I'd be happy to contribute this change if I can > receive some pointers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6276) Support reproducible builds
[
https://issues.apache.org/jira/browse/MNG-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143074#comment-16143074
]
Zlika commented on MNG-6276:
Hi. I'm the author of the [reproducible-build-maven
plugin|http://zlika.github.io/reproducible-build-maven-plugin/]. I gave a talk
at Devoxx France 2016 on this subject (cf. [slides
here|http://zlika.github.io/presentations/devoxx_fr_2016/reproducible-builds/slides_en.html])
and after this talk I had the opportunity to talk with [~hboutemy] from ASF.
He advised me to create a ticket on the Maven JIRA to propose such a feature.
I'm a little bit late, but thanks to [~psacc], here it is! :-)
To have a reproducible build feature in Maven, some of its core plugins (and/or
dependencies) are concerned, like maven-jar-plugin, maven-assembly-plugin...
At least the following things must be done:
* Remove unecessary timestamps, usernames and tool versions in files like
MANIFEST.MF, pom.properties...
* Sorts zip entries of the JAR files (so that the order does not depend on
their order in the user's filesystem) and remove file timestamps.
I think it should be an "opt-in" feature, so it would be nice to have a global
property like {noformat}${project.build.reproducibleBuild}{noformat} to
enable/disable this feature with a one-liner.
Regards
> Support reproducible builds
> ---
>
> Key: MNG-6276
> URL: https://issues.apache.org/jira/browse/MNG-6276
> Project: Maven
> Issue Type: New Feature
> Components: core, General
>Reporter: Paolo Sacconier
>
> A venerable build system like maven should support full build reproduibilty
> (i.e. producing bit a bit identical binaries from the same source).
> As initiatives like https://reproducible-builds.org gain traction and the
> news of the recent Debian policy change to mandate this build behavior (see
> https://reproducible.alioth.debian.org/blog/posts/121/), this seems a feature
> that needs to be considered for inclusion into maven core.
> There is an indipendent ongoing effort to support this feature and the author
> stated that he has found interest from maven project to integrate his work:
> https://github.com/Zlika/reproducible-build-maven-plugin/issues/6#issuecomment-325005883
> I hope this issue helps kickstart the effort.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MWAR-410) Upgrade plexus-utils to version 3.1.0
[ https://issues.apache.org/jira/browse/MWAR-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143073#comment-16143073 ] Hudson commented on MWAR-410: - SUCCESS: Integrated in Jenkins build maven-plugins #9076 (See [https://builds.apache.org/job/maven-plugins/9076/]) [MWAR-410] Upgrade plexus-utils to version 3.1.0 (khmarbaise: [http://svn.apache.org/viewvc/?view=rev&rev=1806347]) * (edit) maven-war-plugin/pom.xml > Upgrade plexus-utils to version 3.1.0 > - > > Key: MWAR-410 > URL: https://issues.apache.org/jira/browse/MWAR-410 > Project: Maven WAR Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MWAR-410) Upgrade plexus-utils to version 3.1.0
[ https://issues.apache.org/jira/browse/MWAR-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MWAR-410. Resolution: Fixed Done in [r1806347|https://svn.apache.org/r1806347] > Upgrade plexus-utils to version 3.1.0 > - > > Key: MWAR-410 > URL: https://issues.apache.org/jira/browse/MWAR-410 > Project: Maven WAR Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MWAR-410) Upgrade plexus-utils to version 3.1.0
Karl Heinz Marbaise created MWAR-410: Summary: Upgrade plexus-utils to version 3.1.0 Key: MWAR-410 URL: https://issues.apache.org/jira/browse/MWAR-410 Project: Maven WAR Plugin Issue Type: Dependency upgrade Affects Versions: 3.2.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: 3.2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
