[jira] [Commented] (MASSEMBLY-989) in RB mode, apply 022 umask to ignore environment group write umask
[ https://issues.apache.org/jira/browse/MASSEMBLY-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728887#comment-17728887 ] Marat Abrarov commented on MASSEMBLY-989: - Hi [~hboutemy], It looks like the changes made within this improvement made Maven Assembly Plugin not following explicitly configured file / directory permissions when building TARs. Could you please check my [comment|https://issues.apache.org/jira/browse/MASSEMBLY-791?focusedCommentId=17726719=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17726719] in MASSEMBLY-791 for the case which fails with 3.6.0 version of Maven Assembly Plugin and for possible (quick & dirty) fix? Thank you. > in RB mode, apply 022 umask to ignore environment group write umask > --- > > Key: MASSEMBLY-989 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-989 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.5.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.0 > > > after MASSEMBLY-941, as expected, environment umask give different output: > some use 002 (group write by default), some use 022 (group read only by > default) > applying 022 umask in reproducible mode will give the same archive for each > environment: group will be read only -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[
https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17726719#comment-17726719
]
Marat Abrarov edited comment on MASSEMBLY-791 at 5/26/23 10:36 PM:
---
Hi [~elharo],
With 3.6.0 version of Maven Assembly Plugin {{fileMode}} and {{directoryMode}}
options look to be ignored or transformed (umask applied?). This is the reason
my team delays migration from 3.5.0 to 3.6.0 - we need to generate archives
with specific permissions, like 0777 for specific directory entry in the
generated TAR, but we get 0755 with 3.6.0.
Refer to
[init-image/src/assembly/rootfs.xml|https://github.com/mabrarov/docker-compose-init-container/blob/master/init-image/src/assembly/rootfs.xml]
in
[mabrarov/docker-compose-init-container|https://github.com/mabrarov/docker-compose-init-container]
for example:
{noformat}
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.5.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxrwxrwx root/root 0 1980-01-01 03:00 config/
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.6.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxr-xr-x root/root 0 1980-01-01 03:00 config/
{noformat}
Example of possible solution (of workaround):
[https://github.com/mabrarov/maven-assembly-plugin/compare/master...mabrarov:maven-assembly-plugin:feature/override_umask].
was (Author: abrarovm):
Hi [~elharo],
With 3.6.0 version of Maven Assembly Plugin {{fileMode}} and {{directoryMode}}
options look to be ignored or transformed (umask applied?). This is the reason
my team delays migration from 3.5.0 to 3.6.0 - we need to generate archives
with specific permissions, like 0777 for specific directory entry in the
generated TAR, but we get 0755 with 3.6.0.
Refer to
[init-image/src/assembly/rootfs.xml|https://github.com/mabrarov/docker-compose-init-container/blob/master/init-image/src/assembly/rootfs.xml]
in
[mabrarov/docker-compose-init-container|https://github.com/mabrarov/docker-compose-init-container]
for example:
{noformat}
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.5.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxrwxrwx root/root 0 1980-01-01 03:00 config/
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.6.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxr-xr-x root/root 0 1980-01-01 03:00 config/
{noformat}
> fileMode not set in dependencySet creating format tar.gz
>
>
> Key: MASSEMBLY-791
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-791
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: permissions
>Affects Versions: 2.6
> Environment: Linux and Windows
>Reporter: Rick Poleshuck
>Priority: Major
>
> The fileMode is ignored within a dependencySet while creating a tar.gz
> archive. This works just fine in 2.4.
>
>
>
> com.company:dependency-artifact
>
> true
>
>
> *.py
>
>
>
> 0750
> 0750
>
>
>
[jira] [Comment Edited] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[
https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17726719#comment-17726719
]
Marat Abrarov edited comment on MASSEMBLY-791 at 5/26/23 9:40 PM:
--
Hi [~elharo],
With 3.6.0 version of Maven Assembly Plugin {{fileMode}} and {{directoryMode}}
options look to be ignored or transformed (umask applied?). This is the reason
my team delays migration from 3.5.0 to 3.6.0 - we need to generate archives
with specific permissions, like 0777 for specific directory entry in the
generated TAR, but we get 0755 with 3.6.0.
Refer to
[init-image/src/assembly/rootfs.xml|https://github.com/mabrarov/docker-compose-init-container/blob/master/init-image/src/assembly/rootfs.xml]
in
[mabrarov/docker-compose-init-container|https://github.com/mabrarov/docker-compose-init-container]
for example:
{noformat}
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.5.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxrwxrwx root/root 0 1980-01-01 03:00 config/
$ mvn -q -pl init-image clean package -D maven-assembly-plugin.version=3.6.0
$ tar -tvf init-image/target/context/rootfs.tar
-r-xr-xr-x root/root 1131168 1980-01-01 03:00 usr/bin/busybox
-r-xr-xr-x root/root 5407 1980-01-01 03:00 run.sh
drwxr-xr-x root/root 0 1980-01-01 03:00 config/
{noformat}
was (Author: abrarovm):
Hi [~elharo],
With 3.6.0 version of Maven Assembly Plugin {{fileMode}} and {{directoryMode}}
options look to be ignored or transformed (umask applied?). This is the reason
my team delays migration from 3.5.0 to 3.6.0 - we need to generate archives
with specific permissions, like 0777 for specific directory entry in the
generated TAR, but we get 0755 with 3.6.0.
> fileMode not set in dependencySet creating format tar.gz
>
>
> Key: MASSEMBLY-791
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-791
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: permissions
>Affects Versions: 2.6
> Environment: Linux and Windows
>Reporter: Rick Poleshuck
>Priority: Major
>
> The fileMode is ignored within a dependencySet while creating a tar.gz
> archive. This works just fine in 2.4.
>
>
>
> com.company:dependency-artifact
>
> true
>
>
> *.py
>
>
>
> 0750
> 0750
>
>
>
[jira] [Commented] (MASSEMBLY-791) fileMode not set in dependencySet creating format tar.gz
[
https://issues.apache.org/jira/browse/MASSEMBLY-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17726719#comment-17726719
]
Marat Abrarov commented on MASSEMBLY-791:
-
Hi [~elharo],
With 3.6.0 version of Maven Assembly Plugin {{fileMode}} and {{directoryMode}}
options look to be ignored or transformed (umask applied?). This is the reason
my team delays migration from 3.5.0 to 3.6.0 - we need to generate archives
with specific permissions, like 0777 for specific directory entry in the
generated TAR, but we get 0755 with 3.6.0.
> fileMode not set in dependencySet creating format tar.gz
>
>
> Key: MASSEMBLY-791
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-791
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: permissions
>Affects Versions: 2.6
> Environment: Linux and Windows
>Reporter: Rick Poleshuck
>Priority: Major
>
> The fileMode is ignored within a dependencySet while creating a tar.gz
> archive. This works just fine in 2.4.
>
>
>
> com.company:dependency-artifact
>
> true
>
>
> *.py
>
>
>
> 0750
> 0750
>
>
>
[jira] [Commented] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated
[ https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721701#comment-17721701 ] Marat Abrarov commented on MASSEMBLY-843: - Hi [~sjaranowski], Are you aware of the schedule for release of Maven Assembly Plugin 3.6.0? This fix should help us to get rid of annoying build log messages which confuse my team members. Thank you. > finalName as readonly parameter makes common usecases very complicated > -- > > Key: MASSEMBLY-843 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-843 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.6.0 > > > The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient: > We need to create an archive with one stable name (independent of e.g. > version) so we don't have to propagate these information to a bunch of > scripts. > The general solution (i.e. Stack-overflow) refers exactly to the finalName: > [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin] > *Please change finalName back to a settable property.* > It being settable does not hurt anyone satisfied with the default naming > convention but makes some usecases vastly simpler (otherwise you have to > rename the artifact using yet another plugin or propagate version info > possibly through a chain of scripts) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[
https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685939#comment-17685939
]
Marat Abrarov edited comment on MASSEMBLY-845 at 3/3/23 5:08 PM:
-
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
endings), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files into the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
Even integration tests of Maven Assembly Plugin (e.g.
[https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml])
still use {{finalName}} parameter.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
FYI [~ctubbsii] (from
[comment|https://issues.apache.org/jira/browse/MASSEMBLY-843?focusedCommentId=17696156=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17696156]
in MASSEMBLY-843).
Thank you.
was (Author: abrarovm):
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
endings), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files into the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
Even integration tests of Maven Assembly Plugin (e.g.
[https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml])
still use {{finalName}} parameter.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
FYI [~ctubbsii] (from comment in MASSEMBLY-843).
Thank you.
> MASSEMBLY-817 makes some usecases very inconvenient
> ---
>
> Key: MASSEMBLY-845
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-845
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some
[jira] [Comment Edited] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[
https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685939#comment-17685939
]
Marat Abrarov edited comment on MASSEMBLY-845 at 3/3/23 4:38 PM:
-
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
endings), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files into the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
Even integration tests of Maven Assembly Plugin (e.g.
[https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml])
still use {{finalName}} parameter.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
FYI [~ctubbsii] (from comment in MASSEMBLY-843).
Thank you.
was (Author: abrarovm):
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
endings), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files in the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
Even integration tests of Maven Assembly Plugin (e.g.
[https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml])
still use {{finalName}} parameter.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
FYI [~ctubbsii] (from
[comment|https://issues.apache.org/jira/browse/MASSEMBLY-843?focusedCommentId=17696156=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17696156]
in MASSEMBLY-843).
Thank you.
> MASSEMBLY-817 makes some usecases very inconvenient
> ---
>
> Key: MASSEMBLY-845
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-845
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases
[jira] [Comment Edited] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[
https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685939#comment-17685939
]
Marat Abrarov edited comment on MASSEMBLY-845 at 3/3/23 4:37 PM:
-
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
endings), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files in the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
Even integration tests of Maven Assembly Plugin (e.g.
[https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml])
still use {{finalName}} parameter.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
FYI [~ctubbsii] (from
[comment|https://issues.apache.org/jira/browse/MASSEMBLY-843?focusedCommentId=17696156=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17696156]
in MASSEMBLY-843).
Thank you.
was (Author: abrarovm):
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
endings), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files in the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
Even integration tests of Maven Assembly Plugin (e.g.
[https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml])
still use {{finalName}} parameter.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
Thank you.
> MASSEMBLY-817 makes some usecases very inconvenient
> ---
>
> Key: MASSEMBLY-845
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-845
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive
[jira] [Comment Edited] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[
https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685939#comment-17685939
]
Marat Abrarov edited comment on MASSEMBLY-845 at 2/8/23 3:10 PM:
-
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
endings), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files in the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
Even integration tests of Maven Assembly Plugin (e.g.
[https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml])
still use {{finalName}} parameter.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
Thank you.
was (Author: abrarovm):
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
endings), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files in the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
Event integration tests for Maven Assembly Plugin (e.g.
[https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml])
still use {{finalName}} parameter.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
Thank you.
> MASSEMBLY-817 makes some usecases very inconvenient
> ---
>
> Key: MASSEMBLY-845
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-845
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive with one stable name (independent of e.g.
> version) so we don't have to propagate these information to a bunch of
> scripts.
> The general solution (i.e. Stack-overflow) refers exactly to the finalName:
>
[jira] [Comment Edited] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[
https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685939#comment-17685939
]
Marat Abrarov edited comment on MASSEMBLY-845 at 2/8/23 3:09 PM:
-
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
endings), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files in the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
Event integration tests for Maven Assembly Plugin (e.g.
[https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml])
still use {{finalName}} parameter.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
Thank you.
was (Author: abrarovm):
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
ending), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files in the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
Thank you.
> MASSEMBLY-817 makes some usecases very inconvenient
> ---
>
> Key: MASSEMBLY-845
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-845
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive with one stable name (independent of e.g.
> version) so we don't have to propagate these information to a bunch of
> scripts.
> The general solution (i.e. Stack-overflow) refers exactly to the finalName:
> [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin]
> *Please change finalName back to a settable property.*
> It being settable does not hurt anyone satisfied with the default
[jira] [Commented] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[
https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685939#comment-17685939
]
Marat Abrarov commented on MASSEMBLY-845:
-
Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom],
Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}}
parameter:
[https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml].
I use Maven Assembly Plugin to create multiple archives (with required
structure, directory and file permissions, directory and file timestamps, line
ending), which are later (within the same maven module) used in Dockerfile
[{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or
[{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions
to place directories / files in the built (using
[docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and
generated Dockerfile) container image.
I also use Maven Assembly Plugin with {{finalName}} parameter to place all
packaged archives and Dockerfile (where I fill placeholders using filtering) in
a single directory which is used as Docker build context.
This way my builds on Windows host (using remote Docker engine which can be
running in a local VM with Linux) and on Linux hosts (using remote or local
Docker engine) are identical, OS independent (comparing to {{docker build}}
command) and reproducible.
Taking into account that Maven Assembly Plugin still supports
[{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory]
parameter (which can replace {{finalName}} parameter for my use case, but it
will complicate maven project and Dockerfile), I find deprecation of
{{finalName}} parameter (MASSEMBLY-817) meaningless.
I vote to make {{finalName}} back editable, or at least consider it editable if
{{attach}} is {{{}false{}}}.
Thank you.
> MASSEMBLY-817 makes some usecases very inconvenient
> ---
>
> Key: MASSEMBLY-845
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-845
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive with one stable name (independent of e.g.
> version) so we don't have to propagate these information to a bunch of
> scripts.
> The general solution (i.e. Stack-overflow) refers exactly to the finalName:
> [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin]
> *Please change finalName back to a settable property.*
> It being settable does not hurt anyone satisfied with the default naming
> convention but makes some usecases vastly simpler (otherwise you have to
> rename the artifact using yet another plugin or propagate version info
> possibly through a chain of scripts)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474525#comment-17474525
]
Marat Abrarov commented on MEAR-307:
Hi [~asbachb],
Regarding [your
note|https://issues.apache.org/jira/browse/MEAR-307?focusedCommentId=17474463=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17474463]
{quote}
I'd expect that the war should behave somehow similar to other modules where I
don't need to define the dependencies manually.
{quote}
{{war}} packaging / artifact type (as well as {{ear}} packaging and some other
packing types) "contains all of its dependencies" in terms of Maven, so these
dependencies are not visible (do not come as transitive dependencies) to EARs
which depend on WARs.
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474469#comment-17474469
]
Marat Abrarov edited comment on MEAR-307 at 1/12/22, 11:50 AM:
---
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared library directory of EAR and what JARs to keep as is. I was ensured that
the trick I shared in [^MEAR-307_fixed_example.zip] is widely used and is
simple to implement (e.g. there is no pain here).
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
was (Author: abrarovm):
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared library directory of EAR and what JARs to keep as is. I was ensured that
the trick I shared in [^MEAR-307_fixed_example.zip] is widely used and is
simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474469#comment-17474469
]
Marat Abrarov edited comment on MEAR-307 at 1/12/22, 11:50 AM:
---
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared library directory of EAR and what JARs to keep as is. I was ensured that
the trick I shared in [^MEAR-307_fixed_example.zip] is widely used and is
simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
was (Author: abrarovm):
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared library directory of EAR and what keep as is. I was ensured that the
trick I shared in [^MEAR-307_fixed_example.zip] is widely used and is simple to
implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474469#comment-17474469
]
Marat Abrarov edited comment on MEAR-307 at 1/12/22, 11:49 AM:
---
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared library directory of EAR and what keep as is. I was ensured that the
trick I shared in [^MEAR-307_fixed_example.zip] is widely used and is simple to
implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
was (Author: abrarovm):
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared folder and what keep as is. I was ensured that the trick I shared in
[^MEAR-307_fixed_example.zip] is widely used and is simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474469#comment-17474469
]
Marat Abrarov commented on MEAR-307:
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / WARs / etc to move into shared
folder and what keep as is. I was ensured that the trick I shared in
[^MEAR-307_fixed_example.zip] is widely used and is simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474469#comment-17474469
]
Marat Abrarov edited comment on MEAR-307 at 1/12/22, 11:48 AM:
---
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared folder and what keep as is. I was ensured that the trick I shared in
[^MEAR-307_fixed_example.zip] is widely used and is simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
was (Author: abrarovm):
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / WARs / etc to move into shared
folder and what keep as is. I was ensured that the trick I shared in
[^MEAR-307_fixed_example.zip] is widely used and is simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MEAR-307) skinny modules war libs are not put into shared lib folder
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474257#comment-17474257
]
Marat Abrarov commented on MEAR-307:
Hi [~asbachb],
This is expected behavior. Example provided in [^ear-war-skinny-bug-ear.zip]
doesn't follow documentation about skinnyWars / skinnyModules. Refer to [Apache
Maven EAR Plugin - Creating Skinny
WARs|https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html]:
{quote}
Now the painful part. Your EAR project's {{pom.xml}} needs to list every
dependency that you want to share through the EAR.
{quote}
Here is the fixed project: [^MEAR-307_fixed_example.zip].
> skinny modules war libs are not put into shared lib folder
> --
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs folder.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MEAR-307) skinny modules war libs are not put into shared lib folder
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-307:
---
Attachment: MEAR-307_fixed_example.zip
> skinny modules war libs are not put into shared lib folder
> --
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs folder.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MEAR-289) skinnyWars issue with finalName for Jar module
[
https://issues.apache.org/jira/browse/MEAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255042#comment-17255042
]
Marat Abrarov commented on MEAR-289:
[~elharo] and [~hboutemy],
Please take this bug into account when preparing 3.2.0 release. It
[feels|https://issues.apache.org/jira/browse/MEAR-289?focusedCommentId=17244742=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17244742]
like this bug is resolved within MEAR-288.
Thank you.
> skinnyWars issue with finalName for Jar module
> --
>
> Key: MEAR-289
> URL: https://issues.apache.org/jira/browse/MEAR-289
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Stefan Schmidt
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: maven-ear-example.zip
>
>
> When a finalName is given for a Jar module in a War it is not found by
> filename @\{artifactId}@-@\{version}@.@\{extension}@ for deletion in
> maven-ear-plugin.
> Example as attached:
> * module-jar
> * module-jar2 (with finalName)
> * module-war (has jar and jar2 as dependency)
> * module-ear (has jar as dependency)
> #> ./mvnw clean install
> The module-ear-0-SNAPSHOT.ear contains the
> com.example-module-war-0-SNAPSHOT.war. In this war both jar's are in folder
> WEB-INF/lib module-jar-0-SNAPSHOT.jar and module-jar2-0-SNAPSHOT.jar.
> On debugging maven-ear-plugin 3.1.0 it is checking only the finalName.jar and
> the name com.example-module-jar-0-SNAPSHOT.jar.
> Debugging -> EarMojo.java line 816 to 838
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-221) SNAPSHOT included with timestamp in skinnyWars but not removed from war(s)
[ https://issues.apache.org/jira/browse/MEAR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255041#comment-17255041 ] Marat Abrarov commented on MEAR-221: [~elharo] and [~hboutemy], Please take this bug into account when preparing 3.2.0 release. It [feels|https://issues.apache.org/jira/browse/MEAR-221?focusedCommentId=17214108=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17214108] like this bug is resolved within MEAR-288. Thank you. > SNAPSHOT included with timestamp in skinnyWars but not removed from war(s) > -- > > Key: MEAR-221 > URL: https://issues.apache.org/jira/browse/MEAR-221 > Project: Maven EAR Plugin > Issue Type: Bug >Affects Versions: 2.10.1 > Environment: Windows 7, Maven 3.0.4, IBM JDK 7.1 >Reporter: Anders Hammar >Priority: Major > Fix For: waiting-for-feedback > > > When configuring ear for skinnyWars and adding a SNAPSHOT dependency, that > jar artifact is added with (with snapshot timestamp identifier) in ear's lib > folder but the SNAPSHOT jar artifact is not removed from skinny wars. (The > jar artifact in the war is not using timestamp identifier but -SNAPSHOT > version in file name.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-272) SNAPSHOT dependencies are copied with timestamp
[ https://issues.apache.org/jira/browse/MEAR-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255039#comment-17255039 ] Marat Abrarov commented on MEAR-272: This issue looks like "not a bug, but a feature". Refer to [that comment|https://issues.apache.org/jira/browse/MEAR-272?focusedCommentId=17214099=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17214099] for details. [~elharo] and [~hboutemy], please take this into account when preparing 3.2.0 release. Thank you. > SNAPSHOT dependencies are copied with timestamp > --- > > Key: MEAR-272 > URL: https://issues.apache.org/jira/browse/MEAR-272 > Project: Maven EAR Plugin > Issue Type: Bug >Affects Versions: 3.0.1 > Environment: JDK 8 > Maven 3.3 and 3.5 >Reporter: Benjamin Cartereau >Priority: Major > > We have an EAR project that have a dependency towards a SNAPSHOT (version in > dependency within the pom set as "1.0-SNASPHOT") version of a jar stored in > our Nexus repository. > When we build the project, the ear:ear plugin is executed and we can see that > the timestamp version of the dependency is copied as is: > [INFO] Copying artifact[jar:xxx:yyy:1.0-20181106.150409-27] > to[yyy-*1.0-20181106.150409-27*.jar] > We also tried with the 3.0.0 version of the ear plugin and we get the same > result. > Then we have tried the 2.10.1 version of the plugin (with the useBaseVersion > set to true in ear plugin configuration) and it is now working: > [INFO] Copying artifact[jar:xxx:yyy:1.0-20181106.150409-27] > to[yyy-*1.0-SNAPSHOT*.jar] > The "useBaseVersion" parameter has no effect with 3.0.1 version of the plugin > except displaying the warn message "Using _useBaseVersion_ not _yet_ fixed". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (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=17195901#comment-17195901
]
Marat Abrarov edited comment on MEAR-212 at 12/24/20, 7:34 AM:
---
[~dahoffer], could [that
workaround|https://issues.apache.org/jira/browse/MEAR-216?focusedCommentId=17195895=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17195895]
(custom type mapping of EAR modules) from MEAR-216 work for you?
was (Author: abrarovm):
[~dahoffer], could that workaround (custom type mapping of EAR modules) from
MEAR-216 work for you?
> 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
(v8.3.4#803005)
[jira] [Commented] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[ https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254423#comment-17254423 ] Marat Abrarov commented on MEAR-166: [~afloom], I opened [pull request #33|https://github.com/apache/maven-ear-plugin/pull/33] to implement this feature request. Your review and testing is appreciated. > 'skinnyWar' doesn't work well with dependencies of type 'ejb' > - > > Key: MEAR-166 > URL: https://issues.apache.org/jira/browse/MEAR-166 > Project: Maven EAR Plugin > Issue Type: New Feature >Affects Versions: 2.8, 2.9 > Environment: many different environments I've verified this on >Reporter: Michal Michalski >Priority: Minor > Labels: contributers-welcome > Fix For: more-investigation > > Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff > > > It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it > does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies > exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic > trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's > dependencies should go to EAR's lib. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MEAR-294) JAR with provided scope should be removed from Class-Path entry of EAR module MANIFEST.mf
[
https://issues.apache.org/jira/browse/MEAR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-294:
---
Summary: JAR with provided scope should be removed from Class-Path entry of
EAR module MANIFEST.mf (was: JAR with provided scope should be removed from
Class-Path of EAR module MANIFEST.mf)
> JAR with provided scope should be removed from Class-Path entry of EAR module
> MANIFEST.mf
> -
>
> Key: MEAR-294
> URL: https://issues.apache.org/jira/browse/MEAR-294
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Marat Abrarov
>Priority: Major
>
> JAR dependency of EAR with provided scope should be removed from
> {{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or
> {{skinnyModules}} option is turned on or if EAR module doesn't contain all of
> its dependencies (like EJB module). This issue looks to be a bug of solution
> of MEAR-243 bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-294) JAR with provided scope should be removed from Class-Path of EAR module MANIFEST.mf
[
https://issues.apache.org/jira/browse/MEAR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-294:
---
Summary: JAR with provided scope should be removed from Class-Path of EAR
module MANIFEST.mf (was: JAR with provided scope should be removed from
Class-Path of EAR module MANIFEST.mf\)
> JAR with provided scope should be removed from Class-Path of EAR module
> MANIFEST.mf
> ---
>
> Key: MEAR-294
> URL: https://issues.apache.org/jira/browse/MEAR-294
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Marat Abrarov
>Priority: Major
>
> JAR dependency of EAR with provided scope should be removed from
> {{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or
> {{skinnyModules}} option is turned on or if EAR module doesn't contain all of
> its dependencies (like EJB module). This issue looks to be a bug of solution
> of MEAR-243 bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-294) JAR with provided scope should be removed from Class-Path
[
https://issues.apache.org/jira/browse/MEAR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-294:
---
Description: JAR dependency of EAR with provided scope should be removed
from {{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or
{{skinnyModules}} option is turned on or if EAR module doesn't contain all of
its dependencies (like EJB module). This issue looks to be a bug of solution of
MEAR-243 bug. (was: JAR dependency of EAR with provided scope should be
removed from {{Class-Path}} entry of MANIFEST.mf of EAR module if
{{skinnyWars}} or {{skinnyModules}} option is turned on or if EAR module
doesn't contain all of its dependencies. This issue looks to be a bug of
solution of MEAR-243 bug.)
> JAR with provided scope should be removed from Class-Path
> -
>
> Key: MEAR-294
> URL: https://issues.apache.org/jira/browse/MEAR-294
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Marat Abrarov
>Priority: Major
>
> JAR dependency of EAR with provided scope should be removed from
> {{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or
> {{skinnyModules}} option is turned on or if EAR module doesn't contain all of
> its dependencies (like EJB module). This issue looks to be a bug of solution
> of MEAR-243 bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-294) JAR with provided scope should be removed from Class-Path of EAR module MANIFEST.mf\
[
https://issues.apache.org/jira/browse/MEAR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-294:
---
Summary: JAR with provided scope should be removed from Class-Path of EAR
module MANIFEST.mf\ (was: JAR with provided scope should be removed from
Class-Path)
> JAR with provided scope should be removed from Class-Path of EAR module
> MANIFEST.mf\
>
>
> Key: MEAR-294
> URL: https://issues.apache.org/jira/browse/MEAR-294
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Marat Abrarov
>Priority: Major
>
> JAR dependency of EAR with provided scope should be removed from
> {{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or
> {{skinnyModules}} option is turned on or if EAR module doesn't contain all of
> its dependencies (like EJB module). This issue looks to be a bug of solution
> of MEAR-243 bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-294) JAR with provided scope should be removed from Class-Path
[
https://issues.apache.org/jira/browse/MEAR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-294:
---
Description: JAR dependency of EAR with provided scope should be removed
from {{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or
{{skinnyModules}} option is turned on or if EAR module doesn't contain all of
its dependencies. This issue looks to be a bug of solution of MEAR-243 bug.
(was: JAR dependency of EAR with provided scope should be removed from
{{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or
{{skinnyModules}} option is turned on. This issue looks to be a bug of solution
of MEAR-243 bug.)
> JAR with provided scope should be removed from Class-Path
> -
>
> Key: MEAR-294
> URL: https://issues.apache.org/jira/browse/MEAR-294
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Marat Abrarov
>Priority: Major
>
> JAR dependency of EAR with provided scope should be removed from
> {{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or
> {{skinnyModules}} option is turned on or if EAR module doesn't contain all of
> its dependencies. This issue looks to be a bug of solution of MEAR-243 bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-294) JAR with provided scope should be removed from Class-Path
[
https://issues.apache.org/jira/browse/MEAR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-294:
---
Summary: JAR with provided scope should be removed from Class-Path (was:
JAR with provided scope should be removed from Class-Path in case of skinnyWars)
> JAR with provided scope should be removed from Class-Path
> -
>
> Key: MEAR-294
> URL: https://issues.apache.org/jira/browse/MEAR-294
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Marat Abrarov
>Priority: Major
>
> JAR dependency of EAR with provided scope should be removed from
> {{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or
> {{skinnyModules}} option is turned on. This issue looks to be a bug of
> solution of MEAR-243 bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252616#comment-17252616
]
Marat Abrarov edited comment on MEAR-166 at 12/21/20, 4:53 AM:
---
FYI [~rfscholte], [~elharo], [~hboutemy] and [~afloom],
I suspect that this new feature depends on (would be easier to start work after
completion of) MEAR-292 and MEAR-294.
Refer to
[MEAR-166|https://github.com/apache/maven-ear-plugin/compare/master...mabrarov:MEAR-166]
branch of mabrarov/maven-ear-plugin repository for initial implementation
(adoption of [^MEAR-166-patch.diff]) which lacks (at the time of creation of
this comment):
# tests
# documentation for the new property of EAR module - {{classPathItem}} - which
controls if EAR module should be added into the {{Class-Path}} entry of
MANIFEST.mf of other modules (in case {{skipClassPathModification}} is
{{false}}, i.e. has default value).
was (Author: abrarovm):
FYI, [~rfscholte], [~elharo] and [~hboutemy].
I suspect that this new feature depends on (would be easier to start work after
completion of) MEAR-292 and MEAR-294.
Refer to
[MEAR-166|https://github.com/apache/maven-ear-plugin/compare/master...mabrarov:MEAR-166]
branch of mabrarov/maven-ear-plugin repository for initial implementation
(adoption of [^MEAR-166-patch.diff]) which lacks (at the time of creation of
this comment):
# tests
# documentation for the new property of EAR module - {{classPathItem}} - which
controls if EAR module should be added into the {{Class-Path}} entry of
MANIFEST.mf of other modules (in case {{skipClassPathModification}} is
{{false}}, i.e. has default value).
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://issues.apache.org/jira/browse/MEAR-166
> Project: Maven EAR Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Labels: contributers-welcome
> Fix For: more-investigation
>
> Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252616#comment-17252616
]
Marat Abrarov edited comment on MEAR-166 at 12/21/20, 4:52 AM:
---
FYI, [~rfscholte], [~elharo] and [~hboutemy].
I suspect that this new feature depends on (would be easier to start work after
completion of) MEAR-292 and MEAR-294.
Refer to
[MEAR-166|https://github.com/apache/maven-ear-plugin/compare/master...mabrarov:MEAR-166]
branch of mabrarov/maven-ear-plugin repository for initial implementation
(adoption of [^MEAR-166-patch.diff]) which lacks (at the time of creation of
this comment):
# tests
# documentation for the new property of EAR module - {{classPathItem}} - which
controls if EAR module should be added into the {{Class-Path}} entry of
MANIFEST.mf of other modules (in case {{skipClassPathModification}} is
{{false}}, i.e. has default value).
was (Author: abrarovm):
I suspect that this new feature depends on (would be easier to start work after
completion of) MEAR-292 and MEAR-294.
Refer to
[MEAR-166|https://github.com/apache/maven-ear-plugin/compare/master...mabrarov:MEAR-166]
branch of mabrarov/maven-ear-plugin repository for initial implementation
(adoption of [^MEAR-166-patch.diff]) which lacks (at the time of creation of
this comment):
# tests
# documentation for the new property of EAR module - {{classPathItem}} - which
controls if EAR module should be added into the {{Class-Path}} entry of
MANIFEST.mf of other modules (in case {{skipClassPathModification}} is
{{false}}, i.e. has default value)
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://issues.apache.org/jira/browse/MEAR-166
> Project: Maven EAR Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Labels: contributers-welcome
> Fix For: more-investigation
>
> Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252616#comment-17252616
]
Marat Abrarov commented on MEAR-166:
I suspect that this new feature depends on (would be easier to start work after
completion of) MEAR-292 and MEAR-294.
Refer to
[MEAR-166|https://github.com/apache/maven-ear-plugin/compare/master...mabrarov:MEAR-166]
branch of mabrarov/maven-ear-plugin repository for initial implementation
(adoption of [^MEAR-166-patch.diff]) which lacks (at the time of creation of
this comment):
# tests
# documentation for the new property of EAR module - {{classPathItem}} - which
controls if EAR module should be added into the {{Class-Path}} entry of
MANIFEST.mf of other modules (in case {{skipClassPathModification}} is
{{false}}, i.e. has default value)
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://issues.apache.org/jira/browse/MEAR-166
> Project: Maven EAR Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Labels: contributers-welcome
> Fix For: more-investigation
>
> Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MEAR-294) JAR with provided scope should be removed from Class-Path in case of skinnyWars
Marat Abrarov created MEAR-294:
--
Summary: JAR with provided scope should be removed from Class-Path
in case of skinnyWars
Key: MEAR-294
URL: https://issues.apache.org/jira/browse/MEAR-294
Project: Maven EAR Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Marat Abrarov
JAR dependency of EAR with provided scope should be removed from {{Class-Path}}
entry of MANIFEST.mf of EAR module if {{skinnyWars}} or {{skinnyModules}}
option is turned on. This issue looks to be a bug of solution of MEAR-243 bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-293) skinnyModules option doesn't work if skinnyWars is false
[
https://issues.apache.org/jira/browse/MEAR-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-293:
---
Description:
If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
off (default value) then WARs are not skinny. Its looks to be a
[bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
introduced by [pull request
#26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to [failed
integration
tests|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
in the Jenkins builds of master branch:
{noformat}
[ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
[ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
elapsed: 19.103 s <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
of module [eartest-war-sample-three-1.0.war] manifest: array lengths differed,
expected.length=3 actual.length=1; arrays first differed at element [0];
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
Caused by: org.junit.ComparisonFailure:
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
{noformat}
was:
If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
off (default value) then no WARs are not skinny. Its looks to be a
[bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
introduced by [pull request
#26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to [failed
integration
tests|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
in the Jenkins builds of master branch:
{noformat}
[ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
[ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
elapsed: 19.103 s <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
of module [eartest-war-sample-three-1.0.war] manifest: array lengths differed,
expected.length=3 actual.length=1; arrays first differed at element [0];
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
Caused by: org.junit.ComparisonFailure:
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
{noformat}
> skinnyModules option doesn't work if skinnyWars is false
>
>
> Key: MEAR-293
> URL: https://issues.apache.org/jira/browse/MEAR-293
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Windows 10 x64, Red Hat JDK 1.8 update 252 x64
>Reporter: Marat Abrarov
>Priority: Blocker
>
> If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
> off (default value) then WARs are not skinny. Its looks to be a
> [bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
> introduced by [pull request
> #26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to
> [failed integration
> tests|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
> in the Jenkins builds of master branch:
> {noformat}
> [ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
> [ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
> elapsed: 19.103 s <<< FAILURE!
> org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
> of module [eartest-war-sample-three-1.0.war] manifest: array lengths
> differed, expected.length=3 actual.length=1; arrays first differed at element
> [0]; expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
> was:<[]jar-sample-two-1.0.j...>
> at
> org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
> Caused by: org.junit.ComparisonFailure:
> expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
> was:<[]jar-sample-two-1.0.j...>
> at
> org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-293) skinnyModules option doesn't work if skinnyWars is false
[
https://issues.apache.org/jira/browse/MEAR-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-293:
---
Description:
If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
off (default value) then WARs are not skinny. It looks to be a
[bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
introduced by [pull request
#26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to [failed
integration
test|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
in the Jenkins builds of master branch:
{noformat}
[ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
[ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
elapsed: 19.103 s <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
of module [eartest-war-sample-three-1.0.war] manifest: array lengths differed,
expected.length=3 actual.length=1; arrays first differed at element [0];
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
Caused by: org.junit.ComparisonFailure:
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
{noformat}
was:
If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
off (default value) then WARs are not skinny. It looks to be a
[bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
introduced by [pull request
#26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to [failed
integration
tests|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
in the Jenkins builds of master branch:
{noformat}
[ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
[ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
elapsed: 19.103 s <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
of module [eartest-war-sample-three-1.0.war] manifest: array lengths differed,
expected.length=3 actual.length=1; arrays first differed at element [0];
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
Caused by: org.junit.ComparisonFailure:
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
{noformat}
> skinnyModules option doesn't work if skinnyWars is false
>
>
> Key: MEAR-293
> URL: https://issues.apache.org/jira/browse/MEAR-293
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Windows 10 x64, Red Hat JDK 1.8 update 252 x64
>Reporter: Marat Abrarov
>Priority: Blocker
>
> If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
> off (default value) then WARs are not skinny. It looks to be a
> [bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
> introduced by [pull request
> #26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to
> [failed integration
> test|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
> in the Jenkins builds of master branch:
> {noformat}
> [ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
> [ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
> elapsed: 19.103 s <<< FAILURE!
> org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
> of module [eartest-war-sample-three-1.0.war] manifest: array lengths
> differed, expected.length=3 actual.length=1; arrays first differed at element
> [0]; expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
> was:<[]jar-sample-two-1.0.j...>
> at
> org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
> Caused by: org.junit.ComparisonFailure:
> expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
> was:<[]jar-sample-two-1.0.j...>
> at
> org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-293) skinnyModules option doesn't work if skinnyWars is false
[
https://issues.apache.org/jira/browse/MEAR-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-293:
---
Description:
If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
off (default value) then WARs are not skinny. It looks to be a
[bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
introduced by [pull request
#26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to [failed
integration
tests|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
in the Jenkins builds of master branch:
{noformat}
[ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
[ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
elapsed: 19.103 s <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
of module [eartest-war-sample-three-1.0.war] manifest: array lengths differed,
expected.length=3 actual.length=1; arrays first differed at element [0];
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
Caused by: org.junit.ComparisonFailure:
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
{noformat}
was:
If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
off (default value) then WARs are not skinny. Its looks to be a
[bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
introduced by [pull request
#26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to [failed
integration
tests|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
in the Jenkins builds of master branch:
{noformat}
[ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
[ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
elapsed: 19.103 s <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
of module [eartest-war-sample-three-1.0.war] manifest: array lengths differed,
expected.length=3 actual.length=1; arrays first differed at element [0];
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
Caused by: org.junit.ComparisonFailure:
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
{noformat}
> skinnyModules option doesn't work if skinnyWars is false
>
>
> Key: MEAR-293
> URL: https://issues.apache.org/jira/browse/MEAR-293
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Windows 10 x64, Red Hat JDK 1.8 update 252 x64
>Reporter: Marat Abrarov
>Priority: Blocker
>
> If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
> off (default value) then WARs are not skinny. It looks to be a
> [bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
> introduced by [pull request
> #26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to
> [failed integration
> tests|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
> in the Jenkins builds of master branch:
> {noformat}
> [ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
> [ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
> elapsed: 19.103 s <<< FAILURE!
> org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
> of module [eartest-war-sample-three-1.0.war] manifest: array lengths
> differed, expected.length=3 actual.length=1; arrays first differed at element
> [0]; expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
> was:<[]jar-sample-two-1.0.j...>
> at
> org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
> Caused by: org.junit.ComparisonFailure:
> expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
> was:<[]jar-sample-two-1.0.j...>
> at
> org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-293) skinnyModules option doesn't work if skinnyWars is false
[
https://issues.apache.org/jira/browse/MEAR-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-293:
---
Description:
If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
off (default value) then no WARs are not skinny. Its looks to be a
[bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
introduced by [pull request
#26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to [failed
integration
tests|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
in the Jenkins builds of master branch:
{noformat}
[ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
[ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
elapsed: 19.103 s <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
of module [eartest-war-sample-three-1.0.war] manifest: array lengths differed,
expected.length=3 actual.length=1; arrays first differed at element [0];
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
Caused by: org.junit.ComparisonFailure:
expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
was:<[]jar-sample-two-1.0.j...>
at
org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
{noformat}
was:If {{skinnyModules}} option is turned on and {{skinnyWars}} option is
turned off (default value) then no WARs are not skinny. Its looks to be a
[bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
introduced by [pull request
#26|https://github.com/apache/maven-ear-plugin/pull/26].
> skinnyModules option doesn't work if skinnyWars is false
>
>
> Key: MEAR-293
> URL: https://issues.apache.org/jira/browse/MEAR-293
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Windows 10 x64, Red Hat JDK 1.8 update 252 x64
>Reporter: Marat Abrarov
>Priority: Blocker
>
> If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
> off (default value) then no WARs are not skinny. Its looks to be a
> [bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
> introduced by [pull request
> #26|https://github.com/apache/maven-ear-plugin/pull/26]. This leads to
> [failed integration
> tests|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/49/console]
> in the Jenkins builds of master branch:
> {noformat}
> [ERROR] Tests run: 94, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 416.522 s <<< FAILURE! - in org.apache.maven.plugins.ear.it.EarMojoIT
> [ERROR] testProject092(org.apache.maven.plugins.ear.it.EarMojoIT) Time
> elapsed: 19.103 s <<< FAILURE!
> org.junit.internal.ArrayComparisonFailure: Wrong elements of Class-Path entry
> of module [eartest-war-sample-three-1.0.war] manifest: array lengths
> differed, expected.length=3 actual.length=1; arrays first differed at element
> [0]; expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
> was:<[]jar-sample-two-1.0.j...>
> at
> org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
> Caused by: org.junit.ComparisonFailure:
> expected:<[libs/eartest-]jar-sample-two-1.0.j...> but
> was:<[]jar-sample-two-1.0.j...>
> at
> org.apache.maven.plugins.ear.it.EarMojoIT.testProject092(EarMojoIT.java:1035)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MEAR-293) skinnyModules option doesn't work if skinnyWars is false
Marat Abrarov created MEAR-293:
--
Summary: skinnyModules option doesn't work if skinnyWars is false
Key: MEAR-293
URL: https://issues.apache.org/jira/browse/MEAR-293
Project: Maven EAR Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Environment: Windows 10 x64, Red Hat JDK 1.8 update 252 x64
Reporter: Marat Abrarov
If {{skinnyModules}} option is turned on and {{skinnyWars}} option is turned
off (default value) then no WARs are not skinny. Its looks to be a
[bug|https://github.com/apache/maven-ear-plugin/pull/26#discussion_r546355822]
introduced by [pull request
#26|https://github.com/apache/maven-ear-plugin/pull/26].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-292) skipClassPathModification option should prevent adding Class-Path entry into MANIFEST.mf
[
https://issues.apache.org/jira/browse/MEAR-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-292:
---
Description: It looks like there is a bug in implementation of
{{skipClassPathModification}} option introduced in MEAR-182 - if
{{skipClassPathModification}} is {{true}} and original MANIFEST.mf of EAR
module artifact has no {{Class-Path}} entry, then empty {{Class-Path}} entry is
added into EAR module. I believe that {{Class-Path}} entry should not be added
in this case. (was: It looks like there is a bug in implementation of
{{skipClassPathModification}} option introduced in MEAR-182 - if
{{skipClassPathModification}} is {{true}} and original MANIFEST.mf of EAR
module artifact has no {{Class-Path}} entry, then empty {{Class-Path}} entry is
added into EAR module.)
> skipClassPathModification option should prevent adding Class-Path entry into
> MANIFEST.mf
>
>
> Key: MEAR-292
> URL: https://issues.apache.org/jira/browse/MEAR-292
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Windows 10 x64
>Reporter: Marat Abrarov
>Priority: Major
>
> It looks like there is a bug in implementation of
> {{skipClassPathModification}} option introduced in MEAR-182 - if
> {{skipClassPathModification}} is {{true}} and original MANIFEST.mf of EAR
> module artifact has no {{Class-Path}} entry, then empty {{Class-Path}} entry
> is added into EAR module. I believe that {{Class-Path}} entry should not be
> added in this case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MEAR-292) skipClassPathModification option should prevent adding Class-Path entry into MANIFEST.mf
Marat Abrarov created MEAR-292:
--
Summary: skipClassPathModification option should prevent adding
Class-Path entry into MANIFEST.mf
Key: MEAR-292
URL: https://issues.apache.org/jira/browse/MEAR-292
Project: Maven EAR Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Environment: Windows 10 x64
Reporter: Marat Abrarov
It looks like there is a bug in implementation of {{skipClassPathModification}}
option introduced in MEAR-182 - if {{skipClassPathModification}} is {{true}}
and original MANIFEST.mf of EAR module artifact has no {{Class-Path}} entry,
then empty {{Class-Path}} entry is added into EAR module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-289) skinnyWars issue with finalName for Jar module
[
https://issues.apache.org/jira/browse/MEAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244742#comment-17244742
]
Marat Abrarov edited comment on MEAR-289 at 12/20/20, 7:28 AM:
---
[~sschmidt] (reporter) and [~elharo] (worked on MEAR-288),
There is a chance that this issue is fixed within MEAR-288. Please retest your
case with Maven EAR Plugin built from the master branch. I tried to do that and
found no issue (comparing to the results produced by Maven EAR Plugin 3.1.0).
Here is my test of the given repro-project ([^maven-ear-example.zip]) which
uses Maven EAR Plugin 3.1.0:
{noformat}
$ mvn clean package
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
212 Defl:N 139 34% 2020-12-06 17:04 d29cf45c META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:04 META-INF/
0 Stored0 0% 2020-12-06 17:04 lib/
0 Stored0 0% 2020-12-06 17:04 META-INF/maven/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:03 697502a0
META-INF/application.xml
4214 Defl:N 3063 27% 2020-12-06 17:04 987f5ff5
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1052 46% 2020-12-06 17:04 fbd50bcf
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:04 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
8600 5052 41%11 files
$ unzip -vl
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Archive:
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
267 Defl:N 170 36% 2020-12-06 17:03 df2d2884 META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:03 META-INF/
0 Stored0 0% 2020-12-06 17:03 META-INF/maven/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/module-war/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/classes/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/lib/
64 Defl:N 65 -2% 2020-12-06 17:03 1310927b
META-INF/maven/com.example/module-war/pom.properties
1057 Defl:N 334 68% 2020-11-12 16:54 fef6778d
META-INF/maven/com.example/module-war/pom.xml
1946 Defl:N 1052 46% 2020-12-06 17:03 fbd50bcf
WEB-INF/lib/module-jar-0-SNAPSHOT.jar
1927 Defl:N 1025 47% 2020-12-06 17:03 935e5609
WEB-INF/lib/module-jar2-0-SNAPSHOT.jar
--- ------
5261 2646 50%12 files
{noformat}
And here is the same test with Maven EAR Plugin 3.2.0-SNAPSHOT built from the
master branch:
{noformat}
$ mvn clean package -Dmaven-ear-plugin.version=3.2.0-SNAPSHOT
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
221 Defl:N 143 35% 2020-12-06 17:05 8528f16f META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:05 META-INF/
0 Stored0 0% 2020-12-06 17:05 lib/
0 Stored0 0% 2020-12-06 17:05 META-INF/maven/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:05 697502a0
META-INF/application.xml
3012 Defl:N 2055 32% 2020-12-06 17:05 f3062fe2
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1062 45% 2020-12-06 17:05 6e22962d
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:05 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
7407
[jira] [Comment Edited] (MEAR-289) skinnyWars issue with finalName for Jar module
[
https://issues.apache.org/jira/browse/MEAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244742#comment-17244742
]
Marat Abrarov edited comment on MEAR-289 at 12/20/20, 7:26 AM:
---
[~sschmidt],
There is a chance that this issue is fixed within MEAR-288. Please retest your
case with Maven EAR Plugin built from the master branch. I tried to do that and
found no issue (comparing to the results produced by Maven EAR Plugin 3.1.0).
Here is my test of the given repro-project ([^maven-ear-example.zip]) which
uses Maven EAR Plugin 3.1.0:
{noformat}
$ mvn clean package
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
212 Defl:N 139 34% 2020-12-06 17:04 d29cf45c META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:04 META-INF/
0 Stored0 0% 2020-12-06 17:04 lib/
0 Stored0 0% 2020-12-06 17:04 META-INF/maven/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:03 697502a0
META-INF/application.xml
4214 Defl:N 3063 27% 2020-12-06 17:04 987f5ff5
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1052 46% 2020-12-06 17:04 fbd50bcf
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:04 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
8600 5052 41%11 files
$ unzip -vl
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Archive:
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
267 Defl:N 170 36% 2020-12-06 17:03 df2d2884 META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:03 META-INF/
0 Stored0 0% 2020-12-06 17:03 META-INF/maven/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/module-war/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/classes/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/lib/
64 Defl:N 65 -2% 2020-12-06 17:03 1310927b
META-INF/maven/com.example/module-war/pom.properties
1057 Defl:N 334 68% 2020-11-12 16:54 fef6778d
META-INF/maven/com.example/module-war/pom.xml
1946 Defl:N 1052 46% 2020-12-06 17:03 fbd50bcf
WEB-INF/lib/module-jar-0-SNAPSHOT.jar
1927 Defl:N 1025 47% 2020-12-06 17:03 935e5609
WEB-INF/lib/module-jar2-0-SNAPSHOT.jar
--- ------
5261 2646 50%12 files
{noformat}
And here is the same test with Maven EAR Plugin 3.2.0-SNAPSHOT built from the
master branch:
{noformat}
$ mvn clean package -Dmaven-ear-plugin.version=3.2.0-SNAPSHOT
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
221 Defl:N 143 35% 2020-12-06 17:05 8528f16f META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:05 META-INF/
0 Stored0 0% 2020-12-06 17:05 lib/
0 Stored0 0% 2020-12-06 17:05 META-INF/maven/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:05 697502a0
META-INF/application.xml
3012 Defl:N 2055 32% 2020-12-06 17:05 f3062fe2
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1062 45% 2020-12-06 17:05 6e22962d
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:05 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
7407 4058 45%
[jira] [Comment Edited] (MEAR-289) skinnyWars issue with finalName for Jar module
[
https://issues.apache.org/jira/browse/MEAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244742#comment-17244742
]
Marat Abrarov edited comment on MEAR-289 at 12/6/20, 5:28 PM:
--
There is a chance that this issue is fixed within MEAR-288. Please retest your
case with Maven EAR Plugin built from the master branch. I tried to do that and
found no issue (comparing to the results produced by Maven EAR Plugin 3.1.0).
Here is my test of the given repro-project ([^maven-ear-example.zip]) which
uses Maven EAR Plugin 3.1.0:
{noformat}
$ mvn clean package
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
212 Defl:N 139 34% 2020-12-06 17:04 d29cf45c META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:04 META-INF/
0 Stored0 0% 2020-12-06 17:04 lib/
0 Stored0 0% 2020-12-06 17:04 META-INF/maven/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:03 697502a0
META-INF/application.xml
4214 Defl:N 3063 27% 2020-12-06 17:04 987f5ff5
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1052 46% 2020-12-06 17:04 fbd50bcf
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:04 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
8600 5052 41%11 files
$ unzip -vl
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Archive:
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
267 Defl:N 170 36% 2020-12-06 17:03 df2d2884 META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:03 META-INF/
0 Stored0 0% 2020-12-06 17:03 META-INF/maven/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/module-war/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/classes/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/lib/
64 Defl:N 65 -2% 2020-12-06 17:03 1310927b
META-INF/maven/com.example/module-war/pom.properties
1057 Defl:N 334 68% 2020-11-12 16:54 fef6778d
META-INF/maven/com.example/module-war/pom.xml
1946 Defl:N 1052 46% 2020-12-06 17:03 fbd50bcf
WEB-INF/lib/module-jar-0-SNAPSHOT.jar
1927 Defl:N 1025 47% 2020-12-06 17:03 935e5609
WEB-INF/lib/module-jar2-0-SNAPSHOT.jar
--- ------
5261 2646 50%12 files
{noformat}
And here is the same test with Maven EAR Plugin 3.2.0-SNAPSHOT built from the
master branch:
{noformat}
$ mvn clean package -Dmaven-ear-plugin.version=3.2.0-SNAPSHOT
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
221 Defl:N 143 35% 2020-12-06 17:05 8528f16f META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:05 META-INF/
0 Stored0 0% 2020-12-06 17:05 lib/
0 Stored0 0% 2020-12-06 17:05 META-INF/maven/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:05 697502a0
META-INF/application.xml
3012 Defl:N 2055 32% 2020-12-06 17:05 f3062fe2
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1062 45% 2020-12-06 17:05 6e22962d
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:05 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
7407 4058 45%11 files
$ unzip
[jira] [Commented] (MEAR-182) Skinny WAR's - Skip Class-Path Modification in Manifest
[
https://issues.apache.org/jira/browse/MEAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244796#comment-17244796
]
Marat Abrarov commented on MEAR-182:
It looks like there is a bug in implementation of {{skipClassPathModification}}
option introduced in MEAR-182. If {{skipClassPathModification}} is {{true}} and
original MANIFEST.mf of EAR module artifact has no {{Class-Path}} entry, then
empty {{Class-Path}} entry is added into EAR module. I tried to fix this bug in
[pull request #28|https://github.com/apache/maven-ear-plugin/pull/28]. Please
review and merge if agree.
> Skinny WAR's - Skip Class-Path Modification in Manifest
> ---
>
> Key: MEAR-182
> URL: https://issues.apache.org/jira/browse/MEAR-182
> Project: Maven EAR Plugin
> Issue Type: Improvement
>Affects Versions: 2.9
>Reporter: Mario Däpp
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 2.10
>
> Attachments: MEAR-182-patch.txt
>
>
> From Java EE 5, a library directory may be specified in the application.xml
> (element library-directory). The Maven EAR Plugin already supports this for
> generating the application.xml (value of property defaultLibBundleDir).
> The Java EE 5 specification mandates that all JAR files contained in the
> library directory be made available to all modules within the EAR file (cf.
> chapter EE.8.2.1 Bundled Libraries, section 2).
> If one specifies both the skinnyWars (value = true) and defaultLibBundleDir
> parameters, the libraries will be removed from the WAR and copied to the
> defaultLibBundleDir. They will also be added to the Class-Path in the WAR
> files manifest. This is unnecessary as per the Java EE 5 specification. Even
> worse, it breaks my EAR on WebLogic (classloading issues).
> I therefore propose the following improvement to the skinny WAR's
> functionality: If the Java EE version is 5 or greater and the
> defaultLibBundleDir has been specified, the Class-Path in the WAR's manifest
> should remain unchanged.
> I've created a corresponding patch and integration test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-289) skinnyWars issue with finalName for Jar module
[
https://issues.apache.org/jira/browse/MEAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244742#comment-17244742
]
Marat Abrarov edited comment on MEAR-289 at 12/6/20, 2:19 PM:
--
There is a chance that this issue is fixed within MEAR-288. Please retest your
case with Maven EAR Plugin built from the master branch. I tried to do that and
found no issue (comparing to the results produced by Maven EAR Plugin 3.1.0).
Here is my test of the given repro-project ([^maven-ear-example.zip]) which
uses Maven EAR Plugin 3.1.0:
{noformat}
$ mvn clean package
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
212 Defl:N 139 34% 2020-12-06 17:04 d29cf45c META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:04 META-INF/
0 Stored0 0% 2020-12-06 17:04 lib/
0 Stored0 0% 2020-12-06 17:04 META-INF/maven/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:03 697502a0
META-INF/application.xml
4214 Defl:N 3063 27% 2020-12-06 17:04 987f5ff5
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1052 46% 2020-12-06 17:04 fbd50bcf
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:04 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
8600 5052 41%11 files
$ unzip -vl
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Archive:
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
267 Defl:N 170 36% 2020-12-06 17:03 df2d2884 META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:03 META-INF/
0 Stored0 0% 2020-12-06 17:03 META-INF/maven/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/module-war/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/classes/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/lib/
64 Defl:N 65 -2% 2020-12-06 17:03 1310927b
META-INF/maven/com.example/module-war/pom.properties
1057 Defl:N 334 68% 2020-11-12 16:54 fef6778d
META-INF/maven/com.example/module-war/pom.xml
1946 Defl:N 1052 46% 2020-12-06 17:03 fbd50bcf
WEB-INF/lib/module-jar-0-SNAPSHOT.jar
1927 Defl:N 1025 47% 2020-12-06 17:03 935e5609
WEB-INF/lib/module-jar2-0-SNAPSHOT.jar
--- ------
5261 2646 50%12 files
{noformat}
And here is the same test with Maven EAR Plugin 3.2.0-SNAPSHOT built from the
master branch:
{noformat}
$ mvn clean package -Dmaven-ear-plugin.version=3.2.0-SNAPSHOT
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
221 Defl:N 143 35% 2020-12-06 17:05 8528f16f META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:05 META-INF/
0 Stored0 0% 2020-12-06 17:05 lib/
0 Stored0 0% 2020-12-06 17:05 META-INF/maven/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:05 697502a0
META-INF/application.xml
3012 Defl:N 2055 32% 2020-12-06 17:05 f3062fe2
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1062 45% 2020-12-06 17:05 6e22962d
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:05 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
7407 4058 45%11 files
$ unzip
[jira] [Comment Edited] (MEAR-289) skinnyWars issue with finalName for Jar module
[
https://issues.apache.org/jira/browse/MEAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244742#comment-17244742
]
Marat Abrarov edited comment on MEAR-289 at 12/6/20, 2:18 PM:
--
There is a chance that this issue is fixed within MEAR-288. Please retest your
case with Maven EAR Plugin built from the master branch. I tried to do that and
found no issue (comparing to the results produced by Maven EAR Plugin 3.1.0).
Here is my test of the given repro-project ([^maven-ear-example.zip]) which
uses Maven EAR Plugin 3.1.0:
{noformat}
$ mvn clean package
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
212 Defl:N 139 34% 2020-12-06 17:04 d29cf45c META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:04 META-INF/
0 Stored0 0% 2020-12-06 17:04 lib/
0 Stored0 0% 2020-12-06 17:04 META-INF/maven/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:03 697502a0
META-INF/application.xml
4214 Defl:N 3063 27% 2020-12-06 17:04 987f5ff5
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1052 46% 2020-12-06 17:04 fbd50bcf
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:04 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
8600 5052 41%11 files
$ unzip -vl
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Archive:
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
267 Defl:N 170 36% 2020-12-06 17:03 df2d2884 META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:03 META-INF/
0 Stored0 0% 2020-12-06 17:03 META-INF/maven/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/module-war/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/classes/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/lib/
64 Defl:N 65 -2% 2020-12-06 17:03 1310927b
META-INF/maven/com.example/module-war/pom.properties
1057 Defl:N 334 68% 2020-11-12 16:54 fef6778d
META-INF/maven/com.example/module-war/pom.xml
1946 Defl:N 1052 46% 2020-12-06 17:03 fbd50bcf
WEB-INF/lib/module-jar-0-SNAPSHOT.jar
1927 Defl:N 1025 47% 2020-12-06 17:03 935e5609
WEB-INF/lib/module-jar2-0-SNAPSHOT.jar
--- ------
5261 2646 50%12 files
{noformat}
And here is the same test with Maven EAR Plugin 3.2.0-SNAPSHOT built from the
master branch:
{noformat}
$ mvn clean package -Dmaven-ear-plugin.version=3.2.0-SNAPSHOT
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
221 Defl:N 143 35% 2020-12-06 17:05 8528f16f META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:05 META-INF/
0 Stored0 0% 2020-12-06 17:05 lib/
0 Stored0 0% 2020-12-06 17:05 META-INF/maven/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:05 697502a0
META-INF/application.xml
3012 Defl:N 2055 32% 2020-12-06 17:05 f3062fe2
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1062 45% 2020-12-06 17:05 6e22962d
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:05 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
7407 4058 45%11 files
$ unzip
[jira] [Comment Edited] (MEAR-289) skinnyWars issue with finalName for Jar module
[
https://issues.apache.org/jira/browse/MEAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244742#comment-17244742
]
Marat Abrarov edited comment on MEAR-289 at 12/6/20, 2:12 PM:
--
There is a chance that this issue is fixed within MEAR-288. Please retest your
case with Maven EAR Plugin built from the master branch. I tried to do that and
found no issue (comparing to the results produced by Maven EAR Plugin 3.1.0).
Here is my test of the given repro-project ([^maven-ear-example.zip]) which
uses Maven EAR Plugin 3.1.0:
{noformat}
$ mvn clean package
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
212 Defl:N 139 34% 2020-12-06 17:04 d29cf45c META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:04 META-INF/
0 Stored0 0% 2020-12-06 17:04 lib/
0 Stored0 0% 2020-12-06 17:04 META-INF/maven/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:03 697502a0
META-INF/application.xml
4214 Defl:N 3063 27% 2020-12-06 17:04 987f5ff5
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1052 46% 2020-12-06 17:04 fbd50bcf
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:04 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
8600 5052 41%11 files
$ unzip -vl
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Archive:
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
267 Defl:N 170 36% 2020-12-06 17:03 df2d2884 META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:03 META-INF/
0 Stored0 0% 2020-12-06 17:03 META-INF/maven/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/module-war/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/classes/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/lib/
64 Defl:N 65 -2% 2020-12-06 17:03 1310927b
META-INF/maven/com.example/module-war/pom.properties
1057 Defl:N 334 68% 2020-11-12 16:54 fef6778d
META-INF/maven/com.example/module-war/pom.xml
1946 Defl:N 1052 46% 2020-12-06 17:03 fbd50bcf
WEB-INF/lib/module-jar-0-SNAPSHOT.jar
1927 Defl:N 1025 47% 2020-12-06 17:03 935e5609
WEB-INF/lib/module-jar2-0-SNAPSHOT.jar
--- ------
5261 2646 50%12 files
{noformat}
And here is the same test with Maven EAR Plugin 3.2.0-SNAPSHOT built from the
master branch:
{noformat}
$ mvn clean package -Dmaven-ear-plugin.version=3.2.0-SNAPSHOT
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
221 Defl:N 143 35% 2020-12-06 17:05 8528f16f META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:05 META-INF/
0 Stored0 0% 2020-12-06 17:05 lib/
0 Stored0 0% 2020-12-06 17:05 META-INF/maven/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:05 697502a0
META-INF/application.xml
3012 Defl:N 2055 32% 2020-12-06 17:05 f3062fe2
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1062 45% 2020-12-06 17:05 6e22962d
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:05 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
7407 4058 45%11 files
$ unzip
[jira] [Commented] (MEAR-289) skinnyWars issue with finalName for Jar module
[
https://issues.apache.org/jira/browse/MEAR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244742#comment-17244742
]
Marat Abrarov commented on MEAR-289:
There is a chance that this issue is fixed within MEAR-288. Please retest your
case with Maven EAR Plugin built from the master branch. I tried to do that and
found no issue (comparing to the results produced by Maven EAR Plugin 3.1.0).
Here is my test of the given repro-project ( [^maven-ear-example.zip]) which
uses Maven EAR Plugin 3.1.0:
{noformat}
$ mvn clean package
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
212 Defl:N 139 34% 2020-12-06 17:04 d29cf45c META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:04 META-INF/
0 Stored0 0% 2020-12-06 17:04 lib/
0 Stored0 0% 2020-12-06 17:04 META-INF/maven/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:04
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:03 697502a0
META-INF/application.xml
4214 Defl:N 3063 27% 2020-12-06 17:04 987f5ff5
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1052 46% 2020-12-06 17:04 fbd50bcf
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:04 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
8600 5052 41%11 files
$ unzip -vl
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Archive:
module-ear/target/module-ear-0-SNAPSHOT/com.example-module-war-0-SNAPSHOT.war
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
267 Defl:N 170 36% 2020-12-06 17:03 df2d2884 META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:03 META-INF/
0 Stored0 0% 2020-12-06 17:03 META-INF/maven/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:03
META-INF/maven/com.example/module-war/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/classes/
0 Stored0 0% 2020-12-06 17:03 WEB-INF/lib/
64 Defl:N 65 -2% 2020-12-06 17:03 1310927b
META-INF/maven/com.example/module-war/pom.properties
1057 Defl:N 334 68% 2020-11-12 16:54 fef6778d
META-INF/maven/com.example/module-war/pom.xml
1946 Defl:N 1052 46% 2020-12-06 17:03 fbd50bcf
WEB-INF/lib/module-jar-0-SNAPSHOT.jar
1927 Defl:N 1025 47% 2020-12-06 17:03 935e5609
WEB-INF/lib/module-jar2-0-SNAPSHOT.jar
--- ------
5261 2646 50%12 files
{noformat}
And here is the same test with Maven EAR Plugin 3.2.0-SNAPSHOT built from the
master branch:
{noformat}
$ mvn clean package -Dmaven-ear-plugin.version=3.2.0-SNAPSHOT
...
$ unzip -vl module-ear/target/module-ear-0-SNAPSHOT.ear
Archive: module-ear/target/module-ear-0-SNAPSHOT.ear
Length MethodSize CmprDateTime CRC-32 Name
-- --- -- -
221 Defl:N 143 35% 2020-12-06 17:05 8528f16f META-INF/MANIFEST.MF
0 Stored0 0% 2020-12-06 17:05 META-INF/
0 Stored0 0% 2020-12-06 17:05 lib/
0 Stored0 0% 2020-12-06 17:05 META-INF/maven/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/
0 Stored0 0% 2020-12-06 17:05
META-INF/maven/com.example/module-ear/
477 Defl:N 258 46% 2020-12-06 17:05 697502a0
META-INF/application.xml
3012 Defl:N 2055 32% 2020-12-06 17:05 f3062fe2
com.example-module-war-0-SNAPSHOT.war
1946 Defl:N 1062 45% 2020-12-06 17:05 6e22962d
lib/com.example-module-jar-0-SNAPSHOT.jar
1687 Defl:N 475 72% 2020-11-12 16:54 9e8c42bb
META-INF/maven/com.example/module-ear/pom.xml
64 Defl:N 65 -2% 2020-12-06 17:05 7dde0569
META-INF/maven/com.example/module-ear/pom.properties
--- ------
7407 4058 45%11 files
$ unzip -vl
[jira] [Comment Edited] (MEAR-216) Unable to include dependencies of type test-jar
[
https://issues.apache.org/jira/browse/MEAR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213237#comment-17213237
]
Marat Abrarov edited comment on MEAR-216 at 10/22/20, 9:56 PM:
---
I opened [https://github.com/apache/maven-ear-plugin/pull/22] to fix this issue
(to implement this improvement). [~wrungel], could you please try Maven EAR
Plugin built from source branch of this pull request?
was (Author: abrarovm):
I opened https://github.com/apache/maven-ear-plugin/pull/22 to fix this issue
(to implement this improvement).
> Unable to include dependencies of type test-jar
> ---
>
> Key: MEAR-216
> URL: https://issues.apache.org/jira/browse/MEAR-216
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Maxim Frolov
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: test-jar-in-ear-2.zip, test-jar-in-ear.zip
>
>
> Please implement support for artifacts of type *test-jar*.
> One of the use cases would be to build a test EAR as a mix of production and
> test JARs where the test JARs are used to set up the test data used to test
> the production code.
> Currently including one or more dependencies of type test-jar causes
> *LifecycleExecutionException*:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project suite-systemtests-common-ear:
> Failed to initialize ear modules: Unknown artifact type[test-jar] for
> artifact_id -> [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 suite-systemtests-common-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[test-jar] for common-domain-impl
> at
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
> ... 22 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-216) Unable to include dependencies of type test-jar
[
https://issues.apache.org/jira/browse/MEAR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213237#comment-17213237
]
Marat Abrarov edited comment on MEAR-216 at 10/22/20, 9:56 PM:
---
I opened [https://github.com/apache/maven-ear-plugin/pull/22] to fix this issue
(to implement this improvement). [~wrungel], could you please try Maven EAR
Plugin built from the source branch of this pull request and let us know here
if it works for you?
was (Author: abrarovm):
I opened [https://github.com/apache/maven-ear-plugin/pull/22] to fix this issue
(to implement this improvement). [~wrungel], could you please try Maven EAR
Plugin built from source branch of this pull request?
> Unable to include dependencies of type test-jar
> ---
>
> Key: MEAR-216
> URL: https://issues.apache.org/jira/browse/MEAR-216
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Maxim Frolov
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: test-jar-in-ear-2.zip, test-jar-in-ear.zip
>
>
> Please implement support for artifacts of type *test-jar*.
> One of the use cases would be to build a test EAR as a mix of production and
> test JARs where the test JARs are used to set up the test data used to test
> the production code.
> Currently including one or more dependencies of type test-jar causes
> *LifecycleExecutionException*:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project suite-systemtests-common-ear:
> Failed to initialize ear modules: Unknown artifact type[test-jar] for
> artifact_id -> [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 suite-systemtests-common-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[test-jar] for common-domain-impl
> at
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
> ... 22 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-288) SNAPSHOT dependency JAR having timestamp name in WAR is not removed from WAR when skinnyWars option is turned on
[
https://issues.apache.org/jira/browse/MEAR-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17216169#comment-17216169
]
Marat Abrarov edited comment on MEAR-288 at 10/20/20, 10:02 AM:
[~elharo], could you please close this bug as resolved because [pull request
#23|https://github.com/apache/maven-ear-plugin/pull/23] was merged?
was (Author: abrarovm):
Can we close this bug as resolved because [pull request
#23|https://github.com/apache/maven-ear-plugin/pull/23] was merged?
> SNAPSHOT dependency JAR having timestamp name in WAR is not removed from WAR
> when skinnyWars option is turned on
>
>
> Key: MEAR-288
> URL: https://issues.apache.org/jira/browse/MEAR-288
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Marat Abrarov
>Priority: Major
>
> SNAPSHOT dependency JAR having *timestamp* name in WAR is not removed from
> WAR when skinnyWars option is turned on.
> Refer to
> [skinny-wars-timestamp|https://github.com/apache/maven-ear-plugin/tree/maven-ear-plugin-3.1.0/src/it/skinny-wars-timestamp]
> integration test. When this test is executed it generates this WAR archive:
> {noformat}
> target/it/skinny-wars-timestamp/war-module/target/war-module-1.0.war
> ├───META-INF/
> │ ├───MANIFEST.MF
> │ └───maven/
> │ └───org.apache.maven.its.ear.skinnywars/
> │ └───war-module/
> │ ├───pom.properties
> │ └───pom.xml
> └───WEB-INF/
> ├───web.xml
> ├───classes/
> └───lib/
> ├───commons-lang-2.5.jar
> └───jar-sample-one-1.0-20150825.210557-91.jar
> {noformat}
> and this EAR archive:
> {noformat}
> target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
> ├───commons-lang-commons-lang-2.5.jar
> ├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
> │
> ├───META-INF/
> │ ├───application.xml
> │ ├───MANIFEST.MF
> │ └───maven/
> │ └───org.apache.maven.its.ear.skinnywars/
> │ └───ear-module/
> │ ├───pom.properties
> │ └───pom.xml
> │
> └───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
> ├───META-INF/
> │ ├───MANIFEST.MF
> │ └───maven/
> │ └───org.apache.maven.its.ear.skinnywars/
> │ └───war-module/
> │ ├───pom.properties
> │ └───pom.xml
> │
> └───WEB-INF/
> ├───web.xml
> ├───classes/
> └───lib/
> └───jar-sample-one-1.0-20150825.210557-91.jar
> {noformat}
> while expected EAR archive is:
> {noformat}
> target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
> ├───commons-lang-commons-lang-2.5.jar
> ├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
> │
> ├───META-INF/
> │ ├───application.xml
> │ ├───MANIFEST.MF
> │ └───maven/
> │ └───org.apache.maven.its.ear.skinnywars/
> │ └───ear-module/
> │ ├───pom.properties
> │ └───pom.xml
> │
> └───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
> ├───META-INF/
> │ ├───MANIFEST.MF
> │ └───maven/
> │ └───org.apache.maven.its.ear.skinnywars/
> │ └───war-module/
> │ ├───pom.properties
> │ └───pom.xml
> │
> └───WEB-INF/
> ├───web.xml
> ├───classes/
> └───lib/
> {noformat}
> i.e.
> target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear/org.apache.maven.its.ear.skinnywars-war-module-1.0.war/WEB-INF/lib/jar-sample-one-1.0-20150825.210557-91.jar
> file should not exist (because of skinnyWars option turned on).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-288) SNAPSHOT dependency JAR having timestamp name in WAR is not removed from WAR when skinnyWars option is turned on
[
https://issues.apache.org/jira/browse/MEAR-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17216169#comment-17216169
]
Marat Abrarov commented on MEAR-288:
Can we close this bug as resolved because [pull request
#23|https://github.com/apache/maven-ear-plugin/pull/23] was merged?
> SNAPSHOT dependency JAR having timestamp name in WAR is not removed from WAR
> when skinnyWars option is turned on
>
>
> Key: MEAR-288
> URL: https://issues.apache.org/jira/browse/MEAR-288
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Marat Abrarov
>Priority: Major
>
> SNAPSHOT dependency JAR having *timestamp* name in WAR is not removed from
> WAR when skinnyWars option is turned on.
> Refer to
> [skinny-wars-timestamp|https://github.com/apache/maven-ear-plugin/tree/maven-ear-plugin-3.1.0/src/it/skinny-wars-timestamp]
> integration test. When this test is executed it generates this WAR archive:
> {noformat}
> target/it/skinny-wars-timestamp/war-module/target/war-module-1.0.war
> ├───META-INF/
> │ ├───MANIFEST.MF
> │ └───maven/
> │ └───org.apache.maven.its.ear.skinnywars/
> │ └───war-module/
> │ ├───pom.properties
> │ └───pom.xml
> └───WEB-INF/
> ├───web.xml
> ├───classes/
> └───lib/
> ├───commons-lang-2.5.jar
> └───jar-sample-one-1.0-20150825.210557-91.jar
> {noformat}
> and this EAR archive:
> {noformat}
> target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
> ├───commons-lang-commons-lang-2.5.jar
> ├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
> │
> ├───META-INF/
> │ ├───application.xml
> │ ├───MANIFEST.MF
> │ └───maven/
> │ └───org.apache.maven.its.ear.skinnywars/
> │ └───ear-module/
> │ ├───pom.properties
> │ └───pom.xml
> │
> └───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
> ├───META-INF/
> │ ├───MANIFEST.MF
> │ └───maven/
> │ └───org.apache.maven.its.ear.skinnywars/
> │ └───war-module/
> │ ├───pom.properties
> │ └───pom.xml
> │
> └───WEB-INF/
> ├───web.xml
> ├───classes/
> └───lib/
> └───jar-sample-one-1.0-20150825.210557-91.jar
> {noformat}
> while expected EAR archive is:
> {noformat}
> target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
> ├───commons-lang-commons-lang-2.5.jar
> ├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
> │
> ├───META-INF/
> │ ├───application.xml
> │ ├───MANIFEST.MF
> │ └───maven/
> │ └───org.apache.maven.its.ear.skinnywars/
> │ └───ear-module/
> │ ├───pom.properties
> │ └───pom.xml
> │
> └───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
> ├───META-INF/
> │ ├───MANIFEST.MF
> │ └───maven/
> │ └───org.apache.maven.its.ear.skinnywars/
> │ └───war-module/
> │ ├───pom.properties
> │ └───pom.xml
> │
> └───WEB-INF/
> ├───web.xml
> ├───classes/
> └───lib/
> {noformat}
> i.e.
> target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear/org.apache.maven.its.ear.skinnywars-war-module-1.0.war/WEB-INF/lib/jar-sample-one-1.0-20150825.210557-91.jar
> file should not exist (because of skinnyWars option turned on).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214123#comment-17214123
]
Marat Abrarov commented on MEAR-166:
[~sdiedrichsen], regarding your question:
{quote}Can I in any way help to get this into the next release?
{quote}
The [^MEAR-166-patch.diff] patch attached to this issue (I guess you provided
this patch) looks good after quick overview. Could you please update patch and
open pull request on Git Hub (https://github.com/apache/maven-ear-plugin/pulls)
?
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://issues.apache.org/jira/browse/MEAR-166
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Labels: contributers-welcome
> Fix For: more-investigation
>
> Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-221) SNAPSHOT included with timestamp in skinnyWars but not removed from war(s)
[ https://issues.apache.org/jira/browse/MEAR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214108#comment-17214108 ] Marat Abrarov edited comment on MEAR-221 at 10/14/20, 5:54 PM: --- According to [pull request #23|https://github.com/apache/maven-ear-plugin/pull/23] and (extended) skinny-wars-timestamp test this bug is not relevant. At least for the changes in [pull request #23|https://github.com/apache/maven-ear-plugin/pull/23]. [~afloom], could you please: # Provide minimal maven project and steps around it to reproduce this bug # Test [pull request #23|https://github.com/apache/maven-ear-plugin/pull/23] for your use case ? was (Author: abrarovm): According to [pull request #23|https://github.com/apache/maven-ear-plugin/pull/23] and (extended) skinny-wars-timestamp test this bug is not relevant. At least for the changes in [pull request #23|https://github.com/apache/maven-ear-plugin/pull/23]. [~afloom], could you please: # Provide minimal maven project to reproduce this issue # Test [pull request #23|https://github.com/apache/maven-ear-plugin/pull/23] for your use case ? > SNAPSHOT included with timestamp in skinnyWars but not removed from war(s) > -- > > Key: MEAR-221 > URL: https://issues.apache.org/jira/browse/MEAR-221 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.10.1 > Environment: Windows 7, Maven 3.0.4, IBM JDK 7.1 >Reporter: Anders Hammar >Priority: Major > > When configuring ear for skinnyWars and adding a SNAPSHOT dependency, that > jar artifact is added with (with snapshot timestamp identifier) in ear's lib > folder but the SNAPSHOT jar artifact is not removed from skinny wars. (The > jar artifact in the war is not using timestamp identifier but -SNAPSHOT > version in file name.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-221) SNAPSHOT included with timestamp in skinnyWars but not removed from war(s)
[ https://issues.apache.org/jira/browse/MEAR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214108#comment-17214108 ] Marat Abrarov commented on MEAR-221: According to [pull request #23|https://github.com/apache/maven-ear-plugin/pull/23] and (extended) skinny-wars-timestamp test this bug is not relevant. At least for the changes in [pull request #23|https://github.com/apache/maven-ear-plugin/pull/23]. [~afloom], could you please: # Provide minimal maven project to reproduce this issue # Test [pull request #23|https://github.com/apache/maven-ear-plugin/pull/23] for your use case ? > SNAPSHOT included with timestamp in skinnyWars but not removed from war(s) > -- > > Key: MEAR-221 > URL: https://issues.apache.org/jira/browse/MEAR-221 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 2.10.1 > Environment: Windows 7, Maven 3.0.4, IBM JDK 7.1 >Reporter: Anders Hammar >Priority: Major > > When configuring ear for skinnyWars and adding a SNAPSHOT dependency, that > jar artifact is added with (with snapshot timestamp identifier) in ear's lib > folder but the SNAPSHOT jar artifact is not removed from skinny wars. (The > jar artifact in the war is not using timestamp identifier but -SNAPSHOT > version in file name.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MEAR-272) SNAPSHOT dependencies are copied with timestamp
[
https://issues.apache.org/jira/browse/MEAR-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214099#comment-17214099
]
Marat Abrarov edited comment on MEAR-272 at 10/14/20, 5:46 PM:
---
I believe that to fix this issue we can use
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#outputFileNameMapping]
option with
{noformat}
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{noformat}
value, i.e. we have to explicitly configure Maven EAR Plugin to use
{{baseVersion}} instead of {{version}}.
Note that default value of outputFileNameMapping option is
{noformat}
@{groupId}@-@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@
{noformat}
It means that this bug is not an issue for Maven EAR Plugin 3.1.0, i.e. it's
expected default behavior of Maven EAR Plugin 3.1.0. I believe that
documentation of
[useBaseVersion|https://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#useBaseVersion]
option clearly states that outputFileNameMapping option should be used instead
of useBaseVersion option (if it's not so then we could enhance documentation
within this issue).
We may need / want to change smth related to useBaseVersion option within this
bug - either make useBaseVersion option impacting default value of
outputFileNameMapping option or clarify description of / remove / deprecate
useBaseVersion option.
[~elharo], could you please review this comment? If you agree that description
of useBaseVersion option is clear and we should use outputFileNameMapping
option instead then could you please close this bug as not an issue?
was (Author: abrarovm):
I believe that to fix this issue we can use
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#outputFileNameMapping]
option with
{noformat}
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{noformat}
value, i.e. we have to explicitly configure Maven EAR Plugin to use
{{baseVersion}} instead of {{version}}.
Note that default value of outputFileNameMapping option is
{noformat}
@{groupId}@-@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@
{noformat}
It means that this bug is not an issue for Maven EAR Plugin 3.1.0, i.e. it's
expected default behavior of Maven EAR Plugin 3.1.0. I believe that
documentation of
[useBaseVersion|https://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#useBaseVersion]
option clearly states that outputFileNameMapping option should be used instead
of useBaseVersion option (if it's not so then we could enhance documentation
within this issue).
We may need / want to change smth related to useBaseVersion option within this
bug - either make useBaseVersion option impacting default value of
outputFileNameMapping option or clarify description of / remove / deprecate
useBaseVersion option.
[~elh...@metalab.unc.edu], could you please review this comment? If you agree
that description of useBaseVersion option is clear and we should use
outputFileNameMapping option instead then could you please close this bug as
not an issue?
> SNAPSHOT dependencies are copied with timestamp
> ---
>
> Key: MEAR-272
> URL: https://issues.apache.org/jira/browse/MEAR-272
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: JDK 8
> Maven 3.3 and 3.5
>Reporter: Benjamin Cartereau
>Priority: Major
>
> We have an EAR project that have a dependency towards a SNAPSHOT (version in
> dependency within the pom set as "1.0-SNASPHOT") version of a jar stored in
> our Nexus repository.
> When we build the project, the ear:ear plugin is executed and we can see that
> the timestamp version of the dependency is copied as is:
> [INFO] Copying artifact[jar:xxx:yyy:1.0-20181106.150409-27]
> to[yyy-*1.0-20181106.150409-27*.jar]
> We also tried with the 3.0.0 version of the ear plugin and we get the same
> result.
> Then we have tried the 2.10.1 version of the plugin (with the useBaseVersion
> set to true in ear plugin configuration) and it is now working:
> [INFO] Copying artifact[jar:xxx:yyy:1.0-20181106.150409-27]
> to[yyy-*1.0-SNAPSHOT*.jar]
> The "useBaseVersion" parameter has no effect with 3.0.1 version of the plugin
> except displaying the warn message "Using _useBaseVersion_ not _yet_ fixed".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-272) SNAPSHOT dependencies are copied with timestamp
[
https://issues.apache.org/jira/browse/MEAR-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214099#comment-17214099
]
Marat Abrarov commented on MEAR-272:
I believe that to fix this issue we can use
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#outputFileNameMapping]
option with
{noformat}
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{noformat}
value, i.e. we have to explicitly configure Maven EAR Plugin to use
{{baseVersion}} instead of {{version}}.
Note that default value of outputFileNameMapping option is
{noformat}
@{groupId}@-@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@
{noformat}
It means that this bug is not an issue for Maven EAR Plugin 3.1.0, i.e. it's
expected default behavior of Maven EAR Plugin 3.1.0. I believe that
documentation of
[useBaseVersion|https://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#useBaseVersion]
option clearly states that outputFileNameMapping option should be used instead
of useBaseVersion option (if it's not so then we could enhance documentation
within this issue).
We may need / want to change smth related to useBaseVersion option within this
bug - either make useBaseVersion option impacting default value of
outputFileNameMapping option or clarify description of / remove / deprecate
useBaseVersion option.
[~elh...@metalab.unc.edu], could you please review this comment? If you agree
that description of useBaseVersion option is clear and we should use
outputFileNameMapping option instead then could you please close this bug as
not an issue?
> SNAPSHOT dependencies are copied with timestamp
> ---
>
> Key: MEAR-272
> URL: https://issues.apache.org/jira/browse/MEAR-272
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: JDK 8
> Maven 3.3 and 3.5
>Reporter: Benjamin Cartereau
>Priority: Major
>
> We have an EAR project that have a dependency towards a SNAPSHOT (version in
> dependency within the pom set as "1.0-SNASPHOT") version of a jar stored in
> our Nexus repository.
> When we build the project, the ear:ear plugin is executed and we can see that
> the timestamp version of the dependency is copied as is:
> [INFO] Copying artifact[jar:xxx:yyy:1.0-20181106.150409-27]
> to[yyy-*1.0-20181106.150409-27*.jar]
> We also tried with the 3.0.0 version of the ear plugin and we get the same
> result.
> Then we have tried the 2.10.1 version of the plugin (with the useBaseVersion
> set to true in ear plugin configuration) and it is now working:
> [INFO] Copying artifact[jar:xxx:yyy:1.0-20181106.150409-27]
> to[yyy-*1.0-SNAPSHOT*.jar]
> The "useBaseVersion" parameter has no effect with 3.0.1 version of the plugin
> except displaying the warn message "Using _useBaseVersion_ not _yet_ fixed".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-288) SNAPSHOT dependency JAR having timestamp name in WAR is not removed from WAR when skinnyWars option is turned on
[
https://issues.apache.org/jira/browse/MEAR-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-288:
---
Description:
SNAPSHOT dependency JAR having *timestamp* name in WAR is not removed from WAR
when skinnyWars option is turned on.
Refer to
[skinny-wars-timestamp|https://github.com/apache/maven-ear-plugin/tree/maven-ear-plugin-3.1.0/src/it/skinny-wars-timestamp]
integration test. When this test is executed it generates this WAR archive:
{noformat}
target/it/skinny-wars-timestamp/war-module/target/war-module-1.0.war
├───META-INF/
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───war-module/
│ ├───pom.properties
│ └───pom.xml
└───WEB-INF/
├───web.xml
├───classes/
└───lib/
├───commons-lang-2.5.jar
└───jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
and this EAR archive:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
├───commons-lang-commons-lang-2.5.jar
├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF/
│ ├───application.xml
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───ear-module/
│ ├───pom.properties
│ └───pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF/
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───war-module/
│ ├───pom.properties
│ └───pom.xml
│
└───WEB-INF/
├───web.xml
├───classes/
└───lib/
└───jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
while expected EAR archive is:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
├───commons-lang-commons-lang-2.5.jar
├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF/
│ ├───application.xml
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───ear-module/
│ ├───pom.properties
│ └───pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF/
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───war-module/
│ ├───pom.properties
│ └───pom.xml
│
└───WEB-INF/
├───web.xml
├───classes/
└───lib/
{noformat}
i.e.
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear/org.apache.maven.its.ear.skinnywars-war-module-1.0.war/WEB-INF/lib/jar-sample-one-1.0-20150825.210557-91.jar
file should not exist (because of skinnyWars option turned on).
was:
SNAPSHOT dependency JAR having *timestamp* name in WAR is not removed from WAR
when skinnyWars option is turned on.
Refer to
[skinny-wars-timestamp|https://github.com/apache/maven-ear-plugin/tree/maven-ear-plugin-3.1.0/src/it/skinny-wars-timestamp]
integration test. When this test is executed it generates this WAR archive:
{noformat}
target/it/skinny-wars-timestamp/war-module/target/war-module-1.0.war
├───META-INF/
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───war-module/
│ ├───pom.properties
│ └───pom.xml
└───WEB-INF/
├───web.xml
├───classes/
└───lib/
├───commons-lang-2.5.jar
└───jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
and this EAR archive:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
├───commons-lang-commons-lang-2.5.jar
├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF/
│ ├───application.xml
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───ear-module/
│ ├───pom.properties
│ └───pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF/
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───war-module/
│ ├───pom.properties
│ └───pom.xml
│
└───WEB-INF/
├───web.xml
├───classes/
└───lib/
└───jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
while expected EAR archive is:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
├───commons-lang-commons-lang-2.5.jar
├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF/
│ ├───application.xml
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───ear-module/
│ ├───pom.properties
│ └───pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF/
│ ├───MANIFEST.MF
│ └───maven/
│
[jira] [Updated] (MEAR-288) SNAPSHOT dependency JAR having timestamp name in WAR is not removed from WAR when skinnyWars option is turned on
[
https://issues.apache.org/jira/browse/MEAR-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-288:
---
Description:
SNAPSHOT dependency JAR having *timestamp* name in WAR is not removed from WAR
when skinnyWars option is turned on.
Refer to
[skinny-wars-timestamp|https://github.com/apache/maven-ear-plugin/tree/maven-ear-plugin-3.1.0/src/it/skinny-wars-timestamp]
integration test. When this test is executed it generates this WAR archive:
{noformat}
target/it/skinny-wars-timestamp/war-module/target/war-module-1.0.war
├───META-INF/
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───war-module/
│ ├───pom.properties
│ └───pom.xml
└───WEB-INF/
├───web.xml
├───classes/
└───lib/
├───commons-lang-2.5.jar
└───jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
and this EAR archive:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
├───commons-lang-commons-lang-2.5.jar
├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF/
│ ├───application.xml
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───ear-module/
│ ├───pom.properties
│ └───pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF/
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───war-module/
│ ├───pom.properties
│ └───pom.xml
│
└───WEB-INF/
├───web.xml
├───classes/
└───lib/
└───jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
while expected EAR archive is:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
├───commons-lang-commons-lang-2.5.jar
├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF/
│ ├───application.xml
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───ear-module/
│ ├───pom.properties
│ └───pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF/
│ ├───MANIFEST.MF
│ └───maven/
│ └───org.apache.maven.its.ear.skinnywars/
│ └───war-module/
│ ├───pom.properties
│ └───pom.xml
│
└───WEB-INF/
├───web.xml
├───classes/
└───lib/
{noformat}
i.e.
ear-module-1.0.ear/org.apache.maven.its.ear.skinnywars-war-module-1.0.war/WEB-INF/lib/jar-sample-one-1.0-20150825.210557-91.jar
file should not exist (because of skinnyWars option turned on).
was:
SNAPSHOT dependency JAR having *timestamp* name in WAR is not removed from WAR
when skinnyWars option is turned on.
Refer to
[skinny-wars-timestamp|https://github.com/apache/maven-ear-plugin/tree/maven-ear-plugin-3.1.0/src/it/skinny-wars-timestamp]
integration test. When this test is executed it generates this WAR archive:
{noformat}
target/it/skinny-wars-timestamp/war-module/target/war-module-1.0.war
├───META-INF
│ ├───MANIFEST.MF
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│ ├───pom.properties
│ └───pom.xml
└───WEB-INF
├───web.xml
├───classes
└───lib
├───commons-lang-2.5.jar
└───jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
and this EAR archive:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
├───commons-lang-commons-lang-2.5.jar
├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF
│ ├───application.xml
│ ├───MANIFEST.MF
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───ear-module
│ ├───pom.properties
│ └───pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF
│ ├───MANIFEST.MF
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│ ├───pom.properties
│ └───pom.xml
│
└───WEB-INF
├───web.xml
├───classes
└───lib
└───jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
while expected EAR archive is:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
├───commons-lang-commons-lang-2.5.jar
├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF
│ ├───application.xml
│ ├───MANIFEST.MF
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───ear-module
│ ├───pom.properties
│ └───pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF
│ ├───MANIFEST.MF
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│
[jira] [Updated] (MEAR-288) SNAPSHOT dependency JAR having timestamp name in WAR is not removed from WAR when skinnyWars option is turned on
[
https://issues.apache.org/jira/browse/MEAR-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-288:
---
Description:
SNAPSHOT dependency JAR having *timestamp* name in WAR is not removed from WAR
when skinnyWars option is turned on.
Refer to
[skinny-wars-timestamp|https://github.com/apache/maven-ear-plugin/tree/maven-ear-plugin-3.1.0/src/it/skinny-wars-timestamp]
integration test. When this test is executed it generates this WAR archive:
{noformat}
target/it/skinny-wars-timestamp/war-module/target/war-module-1.0.war
├───META-INF
│ ├───MANIFEST.MF
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│ ├───pom.properties
│ └───pom.xml
└───WEB-INF
├───web.xml
├───classes
└───lib
├───commons-lang-2.5.jar
└───jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
and this EAR archive:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
├───commons-lang-commons-lang-2.5.jar
├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF
│ ├───application.xml
│ ├───MANIFEST.MF
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───ear-module
│ ├───pom.properties
│ └───pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF
│ ├───MANIFEST.MF
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│ ├───pom.properties
│ └───pom.xml
│
└───WEB-INF
├───web.xml
├───classes
└───lib
└───jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
while expected EAR archive is:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
├───commons-lang-commons-lang-2.5.jar
├───eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF
│ ├───application.xml
│ ├───MANIFEST.MF
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───ear-module
│ ├───pom.properties
│ └───pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF
│ ├───MANIFEST.MF
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│ ├───pom.properties
│ └───pom.xml
│
└───WEB-INF
├───web.xml
├───classes
└───lib
{noformat}
i.e.
ear-module-1.0.ear/org.apache.maven.its.ear.skinnywars-war-module-1.0.war/WEB-INF/lib/jar-sample-one-1.0-20150825.210557-91.jar
file should not exist (because of skinnyWars option turned on).
was:
SNAPSHOT dependency JAR having *timestamp* name in WAR is not removed from WAR
when skinnyWars option is turned on.
Refer to
[skinny-wars-timestamp|https://github.com/apache/maven-ear-plugin/tree/maven-ear-plugin-3.1.0/src/it/skinny-wars-timestamp]
integration test. When this test is executed it generates this WAR archive:
{noformat}
target/it/skinny-wars-timestamp/war-module/target/war-module-1.0.war
├───META-INF
│ │ MANIFEST.MF
│ │
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│ pom.properties
│ pom.xml
│
└───WEB-INF
│ web.xml
│
├───classes
└───lib
commons-lang-2.5.jar
jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
and this EAR archive:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
│ commons-lang-commons-lang-2.5.jar
│ eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF
│ │ application.xml
│ │ MANIFEST.MF
│ │
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───ear-module
│ pom.properties
│ pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF
│ │ MANIFEST.MF
│ │
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│ pom.properties
│ pom.xml
│
└───WEB-INF
│ web.xml
│
├───classes
└───lib
jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
while expected EAR archive is:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
│ commons-lang-commons-lang-2.5.jar
│ eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF
│ │ application.xml
│ │ MANIFEST.MF
│ │
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───ear-module
│ pom.properties
│ pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF
│ │ MANIFEST.MF
│ │
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│
[jira] [Issue Comment Deleted] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-166:
---
Comment: was deleted
(was: [~afloom], could you please provide a minimal maven project to reproduce
your use case? It looks like you don't follow
[https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html]
(refer to "the painful part"). I use [this
trick|https://github.com/mabrarov/maven-ear-plugin/blob/ea215eef8ea4cf429a793c29a15b6d48b7fe095c/src/test/resources/projects/project-092/ear/pom.xml#L40]
with {{pom}} to include all dependencies of EAR modules (of
{{eartest:war-sample-two:war}}) into EAR.)
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://issues.apache.org/jira/browse/MEAR-166
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Labels: contributers-welcome
> Fix For: more-investigation
>
> Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MEAR-288) SNAPSHOT dependency JAR having timestamp name in WAR is not removed from WAR when skinnyWars option is turned on
Marat Abrarov created MEAR-288:
--
Summary: SNAPSHOT dependency JAR having timestamp name in WAR is
not removed from WAR when skinnyWars option is turned on
Key: MEAR-288
URL: https://issues.apache.org/jira/browse/MEAR-288
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Marat Abrarov
SNAPSHOT dependency JAR having *timestamp* name in WAR is not removed from WAR
when skinnyWars option is turned on.
Refer to
[skinny-wars-timestamp|https://github.com/apache/maven-ear-plugin/tree/maven-ear-plugin-3.1.0/src/it/skinny-wars-timestamp]
integration test. When this test is executed it generates this WAR archive:
{noformat}
target/it/skinny-wars-timestamp/war-module/target/war-module-1.0.war
├───META-INF
│ │ MANIFEST.MF
│ │
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│ pom.properties
│ pom.xml
│
└───WEB-INF
│ web.xml
│
├───classes
└───lib
commons-lang-2.5.jar
jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
and this EAR archive:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
│ commons-lang-commons-lang-2.5.jar
│ eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF
│ │ application.xml
│ │ MANIFEST.MF
│ │
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───ear-module
│ pom.properties
│ pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF
│ │ MANIFEST.MF
│ │
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│ pom.properties
│ pom.xml
│
└───WEB-INF
│ web.xml
│
├───classes
└───lib
jar-sample-one-1.0-20150825.210557-91.jar
{noformat}
while expected EAR archive is:
{noformat}
target/it/skinny-wars-timestamp/ear-module/target/ear-module-1.0.ear
│ commons-lang-commons-lang-2.5.jar
│ eartest-jar-sample-one-1.0-20150825.210557-91.jar
│
├───META-INF
│ │ application.xml
│ │ MANIFEST.MF
│ │
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───ear-module
│ pom.properties
│ pom.xml
│
└───org.apache.maven.its.ear.skinnywars-war-module-1.0.war
├───META-INF
│ │ MANIFEST.MF
│ │
│ └───maven
│ └───org.apache.maven.its.ear.skinnywars
│ └───war-module
│ pom.properties
│ pom.xml
│
└───WEB-INF
│ web.xml
│
├───classes
└───lib
{noformat}
i.e.
ear-module-1.0.ear/org.apache.maven.its.ear.skinnywars-war-module-1.0.war/WEB-INF/lib/jar-sample-one-1.0-20150825.210557-91.jar
file should not exist (because of skinnyWars option turned on).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-286) filtered resources not copied if run-its profile not activated
[ https://issues.apache.org/jira/browse/MEAR-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213238#comment-17213238 ] Marat Abrarov commented on MEAR-286: [~hboutemy] and [~elharo], I see [pull request #18|https://github.com/apache/maven-ear-plugin/pull/18] was merged into master branch. Can we close this bug as resolved now? > filtered resources not copied if run-its profile not activated > -- > > Key: MEAR-286 > URL: https://issues.apache.org/jira/browse/MEAR-286 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 3.0.0, 3.1.0 >Reporter: Herve Boutemy >Priority: Major > > found during Reproducible Builds check for 3.1.0 release... > Notice that reference builds published to Central Repository have the > filtered resource (/META-INF/plexus/components.xml) because our release > process using maven-release-plugin activates the run-its profile: at least, > official releases are ok > issue happens only for manual "light" builds (run without ITs) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-216) Unable to include dependencies of type test-jar
[
https://issues.apache.org/jira/browse/MEAR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213237#comment-17213237
]
Marat Abrarov commented on MEAR-216:
I opened https://github.com/apache/maven-ear-plugin/pull/22 to fix this issue
(to implement this improvement).
> Unable to include dependencies of type test-jar
> ---
>
> Key: MEAR-216
> URL: https://issues.apache.org/jira/browse/MEAR-216
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Maxim Frolov
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: test-jar-in-ear-2.zip, test-jar-in-ear.zip
>
>
> Please implement support for artifacts of type *test-jar*.
> One of the use cases would be to build a test EAR as a mix of production and
> test JARs where the test JARs are used to set up the test data used to test
> the production code.
> Currently including one or more dependencies of type test-jar causes
> *LifecycleExecutionException*:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project suite-systemtests-common-ear:
> Failed to initialize ear modules: Unknown artifact type[test-jar] for
> artifact_id -> [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 suite-systemtests-common-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[test-jar] for common-domain-impl
> at
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
> ... 22 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212564#comment-17212564
]
Marat Abrarov edited comment on MEAR-166 at 10/12/20, 6:15 PM:
---
[~afloom], could you please provide a minimal maven project to reproduce your
use case? It looks like you don't follow
[https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html]
(refer to "the painful part"). I use [this
trick|https://github.com/mabrarov/maven-ear-plugin/blob/ea215eef8ea4cf429a793c29a15b6d48b7fe095c/src/test/resources/projects/project-092/ear/pom.xml#L40]
with {{pom}} to include all dependencies of EAR modules (of
{{eartest:war-sample-two:war}}) into EAR.
was (Author: abrarovm):
[~afloom], could you please provide a minimal maven project to reproduce your
use case? It looks like you don't follow
https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html
(refer to "the painful part").
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://issues.apache.org/jira/browse/MEAR-166
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Labels: contributers-welcome
> Fix For: more-investigation
>
> Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[ https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212564#comment-17212564 ] Marat Abrarov edited comment on MEAR-166 at 10/12/20, 6:12 PM: --- [~afloom], could you please provide a minimal maven project to reproduce your use case? It looks like you don't follow https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html (refer to "the painful part"). was (Author: abrarovm): [~afloom], could you please provide a minimal maven project to reproduce your use case? > 'skinnyWar' doesn't work well with dependencies of type 'ejb' > - > > Key: MEAR-166 > URL: https://issues.apache.org/jira/browse/MEAR-166 > Project: Maven Ear Plugin > Issue Type: New Feature >Affects Versions: 2.8, 2.9 > Environment: many different environments I've verified this on >Reporter: Michal Michalski >Priority: Minor > Labels: contributers-welcome > Fix For: more-investigation > > Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff > > > It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it > does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies > exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic > trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's > dependencies should go to EAR's lib. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[ https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212564#comment-17212564 ] Marat Abrarov commented on MEAR-166: [~afloom], could you please provide a minimal maven project to reproduce your use case? > 'skinnyWar' doesn't work well with dependencies of type 'ejb' > - > > Key: MEAR-166 > URL: https://issues.apache.org/jira/browse/MEAR-166 > Project: Maven Ear Plugin > Issue Type: New Feature >Affects Versions: 2.8, 2.9 > Environment: many different environments I've verified this on >Reporter: Michal Michalski >Priority: Minor > Labels: contributers-welcome > Fix For: more-investigation > > Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff > > > It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it > does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies > exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic > trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's > dependencies should go to EAR's lib. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-286) filtered resources not copied if run-its profile not activated
[ https://issues.apache.org/jira/browse/MEAR-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206892#comment-17206892 ] Marat Abrarov commented on MEAR-286: I believe that I fixed this bug in https://github.com/apache/maven-ear-plugin/pull/18 > filtered resources not copied if run-its profile not activated > -- > > Key: MEAR-286 > URL: https://issues.apache.org/jira/browse/MEAR-286 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 3.0.0, 3.1.0 >Reporter: Herve Boutemy >Priority: Major > > found during Reproducible Builds check for 3.1.0 release... > Notice that reference builds published to Central Repository have the > filtered resource (/META-INF/plexus/components.xml) because our release > process using maven-release-plugin activates the run-its profile: at least, > official releases are ok > issue happens only for manual "light" builds (run without ITs) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206849#comment-17206849
]
Marat Abrarov commented on MEAR-267:
I implemented possible fix for this bug in [pull request
#19|https://github.com/apache/maven-ear-plugin/pull/19]. I appreciate if
[~hboutemy] and [~elharo] could help me with review and creation of tests.
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-287) Failed to create target directory when run without clean
[
https://issues.apache.org/jira/browse/MEAR-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205968#comment-17205968
]
Marat Abrarov commented on MEAR-287:
Integration test for the fix provided in [pull request
#17|https://github.com/apache/maven-ear-plugin/pull/17] can be found in
https://github.com/zzzLobster/maven-ear-plugin/pull/1
> Failed to create target directory when run without clean
>
>
> Key: MEAR-287
> URL: https://issues.apache.org/jira/browse/MEAR-287
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Mikhail Gavrilov
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.1.1
>
>
> Steps to reproduce:
> # Checkout [https://github.com/mabrarov/dockerfile-test]
> # Set version of maven-ear-plugin in pom.xml to '3.1.0'
> # Execute: {{mvn clean package -Ddocker.skip && mvn package -Ddocker.skip}}
> {code:bash}
> $ git clone --branch develop https://github.com/mabrarov/dockerfile-test.git
> && \
> mvn -f dockerfile-test/pom.xml package -Dmaven-ear-plugin.version=3.1.0
> -Ddocker.skip && \
> mvn -f dockerfile-test/pom.xml package -Dmaven-ear-plugin.version=3.1.0
> -Ddocker.skip
> ...
> [INFO] --- maven-ear-plugin:3.1.0:ear (default-ear) @ ear ---
> [INFO] Copying artifact [war:org.mabrarov.dockerfile-test:war:1.1.7-SNAPSHOT]
> to [org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war]
> [INFO]
>
> [INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
> [INFO]
> [INFO] dockerfile-test SUCCESS [ 1.728
> s]
> [INFO] war SUCCESS [ 3.652
> s]
> [INFO] ear FAILURE [ 0.371
> s]
> [INFO] base-image . SUCCESS [ 2.297
> s]
> [INFO] hollow-image ... SUCCESS [ 1.152
> s]
> [INFO] app-image .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 6.011 s (Wall Clock)
> [INFO] Finished at: 2020-10-01T14:34:15+03:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on project
> ear: Failed to create directory
> XXX...\dockerfile-test\ear\target\temp\org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :ear
> {code}
> The same is described
> [here|https://github.com/apache/maven-ear-plugin/pull/15#issuecomment-702158521]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/27/20, 2:42 AM:
--
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (tested on JDK 11 and 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to run on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}}
maven property may be omitted if Maven runs on Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to run on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}}
maven property may be omitted if Maven runs on Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:30 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to run on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}}
maven property may be omitted if Maven runs on Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}}
maven property may be omitted if Maven runs on Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:29 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}}
maven property may be omitted if Maven runs on Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:28 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpneJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:28 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpneJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:26 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:17 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug,
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:07 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
> assembly.xml contains incorrect references to modules
>
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:07 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without workaround I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
# workaround exists
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 9:57 PM:
--
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without workaround I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
# workaround exists
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to execute on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{${JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the
[jira] [Commented] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202689#comment-17202689
]
Marat Abrarov commented on MEAR-267:
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to execute on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{${JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202439#comment-17202439
]
Marat Abrarov edited comment on MEAR-267 at 9/25/20, 10:04 PM:
---
Hi [~leokom],
Won't workaround in [pull request
#1|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] of
lrozenblyum/MEAR-267-issue-demo project work for you? I understand that it's
not solution, e.g. the same EJB JAR may be included into different EARs each
having different
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html]
and the workaround doesn't work in this case.
It looks like with 3.0 version of Maven EAR Plugin default
outputFileNameMapping was changed to include group ID. I explicitly defined
outputFileNameMapping to look like:
{noformat}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{noformat}
when migrated one of my projects from Maven EAR Plugin 2.10.1 to 3.0.2. May be
the same solution is more applicable to your needs.
Thank you for detecting and describing this bug.
was (Author: abrarovm):
Hi [~leokom],
Won't workaround in [pull request
#1|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] of
lrozenblyum/MEAR-267-issue-demo project work for you? I understand that it's
not solution, e.g. the same EJB JAR may be included into different EARs each
having different
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html]
and the workaround doesn't work in this case.
It looks like with 3.0 version of Maven EAR Plugin default
outputFileNameMapping was changed to include group ID. I explicitly defined
outputFileNameMapping to look like:
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
when migrated one of my projects from Maven EAR Plugin 2.10.1 to 3.0.2. May be
the same solution is more applicable to your needs.
Thank you for detecting and describing this bug.
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202439#comment-17202439
]
Marat Abrarov commented on MEAR-267:
Hi [~leokom],
Won't workaround in [pull request
#1|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] of
lrozenblyum/MEAR-267-issue-demo project work for you? I understand that it's
not solution, e.g. the same EJB JAR may be included into different EARs each
having different
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html]
and the workaround doesn't work in this case.
It looks like with 3.0 version of Maven EAR Plugin default
outputFileNameMapping was changed to include group ID. I explicitly defined
outputFileNameMapping to look like:
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
when migrated one of my projects from Maven EAR Plugin 2.10.1 to 3.0.2. May be
the same solution is more applicable to your needs.
Thank you for detecting and describing this bug.
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202439#comment-17202439
]
Marat Abrarov edited comment on MEAR-267 at 9/25/20, 10:03 PM:
---
Hi [~leokom],
Won't workaround in [pull request
#1|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] of
lrozenblyum/MEAR-267-issue-demo project work for you? I understand that it's
not solution, e.g. the same EJB JAR may be included into different EARs each
having different
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html]
and the workaround doesn't work in this case.
It looks like with 3.0 version of Maven EAR Plugin default
outputFileNameMapping was changed to include group ID. I explicitly defined
outputFileNameMapping to look like:
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
when migrated one of my projects from Maven EAR Plugin 2.10.1 to 3.0.2. May be
the same solution is more applicable to your needs.
Thank you for detecting and describing this bug.
was (Author: abrarovm):
Hi [~leokom],
Won't workaround in [pull request
#1|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] of
lrozenblyum/MEAR-267-issue-demo project work for you? I understand that it's
not solution, e.g. the same EJB JAR may be included into different EARs each
having different
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html]
and the workaround doesn't work in this case.
It looks like with 3.0 version of Maven EAR Plugin default
outputFileNameMapping was changed to include group ID. I explicitly defined
outputFileNameMapping to look like:
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
when migrated one of my projects from Maven EAR Plugin 2.10.1 to 3.0.2. May be
the same solution is more applicable to your needs.
Thank you for detecting and describing this bug.
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-284) Tests fail at HEAD on Linux
[
https://issues.apache.org/jira/browse/MEAR-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195993#comment-17195993
]
Marat Abrarov commented on MEAR-284:
This issue looks like the only blocker for release of 3.1.0 version. Is
somebody working on that workaround?
> Tests fail at HEAD on Linux
> ---
>
> Key: MEAR-284
> URL: https://issues.apache.org/jira/browse/MEAR-284
> Project: Maven Ear Plugin
> Issue Type: Test
>Affects Versions: 3.1.0
>Reporter: Elliotte Rusty Harold
>Priority: Blocker
> Fix For: 3.1.0
>
>
> Possibly on other systems:
> {noformat}[INFO] Building: packaging-includes/pom.xml
> [INFO] run post-build script verify.bsh
> [INFO] The post-build script did not succeed. Missing archive entry:
> META-INF/application.xml
> [INFO] packaging-includes/pom.xml FAILED (1.4 s)
> ...
> [ERROR] The following builds failed:
> [ERROR] * packaging-includes/pom.xml
> [ERROR] * basic/pom.xml{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-284) Tests fail at HEAD on Linux
[
https://issues.apache.org/jira/browse/MEAR-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195993#comment-17195993
]
Marat Abrarov edited comment on MEAR-284 at 9/15/20, 9:00 AM:
--
This issue looks like the only blocker for release of 3.1.0 version. Is
somebody working on [that
workaround|https://issues.apache.org/jira/browse/MEAR-284?focusedCommentId=17194817=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17194817]?
was (Author: abrarovm):
This issue looks like the only blocker for release of 3.1.0 version. Is
somebody working on that workaround?
> Tests fail at HEAD on Linux
> ---
>
> Key: MEAR-284
> URL: https://issues.apache.org/jira/browse/MEAR-284
> Project: Maven Ear Plugin
> Issue Type: Test
>Affects Versions: 3.1.0
>Reporter: Elliotte Rusty Harold
>Priority: Blocker
> Fix For: 3.1.0
>
>
> Possibly on other systems:
> {noformat}[INFO] Building: packaging-includes/pom.xml
> [INFO] run post-build script verify.bsh
> [INFO] The post-build script did not succeed. Missing archive entry:
> META-INF/application.xml
> [INFO] packaging-includes/pom.xml FAILED (1.4 s)
> ...
> [ERROR] The following builds failed:
> [ERROR] * packaging-includes/pom.xml
> [ERROR] * basic/pom.xml{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (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=17195901#comment-17195901
]
Marat Abrarov edited comment on MEAR-212 at 9/15/20, 6:22 AM:
--
[~dahoffer], could that workaround (custom type mapping of EAR modules) from
MEAR-216 work for you?
was (Author: abrarovm):
[~dahoffer], could you please provide minimal maven project reproducing this
issue?
Could [that
workaround|https://issues.apache.org/jira/browse/MEAR-216?focusedCommentId=17195895=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17195895]
(custom type mapping of EAR modules) from MEAR-216 work for you?
> 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: 3.1.0
>
>
> 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
[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=17195901#comment-17195901
]
Marat Abrarov commented on MEAR-212:
[~dahoffer], could you please provide minimal maven project reproducing this
issue?
Could [that
workaround|https://issues.apache.org/jira/browse/MEAR-216?focusedCommentId=17195895=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17195895]
(custom type mapping of EAR modules) from MEAR-216 work for you?
> 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: 3.1.0
>
>
> 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
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-216) Unable to include dependencies of type test-jar
[
https://issues.apache.org/jira/browse/MEAR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195895#comment-17195895
]
Marat Abrarov edited comment on MEAR-216 at 9/15/20, 6:13 AM:
--
[~wrungel], what about custom artifact type mappings -
[artifactTypeMappings|https://maven.apache.org/plugins/maven-ear-plugin/generate-application-xml-mojo.html#artifactTypeMappings]
configuration parameter of ear:generate-application-xml and ear:ear goals?
I tried this configuration (upgraded till the latest GA version of Maven EAR
Plugin and added artifactTypeMappings option):
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
7
lib
true
{code}
for [^test-jar-in-ear-2.zip] maven project you provided and it works:
{noformat}
$ mvn clean package
...
[INFO] --< frol:test-jar-in-ear-ear >--
[INFO] Building test-jar-in-ear-ear 1.0-SNAPSHOT [3/3]
[INFO] [ ear ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-jar-in-ear-ear
---
[INFO]
[INFO] --- maven-ear-plugin:3.0.2:generate-application-xml
(default-generate-application-xml) @ test-jar-in-ear-ear ---
[WARNING] Using useBaseVersion not yet fixed.
[INFO] Generating application.xml
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
test-jar-in-ear-ear ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
D:\Users\Marat\Documents\work\java\test-jar-in-ear\ear\src\main\resources
[INFO]
[INFO] --- maven-ear-plugin:3.0.2:ear (default-ear) @ test-jar-in-ear-ear ---
[WARNING] Using useBaseVersion not yet fixed.
[INFO] Copying artifact [jar:frol:test-jar-in-ear-lib:1.0-SNAPSHOT] to
[lib/frol-test-jar-in-ear-lib-1.0-SNAPSHOT.jar]
[INFO] Copying artifact [jar:frol:test-jar-in-ear-lib:tests:1.0-SNAPSHOT] to
[lib/frol-test-jar-in-ear-lib-1.0-SNAPSHOT-tests.jar]
[INFO] Copy ear sources to
D:\Users\Marat\Documents\work\java\test-jar-in-ear\ear\target\test-jar-in-ear-ear-1.0-SNAPSHOT
[INFO] Building jar:
D:\Users\Marat\Documents\work\java\test-jar-in-ear\ear\target\test-jar-in-ear-ear-1.0-SNAPSHOT.ear
[INFO]
[INFO] Reactor Summary for test-jar-in-ear-parent 1.0-SNAPSHOT:
[INFO]
[INFO] test-jar-in-ear-parent . SUCCESS [ 0.194 s]
[INFO] test-jar-in-ear-lib SUCCESS [ 2.390 s]
[INFO] test-jar-in-ear-ear SUCCESS [ 0.892 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 3.655 s (Wall Clock)
[INFO] Finished at: 2020-09-15T08:56:36+03:00
[INFO]
$ cat ear/target/application.xml
http://xmlns.jcp.org/xml/ns/javaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/application_7.xsd; version="7">
test-jar-in-ear-ear
lib
$ unzip -l ear/target/test-jar-in-ear-ear-1.0-SNAPSHOT.ear
Archive: ear/target/test-jar-in-ear-ear-1.0-SNAPSHOT.ear
Length DateTimeName
- -- -
95 09-15-2020 09:04 META-INF/MANIFEST.MF
0 09-15-2020 09:04 META-INF/
0 09-15-2020 09:04 lib/
0 09-15-2020 09:04 META-INF/maven/
0 09-15-2020 09:04 META-INF/maven/frol/
0 09-15-2020 09:04 META-INF/maven/frol/test-jar-in-ear-ear/
2076 09-15-2020 09:04
lib/frol-test-jar-in-ear-lib-1.0-SNAPSHOT-tests.jar
381 09-15-2020 09:04 META-INF/application.xml
1684 09-15-2020 08:56 META-INF/maven/frol/test-jar-in-ear-ear/pom.xml
96 09-15-2020 09:04
META-INF/maven/frol/test-jar-in-ear-ear/pom.properties
2082 09-15-2020 09:04 lib/frol-test-jar-in-ear-lib-1.0-SNAPSHOT.jar
- ---
6414 11 files
{noformat}
Refer to
[{{org.apache.maven.plugins.ear.util.ArtifactTypeMappingService}}|https://github.com/apache/maven-ear-plugin/blob/maven-ear-plugin-3.0.2/src/main/java/org/apache/maven/plugins/ear/util/ArtifactTypeMappingService.java]
class and to
[{{org.apache.maven.plugins.ear.util.ArtifactRepository#getArtifacts}}|https://github.com/apache/maven-ear-plugin/blob/maven-ear-plugin-3.0.2/src/main/java/org/apache/maven/plugins/ear/util/ArtifactRepository.java#L138]
method which is called by
[jira] [Commented] (MEAR-216) Unable to include dependencies of type test-jar
[
https://issues.apache.org/jira/browse/MEAR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195895#comment-17195895
]
Marat Abrarov commented on MEAR-216:
[~wrungel], what about custom artifact type mappings -
[artifactTypeMappings|https://maven.apache.org/plugins/maven-ear-plugin/generate-application-xml-mojo.html#artifactTypeMappings]
configuration parameter of ear:generate-application-xml and ear:ear goals?
I tried this configuration (upgraded till the latest GA version of Maven EAR
Plugin and added artifactTypeMappings option):
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
7
lib
true
{code}
for [^test-jar-in-ear-2.zip] maven project you provided and it works:
{noformat}
$ mvn clean package
...
[INFO] --< frol:test-jar-in-ear-ear >--
[INFO] Building test-jar-in-ear-ear 1.0-SNAPSHOT [3/3]
[INFO] [ ear ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-jar-in-ear-ear
---
[INFO]
[INFO] --- maven-ear-plugin:3.0.2:generate-application-xml
(default-generate-application-xml) @ test-jar-in-ear-ear ---
[WARNING] Using useBaseVersion not yet fixed.
[INFO] Generating application.xml
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
test-jar-in-ear-ear ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
D:\Users\Marat\Documents\work\java\test-jar-in-ear\ear\src\main\resources
[INFO]
[INFO] --- maven-ear-plugin:3.0.2:ear (default-ear) @ test-jar-in-ear-ear ---
[WARNING] Using useBaseVersion not yet fixed.
[INFO] Copying artifact [jar:frol:test-jar-in-ear-lib:1.0-SNAPSHOT] to
[lib/frol-test-jar-in-ear-lib-1.0-SNAPSHOT.jar]
[INFO] Copying artifact [jar:frol:test-jar-in-ear-lib:tests:1.0-SNAPSHOT] to
[lib/frol-test-jar-in-ear-lib-1.0-SNAPSHOT-tests.jar]
[INFO] Copy ear sources to
D:\Users\Marat\Documents\work\java\test-jar-in-ear\ear\target\test-jar-in-ear-ear-1.0-SNAPSHOT
[INFO] Building jar:
D:\Users\Marat\Documents\work\java\test-jar-in-ear\ear\target\test-jar-in-ear-ear-1.0-SNAPSHOT.ear
[INFO]
[INFO] Reactor Summary for test-jar-in-ear-parent 1.0-SNAPSHOT:
[INFO]
[INFO] test-jar-in-ear-parent . SUCCESS [ 0.194 s]
[INFO] test-jar-in-ear-lib SUCCESS [ 2.390 s]
[INFO] test-jar-in-ear-ear SUCCESS [ 0.892 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 3.655 s (Wall Clock)
[INFO] Finished at: 2020-09-15T08:56:36+03:00
[INFO]
$ cat ear/target/application.xml
http://xmlns.jcp.org/xml/ns/javaee;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/application_7.xsd; version="7">
test-jar-in-ear-ear
lib
$ unzip -l ear/target/test-jar-in-ear-ear-1.0-SNAPSHOT.ear
Archive: ear/target/test-jar-in-ear-ear-1.0-SNAPSHOT.ear
Length DateTimeName
- -- -
95 09-15-2020 09:04 META-INF/MANIFEST.MF
0 09-15-2020 09:04 META-INF/
0 09-15-2020 09:04 lib/
0 09-15-2020 09:04 META-INF/maven/
0 09-15-2020 09:04 META-INF/maven/frol/
0 09-15-2020 09:04 META-INF/maven/frol/test-jar-in-ear-ear/
2076 09-15-2020 09:04
lib/frol-test-jar-in-ear-lib-1.0-SNAPSHOT-tests.jar
381 09-15-2020 09:04 META-INF/application.xml
1684 09-15-2020 08:56 META-INF/maven/frol/test-jar-in-ear-ear/pom.xml
96 09-15-2020 09:04
META-INF/maven/frol/test-jar-in-ear-ear/pom.properties
2082 09-15-2020 09:04 lib/frol-test-jar-in-ear-lib-1.0-SNAPSHOT.jar
- ---
6414 11 files
{noformat}
Refer to
[{{org.apache.maven.plugins.ear.util.ArtifactTypeMappingService}}|https://github.com/apache/maven-ear-plugin/blob/maven-ear-plugin-3.0.2/src/main/java/org/apache/maven/plugins/ear/util/ArtifactTypeMappingService.java]
class and to
[{{org.apache.maven.plugins.ear.util.ArtifactRepository#getArtifacts}}|https://github.com/apache/maven-ear-plugin/blob/maven-ear-plugin-3.0.2/src/main/java/org/apache/maven/plugins/ear/util/ArtifactRepository.java#L138]
method which is called by
[jira] [Updated] (MEAR-216) Unable to include dependencies of type test-jar
[
https://issues.apache.org/jira/browse/MEAR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-216:
---
Attachment: (was: screenshot-1.png)
> Unable to include dependencies of type test-jar
> ---
>
> Key: MEAR-216
> URL: https://issues.apache.org/jira/browse/MEAR-216
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Maxim Frolov
>Priority: Major
> Fix For: 3.1.0
>
> Attachments: test-jar-in-ear-2.zip, test-jar-in-ear.zip
>
>
> Please implement support for artifacts of type *test-jar*.
> One of the use cases would be to build a test EAR as a mix of production and
> test JARs where the test JARs are used to set up the test data used to test
> the production code.
> Currently including one or more dependencies of type test-jar causes
> *LifecycleExecutionException*:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project suite-systemtests-common-ear:
> Failed to initialize ear modules: Unknown artifact type[test-jar] for
> artifact_id -> [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 suite-systemtests-common-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[test-jar] for common-domain-impl
> at
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
> ... 22 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-216) Unable to include dependencies of type test-jar
[
https://issues.apache.org/jira/browse/MEAR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marat Abrarov updated MEAR-216:
---
Attachment: screenshot-1.png
> Unable to include dependencies of type test-jar
> ---
>
> Key: MEAR-216
> URL: https://issues.apache.org/jira/browse/MEAR-216
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Maxim Frolov
>Priority: Major
> Fix For: 3.1.0
>
> Attachments: test-jar-in-ear-2.zip, test-jar-in-ear.zip
>
>
> Please implement support for artifacts of type *test-jar*.
> One of the use cases would be to build a test EAR as a mix of production and
> test JARs where the test JARs are used to set up the test data used to test
> the production code.
> Currently including one or more dependencies of type test-jar causes
> *LifecycleExecutionException*:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project suite-systemtests-common-ear:
> Failed to initialize ear modules: Unknown artifact type[test-jar] for
> artifact_id -> [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 suite-systemtests-common-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[test-jar] for common-domain-impl
> at
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
> ... 22 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)
[
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179014#comment-17179014
]
Marat Abrarov edited comment on MEAR-280 at 9/1/20, 9:14 AM:
-
This issue looks being still actual because Maven EAR Plugin generates not
reproducible EARs when skinnyWars option is used
({{true}} in {{configuration}} of Maven EAR Plugin).
[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
branch of mabrarov/dockerfile-test repository can be used for reproducing this
issue (requires Maven EAR Plugin and [Maven Artifact
Plugin|https://github.com/apache/maven-artifact-plugin] to be built and
installed into local maven repository).
With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO]
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test SUCCESS [ 1.381 s]
[INFO] war SUCCESS [ 1.190 s]
[INFO] ear SUCCESS [ 0.484 s]
[INFO] base-image . SUCCESS [ 1.275 s]
[INFO] hollow-image ... SUCCESS [ 0.163 s]
[INFO] app-image .. SUCCESS [ 0.242 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO]
$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro
registry.salsa.debian.org/reproducible-builds/diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract: 2.0
│compression method: deflated
│compression sub-type (deflation): normal
│file security status: not encrypted
│extended local header: no
│file last modified on (DOS date/time): 2020 Aug 17 14:23:02
│ - 32-bit CRC value (hex): f3f3d0e7
│ + 32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size: 3687 bytes
│length of filename: 51 characters
│length of extra field: 0 bytes
│length of file comment: 0 characters
│disk number on which file begins: disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software: 2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract: 2.0
│ │compression method: deflated
│ │compression sub-type (deflation): normal
│ │file security status: not encrypted
│ │extended local header: no
│ │ - file last modified on (DOS date/time): 2020 Aug 17 17:36:34
│ │ + file last modified on (DOS date/time): 2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size: 241 bytes
│ │length of filename: 20 characters
│ │length of extra field: 0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins: disk 1
│ │ @@ -54,15 +54,15 @@
│
[jira] [Created] (MEAR-283) Not reproducible builds when skinnyWars option turned on
Marat Abrarov created MEAR-283:
--
Summary: Not reproducible builds when skinnyWars option turned on
Key: MEAR-283
URL: https://issues.apache.org/jira/browse/MEAR-283
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Marat Abrarov
Implementation of MEAR-280 lacks support of skinnyWars option - when this
option is turned on and when Maven EAR Plugin repackages WARs included into
EAR, then current time is used for timestamps of files in repackaged EAR
instead of {{project.build.outputTimestamp}} maven property.
Refer to [that
comment|https://issues.apache.org/jira/browse/MEAR-280?focusedCommentId=17179014=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17179014]
in MEAR-280 for details like repro repo and for the link to possible fix (link
to GitHub pull request).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)
[
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179014#comment-17179014
]
Marat Abrarov edited comment on MEAR-280 at 8/26/20, 12:09 PM:
---
This issue looks being still actual because Maven EAR Plugin generates not
reproducible EARs when skinnyWars option is used
({{true}} in {{configuration}} of Maven EAR Plugin).
[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
branch of mabrarov/dockerfile-test repository can be used for reproducing this
issue (requires Maven EAR Plugin and [Maven Artifact
Plugin|https://github.com/apache/maven-artifact-plugin] to be built and
installed into local maven repository).
With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO]
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test SUCCESS [ 1.381 s]
[INFO] war SUCCESS [ 1.190 s]
[INFO] ear SUCCESS [ 0.484 s]
[INFO] base-image . SUCCESS [ 1.275 s]
[INFO] hollow-image ... SUCCESS [ 0.163 s]
[INFO] app-image .. SUCCESS [ 0.242 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO]
$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro
registry.salsa.debian.org/reproducible-builds/diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract: 2.0
│compression method: deflated
│compression sub-type (deflation): normal
│file security status: not encrypted
│extended local header: no
│file last modified on (DOS date/time): 2020 Aug 17 14:23:02
│ - 32-bit CRC value (hex): f3f3d0e7
│ + 32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size: 3687 bytes
│length of filename: 51 characters
│length of extra field: 0 bytes
│length of file comment: 0 characters
│disk number on which file begins: disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software: 2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract: 2.0
│ │compression method: deflated
│ │compression sub-type (deflation): normal
│ │file security status: not encrypted
│ │extended local header: no
│ │ - file last modified on (DOS date/time): 2020 Aug 17 17:36:34
│ │ + file last modified on (DOS date/time): 2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size: 241 bytes
│ │length of filename: 20 characters
│ │length of extra field: 0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins: disk 1
│ │ @@ -54,15 +54,15
[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)
[
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179014#comment-17179014
]
Marat Abrarov edited comment on MEAR-280 at 8/17/20, 11:56 PM:
---
This issue looks being still actual because Maven EAR Plugin generates not
reproducible EARs when skinnyWars option is used
({{true}} in {{configuration}} of Maven EAR Plugin).
[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
branch of mabrarov/dockerfile-test repository can be used for reproducing this
issue (requires Maven EAR Plugin and [Maven Artifact
Plugin|https://github.com/apache/maven-artifact-plugin] to be built and
installed into local maven repository).
With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO]
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test SUCCESS [ 1.381 s]
[INFO] war SUCCESS [ 1.190 s]
[INFO] ear SUCCESS [ 0.484 s]
[INFO] base-image . SUCCESS [ 1.275 s]
[INFO] hollow-image ... SUCCESS [ 0.163 s]
[INFO] app-image .. SUCCESS [ 0.242 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO]
$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro
registry.salsa.debian.org/reproducible-builds/diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract: 2.0
│compression method: deflated
│compression sub-type (deflation): normal
│file security status: not encrypted
│extended local header: no
│file last modified on (DOS date/time): 2020 Aug 17 14:23:02
│ - 32-bit CRC value (hex): f3f3d0e7
│ + 32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size: 3687 bytes
│length of filename: 51 characters
│length of extra field: 0 bytes
│length of file comment: 0 characters
│disk number on which file begins: disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software: 2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract: 2.0
│ │compression method: deflated
│ │compression sub-type (deflation): normal
│ │file security status: not encrypted
│ │extended local header: no
│ │ - file last modified on (DOS date/time): 2020 Aug 17 17:36:34
│ │ + file last modified on (DOS date/time): 2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size: 241 bytes
│ │length of filename: 20 characters
│ │length of extra field: 0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins: disk 1
│ │ @@ -54,15 +54,15
[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)
[
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179014#comment-17179014
]
Marat Abrarov edited comment on MEAR-280 at 8/17/20, 11:45 PM:
---
This issue looks being still actual because Maven EAR Plugin generates not
reproducible EARs when skinnyWars option is used
({{true}} in {{configuration}} of Maven EAR Plugin).
[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
branch of mabrarov/dockerfile-test repository can be used for reproducing this
issue (requires Maven EAR Plugin and [Maven Artifact
Plugin|https://github.com/apache/maven-artifact-plugin] to be built and
installed into local maven repository).
With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO]
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test SUCCESS [ 1.381 s]
[INFO] war SUCCESS [ 1.190 s]
[INFO] ear SUCCESS [ 0.484 s]
[INFO] base-image . SUCCESS [ 1.275 s]
[INFO] hollow-image ... SUCCESS [ 0.163 s]
[INFO] app-image .. SUCCESS [ 0.242 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO]
$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro
registry.salsa.debian.org/reproducible-builds/diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract: 2.0
│compression method: deflated
│compression sub-type (deflation): normal
│file security status: not encrypted
│extended local header: no
│file last modified on (DOS date/time): 2020 Aug 17 14:23:02
│ - 32-bit CRC value (hex): f3f3d0e7
│ + 32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size: 3687 bytes
│length of filename: 51 characters
│length of extra field: 0 bytes
│length of file comment: 0 characters
│disk number on which file begins: disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software: 2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract: 2.0
│ │compression method: deflated
│ │compression sub-type (deflation): normal
│ │file security status: not encrypted
│ │extended local header: no
│ │ - file last modified on (DOS date/time): 2020 Aug 17 17:36:34
│ │ + file last modified on (DOS date/time): 2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size: 241 bytes
│ │length of filename: 20 characters
│ │length of extra field: 0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins: disk 1
│ │ @@ -54,15 +54,15
[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)
[
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179014#comment-17179014
]
Marat Abrarov edited comment on MEAR-280 at 8/17/20, 2:47 PM:
--
This issue looks being still actual because Maven EAR Plugin generates not
reproducible EARs when skinnyWars option is used
({{true}} in {{configuration}} of Maven EAR Plugin).
[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
branch of mabrarov/dockerfile-test repository can be used for reproducing this
issue (requires Maven EAR Plugin to be built and installed into local maven
repository).
With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO]
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test SUCCESS [ 1.381 s]
[INFO] war SUCCESS [ 1.190 s]
[INFO] ear SUCCESS [ 0.484 s]
[INFO] base-image . SUCCESS [ 1.275 s]
[INFO] hollow-image ... SUCCESS [ 0.163 s]
[INFO] app-image .. SUCCESS [ 0.242 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO]
$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro
registry.salsa.debian.org/reproducible-builds/diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract: 2.0
│compression method: deflated
│compression sub-type (deflation): normal
│file security status: not encrypted
│extended local header: no
│file last modified on (DOS date/time): 2020 Aug 17 14:23:02
│ - 32-bit CRC value (hex): f3f3d0e7
│ + 32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size: 3687 bytes
│length of filename: 51 characters
│length of extra field: 0 bytes
│length of file comment: 0 characters
│disk number on which file begins: disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software: 2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract: 2.0
│ │compression method: deflated
│ │compression sub-type (deflation): normal
│ │file security status: not encrypted
│ │extended local header: no
│ │ - file last modified on (DOS date/time): 2020 Aug 17 17:36:34
│ │ + file last modified on (DOS date/time): 2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size: 241 bytes
│ │length of filename: 20 characters
│ │length of extra field: 0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins: disk 1
│ │ @@ -54,15 +54,15 @@
│ │file system or operating system of origin: Unix
│ │version of
[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)
[
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179014#comment-17179014
]
Marat Abrarov edited comment on MEAR-280 at 8/17/20, 2:46 PM:
--
This issue looks being still actual because Maven EAR Plugin generates not
reproducible EARs when skinnyWars option is used
({{true}} in {{configuration}} of Maven EAR Plugin).
[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
branch of mabrarov/dockerfile-test repository can be used for reproducing this
issue (requires Maven EAR Plugin to be built and installed into local maven
repository).
With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO]
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test SUCCESS [ 1.381 s]
[INFO] war SUCCESS [ 1.190 s]
[INFO] ear SUCCESS [ 0.484 s]
[INFO] base-image . SUCCESS [ 1.275 s]
[INFO] hollow-image ... SUCCESS [ 0.163 s]
[INFO] app-image .. SUCCESS [ 0.242 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO]
$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro
registry.salsa.debian.org/reproducible-builds/diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract: 2.0
│compression method: deflated
│compression sub-type (deflation): normal
│file security status: not encrypted
│extended local header: no
│file last modified on (DOS date/time): 2020 Aug 17 14:23:02
│ - 32-bit CRC value (hex): f3f3d0e7
│ + 32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size: 3687 bytes
│length of filename: 51 characters
│length of extra field: 0 bytes
│length of file comment: 0 characters
│disk number on which file begins: disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software: 2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract: 2.0
│ │compression method: deflated
│ │compression sub-type (deflation): normal
│ │file security status: not encrypted
│ │extended local header: no
│ │ - file last modified on (DOS date/time): 2020 Aug 17 17:36:34
│ │ + file last modified on (DOS date/time): 2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size: 241 bytes
│ │length of filename: 20 characters
│ │length of extra field: 0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins: disk 1
│ │ @@ -54,15 +54,15 @@
│ │file system or operating system of origin: Unix
│ │version of
