Re: Maven Assembly / Common Artifact Filters issues and defect
On 16. 11. 21 17:36, Slawomir Jaranowski wrote:
> Hi,
> Thanks for reporting.
>
> Does your issue is similar to [1] - If yes please comment, vote
> or if it is something else you can create a new issue.
I have created a new issue. In my case, Assembly plugin 2.5.5 works and
3.0.0+ breaks. New issue:
https://issues.apache.org/jira/browse/MASSEMBLY-955
>
> [1] https://issues.apache.org/jira/browse/MASSEMBLY-607
>
>
> wt., 16 lis 2021 o 14:51 Václav Haisman napisał(a):
>
>> Hi.
>>
>> I think I found a defect in the latest currently available Maven Assembly
>> plugin version 3.3.0. The Assembly plugin uses Common Artifact Filters's
>> class `PatternIncludesArtifactFilter`. This class, in its method
>> `matchAgainst()` loops over include patterns. If one of the include
>> patterns contains 4+ components, 4th being the classifier (according to the
>> source code, documentation does not mention classifier), it immediately
>> rejects the artifact being checked for inclusion without testing the other
>> patterns. My inclusion patterns are
>>
>>- com.XYZ:some-artifact:*:service:*
>>- org.python:jython-standalone
>>
>> The jython pattern is not even tested against the jython dependency because
>> it returns from the function early instead of continuing the loop.* This is
>> code, the return statement should be continue statement instead for this to
>> work as I think was intended*:
>>
>> private boolean matchAgainst( final String value, final List
>> patterns, final boolean regionMatch )
>> {
>> final String[] tokens = value.split( ":" );
>> for ( String pattern : patterns )
>> {
>> String[] patternTokens = pattern.split( ":" );
>>
>> if ( patternTokens.length == 5 && tokens.length < 5 )
>> {
>> // 4th element is the classifier
>> if ( !"*".equals( patternTokens[3] ) )
>> {
>> // classifier required, cannot be a match
>> return false;
>> }
>>
>> But this is not all. I tried running the 3.3.0 Assembly plugin with
>> maven-common-artifact-filters artifact version 3.2.0 which seems to have
>> been significantly rewritten. However, that rejects my 5 components pattern
>> entirely. The comment in the code says "*we only accept 5 tokens if the
>> classifier = '*'*", which seems to be a departure from what the previous
>> version tried to support.
>>
>> // we only accept 5 tokens if the classifier = '*'
>> if ( tokens.length == 5 )
>> {
>> if ( tokens[3] != ANY )
>> {
>> throw new IllegalArgumentException( "Invalid pattern: " + pattern
>> );
>> }
>> tokens = new char[][] { tokens[0], tokens[1], tokens[2], tokens[4] };
>> }
>>
>>
>> Was it intentional that the rewrite of the artifact filters stopped
>> supporting previously supported patterns?
>>
>> Can we release Common Artifact Filters version 3.1.1 or such with the
>> return statement changed to continue statement and at the same time release
>> Assembly plugin 3.3.1 which would use this fixed Common Artifact Filters
>> version to unbreak this?
>>
>>
>> --
>> VH
>>
>
>
--
VH
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Assembly / Common Artifact Filters issues and defect
Hi,
Thanks for reporting.
Does your issue is similar to [1] - If yes please comment, vote
or if it is something else you can create a new issue.
[1] https://issues.apache.org/jira/browse/MASSEMBLY-607
wt., 16 lis 2021 o 14:51 Václav Haisman napisał(a):
> Hi.
>
> I think I found a defect in the latest currently available Maven Assembly
> plugin version 3.3.0. The Assembly plugin uses Common Artifact Filters's
> class `PatternIncludesArtifactFilter`. This class, in its method
> `matchAgainst()` loops over include patterns. If one of the include
> patterns contains 4+ components, 4th being the classifier (according to the
> source code, documentation does not mention classifier), it immediately
> rejects the artifact being checked for inclusion without testing the other
> patterns. My inclusion patterns are
>
>- com.XYZ:some-artifact:*:service:*
>- org.python:jython-standalone
>
> The jython pattern is not even tested against the jython dependency because
> it returns from the function early instead of continuing the loop.* This is
> code, the return statement should be continue statement instead for this to
> work as I think was intended*:
>
> private boolean matchAgainst( final String value, final List
> patterns, final boolean regionMatch )
> {
> final String[] tokens = value.split( ":" );
> for ( String pattern : patterns )
> {
> String[] patternTokens = pattern.split( ":" );
>
> if ( patternTokens.length == 5 && tokens.length < 5 )
> {
> // 4th element is the classifier
> if ( !"*".equals( patternTokens[3] ) )
> {
> // classifier required, cannot be a match
> return false;
> }
>
> But this is not all. I tried running the 3.3.0 Assembly plugin with
> maven-common-artifact-filters artifact version 3.2.0 which seems to have
> been significantly rewritten. However, that rejects my 5 components pattern
> entirely. The comment in the code says "*we only accept 5 tokens if the
> classifier = '*'*", which seems to be a departure from what the previous
> version tried to support.
>
> // we only accept 5 tokens if the classifier = '*'
> if ( tokens.length == 5 )
> {
> if ( tokens[3] != ANY )
> {
> throw new IllegalArgumentException( "Invalid pattern: " + pattern
> );
> }
> tokens = new char[][] { tokens[0], tokens[1], tokens[2], tokens[4] };
> }
>
>
> Was it intentional that the rewrite of the artifact filters stopped
> supporting previously supported patterns?
>
> Can we release Common Artifact Filters version 3.1.1 or such with the
> return statement changed to continue statement and at the same time release
> Assembly plugin 3.3.1 which would use this fixed Common Artifact Filters
> version to unbreak this?
>
>
> --
> VH
>
--
Sławomir Jaranowski
[GitHub] [maven-wrapper-plugin] slawekjaranowski commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
slawekjaranowski commented on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-970426760 From wrapper perspective should not be important what `mvn` command is and what happen inside `mvn`. We should assume that `mvn` command from Maven distribution simply work. -- 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. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-wrapper-plugin] rfscholte commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
rfscholte commented on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-970356340 The only potential problem I see is that a script calls another script that calls java. Should be easy to validate. -- 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. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-wrapper-plugin] jvanzyl edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
jvanzyl edited a comment on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-970336499 Historically the Maven Wrapper has been separate, and I believe works well that way. Its concern to bring Maven into existence for build, and I would argue that should be any version of Maven. The simple fact that the Takari Maven Wrapper still needs to exist is an indication that we have an issue. I understand the maintenance issue with the scripts, but I think @slawekjaranowski has an elegant solution to that problem. I would very much like to archive the Takari Maven Wrapper repository, and add some features to the wrapper at Apache. With the wrapper separated we may even be able to help people still using Maven 2.x (I've seen lots of 2.x projects) as the wrapper makes CI so much easier. But again, I think the wrapper has a separate concern, and we may want to add new features to the wrapper and it's been very nice with the Takari Maven Wrapper to just release it when necessary without concern for any particular version of Maven. But I do think having the wrapper and wrapper plugin together makes sense. I didn't think about it very hard with the Takari Wrapper but it definitely would have been easier if all the wrapper capability was together. I think what's in the PR here with the addendum of @slawekjaranowski's solution is ideal. -- 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. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-wrapper-plugin] jvanzyl commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
jvanzyl commented on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-970336499 Historically the Maven Wrapper has been separate, and I believe works well that way. Its concern to bring Maven into existence for build, and I would argue that should be any version of Maven. The simple fact that the Takari Maven Wrapper still needs to exist is an indication that we have an issue. I understand the maintenance issue with the scripts, but I think @slawekjaranowski has an elegant solution to that problem. I would very much like to archive the Takari Maven Wrapper repository, and add some features to the wrapper at Apache. With the wrapper separated we may even be able to help people still using Maven 2.x (I've seen lots of 2.x projects) as the wrapper makes CI so much easier. But again, I think the wrapper has a separate concern, and we may want to add new features to the wrapper and it's been very nice with the Takari Maven Wrapper to just release it when necessary without concern for any particular version of Maven. -- 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. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-wrapper-plugin] jvanzyl edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
jvanzyl edited a comment on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-970322319 > Another idea ... why not simply call `mvn*` scripts from Maven distribution ... of course after needed job for wrapper like downloading > > In this case code will be in one place That's a great idea. I originally thought of a tiny plugin (I think one might actually exist) to have the core grab the scripts from the wrapper for reuse, but your idea is far better and essentially zero maintenance. -- 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. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-wrapper-plugin] jvanzyl commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
jvanzyl commented on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-970322319 > Another idea ... why not simply call `mvn*` scripts from Maven distribution ... of course after needed job for wrapper like downloading > > In this case code will be in one place That's a great idea. -- 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. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven Assembly / Common Artifact Filters issues and defect
Hi.
I think I found a defect in the latest currently available Maven Assembly
plugin version 3.3.0. The Assembly plugin uses Common Artifact Filters's
class `PatternIncludesArtifactFilter`. This class, in its method
`matchAgainst()` loops over include patterns. If one of the include
patterns contains 4+ components, 4th being the classifier (according to the
source code, documentation does not mention classifier), it immediately
rejects the artifact being checked for inclusion without testing the other
patterns. My inclusion patterns are
- com.XYZ:some-artifact:*:service:*
- org.python:jython-standalone
The jython pattern is not even tested against the jython dependency because
it returns from the function early instead of continuing the loop.* This is
code, the return statement should be continue statement instead for this to
work as I think was intended*:
private boolean matchAgainst( final String value, final List
patterns, final boolean regionMatch )
{
final String[] tokens = value.split( ":" );
for ( String pattern : patterns )
{
String[] patternTokens = pattern.split( ":" );
if ( patternTokens.length == 5 && tokens.length < 5 )
{
// 4th element is the classifier
if ( !"*".equals( patternTokens[3] ) )
{
// classifier required, cannot be a match
return false;
}
But this is not all. I tried running the 3.3.0 Assembly plugin with
maven-common-artifact-filters artifact version 3.2.0 which seems to have
been significantly rewritten. However, that rejects my 5 components pattern
entirely. The comment in the code says "*we only accept 5 tokens if the
classifier = '*'*", which seems to be a departure from what the previous
version tried to support.
// we only accept 5 tokens if the classifier = '*'
if ( tokens.length == 5 )
{
if ( tokens[3] != ANY )
{
throw new IllegalArgumentException( "Invalid pattern: " + pattern );
}
tokens = new char[][] { tokens[0], tokens[1], tokens[2], tokens[4] };
}
Was it intentional that the rewrite of the artifact filters stopped
supporting previously supported patterns?
Can we release Common Artifact Filters version 3.1.1 or such with the
return statement changed to continue statement and at the same time release
Assembly plugin 3.3.1 which would use this fixed Common Artifact Filters
version to unbreak this?
--
VH
Re: [VOTE] Release Apache Maven version 3.8.4
+1 Le dim. 14 nov. 2021 à 14:28, Michael Osipov a écrit : > Hi, > > We solved 5 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350685 > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1669/ > > Dev dist directory: > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.4/ > > Source release checksums: > apache-maven-3.8.4-src.zip sha512: > > 2f57dd7476ee1831867930dbe33ebe669b8fc0a9863586093a4eb2188745c5ddc2710beea1bf076263923ce38a487ef92d570bc752c77d0e0f1e3416b65bc785 > apache-maven-3.8.4-src.tar.gz sha512: > > ea4b5f2b29be45d22e716099d0ef87367c78766aade094e8d7f295fe3b2c98cba2bf0f214d3ed55e2c17d2f74c82352cf9dc83fa47ddc97a8d2b847315500431 > > Binary release checksums: > apache-maven-3.8.4-bin.zip sha512: > > bcd1e99548ac8a5b9ec159ee16c23d29d6799696c92140d583d25eb323433aadcc0b47c45b0b6bd9dbcf344bbba38b56dd056a9c49ae714cfc22dc06bb4a4230 > apache-maven-3.8.4-bin.tar.gz sha512: > > a9b2d825eacf2e771ed5d6b0e01398589ac1bfa4171f36154d1b5787879605507802f699da6f7cfc80732a5282fd31b28e4cd6052338cbef0fa1358b48a5e3c8 > > Draft for release notes: > https://github.com/apache/maven-site/pull/274 > > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open until 2021-11-19T18:00Z > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Guillaume Nodet
JDK 18 Early-Access builds 23 are available
Robert,
I’m happy to announce that moving forward Oracle’s Java DevRel Team will
manage the Quality Outreach Program. I would like to thank Rory for all
the efforts he's put into this program and wish him all the joy and
happiness that retirement can bring! We have big shoes to fill but we’re
excited to continue building off the amazing structure Rory has put in
place.
The JDK 18 schedule is now known [1] with a feature freeze date
(Rampdown Phase One) less than 4 weeks away! This time, we have 2
important heads-ups, one related to JEP 411 (Deprecate the Security
Manager for Removal), and one related to JEP 416 (Reimplement Core
Reflection with Method Handles). We're asking your help to test and
confirm that your project works seamlessly now that those 2 JEPs are
integrated in the JDK 18 Early-Access builds.
[1] https://openjdk.java.net/projects/jdk/18/
# JEP 411 - Deprecate the Security Manager for Removal
Starting JDK 18 b21 [2], the default value of the
'java.security.manager' system property is set to "disallow". This means
that any application or library that enables the Security Manager by
calling `System.setSecurityManager` will now have to specify
`-Djava.security.manager=allow` on the command-line in order for that
code to continue working as expected. This change was originally
targeted for JDK 17, but after some discussion/feedback from the
community, the change was delayed until JDK 18 [3].
[2] https://bugs.openjdk.java.net/browse/JDK-8270380
[3] https://openjdk.java.net/jeps/411#Description
# JEP 416 - Reimplement Core Reflection with Method Handles
JEP 416 [4] reimplements `java.lang.reflect.Method`,
`java.lang.reflect.Constructor`, and `java.lang.reflect.Field` on top of
`java.lang.invoke` method handles. Making method handles the underlying
mechanism for reflection will reduce the maintenance and development
cost of both the `java.lang.reflect` and `java.lang.invoke` APIs. This
is solely an implementation change but we encourage you to test your
project to identify any behavior or performance regressions.
[4] https://openjdk.java.net/jeps/416
OpenJDK 18 Early-Access builds 23 are now available [5], and are
provided under the GNU General Public License v2, with the Classpath
Exception. The Release Notes are available [6].
[5] https://jdk.java.net/18/
[6] https://jdk.java.net/18/release-notes
# JEPs integrated to JDK 18, so far:
- JEP 400: UTF-8 by Default https://openjdk.java.net/jeps/400
- JEP 408: Simple Web Server https://openjdk.java.net/jeps/408
- JEP 413: Code Snippets in Java API Documentation
https://openjdk.java.net/jeps/413
- JEP 416: Reimplement Core Reflection with Method Handles
https://openjdk.java.net/jeps/416
- JEP 418: Internet-Address Resolution SPI https://openjdk.java.net/jeps/418
# JEPs targeted to JDK 18, so far:
- JEP 417: Vector API (Third Incubator) https://openjdk.java.net/jeps/417
# JEPs proposed to target JDK 18, so far:
- JEP 419: Foreign Function & Memory API (Second Incubator)
https://openjdk.java.net/jeps/419
- JEP 420: Pattern Matching for switch (Second Preview)
https://openjdk.java.net/jeps/420
# Changes in recent builds that maybe of interest:
## Build 23:
- JDK-8275509: ModuleDescriptor.hashCode isn't reproducible across builds
- JDK-8276220: Reduce excessive allocations in DateTimeFormatter
- JDK-8276298: G1: Remove unused G1SegmentedArrayBufferList::add
- JDK-8273922: (fs) UserDefinedFileAttributeView doesn't handle file
names that are just under the MAX_PATH limit (win)
## Build 22:
- JDK-8271820: Implementation of JEP 416: Reimplement Core Reflection
with Method Handle
- JDK-8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
implementations
- JDK-8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and
getExtendedKeyUsage do not throw CertificateParsingException if
extension is unparseable
## Build 21:
- JDK-8270380: Change the default value of the java.security.manager
system property to disallow
- JDK-8275319: java.net.NetworkInterface throws java.lang.Error instead
of SocketException
- JDK-8270490: Charset.forName() taking fallback default value
- JDK-8269336: Malformed jdk.serialFilter incorrectly handled
# Project Loom update
New Project Loom 18-loom+4-273 (2021/11/10) Early-Access builds are
available [7] with related Javadocs [8].
[7] https://jdk.java.net/loom/
[8] https://download.java.net/java/early_access/loom/docs/api/
These EA builds are provided under the GNU General Public License,
version 2, with the Classpath Exception and are produced for the purpose
of gathering feedback. Use for any other purpose is at your own risk.
Feedback should be send to the `loom-dev` mailing list
(https://mail.openjdk.java.net/mailman/listinfo/loom-dev).
# Topics of Interest:
* New Candidate JEP: 421: Deprecate Finalization for Removal,
https://openjdk.java.net/jeps/421
* What Happens to Finalization in JDK 18 and JEP 416 - Inside Java
Newscast,
