Hi,
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html
patterns as described on this page look okay to me.
So maybe it is not that hard to switch
Robert
On Wed, 15 Jun 2016 19:59:26 +0200, Robert Scholte <[email protected]>
wrote:
On Wed, 15 Jun 2016 00:02:47 +0200, Michael Osipov <[email protected]>
wrote:
Am 2016-06-14 um 23:45 schrieb Robert Scholte:
too much fun to fix this.
http://svn.apache.org/viewvc?rev=1748472&view=rev should do the trick.
Still some doc updates required
Good! We still must take great care because throughout several places
in Aether and Maven coords format with colon might not be consistent
after artifactId. For MASSEMBLY, the classifier comes after type and is
optional.
I'm aware of that. I'd prefer to use the Aether pattern for the filters
to keep it less complex. If plugins want/need to use other patterns it's
up to them, but maybe 3.0 is the right moment to start consistency.
Robert
On Tue, 14 Jun 2016 22:10:30 +0200, Robert Scholte
<[email protected]> wrote:
On Tue, 14 Jun 2016 18:59:50 +0200, Michael Osipov
<[email protected]> wrote:
Am 2016-06-14 um 17:34 schrieb Robert Scholte:
I think we're making it ourself very hard if we keep supporting
:jar.
I would have read it as any groupId + artifactId='jar'.
Instead with 3.0 we should switch to the patterns as defined by
Aether[1]; no need to maintain assembly specific patterns, use them
as
is with Aether.
WDYT?
I agree here. We need less magic and more predictability.
[1]
http://download.eclipse.org/aether/aether-core/1.0.0/apidocs/index.html?org/eclipse/aether/util/filter/PatternExclusionsDependencyFilter.html
It pretty much look like before without omission from left-hard site.
There is, though, a flaw. I see no classifier support and this is
crucial for the assembly plugin.
That's kind of a surprise. Sure, classifier is optional, but I think
it would make sense to have the a pattern including classifier as
well.
g:a:v:e[:c]
It shouldn't be too hard to embed this in the shared component
maven-common-artifact-filters so it'll work for both Aether
implementations.
Robert
Michael
On Tue, 14 Jun 2016 00:16:44 +0200, Michael Osipov
<[email protected]>
wrote:
Hi folks,
I am currently investigating
https://issues.apache.org/jira/browse/MASSEMBLY-809
After an analysis, I came to the conclusion that Maven Common
Artifact
Filters apply include filters telescopic for non-wildcard patterns.
Consider this in the assembly.xml [1]:
....
<include>test.project:project:jar</include>
....
The dependency list contains:
1. test.project:project:jar
2. test.project:project:jar:doc
PatternIncludesArtifactFilter says that both artifacts match that
pattern while *:jar matches only the first one. It does not feel
right
to me that *all* classifiers are included if none is given
compared to
wildcard ones [2].
Is this a shortcoming of our MASSEMBLY documentation or a bug in
the
shared component?
[1]
https://github.com/ochaloup/reproducer-massebly-809/blob/master/assembly/distro.xml
[2]
http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html#Advanced_Artifact-Matching_in_includes_and_excludes
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
