Re: plexus-utils 4.x and Xpp3DomBuilder
On 25. 07. 23 20:56, Slawomir Jaranowski wrote: Hi I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml 4.x in maven-enforcer In maven-enforcer (and in many other plugins ...) is used, code like: Xpp3Dom enforcerRules = Xpp3DomBuilder.build(descriptorStream, "UTF-8"); Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml but Maven 3.x exports org.codehaus.plexus.util.xml.Xpp3Dom org.codehaus.plexus.util.xml.pull.XmlPullParser org.codehaus.plexus.util.xml.pull.XmlPullParserException org.codehaus.plexus.util.xml.pull.XmlSerializer It is very magical that we export classes but not export artifact which contains those classes ... so incompatibilite code for Xpp3Dom is used ... Any hints on how to process it. So, what is the takeaway of this tread for casual Maven plugin developers like me? Should I avoid plexus-utils 4.x in Maven 3 plugins? -- VH - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Install Plugin 3.0.1
On 19. 07. 22 16:26, Tamás Cservenák wrote: > Howdy, > > We fixed one regression in install-file Mojo > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINSTALL%20AND%20fixVersion%20%3D%203.0.1 > > Staged repository: > https://repository.apache.org/content/repositories/maven-1784 > > Source release SHA512: > bb2b4216ba0da11f6de4a9c02921a92839a3e0eb11f6df3a3ed11275b2ee323f81341ab9de263cb043aaea73a4c749667bbc3cef7a2887b00f22135c75f6c2f4 > > Staged site: > https://maven.apache.org/plugins-archives/maven-install-plugin-LATEST/ > > Vote open for 72h > > Thanks > T > +1 -- VH - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Install Plugin 3.0.0
Dne so 16. 7. 2022 18:10 uživatel Tamás Cservenák napsal: > Howdy, > > We fixed several issues: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINSTALL%20AND%20fixVersion%20%3D%203.0.0 > > Staged repository: > https://repository.apache.org/content/repositories/maven-1779/ > > Source release SHA512: > > 9a0912ced134552976693f449ecce493e0ff4a8aec071ce66cc8781cbb573dba14f6642d190b5562dfc3c6eb3e4469dc5e3e3775b102b4be041a8bed78f0bda1 > > Staged site: > https://maven.apache.org/plugins-archives/maven-install-plugin-LATEST/ > > Vote open for 72h > > Thanks > T > -1 because of the regession. >
Re: m-install-p and m-deploy-p 3.0.0 release soon
On 12. 07. 22 15:18, Tamás Cservenák wrote: > Howdy, > > The release of m-install-p and m-deploy-p 3.0.0 will happen soon, if anyone > has anything to add, speak up! > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINSTALL%20AND%20fixVersion%20in%20(3.0.0%2C%203.0.0-M2) > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MDEPLOY%20AND%20fixVersion%20in%20(3.0.0%2C%203.0.0-M3) > > Planned version for both is "3.0.0" so not more M releases. > > T > maven-install-plugin 3.x has a regression in install-file goal. See MINSTALL-160. -- VH - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Common Artifact Filters version 3.3.0
On 11. 06. 22 15:39, Michael Osipov wrote: > Hi, > > We solved 5 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12349729 > > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-common-artifact-filters > > > Staging repo: > https://repository.apache.org/content/repositories/maven-1763/ > https://repository.apache.org/content/repositories/maven-1763/org/apache/maven/shared/maven-common-artifact-filters/3.3.0/maven-common-artifact-filters-3.3.0-source-release.zip > > > Source release checksum(s): > maven-common-artifact-filters-3.3.0-source-release.zip > sha512: > d48ab1025fc02999060eb43708bc7f255ae59b9a79e1b22c93badb78fe78eb455b11be547fcfd0b2887fac9d1e99bbb025685a6276c006ebd085e1d5354f7f90 > > > Staging site: > https://maven.apache.org/shared-archives/maven-common-artifact-filters-LATEST/ > > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > > [ ] +1 > [ ] +0 > [ ] -1 +1 as reporter of a fixed bug. -- VH - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Modello release
On 31. 01. 22 8:30, Guillaume Nodet wrote: > I was looking at why the maven builds are a bit slow and found out one of > the culprit is modello which overwrites its generated files even if there > are no changes: that cascades to recompiling the module, checking the style > again, making a new archive and then recompiling the dependant modules > aso... > That was fixed a few months ago with > https://github.com/codehaus-plexus/modello/pull/116 The linked PR has a comment that is not answered. Is the code correct with respect to encoding? > Would it be possible to release modello to be able to incorporate the fix > and continue the work on optimization the build ? > > I'm willing to help in any way if that can actually speed up things... -- 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
On 02. 12. 21 19:09, Michael Osipov wrote: > Am 2021-12-01 um 21:06 schrieb Václav Haisman: >> On 16. 11. 21 20:58, Václav Haisman wrote: >>> 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 > > Ahoj Václav, > > been too busy with other stuff. Please ping me on GH by mid of next > week. Won't have the time to get a closer look earlier. If anyone beat > me, that's fine. > Ping. https://issues.apache.org/jira/browse/MASSEMBLY-955 https://github.com/apache/maven-common-artifact-filters/pull/24 https://github.com/apache/maven-assembly-plugin/pull/48 -- 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
On 16. 11. 21 20:58, Václav Haisman wrote: > 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 PING. -- 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
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
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: Un-deprecating DirectoryScanner?
On 23. 10. 21 21:30, Michael Osipov wrote: > Am 2021-10-23 um 21:10 schrieb Václav Haisman: >> Hi. >> >> I just updated dependencies and I noticed >> org.apache.maven.shared.utils.io.DirectoryScanner is deprecated with >> "Deprecated >> use java.nio.file.DirectoryStream and related classes" note in sources. >> >> Is this the only reason for the deprecation? I would have to implement >> the Ant patterns and regexes around DirectoryStream if I would like to >> get on par with DirectoryScanner. >> >> I would rather like to suggest that the class is still very useful, even >> though Java now supports directory listing better. > > I agree here. Had to do similar in another project with the > DirectoryWalker. The NIO classes are too low level, I prefer DRY. Maybe > DirectoryScanner and friends can be rewritten to use NIO while > maintaining a high level API? I am actually not the first to notice: MSHARED-989 -- VH - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Un-deprecating DirectoryScanner?
Hi. I just updated dependencies and I noticed org.apache.maven.shared.utils.io.DirectoryScanner is deprecated with "Deprecated use java.nio.file.DirectoryStream and related classes" note in sources. Is this the only reason for the deprecation? I would have to implement the Ant patterns and regexes around DirectoryStream if I would like to get on par with DirectoryScanner. I would rather like to suggest that the class is still very useful, even though Java now supports directory listing better. -- VH - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
