[jira] [Commented] (MSHADE-339) Shaded test jar has wrong type "jar"
[
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005182#comment-17005182
]
Herve Boutemy commented on MSHADE-339:
--
it seems we now agree on changing the PR to not override classifier but use the
default value:
{code:java}projectHelper.attachArtifact( project, "test-jar", shadedTests
);{code}
on deciding whether this change should really be done instead of letting
initial
{code:java}projectHelper.attachArtifact( project, "jar", "tests", shadedTests
);{code}
we perfectly see the difference in the 2 Artifact objects that are created by
these 2 API calls, that map to the same file (classifier + extension): notice
that these objects are not equal given equals() implementation that uses
groupId, artifactId, version, type and classifier
Now, in the context of the project attaching the artifact, the project does not
care: it does not use the artifact as a dependency.
In the context of another project that would use the file as a dependency, it
would create another Artifact instance with the expected type for the
dependency, and that would match the file. The resolution of the dependency
happens at File level, as resolved from repositories: the artifact instance
that created the file has no impact. Reactor resolution optimization does the
same, using extension:
https://maven.apache.org/ref/3.6.3/maven-core/xref/org/apache/maven/ReactorReader.html#L232
(notice that Artifact here is org.eclipse.aether.Artifact, that perfectly
separates Artifact and Dependency notions: it learned from initial Maven
mistake)
I'm confident that ITs will prove that both codes work.
I'm clear that the "test-jar" is what the API intended.
I'm sure that "jar" + "tests" is what best represents the reality in the
context of the project that attach the file, and that when we refactor Maven's
Artifact to split its dependency aspects, "test-jar" won't work any more at
artifact level but only at dependency level
I'm torn if the PR should be applied :/
> Shaded test jar has wrong type "jar"
>
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-339) Shaded test jar has wrong type "jar"
[
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005051#comment-17005051
]
Peter De Maeyer edited comment on MSHADE-339 at 12/30/19 7:38 AM:
--
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it
actually is given the implementation), we should attach with "test-jar" type
and no classifier, since the implementation will fill with the default
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}
I agree with you there, but if we do that consistently in the implementation of
{{ShadeMojo}}, that's a much bigger change than I was willing to do in the
context of this issue. I was planning to create a separate issue for that at
some point.
# Everywhere in the implementation {{ShadeMojo}} where
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as
classifier. In fact, the only reason to ever pass a non-null classifier is if
you intend to use a _different_ one than the default. Classifiers and extension
should always be gotten from the {{ArtifactHandler}} instead of the hardcoded
ones that are currently used. If you do that, it would be easier to prove that
"jar" is the wrong type, and it should really be "test-jar".
{quote}
if we consider we want to use it more as an extension (which is IMHO more
logical given
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we
should use "jar" extension and "tests" classifier
{quote}
I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type,
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar"
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the
rest of the code because the classifier "tests" is passed in to override it,
but that doesn't make it right.
was (Author: peterdm):
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it
actually is given the implementation), we should attach with "test-jar" type
and no classifier, since the implementation will fill with the default
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}
I agree with you there, but if we do that consistently in the implementation of
{{ShadeMojo}}, that's a much bigger change than I was willing to do in the
context of this issue. I was planning to create a separate issue for that at
some point. _Everywhere_ in the implementation {{ShadeMojo}} where
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as
classifier. In fact, the only reason to ever pass a non-null classifier is if
you intend to use a _different_ one than the default, which the {{ShadeMojo}}
plugin never does. If you do that, it would be easier to prove that "jar" is
the wrong type, and it should really be "test-jar".
{quote}
if we consider we want to use it more as an extension (which is IMHO more
logical given
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we
should use "jar" extension and "tests" classifier
{quote}
I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type,
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar"
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the
rest of the code because the classifier "tests" is passed in to override it,
but that doesn't make it right.
> Shaded test jar has wrong type "jar"
>
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "tes
[GitHub] [maven-checkstyle-plugin] romani commented on issue #18: [MCHECKSTYLE-381] remove call to checker.setClassLoader().
romani commented on issue #18: [MCHECKSTYLE-381] remove call to checker.setClassLoader(). URL: https://github.com/apache/maven-checkstyle-plugin/pull/18#issuecomment-569548423 > You will start seeing warnings about some internal unused methods. it is better than live in illusions that classpath is actually helping chekstyle to do validation. Classpath functionality was completely removed in 8.28 (released today), it was very unreliable in validation from the beginning. So users unlikely happy with classpath related features. > I'd love to hear why to implement that warning. I am not ready to provide good reasons. If you not feel that it is good - I trust you. Lets proceed without warning. I just try to send a message that any attempts to provide classpath to plugin will be ignored by library/validator. I thought in some discussion that you are in favor of deprecation process, I agree with you to some extend, we need to give signal to user that classpath is deprecated (Checks do not use classpath). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (MSHADE-339) Shaded test jar has wrong type "jar"
[
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005051#comment-17005051
]
Peter De Maeyer edited comment on MSHADE-339 at 12/29/19 9:54 PM:
--
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it
actually is given the implementation), we should attach with "test-jar" type
and no classifier, since the implementation will fill with the default
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}
I agree with you there, but if we do that consistently in the implementation of
{{ShadeMojo}}, that's a much bigger change than I was willing to do in the
context of this issue. I was planning to create a separate issue for that at
some point. _Everywhere_ in the implementation {{ShadeMojo}} where
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as
classifier. In fact, the only reason to ever pass a non-null classifier is if
you intend to use a _different_ one than the default, which the {{ShadeMojo}}
plugin never does. If you do that, it would be easier to prove that "jar" is
the wrong type, and it should really be "test-jar".
{quote}
if we consider we want to use it more as an extension (which is IMHO more
logical given
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we
should use "jar" extension and "tests" classifier
{quote}
I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type,
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar"
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the
rest of the code because the classifier "tests" is passed in to override it,
but that doesn't make it right.
was (Author: peterdm):
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it
actually is given the implementation), we should attach with "test-jar" type
and no classifier, since the implementation will fill with the default
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}
In fact, I agree with you there, but if we do that consistently in the
implementation of {{ShadeMojo}}, that's a much bigger change than I was willing
to do in the context of this issue. I was planning to create a separate issue
for that at some point. _Everywhere_ in the implementation {{ShadeMojo}} where
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as
classifier. In fact, the only reason to ever pass a non-null classifier is if
you intend to use a _different_ one than the default, which the {{ShadeMojo}}
plugin never does. If you do that, it would be easier to prove that "jar" is
the wrong type, and it should really be "test-jar".
{quote}
if we consider we want to use it more as an extension (which is IMHO more
logical given
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we
should use "jar" extension and "tests" classifier
{quote}
I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type,
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar"
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the
rest of the code because the classifier "tests" is passed in to override it,
but that doesn't make it right.
> Shaded test jar has wrong type "jar"
>
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-339) Shaded test jar has wrong type "jar"
[
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005051#comment-17005051
]
Peter De Maeyer edited comment on MSHADE-339 at 12/29/19 9:53 PM:
--
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it
actually is given the implementation), we should attach with "test-jar" type
and no classifier, since the implementation will fill with the default
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}
In fact, I agree with you there, but if we do that consistently in the
implementation of {{ShadeMojo}}, that's a much bigger change than I was willing
to do in the context of this issue. I was planning to create a separate issue
for that at some point. _Everywhere_ in the implementation {{ShadeMojo}} where
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as
classifier. In fact, the only reason to ever pass a non-null classifier is if
you intend to use a _different_ one than the default, which the {{ShadeMojo}}
plugin never does. If you do that, it would be easier to prove that "jar" is
the wrong type, and it should really be "test-jar".
{quote}
if we consider we want to use it more as an extension (which is IMHO more
logical given
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we
should use "jar" extension and "tests" classifier
{quote}
I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type,
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar"
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the
rest of the code because the classifier "tests" is passed in to override it,
but that doesn't make it right.
was (Author: peterdm):
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it
actually is given the implementation), we should attach with "test-jar" type
and no classifier, since the implementation will fill with the default
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}
In fact, I agree with you there, but if we do that consistently in the
implementation of {{ShadeMojo}}, that's a much bigger change than I was willing
to do in the context of this issue. I was planning to create a separate issue
for that at some point. _Everywhere_ in the implementation {{ShadeMojo}} where
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as
classifier. In fact, the only reason you would ever pass a non-null classifier
is if you intend to use a different one than the default, which the
{{ShadeMojo}} plugin never does. If you do that, it would be easier to prove
that "jar" is the wrong type, and it should really be "test-jar".
{quote}
if we consider we want to use it more as an extension (which is IMHO more
logical given
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we
should use "jar" extension and "tests" classifier
{quote}
I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type,
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar"
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the
rest of the code because the classifier "tests" is passed in to override it,
but that doesn't make it right.
> Shaded test jar has wrong type "jar"
>
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".
--
This message was sent by Atlassian Jira
(v8.3.4#803005
[jira] [Commented] (MSHADE-339) Shaded test jar has wrong type "jar"
[
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005051#comment-17005051
]
Peter De Maeyer commented on MSHADE-339:
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it
actually is given the implementation), we should attach with "test-jar" type
and no classifier, since the implementation will fill with the default
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}
In fact, I agree with you there, but if we do that consistently in the
implementation of {{ShadeMojo}}, that's a much bigger change than I was willing
to do in the context of this issue. I was planning to create a separate issue
for that at some point. _Everywhere_ in the implementation {{ShadeMojo}} where
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as
classifier. In fact, the only reason you would ever pass a non-null classifier
is if you intend to use a different one than the default, which the
{{ShadeMojo}} plugin never does. If you do that, it would be easier to prove
that "jar" is the wrong type, and it should really be "test-jar".
{quote}
if we consider we want to use it more as an extension (which is IMHO more
logical given
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we
should use "jar" extension and "tests" classifier
{quote}
I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type,
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar"
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the
rest of the code because the classifier "tests" is passed in to override it,
but that doesn't make it right.
> Shaded test jar has wrong type "jar"
>
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-checkstyle-plugin] bmhm commented on issue #18: [MCHECKSTYLE-381] remove call to checker.setClassLoader().
bmhm commented on issue #18: [MCHECKSTYLE-381] remove call to checker.setClassLoader(). URL: https://github.com/apache/maven-checkstyle-plugin/pull/18#issuecomment-569537715 For users? No. This is really interesting for devs. Imagine you do not upgrade checkstyle (yet) for various reasons, but the checkstyle plugin. You will start seeing warnings about some internal unused methods. I do not believe they are useful to maven users. If you think they are, I'd love to hear why to implement that warning. Please don't take this as a criticism. I just want to avoid warnings issued to users which are not that important to them as they may seem helpful to us. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #248: SUREFIRE-1695 Support multiple inheritance of @Categories
Tibor17 commented on issue #248: SUREFIRE-1695 Support multiple inheritance of
@Categories
URL: https://github.com/apache/maven-surefire/pull/248#issuecomment-569525999
@YiannisDermitzakis
It looks good but still it is incomplete. Typically the unit tests must be
included in `JUnit4SuiteTest`. The problem here is that
`GroupMatcherCategoryFilterPreJUnit412Test` has to have older `junit` library
in the test classpath and the test `GroupMatcherCategoryFilterTest` requires
the version `4.12`. It can be done but you have to modify the executions of the
plugin
https://github.com/apache/maven-surefire/blob/84fc3518b999f3ffba522840a9a6551fe00d7ee5/surefire-providers/common-junit48/pom.xml#L76
so that the pase `default-test` of the first execution with the configuration
as you can see in the POM. The second execution should have another phase id
name with new config, new test suite class pointing to the
`GroupMatcherCategoryFilterTest` and `junit:4.12` referenced by
`additionalClasspathElements`. Here is an example to copy external artifact to
a separate folder under `/target`, see
`${project.build.directory}/endorsed-test` and
https://github.com/apache/maven-surefire/blob/84fc3518b999f3ffba522840a9a6551fe00d7ee5/surefire-providers/surefire-junit47/pom.xml#L125
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Updated] (MSHADE-342) Many integration tests fail when run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-342:
---
Description:
Maven invoker plugin supports running ITs in isolation, but many ITs fail when
run in isolation.
One example (there are many others):
{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}
They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.
The reason is that there is a missing parent dependency, which is apparently
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing
directory is created by some other test in the beginning of the IT test run,
and then all subsequent tests work as well.
h3. Potential solution
A fix is to identify the broken ITs by running all of them in isolation and add
the following to all of the broken ones:
{code:xml}
org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent
{code}
It should be documented somewhere (maybe it is but I overlooked it?) that, when
writing an IT, this _must_ be the parent.
The acceptance criteria for the fix should be:
# {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in
isolation.
# Optional, but nice if it works: after running the IT (or all ITs) once, it
must be possible to debug the Maven project by doing {{cd target/it/;
mvnDebug install}}.
(+) It satisfies both acceptance criteria.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).
Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the
{{setup-parent}} project comes from.
was:
Maven invoker plugin supports running ITs in isolation, but many ITs fail when
running them in isolation.
One example (there are many others):
{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}
They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.
The reason is that there is a missing parent dependency, which is apparently
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing
directory is created by some other test in the beginning of the IT test run,
and then all subsequent tests work as well.
h3. Potential solution
A fix is to identify the broken ITs by running all of them in isolation and add
the following to all of the broken ones:
{code:xml}
org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent
{code}
It should be documented somewhere (maybe it is but I overlooked it?) that, when
writing an IT, this _must_ be the parent.
The acceptance criteria for the fix should be:
# {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in
isolation.
# Optional, but nice if it works: after running the IT (or all ITs) once, it
must be possible to debug the Maven project by doing {{cd target/it/;
mvnDebug install}}.
(+) It satisfies both acceptance criteria.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).
Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the
{{setup-parent}} project comes from.
> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail
> when run in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> h3. Potential solution
> A fix is to identify the broken ITs by running all of them in isolation and
> add th
[jira] [Commented] (MSHADE-342) Many integration tests fail when run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004828#comment-17004828
]
Peter De Maeyer commented on MSHADE-342:
{quote}
this IT should be defined as a setup IT
{quote}
I don't know how to do that, I'm not so familiar with the
{{maven-invoker-plugin}}. I'll need to figure that out.
> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> h3. Potential solution
> A fix is to identify the broken ITs by running all of them in isolation and
> add the following to all of the broken ones:
> {code:xml}
>
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
>
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that,
> when writing an IT, this _must_ be the parent.
> The acceptance criteria for the fix should be:
> # {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in
> isolation.
> # Optional, but nice if it works: after running the IT (or all ITs) once, it
> must be possible to debug the Maven project by doing {{cd target/it/;
> mvnDebug install}}.
> (+) It satisfies both acceptance criteria.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the
> {{setup-parent}} project comes from.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-342) Many integration tests fail when run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-342:
---
Description:
Maven invoker plugin supports running ITs in isolation, but many ITs fail when
running them in isolation.
One example (there are many others):
{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}
They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.
The reason is that there is a missing parent dependency, which is apparently
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing
directory is created by some other test in the beginning of the IT test run,
and then all subsequent tests work as well.
h3. Potential solution
A fix is to identify the broken ITs by running all of them in isolation and add
the following to all of the broken ones:
{code:xml}
org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent
{code}
It should be documented somewhere (maybe it is but I overlooked it?) that, when
writing an IT, this _must_ be the parent.
The acceptance criteria for the fix should be:
# {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in
isolation.
# Optional, but nice if it works: after running the IT (or all ITs) once, it
must be possible to debug the Maven project by doing {{cd target/it/;
mvnDebug install}}.
(+) It satisfies both acceptance criteria.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).
Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the
{{setup-parent}} project comes from.
was:
Maven invoker plugin supports running ITs in isolation, but many ITs fail when
running them in isolation.
One example (there are many others):
{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}
They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.
The reason is that there is a missing parent dependency, which is apparently
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing
directory is created by some other test in the beginning of the IT test run,
and then all subsequent tests work as well.
h3. Potential solution 1
A fix is to identify the broken ITs by running all of them in isolation and add
the following to all of the broken ones:
{code:xml}
org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent
{code}
It should be documented somewhere (maybe it is but I overlooked it?) that, when
writing an IT, this _must_ be the parent.
(+) This will work.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).
Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the
{{setup-parent}} project comes from.
> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> h3. Potential solution
> A fix is to identify the broken ITs by running all of them in isolation and
> add the following to all of the broken ones:
> {code:xml}
>
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
>
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that,
> when writing an IT, this _must_ be t
[jira] [Commented] (MRESOURCES-250) Add ability to flatten folder structure into target directory when copying resources
[ https://issues.apache.org/jira/browse/MRESOURCES-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004798#comment-17004798 ] Michel Schudel commented on MRESOURCES-250: --- [~khmarbaise] can you shed a light on your or my proposed solution? Or you can follow me on Twitter so we can DM: @MichelSchudel > Add ability to flatten folder structure into target directory when copying > resources > > > Key: MRESOURCES-250 > URL: https://issues.apache.org/jira/browse/MRESOURCES-250 > Project: Maven Resources Plugin > Issue Type: New Feature > Components: copy >Reporter: Jamie Spence >Priority: Major > Labels: up-for-grabs > > See flatten description at: > h[ttps://ant.apache.org/manual/Tasks/copy.html|https://ant.apache.org/manual/Tasks/copy.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHADE-342) Many integration tests fail when run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-342:
---
Description:
Maven invoker plugin supports running ITs in isolation, but many ITs fail when
running them in isolation.
One example (there are many others):
{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}
They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.
The reason is that there is a missing parent dependency, which is apparently
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing
directory is created by some other test in the beginning of the IT test run,
and then all subsequent tests work as well.
h3. Potential solution 1
A fix is to identify the broken ITs by running all of them in isolation and add
the following to all of the broken ones:
{code:xml}
org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent
{code}
It should be documented somewhere (maybe it is but I overlooked it?) that, when
writing an IT, this _must_ be the parent.
(+) This will work.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).
Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the
{{setup-parent}} project comes from.
was:
Maven invoker plugin supports running ITs in isolation, but many ITs fail when
running them in isolation.
One example (there are many others):
{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}
They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.
The reason is that there is a missing parent dependency, which is apparently
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing
directory is created by some other test in the beginning of the IT test run,
and then all subsequent tests work as well.
h3. Potential solution 1
A fix is to identify the broken ITs by running all of them in isolation and add
the following to all of the broken ones:
{code:xml}
org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent
{code}
It should be documented somewhere (maybe it is but I overlooked it?) that, when
writing an IT, this _must_ be the parent.
(+) This will work.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).
Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the
{{setup-parent}} project comes from.
> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> h3. Potential solution 1
> A fix is to identify the broken ITs by running all of them in isolation and
> add the following to all of the broken ones:
> {code:xml}
>
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
>
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that,
> when writing an IT, this _must_ be the parent.
> (+) This will work.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to in
[jira] [Updated] (MSHADE-342) Many integration tests fail when run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-342:
---
Summary: Many integration tests fail when run in isolation (was: Many ITs
fail when run in isolation)
> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> h3. Potential solution 1
> A fix is to identify the broken ITs by running all of them in isolation and
> add the following to all of the broken ones:
> {code:xml}
>
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
>
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that,
> when writing an IT, this _must_ be the parent.
> (+) This will work.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the
> {{setup-parent}} project comes from.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-checkstyle-plugin] bmhm commented on issue #18: [MCHECKSTYLE-381] remove call to checker.setClassLoader().
bmhm commented on issue #18: [MCHECKSTYLE-381] remove call to checker.setClassLoader(). URL: https://github.com/apache/maven-checkstyle-plugin/pull/18#issuecomment-569505877 Thanks and agreed about the tests. We may need to refibe existing tests if/when we use checkstyle 8.24 or newer. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-checkstyle-plugin] bmhm edited a comment on issue #18: [MCHECKSTYLE-381] remove call to checker.setClassLoader().
bmhm edited a comment on issue #18: [MCHECKSTYLE-381] remove call to checker.setClassLoader(). URL: https://github.com/apache/maven-checkstyle-plugin/pull/18#issuecomment-569505877 Thanks and agreed about the tests. We may need to refine existing tests if/when we use checkstyle 8.24 or newer. That's it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-checkstyle-plugin] bmhm commented on issue #18: [MCHECKSTYLE-381] remove call to checker.setClassLoader().
bmhm commented on issue #18: [MCHECKSTYLE-381] remove call to checker.setClassLoader(). URL: https://github.com/apache/maven-checkstyle-plugin/pull/18#issuecomment-569500345 @romani @struberg @rfscholte Reworked to call the method if it is available by catching a `NoSuchMethodError`. I was also thinking of using reflection to check if the method exists, but I decided agains this to have minimal changes. However, I changed the `urls.toArray()` method to use `new URL[0]` which is faster than `new URL[urls.size()]` and also the recommended way on more recent versions (Java 8+). Please review. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MSHADE-340) Shaded test jar artifact is not attached
[
https://issues.apache.org/jira/browse/MSHADE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHADE-340:
-
Fix Version/s: 3.2.2
> Shaded test jar artifact is not attached
>
>
> Key: MSHADE-340
> URL: https://issues.apache.org/jira/browse/MSHADE-340
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Major
> Fix For: 3.2.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{shadedArtifactAttached=true}} and {{shadeTestJar=true}}, the shaded
> test jar file is created but the artifact is not attached to the project.
> As a result, projects that depend on the attached test artifact don't compile.
> This does not affect the default case {{shadedArtifactAttached=false}} where
> the shaded artifact replaces the original artifact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-339) Shaded test jar has wrong type "jar"
[ https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004732#comment-17004732 ] Herve Boutemy commented on MSHADE-339: -- thanks [~peterdm] I had a look at Artifact interface https://maven.apache.org/ref/3.6.3/maven-artifact/apidocs/org/apache/maven/artifact/Artifact.html and its default implementation the root issue is in this interface, which mixes artifact features with dependency features, then it's hard to really use only one aspect... IMHO if we consider that the MavenProjectHelper parameter is a type (which it actually is given the implementation), we should attach with "test-jar" type and no classifier, since the implementation will fill with the default classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html if we consider we want to use it more as an extension (which is IMHO more logical given https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we should use "jar" extension and "tests" classifier of course, if your IT can prove one provides different result than the other (which is not obvious to me), this will give us a preference for one implementation over the other... > Shaded test jar has wrong type "jar" > > > Key: MSHADE-339 > URL: https://issues.apache.org/jira/browse/MSHADE-339 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.2, 3.2.2 >Reporter: Peter De Maeyer >Priority: Minor > Fix For: 3.2.2 > > Time Spent: 10m > Remaining Estimate: 0h > > The shaded test jar has the wrong type "jar". > It should be "test-jar". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-342) Many ITs fail when run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004726#comment-17004726
]
Herve Boutemy edited comment on MSHADE-342 at 12/29/19 9:50 AM:
nice catch: looks like this IT should be defined as a setup IT = the normal way
to show its special role
setting relativePath is a good workaround, given the setup is really minimal
putting the pom.xml in the root directory and not defining it as setup job
could perhaps do even a better job at showing the intent of this parent pom
(that is just a config for Java 9+, look also at git blame)
was (Author: hboutemy):
nice catch: looks like this IT should be defined as a setup IT = the normal way
to show its special role
setting relativePath is a good workaround, given the setup is really minimal
putting the pom.xml in the root directory and not defining it as setup job
could perhaps do even a better job at showing the intent of this parent pom
(that is just a config for Java 9+)
> Many ITs fail when run in isolation
> ---
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> h3. Potential solution 1
> A fix is to identify the broken ITs by running all of them in isolation and
> add the following to all of the broken ones:
> {code:xml}
>
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
>
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that,
> when writing an IT, this _must_ be the parent.
> (+) This will work.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the
> {{setup-parent}} project comes from.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-342) Many ITs fail when run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004726#comment-17004726
]
Herve Boutemy commented on MSHADE-342:
--
nice catch: looks like this IT should be defined as a setup IT = the normal way
to show its special role
setting relativePath is a good workaround, given the setup is really minimal
putting the pom.xml in the root directory and not defining it as setup job
could perhaps do even a better job at showing the intent of this parent pom
(that is just a config for Java 9+)
> Many ITs fail when run in isolation
> ---
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> h3. Potential solution 1
> A fix is to identify the broken ITs by running all of them in isolation and
> add the following to all of the broken ones:
> {code:xml}
>
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
>
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that,
> when writing an IT, this _must_ be the parent.
> (+) This will work.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the
> {{setup-parent}} project comes from.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-342) Many ITs fail when run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-342:
---
Description:
Maven invoker plugin supports running ITs in isolation, but many ITs fail when
running them in isolation.
One example (there are many others):
{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}
They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.
The reason is that there is a missing parent dependency, which is apparently
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing
directory is created by some other test in the beginning of the IT test run,
and then all subsequent tests work as well.
h3. Potential solution 1
A fix is to identify the broken ITs by running all of them in isolation and add
the following to all of the broken ones:
{code:xml}
org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent
{code}
It should be documented somewhere (maybe it is but I overlooked it?) that, when
writing an IT, this _must_ be the parent.
(+) This will work.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).
Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the
{{setup-parent}} project comes from.
was:
Maven invoker plugin supports running ITs in isolation, but many ITs in the
"maven-shade-plugin" don't:.
One example (there are many others):
{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}
If you try to run them, they fail because of a missing
{{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.
The reason is that there is a missing parent dependency, which is apparently
required for _any_ IT in this project.
When you run the ITs as a whole, it works by accident because the missing
directory is created by some other test in the beginning of the IT test run,
and then all subsequent tests work as well.
The fix is to identify the broken ITs by running all of them in isolation and
add the following to all of the broken ones:
{code:xml}
org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent
{code}
It should be documented somewhere (maybe it is but I overlooked it?) that, when
writing an IT, this _must_ be the parent.
> Many ITs fail when run in isolation
> ---
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> h3. Potential solution 1
> A fix is to identify the broken ITs by running all of them in isolation and
> add the following to all of the broken ones:
> {code:xml}
>
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
>
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that,
> when writing an IT, this _must_ be the parent.
> (+) This will work.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the
> {{setup-parent}} project comes from.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-342) Many ITs fail when run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MSHADE-342:
---
Summary: Many ITs fail when run in isolation (was: Many ITs don't run in
isolation)
> Many ITs fail when run in isolation
> ---
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs in the
> "maven-shade-plugin" don't:.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> If you try to run them, they fail because of a missing
> {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run the ITs as a whole, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> The fix is to identify the broken ITs by running all of them in isolation and
> add the following to all of the broken ones:
> {code:xml}
>
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
>
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that,
> when writing an IT, this _must_ be the parent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-342) Many ITs don't run in isolation
[
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004699#comment-17004699
]
Peter De Maeyer commented on MSHADE-342:
It's on my to-do list to fix this, but if someone wants to beat me to it, knock
yourself out.
> Many ITs don't run in isolation
> ---
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs in the
> "maven-shade-plugin" don't:.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> If you try to run them, they fail because of a missing
> {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently
> required for _any_ IT in this project.
> When you run the ITs as a whole, it works by accident because the missing
> directory is created by some other test in the beginning of the IT test run,
> and then all subsequent tests work as well.
> The fix is to identify the broken ITs by running all of them in isolation and
> add the following to all of the broken ones:
> {code:xml}
>
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
>
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that,
> when writing an IT, this _must_ be the parent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MSHADE-342) Many ITs don't run in isolation
Peter De Maeyer created MSHADE-342:
--
Summary: Many ITs don't run in isolation
Key: MSHADE-342
URL: https://issues.apache.org/jira/browse/MSHADE-342
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 3.2.2
Reporter: Peter De Maeyer
Maven invoker plugin supports running ITs in isolation, but many ITs in the
"maven-shade-plugin" don't:.
One example (there are many others):
{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}
If you try to run them, they fail because of a missing
{{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.
The reason is that there is a missing parent dependency, which is apparently
required for _any_ IT in this project.
When you run the ITs as a whole, it works by accident because the missing
directory is created by some other test in the beginning of the IT test run,
and then all subsequent tests work as well.
The fix is to identify the broken ITs by running all of them in isolation and
add the following to all of the broken ones:
{code:xml}
org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent
{code}
It should be documented somewhere (maybe it is but I overlooked it?) that, when
writing an IT, this _must_ be the parent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
