[jira] [Commented] (MSHADE-323) Flatten Maven Plugin conflicts with Maven Shade Plugin
[
https://issues.apache.org/jira/browse/MSHADE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521142#comment-17521142
]
Ilya Kasnacheev commented on MSHADE-323:
Unfortunately I'm not a committer to Maven and can't carry modified Maven
around. Still, thank you.
> Flatten Maven Plugin conflicts with Maven Shade Plugin
> --
>
> Key: MSHADE-323
> URL: https://issues.apache.org/jira/browse/MSHADE-323
> Project: Maven Shade Plugin
> Issue Type: Bug
>Reporter: lakunma
>Priority: Minor
>
> When using Flatten Maven Plugin in the same project with Maven Shade Plugin
> then the dependency reduced POM is _not_ flattened.
> What i encountered that having flatten plugin configured according to
> [https://maven.apache.org/maven-ci-friendly.html], and having shade plugin
> configured with the default settings to produce uber jar the ${revision}
> variable remains and gets installed/deployed within the final pom, thus
> making the pom in the repository invalid.
> It seems that both plugins transform original pom. And then what gets
> installed in the last one, which is the 'shades' one. I'm not sure that's a
> bug (in a sense that it is shade's fault).
> See also [https://github.com/mojohaus/flatten-maven-plugin/issues/100]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHADE-323) Flatten Maven Plugin conflicts with Maven Shade Plugin
[
https://issues.apache.org/jira/browse/MSHADE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466457#comment-17466457
]
Ilya Kasnacheev commented on MSHADE-323:
This is a Shade bug, since it works the other way around: Flatten maven plugin
will pick up changes made by Shade, but Shade will ignore changes made by
Flatten.
> Flatten Maven Plugin conflicts with Maven Shade Plugin
> --
>
> Key: MSHADE-323
> URL: https://issues.apache.org/jira/browse/MSHADE-323
> Project: Maven Shade Plugin
> Issue Type: Bug
>Reporter: lakunma
>Priority: Minor
>
> When using Flatten Maven Plugin in the same project with Maven Shade Plugin
> then the dependency reduced POM is _not_ flattened.
> What i encountered that having flatten plugin configured according to
> [https://maven.apache.org/maven-ci-friendly.html], and having shade plugin
> configured with the default settings to produce uber jar the ${revision}
> variable remains and gets installed/deployed within the final pom, thus
> making the pom in the repository invalid.
> It seems that both plugins transform original pom. And then what gets
> installed in the last one, which is the 'shades' one. I'm not sure that's a
> bug (in a sense that it is shade's fault).
> See also [https://github.com/mojohaus/flatten-maven-plugin/issues/100]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MJAVADOC-557) Deprecate parameter includeTransitiveDependencySources
[
https://issues.apache.org/jira/browse/MJAVADOC-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464942#comment-17464942
]
Ilya Kasnacheev commented on MJAVADOC-557:
--
I think this is a bad call - there are clear use cases for transitive
dependencies.
The use case as follows: you want a fat JAR and fat Javadoc for your module,
which hierarchically depends on many of your modules. Currently, it is possible
with includeTransitiveDependencySources and
{{dependencySourceInclude=com.pany:*}} - the ones which you actually control,
and hence they would not drop dependencies on random.
The currently advised approach of explicitly listing all dependencies
encourages having a small number of non-hierarchial, blobby dependencies, which
is an antipattert in itself.
So I suggest that maybe this parameter may be un-deprecated.
> Deprecate parameter includeTransitiveDependencySources
> --
>
> Key: MJAVADOC-557
> URL: https://issues.apache.org/jira/browse/MJAVADOC-557
> Project: Maven Javadoc Plugin
> Issue Type: Task
> Components: javadoc
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.0
>
>
> This parameter is only useful when your code depends on transitive
> dependencies, which is actually a very bad practice. Your direct dependencies
> always have the freedom to drop libraries, which could mean that your code
> won't work anymore.
> Removing this parameter will simplify the code and encourage developers to
> not depend on transitive dependencies.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1457) trimStackTrace should be disabled by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16435438#comment-16435438
]
Ilya Kasnacheev commented on SUREFIRE-1457:
---
This default makes exactly zero sense. Please change it in the next major.
> trimStackTrace should be disabled by default
>
>
> Key: SUREFIRE-1457
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1457
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.21.2
>Reporter: Réda Housni Alaoui
>Assignee: Tibor Digana
>Priority: Critical
>
> We are using Jenkins at work.
> Each time we had test failures, stack trace were incomplete and therefore
> totally useless.
> I just discovered {{trimStackTrace}} option.
> IMO, the fact that this option is currently enabled by default is a total non
> sense.
> Now we have to change the pom.xml of every projects of the company to have a
> correct default.
> IMO, and I think I am not the only one here, trimStackTrace should be
> disabled by default.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
