Logging api in plugins

[Slawomir Jaranowski]

Hi,

I'm writing some maven plugins - some for fun and with public code but more
maven plugins I'm writing for job in my company.

Maven from version 3.1.x use slf4j for logging.

But plugin api still use simple logging api
org.apache.maven.plugin.logging.Log.
It will be useful to have access to more richer feature of logging task.

What is the plan for future in this case?
 - extends  org.apache.maven.plugin.logging.Log in order to support slf4j
feature
 -  stop using/deprecating org.apache.maven.plugin.logging.Log and use in
plugins slf4j api for accesing loger.
 - maybe something else ...


-- 
 Best regards
 Sławomir Jaranowski

Re: Logging api in plugins

[Slawomir Jaranowski]

pon., 2 gru 2019 o 09:52 Jochen Wiedmann 
napisał(a):

> On Thu, Nov 28, 2019 at 9:46 PM Slawomir Jaranowski
>  wrote:
>
> > I'm writing some maven plugins - some for fun and with public code but
> more
> > maven plugins I'm writing for job in my company.
> >
> > Maven from version 3.1.x use slf4j for logging.
> >
> > But plugin api still use simple logging api
> > org.apache.maven.plugin.logging.Log.
> > It will be useful to have access to more richer feature of logging task.
> >
> > What is the plan for future in this case?
> >  - extends  org.apache.maven.plugin.logging.Log in order to support slf4j
> > feature
>
> My personal experience suggests, that we shouldn't bind ourselves to a
> particular logging API. So, I'd go for this one.
>
> Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
Hi,

I've looked a little more info about this topic and I found:
https://maven.apache.org/maven-logging.html
https://maven.apache.org/ref/3.5.3/maven-embedder/logging.html

So it is look like I can use slf4j directly - I hope i'm right.

And I think that question about future implementation to
org.apache.maven.plugin.logging.Log is still actual.

I've looked at code and when we will want to extend plexus logging it will
be a lot of work that are already done in slf4j.

-- 
Sławomir Jaranowski

Accessing a pgp signature file from plugin

[Slawomir Jaranowski]

Hi,

I'm author of pgpverify-maven-plugin, this plugin check pgp signatures of
project dependencies.

I have problem how to access/download "asc" signature file from mojo.

Currently I use repositorySystem.resolve(...), for artifact with changed
file name, but in logs I see, eg:

Could not validate integrity of download from
  
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-ejb-plugin/3.0.1/maven-ejb-plugin-3.0.1.jar.asc:
  Checksum validation failed, no checksums available

My problem code are here:
https://github.com/s4u/pgpverify-maven-plugin/blob/master/src/main/java/org/simplify4u/plugins/ArtifactResolver.java#L111
https://github.com/s4u/pgpverify-maven-plugin/blob/master/src/main/java/org/simplify4u/plugins/AscArtifactHandler.java#L56


-- 
Sławomir Jaranowski

Re: archiving obsolete Git repository

[Slawomir Jaranowski]

Hi, I'm outside apache team and I can't know all apache projects.

It will be good idea add simple README with short explain why repository is
archived and if possible where developers should go for current project.

pon., 20 sty 2020 o 00:09 Sylwester Lachiewicz 
napisał(a):

> Few of them have still open PR [1] - can we somehow, before archiving,
> review/move to the active repo?
>
> [1] https://github.com/apache/maven-plugins/pulls
>
> niedz., 19 sty 2020 o 21:13 Michael Osipov 
> napisał(a):
>
> > Am 2020-01-19 um 20:56 schrieb Hervé BOUTEMY:
> > > As discussed recently, we have multiple obsolete Git repositories from
> > old
> > > projects or read-only svn2git, that are confusing for users: we should
> > archive
> > > them, to get the same result as
> > https://github.com/apache/maven-ant-plugin
> > >
> > > Here is the list of such repositories:
> > > - https://github.com/apache/maven-plugins
> > > - https://github.com/apache/maven-shared
> > > - https://github.com/apache/maven-doxia-tools
> > > - https://github.com/apache/maven-pom
> > > - https://github.com/apache/maven-artifact
> > > - https://github.com/apache/maven-mercury
> > > - https://github.com/apache/maven-app-engine
> > > - https://github.com/apache/maven-repository-tools
> > > - https://github.com/apache/maven-resources
> > > - https://github.com/apache/maven-sandbox
> > > - https://github.com/apache/maven-doxia-ide
> > >
> > > Any objection to archive any of them? Or any additional repository?
> >
> > LGTM
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


-- 
Sławomir Jaranowski

Re: Maven Repository Security issues: any war stories?

[Slawomir Jaranowski]

Hi,

In maven world all artifacts have pgp signature which is created by current
maintainer (from some time pgp signature is required on Maven Central).

You can verify signatures of all your dependencies, you can also track
which pgp key is used for specific artifact.

So if maintainer of some artifacts will be changed you can easy detect it,
and take proper decision about it.

Of course is open question how to verify maintainer and reputation of used
maven artifacts.

pt., 28 lut 2020 o 20:43 Manfred Moser 
napisał(a):

> The order of repositories in a pom, settings and repo manager is crucial.
> Some companies use their own repos on top since they trust them the most. I
> have seen internal teams deploying patched version into those which then
> essentially override the real dep from central.
>
> This is a feature and is used quite often .. however it also opens the
> door for abuse on that level.
>
> With all sorts of repos out there you really have to check what you
> consume. If you consume repos that are not trustworthy or just badly
> maintained .. anything is possible including security attacks... however I
> have not seen it in practice.
>
> Overall its important that you use Central and othter trusted repos first
> and foremost..
>
> Manfred
>
> Elliotte Rusty Harold wrote on 2020-02-28 11:01 (GMT -08:00):
>
> > Folks,
> >
> > A colleague is preparing a presentation on general dependency security
> > issues. I'm not aware of any compromises of the Maven repo system such
> > that a malicious actor was able to push malware to client systems, but
> > I'm not sure it's never happened.
> >
> > Does anyone know about anything like the attack on npm a couple of
> > years ago
> > <
> https://www.trendmicro.com/vinfo/dk/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets
> >
> > that happened in the Java space?
> >
> > Even if something just went a little wonky in a way that could have
> > been used to serve malware but wasn't, that would be almost as
> > interesting.
> >
> > Of course, I'd love for the answer to be, "No, that's never happened
> > to Java, and it can't because..." I suspect we're a little more
> > resistant to these classes of attacks than npm because version ranges
> > are far less common. However, I can't think of anything that would
> > prevent someone from buying and compromising future versions of any
> > particular artifact. It's not like intelligence agencies haven't
> > bought entire companies before,
> > <
> https://www.washingtonpost.com/graphics/2020/world/national-security/cia-crypto-encryption-machines-espionage/
> >
> > and most open source projects could be had for a lot less.
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: Maven Repository Security issues: any war stories?

[Slawomir Jaranowski]

You are right, native method from maven does not support verifying of pgp
signature.

For pgpverify-maven-plugin you can prepare configuration file which
contains mapping artifact gav to pgp key fingerprint.
Without this configuration any existing key  is good.
>From some time I try to collect which key should be used to sign artifact:
https://github.com/s4u/pgp-keys-map/blob/master/resources/pgp-keys-map.list

pgpverify-maven-plugin search keys on keyserver by default:
hkps.pool.sks-keyservers.net

Maybe information about signing key should has some place in maven
dependency declaration ... but I think is topic for another discussion.
Here I only want to show some possibility to protect for situation when
owner is changed.

sob., 29 lut 2020 o 12:21 Elliotte Rusty Harold 
napisał(a):

> On Sat, Feb 29, 2020 at 2:55 AM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > In maven world all artifacts have pgp signature which is created by
> current
> > maintainer (from some time pgp signature is required on Maven Central).
> >
> > You can verify signatures of all your dependencies, you can also track
> > which pgp key is used for specific artifact.
>
>
> Do typical invocations of Maven actually do this? That is, if the
> signature of a downloaded artifact doesn't match does maven fail the
> build?
>
> If the signature has changed, will Maven fail the build? Or if the
> signer has changed?
>
> If not, is there a switch that can turn this on?
>
> There is a now well documented third party plugin to do some of this,
> but it's not clear exactly how it operates. E.g. how does it find and
> verify the right public key with which to verify a signature?
>
> https://www.simplify4u.org/pgpverify-maven-plugin/
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

MavenProject - replacement for deprecated method

[Slawomir Jaranowski]

Hi,

In my plugin I need list of report plugins, I use method:

org.apache.maven.project.MavenProject#getReportArtifacts

but this method (and many other) is deprecated in class MavenProject -
maven-core version 3.5.0

What method / class / library I should use instead of this.
In source code there isn't any information about replacement.

-- 
Sławomir Jaranowski

Re: (anonymous) github user commits

[Slawomir Jaranowski]

Hi,
If I can I want show to you some advantages/disadvantages as I see as
collaborator to external project. Maybe some of them you will like.


I've analyzed some commits what I did to maven-invoker-plugin project.

I used:  git log --graph --show-signature --format=full

*1. commit made manually - without using github ui*
https://github.com/apache/maven-invoker-plugin/pull/13

* commit 808d2d20f16771aa18ee87a53b52e70b031d53a0

| Author: Slawomir Jaranowski 

| Commit: Sylwester Lachiewicz 

|

| [MINVOKER-257] Test code should meet checkstyle requirements

|

| Closes #13

A:
 - no github user
 - committer and reviewer are known for git history

D:
 - manually work
 - lost my pgp signature -* so commit may have been changed*

*2. probably rebase and merge or squash at github*
https://github.com/apache/maven-invoker-plugin/pull/12

* commit a9e215cded354f25a81c616cd8aa8af767665494

| gpg: Signature made Sun Feb 16 21:55:34 2020 CET

| gpg:using RSA key 4AEE18F83AFDEB23

| gpg: Good signature from "GitHub (web-flow commit signing) <
nore...@github.com>" [ultimate]

| Author: Slawomir Jaranowski 

| Commit: GitHub 

|

| [MINVOKER-256] upgrade parent pom to latest version - 34 (#12)

A:
 - no manually work
 - committer is known from git history

D:
 - reviewer isn't known for git history
 - lost my pgp signature
 - github as commiter
 - pgp signature from github user - maybe advantage - we have some check of
integrity

*3*.* merg pull request at github*
https://github.com/apache/maven-invoker-plugin/pull/9

*   commit 77e3a86e0ff10dd016382621d40a4ca0bbcb7883

|\  gpg: Signature made Sun Nov 17 22:12:29 2019 CET

| | gpg:using RSA key 4AEE18F83AFDEB23

| | gpg: Good signature from "GitHub (web-flow commit signing) <
nore...@github.com>" [ultimate]

| | Merge: a9ce363 bbdaabc

| | Author: Robert Scholte 

| | Commit: GitHub 

| |

| | some log is too verbose in normal run

| |

| * commit bbdaabc1f319335ab8478016a45cdfe93fd0bae4

|/  gpg: Signature made Sun Nov 17 21:22:02 2019 CET

|   gpg:using RSA key
6636274B2E8BEA9D15A61143F8484389379ACEAC

|   gpg: Good signature from "Slawomir Jaranowski "
[ultimate]

|   Author: Slawomir Jaranowski 

|   Commit: Slawomir Jaranowski 

|

|   some log is too more verbose in normal run

A:
 - no manually work
 - committer and reviewer are known for git history
 - preserve original commit and pgp signature of commiter - no change to
commit body

D:
 - two commits - but one is merge commit
 - github as commiter in merge commit


#

Personally I like and use option 3.
Repository can be configured which option is allowed.

I think, that every author of change should do the most of work as is
possible and reviewer should do review and do one action as easy as
possible.


sob., 21 mar 2020 o 19:53 Benjamin Marwell  napisał(a):

> Checkstyle builds will fail of there is more than one commit in a PR.
> Not saying I like it, but it's an option.
>
>
>
>
> On Sat, 21 Mar 2020, 16:17 Elliotte Rusty Harold, 
> wrote:
>
> > So it appears that if I do all squashing and merging locally and then
> > push directly to master, I get listed as committer and author:
> >
> >
> >
> https://gitbox.apache.org/repos/asf?p=maven-shared-utils.git&a=commit&h=4264899a152a6205b0f34a32e9c947edcd9cb1e8
> >
> > Github is no longer listed as the committer. This is what we want.
> >
> > However this is quite cumbersome, and I'm confident I'm going to mix
> > this up, probably sooner rather than later. E.g. I might forget or
> > squash or worse yet push commits into master I didn't want to push.
> >
> > Does anyone have an alternate workflow that lets us use the Github
> > buttons? If not, is keeping Github out of the committer messages
> > critical? It seems Author is still accurate.
> >
> >
> >
> >
> > On Thu, Mar 12, 2020 at 2:46 PM Robert Scholte 
> > wrote:
> > >
> > > This week I was very surprised to see commits from the user call
> > "github" in Jenkins:
> > >
> >
> https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/changes
> > >
> > >
> > > IMO we shouldn't want these kind of commits.
> > > Based on the most recent activities I had a chat with Sylwester en
> > Elliotte.
> > >
> > > The reason is the author of these commits was Elliotte, but the
> > committer Github
> > >
> >
> https://gitbox.apache.org/repos/asf?p=maven-shared-utils.git&a=commit&h=8ed3e6827885a161a8802100f0f50968555356b0
> > >
> > >
> > > Elliotte tried to figure it out, and his conclusion was that in case

Maven Invoker Plugin - streamLogsOnFailures

[Slawomir Jaranowski]

Hi,

According to the issue https://issues.apache.org/jira/browse/MINVOKER-250 I
will take your opinion about new feature.

My proposition is to add possibility to show build.log of failed job at the
end of all tests.

I chose this way because printing log during execute tests can cause mixed
output of different tests in parallel mode.

In order to meet this requirements
 - I extend build-job.xml report about file name for logs
 - stream build.log to mojo log in verify goal or in processResults method
in run goal.

This feature will be very useful especially in problem in test.
If everything is ok we don't need print build.log (it can have many lines)
but after test failed is difficult to examine what happened.

PR is ready and waiting for your opinion.

-- 
Sławomir Jaranowski

Re: Maven Invoker Plugin - streamLogsOnFailures

[Slawomir Jaranowski]

ion' of '99.0.0' is newer than the versions supported by
this version of Maven: [4.0.0]. Building this project requires a newer
version of Maven. @ line 24, column 17
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project test:fail-build:0.1-SNAPSHOT
(.../maven-invoker-plugin/target/it/fail-build-with-verify-streamLogsOnFailures/target/it/project/pom.xml)
has 2 errors
[ERROR] Malformed POM
.../maven-invoker-plugin/target/it/fail-build-with-verify-streamLogsOnFailures/target/it/project/pom.xml:
Unrecognised tag: 'invalidElementShouldFailBuild' (position: START_TAG seen
...\n\n  ... @34:35)  @
.../maven-invoker-plugin/target/it/fail-build-with-verify-streamLogsOnFailures/target/it/project/pom.xml,
line 34, column 35 -> [Help 2]
[ERROR] 'modelVersion' of '99.0.0' is newer than the versions supported
by this version of Maven: [4.0.0]. Building this project requires a newer
version of Maven. @ line 24, column 17
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/ModelParseException
*** end build.log for: project/pom.xml ***

[ERROR] -
[ERROR]
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  2.316 s
[INFO] Finished at: 2020-04-01T17:48:03+02:00
[INFO]


śr., 1 kwi 2020 o 17:13 Elliotte Rusty Harold 
napisał(a):

> Can you show us:
>
> A. What the configuration for this looks like?
> B. What the output looks like when this is turned on?
>
> Thanks.
>
> On Wed, Apr 1, 2020 at 10:56 AM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > According to the issue
> https://issues.apache.org/jira/browse/MINVOKER-250 I
> > will take your opinion about new feature.
> >
> > My proposition is to add possibility to show build.log of failed job at
> the
> > end of all tests.
> >
> > I chose this way because printing log during execute tests can cause
> mixed
> > output of different tests in parallel mode.
> >
> > In order to meet this requirements
> >  - I extend build-job.xml report about file name for logs
> >  - stream build.log to mojo log in verify goal or in processResults
> method
> > in run goal.
> >
> > This feature will be very useful especially in problem in test.
> > If everything is ok we don't need print build.log (it can have many
> lines)
> > but after test failed is difficult to examine what happened.
> >
> > PR is ready and waiting for your opinion.
> >
> > --
> > Sławomir Jaranowski
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

fluido-1.9 skin - release plan

[Slawomir Jaranowski]

Hi,

I want kindly ask - when do you want release next version of fluido skin?

I think that many valuable issue was resolved
https://issues.apache.org/jira/projects/MSKINS/versions/12346750

Is there some rules when new version of maven component will be released?

-- 
Sławomir Jaranowski

Re: Maven Filtering Plugin should avoid overwriting even when filtering

[Slawomir Jaranowski]

Hi,

Can you describe your case and what you want to achieve.

By default all files created during maven running are write to target
directory. And in most case target directory is cleaned before new build
starting.
Usual maven is running  by:
  mvn clean install.

sob., 25 kwi 2020 o 00:59 Robert Oxspring 
napisał(a):

> Hi all,
>
>
> When copying resources with filtering on, files are always overwritten
> even when the filters have not changed. I’d like to change this such that
> repeated filtering copies do not modify the destination file.
>
> I’ve prepared a change to write the filtered content to a temporary file
> and only rename that over the destination if they’re different:
>
> https://github.com/apache/maven-filtering/compare/master...roxspring:feature/avoid-overwrite-on-no-op-filter
>
> Would something like this be acceptable? I’m guessing the next step is to
> create an issue in Jira? - agains MNG??
>
> Thanks,
>
> Rob
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: Maven Invoker Plugin - streamLogsOnFailures

[Slawomir Jaranowski]

Hi
Did you found some time to look at my proposition?
I'm waiting for your opinion.
Maybe you need some more explanations.

śr., 1 kwi 2020 o 17:58 Slawomir Jaranowski 
napisał(a):

> A.
> new parameters *streamLogsOnFailures* with boolean value - default false
> - don't change current behavior, eg. from IT test
>
> 
>  org.apache.maven.plugins
>  maven-invoker-plugin
>  @pom.version@
>  
>true
>false
>${project.build.directory}/it
>
>  */pom.xml
>
>*true*
>  
>  
> 
>
> B.
> *output - run goal*
>
> [INFO] --- maven-invoker-plugin:3.2.2-SNAPSHOT:run (integration-test) @
> fail-build-streamLogsOnFailures ---
> [INFO]
> [INFO] Building: project/pom.xml
> [INFO]   The build exited with code 1. See
> ./maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/build.log
> for details.
> [INFO]   project/pom.xml .. FAILED
> (1.6 s)
> [INFO] -
> [INFO] Build Summary:
> [INFO]   Passed: 0, Failed: 1, Errors: 0, Skipped: 0
> [INFO] -
> [ERROR] The following builds failed:
> [ERROR] *  project/pom.xml
> [INFO] -
> [ERROR] -
> [ERROR]
>
> *** begin build.log for: project/pom.xml ***
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Malformed POM
> .../maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml:
> Unrecognised tag: 'invalidElementShouldFailBuild' (position: START_TAG seen
> ...\n\n  ... @34:35)  @
> .../maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml,
> line 34, column 35
> [FATAL] 'modelVersion' of '99.0.0' is newer than the versions supported by
> this version of Maven: [4.0.0]. Building this project requires a newer
> version of Maven. @ line 24, column 17
>  @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project test:fail-build:0.1-SNAPSHOT
> (.../maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml)
> has 2 errors
> [ERROR] Malformed POM
> .../maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml:
> Unrecognised tag: 'invalidElementShouldFailBuild' (position: START_TAG seen
> ...\n\n  ... @34:35)  @
> .../maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml,
> line 34, column 35 -> [Help 2]
> [ERROR] 'modelVersion' of '99.0.0' is newer than the versions
> supported by this version of Maven: [4.0.0]. Building this project requires
> a newer version of Maven. @ line 24, column 17
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/ModelParseException
> *** end build.log for: project/pom.xml ***
>
> [ERROR] -
> [ERROR]
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  3.863 s
> [INFO] Finished at: 2020-04-01T17:47:55+02:00
> [INFO]
> 
>
>
> *goals - integration-test, verify*
>
> [INFO]
> [INFO] --- maven-invoker-plugin:3.2.2-SNAPSHOT:integration-test
> (integration-test) @ fail-build-with-verify-streamLogsOnFailures ---
> [INFO] Building: project/pom.xml
> [INFO]   The build exited with code 1. See
> .../maven-invoker-plugin/target/it/fail-build-with-verify-streamLogsOnFailures/target/it/project/build.log
> for details.
> [INFO]   project/pom.xml .. FAILED
> (1.3 s)
> [INFO]
> [INFO] --- maven-invoker-plugin:3.2.2-SNAPSHOT:verify (integration-test) @
> fail-build-with-verify-streamLogsOnFailures ---
> [INFO] -
> [INFO] Build Summary:
> [INFO]   Passed: 0, Failed: 1, Errors: 0, Skipped: 0
> [INFO] --

Re: Maven Runtime Metrics System - MNG-6899

[Slawomir Jaranowski]

Hi,
In my humble opinion it is not the best way to implement own api when
similar api is already ready and maintained.

There is another project used for metrics: micrometer, as we can see it is
a quite popular 2.3K stars, 500 forks  on github
https://github.com/micrometer-metrics/micrometer

Please consider similar situation with logging api used in maven, we have
different logging in plexus component, maven plugin api, maven core, ...
and now slf4j is try to replace old

  Why it is so important to you to be independent in this case?

sob., 2 maj 2020 o 15:20 Enrico Olivelli  napisał(a):

> Robert
>
> Il Sab 2 Mag 2020, 15:11 Robert Scholte  ha scritto:
>
> > If I take a look at the pom of maven-metrics, I see no dependency on
> Maven.
> > And looking at
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > [
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > ]
> > This looks a lot like
> >
> https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> > [
> >
> https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> > ]
> >
> > So do we need to maintain our own Metrics API?
> >
>
> Yes it is really better.
>
> We will be in charge for this API, it will be a new API on which we will
> depend in many part of Maven core and in plugins.
> It is better to not depend on third party.
>
> There are other initiatives like microprofile metrics.
>
> The API itself is very small and we could add an implementation that uses
> micro profile. But we must be independent.
>
> Enrico
>
>
>
> > thanks,
> > Robert
> > On 2-5-2020 10:26:19, Enrico Olivelli  wrote:
> > Hello community,
> > I am now ready to move forward with concrete steps for the implementation
> > of Maven Runtime Metrics.
> >
> > This is the JIRA
> > https://issues.apache.org/jira/browse/MNG-6899
> >
> > It links to my proof-of-concept branch on maven studies.
> > https://github.com/apache/maven-studies/tree/maven-metrics
> >
> > In order to move forward I have to create an independent module/git
> > repository for the Maven Metrics Runtime API.
> > Currently I have it on maven-studies inside Maven Core but this is not
> > good, because I would like to use it in Plugins independently from the
> > version of Maven Core.
> > When you run the plugin on an old version of Maven all of the data will
> be
> > simply ignored.
> >
> > My plan:
> > - create a git repository
> > - put there the first version of the API (maybe we can put there a simple
> > implementation of the API, but I could leave it off for the first
> release)
> > - release it to the public
> > - use it in Maven 3.7
> > - use it in Wagon and in Resolver and in other "interesting" modules/core
> > plugins
> >
> > Best regards
> > Enrico
> >
>


-- 
Sławomir Jaranowski

Re: Maven Invoker Plugin - streamLogsOnFailures

[Slawomir Jaranowski]

Hi,

Thanks for last review, I hope that all remarks are resolved in PR.

Now is one new - how new parameters should be named.
I'm waiting for final decision.
https://github.com/apache/maven-invoker-plugin/pull/20#pullrequestreview-403456129


sob., 25 kwi 2020 o 15:40 Slawomir Jaranowski 
napisał(a):

> Hi
> Did you found some time to look at my proposition?
> I'm waiting for your opinion.
> Maybe you need some more explanations.
>
> śr., 1 kwi 2020 o 17:58 Slawomir Jaranowski 
> napisał(a):
>
>> A.
>> new parameters *streamLogsOnFailures* with boolean value - default false
>> - don't change current behavior, eg. from IT test
>>
>> 
>>  org.apache.maven.plugins
>>  maven-invoker-plugin
>>  @pom.version@
>>  
>>true
>>false
>>${project.build.directory}/it
>>
>>  */pom.xml
>>
>>*true*
>>  
>>  
>> 
>>
>> B.
>> *output - run goal*
>>
>> [INFO] --- maven-invoker-plugin:3.2.2-SNAPSHOT:run (integration-test) @
>> fail-build-streamLogsOnFailures ---
>> [INFO]
>> [INFO] Building: project/pom.xml
>> [INFO]   The build exited with code 1. See
>> ./maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/build.log
>> for details.
>> [INFO]   project/pom.xml ..
>> FAILED (1.6 s)
>> [INFO] -
>> [INFO] Build Summary:
>> [INFO]   Passed: 0, Failed: 1, Errors: 0, Skipped: 0
>> [INFO] -
>> [ERROR] The following builds failed:
>> [ERROR] *  project/pom.xml
>> [INFO] -
>> [ERROR] -
>> [ERROR]
>>
>> *** begin build.log for: project/pom.xml ***
>> [INFO] Scanning for projects...
>> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
>> [ERROR] Malformed POM
>> .../maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml:
>> Unrecognised tag: 'invalidElementShouldFailBuild' (position: START_TAG seen
>> ...\n\n  ... @34:35)  @
>> .../maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml,
>> line 34, column 35
>> [FATAL] 'modelVersion' of '99.0.0' is newer than the versions supported
>> by this version of Maven: [4.0.0]. Building this project requires a newer
>> version of Maven. @ line 24, column 17
>>  @
>> [ERROR] The build could not read 1 project -> [Help 1]
>> [ERROR]
>> [ERROR]   The project test:fail-build:0.1-SNAPSHOT
>> (.../maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml)
>> has 2 errors
>> [ERROR] Malformed POM
>> .../maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml:
>> Unrecognised tag: 'invalidElementShouldFailBuild' (position: START_TAG seen
>> ...\n\n  ... @34:35)  @
>> .../maven-invoker-plugin/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml,
>> line 34, column 35 -> [Help 2]
>> [ERROR] 'modelVersion' of '99.0.0' is newer than the versions
>> supported by this version of Maven: [4.0.0]. Building this project requires
>> a newer version of Maven. @ line 24, column 17
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>> -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
>> [ERROR] [Help 2]
>> http://cwiki.apache.org/confluence/display/MAVEN/ModelParseException
>> *** end build.log for: project/pom.xml ***
>>
>> [ERROR] -
>> [ERROR]
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Total time:  3.863 s
>> [INFO] Finished at: 2020-04-01T17:47:55+02:00
>> [INFO]
>> 
>>
>>
>> *goals - integration-test, verify*
>>
>> [INFO]
>> [INFO] --- maven-invoker-p

Re: Hooking custom plugin into deploy phase

[Slawomir Jaranowski]

Hi Peter

Your plugin name doesn't meet maven plugin name requirements.
Maybe some maven plugin name patterns are hardcoded in maven code.

Please try rename your plugin to something as askpass-maven-plugin.

https://maven.apache.org/guides/plugin/guide-java-plugin-development.html

śr., 20 maj 2020 o 08:58 Maarten Mulders  napisał(a):

> Hi Petr,
>
> If you want to specifically invoke your plugin, you would need
> mvn
>
> cz.fiisch.maven.plugin.deploy.askpass:askpass-deploy-plugin:1.0-SNAPSHOT:askpass
> (so not mvn deploy:askpass - this looks for the askpass goal in the
> maven-deploy-plugin which doesn't exist)
>
> That said, I would expect that if you took the snippet from the pom.xml
> you have in your email (without the goals section commented out), the
> askpass goal of your plugin should be invoked.
>
> I do agree that - at this stage - seeing messages about missing
> distributionManagement is probably not the cause of the fact that your
> custom plugin not being invoked.
>
> You could add -X (e.g. mvn -X ) - it will create a lot of debugging
> output, it might give some clues as to why your plugin is not executing.
>
> HTH,
>
> Maarten
>
> On May 20, 2020 at 07:56, Petr Fišer wrote:
>
> > Hi,
> > This sound interesting. I gave it a try but it didn't work for me. It
> > even seems that my plugin does not get picked up during "deploy" at
> > all.
> > I added maven-deploy-plugin to the build config like this:
> >
> > 
> > 
> > 
> > cz.fiisch.maven.plugin.deploy.askpass
> > askpass-deploy-plugin
> > 1.0-SNAPSHOT
> > 
> > 
> > deploy
> > 
> > 
> > 
> > 
> >
> > 
> > maven-deploy-plugin
> > 2.8.2
> > 
> > 
> > deploy
> > 
> > 
> > 
> > 
> > 
> >
> > And when running "mvn deploy" there is still only maven-deploy-plugin
> > complaining about the distributionManagement config, blablabla. Like I
> > said before, don't think that is a cause. :)
> > When running specifically for the goal "deploy:askpass" the Maven
> > complains that "Could not find goal 'askpass' in plugin
> > org.apache.maven.plugins:maven-deploy-plugin:2.8.2 ..." which still
> > means that only maven-deploy-plugin got executed.
> >
> > Any idea what could be wrong? Maybe I have some error in my POM?
> > Cheers,
> >
> > Petr Fišer
> >
> > BCV solutions s.r.o.
> > Mobile: +420 607 618 243
> > E-mail: petr.fi...@bcvsolutions.eu
> > Jabber: petr.fi...@bcvsolutions.eu
> >
> > On 05/19/2020 02:39 PM, Maarten Mulders wrote: Hi Petr,
> >
> > As far as I know, when two plugins are bound to the same phase, the
> > order of execution is the same as the order in which you define them in
> > pom.xml.
> > So if you want your plugin to be executed before the
> > maven-deploy-plugin, I guess you'll need to explicitly list the
> > maven-deploy-plugin in your pom.xml, straight after your custom plugin.
> > (Besides, it would be a good idea to do that anyway since it allows you
> > to specify which version of the maven-deploy-plugin your project uses.)
> >
> > Hope this helps!
> >
> > Maarten
> >
> > On May 19, 2020 at 14:24, Petr Fišer wrote:
> >
> > Hello,
> > I am trying to create custom maven plugin. Problem is I need to hook it
> > up into the "deploy" phase before the default maven-deploy-plugin gets
> > executed.
> > The plugin itself seems to be ok - I hooked it up to "package" phase to
> > verify its working. But when trying to get it into "deploy" phase, the
> > maven-deploy-plugin executes first (and of course complains that I do
> > not have the distributionManagement section in the pom.xml but I guess
> > that is not the root of my problem).
> >
> > Could somebody point me in the right direction please?
> >
> > Base class of the plugin:
> >
> > @Mojo( name ="askpass", defaultPhase = LifecyclePhase.DEPLOY )
> > public class AskpassDeployPluginMojoextends AbstractMojo {
> > public void execute()throws MojoExecutionException,
> > MojoFailureException {
> > //do something here }
> > }
> >
> > Reference from pom.xml of sample project where I am testing this:
> > http://maven.apache.org/POM/4.0.0";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd";>
> > 4.0.0
> > com.mycompany.app
> > my-app
> > jar
> > 1.0-SNAPSHOT
> > my-app
> > http://maven.apache.org
> > 
> > 
> > junit
> > junit
> > 3.8.1
> > test
> > 
> > 
> >
> > 
> > 
> > 
> > cz.fiisch.maven.plugin.deploy.askpass
> > askpass-deploy-plugin
> > 1.0-SNAPSHOT
> > 
> > 
> > deploy
> > 
> > askpass
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > Cheers,
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Proposition of improvement in maven-script-interpreter

[Slawomir Jaranowski]

Hi,

I've created issues with some of proposition:

https://issues.apache.org/jira/browse/MSHARED-910
https://issues.apache.org/jira/browse/MSHARED-911
https://issues.apache.org/jira/browse/MSHARED-914

I can do this change after your approval, and after release new version of
maven-script-interpreter I can update it in maven-invoker-plugin.

I did PR for https://issues.apache.org/jira/browse/MSHARED-907
I know this break compatibility, but I can remove dependency do
maven-plugin-api and code can be easier.
So I'm also waiting for your opinion for it.

-- 
Sławomir Jaranowski

maven-invoker-plugin release plan

[Slawomir Jaranowski]

Hi,
I see that many my PR to maven-invoker-plugin, maven-script-interpreter was
merged - thanks especially for Sylwester.

One of issue is easy to fix:
https://issues.apache.org/jira/browse/MINVOKER-265 by
https://issues.apache.org/jira/browse/MSHARED-914

Next step will be release of maven-script-interpreter and use new version
in maven-invoker-plugin.

So what is your plan to prepare next release - I can help in apply new
version maven-script-interpreter to maven-invoker-plugin.


-- 
Sławomir Jaranowski

List of public pgp key servers

[Slawomir Jaranowski]

Hi,

Are there any informations / documentations / recommendations which key
servers should be used to publish public key.

On site
https://maven.apache.org/repository/guide-central-repository-upload.html#pgp-signature
we have "like" http://pgp.mit.edu/
and on site
https://central.sonatype.org/pages/working-with-pgp-signatures.html#distributing-your-public-key
we have example with hkp://pool.sks-keyservers.net

I also asked Sonatype about it - and I'm waiting for a response.

-- 
Sławomir Jaranowski

Re: maven-invoker-plugin release plan

[Slawomir Jaranowski]

Hi,

I would kindly remind my question about the release plan for
maven-invoker-plugin.

We have already resolved 10 issues.
https://issues.apache.org/jira/projects/MINVOKER/versions/12346157

Below are easy to resolv:
https://issues.apache.org/jira/browse/MINVOKER-265
https://issues.apache.org/jira/browse/MINVOKER-260

Some of issue in maven-script-interpreter are waiting for your
opinion/approval
https://issues.apache.org/jira/browse/MSHARED-910
https://issues.apache.org/jira/browse/MSHARED-911
https://issues.apache.org/jira/browse/MSHARED-914
https://issues.apache.org/jira/browse/MSHARED-917

First we should release maven-script-interpreter and use new version in
maven-invoker-plugin.

So i'm waiting for your opinion / suggestion how can I help in this process.


niedz., 7 cze 2020 o 13:01 Slawomir Jaranowski 
napisał(a):

>
> Hi,
> I see that many my PR to maven-invoker-plugin, maven-script-interpreter
> was merged - thanks especially for Sylwester.
>
> One of issue is easy to fix:
> https://issues.apache.org/jira/browse/MINVOKER-265 by
> https://issues.apache.org/jira/browse/MSHARED-914
>
> Next step will be release of maven-script-interpreter and use new version
> in maven-invoker-plugin.
>
> So what is your plan to prepare next release - I can help in apply new
> version maven-script-interpreter to maven-invoker-plugin.
>
>
> --
> Sławomir Jaranowski
>


-- 
Sławomir Jaranowski

maven-script-interpreter next version - please help

[Slawomir Jaranowski]

Hi,

I made changes to maven-script-interpreter which will resolve some issues
in invoker plugin.

Last my changes brake compatibility, so next version should be: *2.0*
according to semVer

Here is a list of change:
https://issues.apache.org/jira/projects/MSHARED/versions/12341132

And the last PR for this release:
https://issues.apache.org/jira/browse/MSHARED-939

There is anybody, who can help in release - maven-script-interpreter?

-- 
Sławomir Jaranowski

Re: maven-source-plugin broken on Windows + JDK8

[Slawomir Jaranowski]

jdk can be good point,
pass build use: Java version: 1.8.0_241, vendor: Oracle Corporation,
runtime: /usr/local/asfpackages/java/jdk1.8.0_241/jre
failed has: Java version: 1.8.0_252, vendor: Oracle Corporation,
runtime: /usr/local/asfpackages/java/openjdk-8u252-b09/jre

on mac os with: Java version: 1.8.0_252, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
build pass successful

pon., 27 lip 2020 o 08:31 Robert Scholte  napisał(a):

> My bad, it is indeed the Ubuntu that is failing.
> It might be caused be JDK-8177809[1]
> IIRC when using Path instead of File you won't have this issue.
>
> Robert
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8177809
>
>
> On 27-7-2020 07:31:41, Christian Stein  wrote:
> Hi,
>
> Why do you think it's the Windows node, Robert?
>
> For me, it [1] says 5 times: linux-jdk8-m3.6.x_build
> The file separator chars displayed in the log file also points to a Linux
> node:
>
> >
> > [INFO] The post-build script did not succeed. assert buildLog.text =~
> > /(?i) Archive .*${sourcesJarFileName} is uptodate/
> > | | | |
> > | | |
> > empty-source-directory-1.0-SNAPSHOT-sources.jar
> > | | java.util.regex.Matcher[pattern=(?i) Archive
> > .*empty-source-directory-1.0-SNAPSHOT-sources.jar is uptodate
> > region=0,44353 lastmatch=]
> > | Picked up JAVA_TOOL_OPTIONS:
> >
> -Dmaven.ext.class.path="/home/jenkins/jenkins-slave/workspace/n-box_maven-source-plugin_master@3
> > @2@tmp/withMaven42d62564/pipeline-maven-spy.jar"
> >
> -Dorg.jenkinsci.plugins.pipeline.maven.reportsFolder="/home/jenkins/jenkins-slave/workspace/n-box_maven-source-plugin_master@3
> > @2@tmp/withMaven42d62564"
>
>
> The underlying reason for the failure is not clear to me.
> IIUC, the log says a new -sources.jar was created for an IT
> named MSOURCES-95.
> But the expectation is, that an "uptodate" check prevents a recreation of
> the -sources.jar file?
>
> Cheers,
> Christian
>
> [1]
>
> https://builds.apache.org/blue/organizations/jenkins/maven-box%2Fmaven-source-plugin/activity
>
>
>
> On Sun, Jul 26, 2020 at 9:56 PM Robert Scholte wrote:
>
> > Anybody willing to analyze why this plugin is broken for a while?[1]
> > It look like there hasn't been a commit since the last success (recent
> > changes only show commits on our Jenkins files)
> >
> > All other master are currently stable.[2]
> >
> > thanks,
> > Robert
> >
> > [1]
> >
> https://builds.apache.org/job/maven-box/job/maven-source-plugin/job/master/
> > [2]
> >
> https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-master-jobs.html
> >
> >
>


-- 
Sławomir Jaranowski

Re: maven-script-interpreter next version - please help

[Slawomir Jaranowski]

Hi,
I would kindly remind
There are anybody who can and want help me in
release maven-script-interpreter

sob., 25 lip 2020 o 10:35 Slawomir Jaranowski 
napisał(a):

> Hi,
>
> I made changes to maven-script-interpreter which will resolve some issues
> in invoker plugin.
>
> Last my changes brake compatibility, so next version should be: *2.0*
> according to semVer
>
> Here is a list of change:
> https://issues.apache.org/jira/projects/MSHARED/versions/12341132
>
> And the last PR for this release:
> https://issues.apache.org/jira/browse/MSHARED-939
>
> There is anybody, who can help in release - maven-script-interpreter?
>
> --
> Sławomir Jaranowski
>


-- 
Sławomir Jaranowski

Re: Maven Sign Plugin

[Slawomir Jaranowski]

Hi

I have some experience in case of verifying pgp signatures using Bouncy
Castle during work on my pgpverify-maven-plugin.
So If you would, I can try to help with the sign plugin.

Let me know if you are interested.

niedz., 20 wrz 2020 o 20:38 Robert Scholte 
napisał(a):

> With the next release of Maven the current maven-gpg-plugin will become
> useless.
> With the build//consumer pom, the local pom will be different compared to
> the uploaded pom.
> However, the maven-gpg-plugin now uses the pom.xml of the local project.
> (btw, the plugin uses the gpg commandline with a bunch of arguments. The
> stdio is used for passing the passphrase, you cannot stream the file via
> commandline)
>
> In Maven 3.6.x changes have been made to support InputStream next to File.
> This way we don't have to create a backdoor of writing a temporary file,
> which is likely to cause issues with very creative plugin/extension
> writers. Instead we should do in memory signing.
>
> It would make sense to introduce a new plugin, and during a discussion
> with the PMC the idea of maven-sign-plugin was proposed (a much better
> alternative campared to maven-gpg2-plugin)
>
> Dennis Lundberg started a POC based on Apache Common OpenGPG, however, it
> is still in the sandbox[1]
>
> Olivier Lamy already discovered that signing doesn't work with the current
> Maven 3.7.0-SNAPSHOT.
> Before we can even start thinking of an alpha-release, this issue must be
> fixed, because signing is a critical step for sharing artifacts.
>
> I'm still struggling with MNG-6957, but in parallel a few should be able
> implement this.
>
> Anybody willing to make this work?
>
> thanks,
> Robert
>
> [1] http://commons.apache.org/sandbox/commons-openpgp/ [
> http://commons.apache.org/sandbox/commons-openpgp/]
>


-- 
Sławomir Jaranowski

Re: Maven Sign Plugin

[Slawomir Jaranowski]

Hi

On the weekend I will have some spare time, so I can do something about it
..

My questions:
  - are there git repository, jira project for new plugin
  - does anybody working on it now - what is progress
  - if you want to use  Apache Common OpenGPG, I think should be refreshed
first  - is there git repo for it


czw., 24 wrz 2020 o 18:57 Robert Scholte  napisał(a):

> Thanks for the offer.
> Signing is very delicate process, so I appreciate the extra help.
>
> thanks,
> Robert
> On 21-9-2020 09:14:54, Slawomir Jaranowski  wrote:
> Hi
>
> I have some experience in case of verifying pgp signatures using Bouncy
> Castle during work on my pgpverify-maven-plugin.
> So If you would, I can try to help with the sign plugin.
>
> Let me know if you are interested.
>
> niedz., 20 wrz 2020 o 20:38 Robert Scholte
> napisał(a):
>
> > With the next release of Maven the current maven-gpg-plugin will become
> > useless.
> > With the build//consumer pom, the local pom will be different compared to
> > the uploaded pom.
> > However, the maven-gpg-plugin now uses the pom.xml of the local project.
> > (btw, the plugin uses the gpg commandline with a bunch of arguments. The
> > stdio is used for passing the passphrase, you cannot stream the file via
> > commandline)
> >
> > In Maven 3.6.x changes have been made to support InputStream next to
> File.
> > This way we don't have to create a backdoor of writing a temporary file,
> > which is likely to cause issues with very creative plugin/extension
> > writers. Instead we should do in memory signing.
> >
> > It would make sense to introduce a new plugin, and during a discussion
> > with the PMC the idea of maven-sign-plugin was proposed (a much better
> > alternative campared to maven-gpg2-plugin)
> >
> > Dennis Lundberg started a POC based on Apache Common OpenGPG, however, it
> > is still in the sandbox[1]
> >
> > Olivier Lamy already discovered that signing doesn't work with the
> current
> > Maven 3.7.0-SNAPSHOT.
> > Before we can even start thinking of an alpha-release, this issue must be
> > fixed, because signing is a critical step for sharing artifacts.
> >
> > I'm still struggling with MNG-6957, but in parallel a few should be able
> > implement this.
> >
> > Anybody willing to make this work?
> >
> > thanks,
> > Robert
> >
> > [1] http://commons.apache.org/sandbox/commons-openpgp/ [
> > http://commons.apache.org/sandbox/commons-openpgp/]
> >
>
>
> --
> Sławomir Jaranowski
>


-- 
Sławomir Jaranowski

Re: Maven Sign Plugin

[Slawomir Jaranowski]

Ok, I don't want to reinvent the wheels, so

How to reach handle to project artifacts list, especially project pom after
transformation in plugin code?

Some plugin examples, point which component should I use to achieve this
will be great.

pt., 25 wrz 2020 o 17:05 Robert Scholte  napisał(a):

> There no plugin yet, but I suggest to start with a branch under
> https://github.com/apache/maven-studies before making an official new
> repository.
>
> Let me quote 2 points mentioned by Stephen Connolly, which we still need
> to address:
>
> - If we switch to bouncycastle based, we will now own the key storage.
> This is both good and bad.
>   * People who have their keys stored in gpg2 will have a “fun time”
> extracting them... or else we will have to do the dance of extracting them
> ourselves.
>   * If we “own” the key storage, publishing keys to a key registry and
> generating keys may become our problem from the user’s perspective.
>   * One of the biggest complaints about publishing on central has been the
> difficulty of gpg signing. New users will likely thank us if we make it
> easier.
>
> - PGP functionality provider security issues become our problem. Before,
> users could independently upgrade the gpg CLI tooling to work past security
> issues (causing it’s own issues as CLI options changed from gpg1 to gpg2).
> With this plugin, the pgp provider version will be baked into the pom. How
> will users be able to assure their security team that signatures have been
> made in the version without a security issue?
>
> thanks,
> Robert
> On 25-9-2020 15:35:01, Slawomir Jaranowski  wrote:
> Hi
>
> On the weekend I will have some spare time, so I can do something about it
> ..
>
> My questions:
> - are there git repository, jira project for new plugin
> - does anybody working on it now - what is progress
> - if you want to use Apache Common OpenGPG, I think should be refreshed
> first - is there git repo for it
>
>
> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a):
>
> > Thanks for the offer.
> > Signing is very delicate process, so I appreciate the extra help.
> >
> > thanks,
> > Robert
> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote:
> > Hi
> >
> > I have some experience in case of verifying pgp signatures using Bouncy
> > Castle during work on my pgpverify-maven-plugin.
> > So If you would, I can try to help with the sign plugin.
> >
> > Let me know if you are interested.
> >
> > niedz., 20 wrz 2020 o 20:38 Robert Scholte
> > napisał(a):
> >
> > > With the next release of Maven the current maven-gpg-plugin will become
> > > useless.
> > > With the build//consumer pom, the local pom will be different compared
> to
> > > the uploaded pom.
> > > However, the maven-gpg-plugin now uses the pom.xml of the local
> project.
> > > (btw, the plugin uses the gpg commandline with a bunch of arguments.
> The
> > > stdio is used for passing the passphrase, you cannot stream the file
> via
> > > commandline)
> > >
> > > In Maven 3.6.x changes have been made to support InputStream next to
> > File.
> > > This way we don't have to create a backdoor of writing a temporary
> file,
> > > which is likely to cause issues with very creative plugin/extension
> > > writers. Instead we should do in memory signing.
> > >
> > > It would make sense to introduce a new plugin, and during a discussion
> > > with the PMC the idea of maven-sign-plugin was proposed (a much better
> > > alternative campared to maven-gpg2-plugin)
> > >
> > > Dennis Lundberg started a POC based on Apache Common OpenGPG, however,
> it
> > > is still in the sandbox[1]
> > >
> > > Olivier Lamy already discovered that signing doesn't work with the
> > current
> > > Maven 3.7.0-SNAPSHOT.
> > > Before we can even start thinking of an alpha-release, this issue must
> be
> > > fixed, because signing is a critical step for sharing artifacts.
> > >
> > > I'm still struggling with MNG-6957, but in parallel a few should be
> able
> > > implement this.
> > >
> > > Anybody willing to make this work?
> > >
> > > thanks,
> > > Robert
> > >
> > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [
> > > http://commons.apache.org/sandbox/commons-openpgp/]
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
>
> --
> Sławomir Jaranowski
>


-- 
Sławomir Jaranowski

Re: Maven Sign Plugin

[Slawomir Jaranowski]

Ok.
I did some research and spike.

We need access to *FileTransformerManager*, it look like this is method,
which we want:

* org.eclipse.aether.RepositorySystemSession#getFileTransformerManager*
We can use it from maven 3.6 (without overwriting the version of
 maven-resolver-api) ... so the plugin has a minimum maven requirement for
this version. But even in 3.6 and 3.7-SNAPSHOT i have exception during
execution:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign
(with-method-call) on project test1: Execution with-method-call of goal
org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign failed: A
required class was missing while executing
org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign:
org/eclipse/aether/transform/FileTransformerManager

So next I try by reflection ... (now looks not good) ... but I have
expected result

So when we must use reflection maybe this magic should be done in separate
utils like
*maven-resolver, maven-artifact-transfer *(where we have magic with
reflections)
When we prepare a method/class for transparent transformation in an
external library we can simply use it in the gpg plugin and problems for
the new version of maven will be solved.
Gpg plugin already use *maven-resolver, maven-artifact-transfer*

Of course we can continue work on the new plugin - but we need more time to
develop the first production/beta version.

Another question in about api for
*org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact*
result is collection of *FileTransformer* so what should happen when we
have more then one transformer.
In
https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246
result file is overwrited by last transformer from list.

You can look at what I did at my fork:
https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin

I'm waiting for a decision on what should be done next ...

sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski 
napisał(a):

> Ok, I don't want to reinvent the wheels, so
>
> How to reach handle to project artifacts list, especially project pom
> after transformation in plugin code?
>
> Some plugin examples, point which component should I use to achieve this
> will be great.
>
> pt., 25 wrz 2020 o 17:05 Robert Scholte  napisał(a):
>
>> There no plugin yet, but I suggest to start with a branch under
>> https://github.com/apache/maven-studies before making an official new
>> repository.
>>
>> Let me quote 2 points mentioned by Stephen Connolly, which we still need
>> to address:
>>
>> - If we switch to bouncycastle based, we will now own the key storage.
>> This is both good and bad.
>>   * People who have their keys stored in gpg2 will have a “fun time”
>> extracting them... or else we will have to do the dance of extracting them
>> ourselves.
>>   * If we “own” the key storage, publishing keys to a key registry and
>> generating keys may become our problem from the user’s perspective.
>>   * One of the biggest complaints about publishing on central has been
>> the difficulty of gpg signing. New users will likely thank us if we make it
>> easier.
>>
>> - PGP functionality provider security issues become our problem. Before,
>> users could independently upgrade the gpg CLI tooling to work past security
>> issues (causing it’s own issues as CLI options changed from gpg1 to gpg2).
>> With this plugin, the pgp provider version will be baked into the pom. How
>> will users be able to assure their security team that signatures have been
>> made in the version without a security issue?
>>
>> thanks,
>> Robert
>> On 25-9-2020 15:35:01, Slawomir Jaranowski 
>> wrote:
>> Hi
>>
>> On the weekend I will have some spare time, so I can do something about it
>> ..
>>
>> My questions:
>> - are there git repository, jira project for new plugin
>> - does anybody working on it now - what is progress
>> - if you want to use Apache Common OpenGPG, I think should be refreshed
>> first - is there git repo for it
>>
>>
>> czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a):
>>
>> > Thanks for the offer.
>> > Signing is very delicate process, so I appreciate the extra help.
>> >
>> > thanks,
>> > Robert
>> > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote:
>> > Hi
>> >
>> > I have some experience in case of verifying pgp signatures using Bouncy
>> > Castle during work on my pgpverify-maven-plugin.
>> > So If you would, I can try to help with the sign plugin.
>> >
>> > Let me know if you ar

Re: Maven Sign Plugin

[Slawomir Jaranowski]

In order to remove reflection and possibility to call:

   FileTransformerManager fileTransformerManager =
repositorySystemSession.getFileTransformerManager();

I must add:

org.eclipse.aether.transform

in:
https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58

Without it I have:
   java.lang.ClassNotFoundException:
org.eclipse.aether.transform.FileTransformerManager

this change will be possible in the latest maven version, call above method
on older maven version will cause ClassNotFoundException

adding direct dependency to maven-resolver-api (even in newer version)  in
plugin not help,
I suppose that classloader for plugin is prepare in special way according
to META-INF/maven/extension.xml

I don't know why reflection works ...



niedz., 27 wrz 2020 o 20:30 Robert Scholte 
napisał(a):

> For now I would focus on making it work for Maven 3.7.0 and above.
> That would remove the need for reflection right?
>
> If there are multiple transfomers, in the end their result should all be
> signed.
> The reason behind this is that in the future we could upload multiple
> files based on the same pom.
> We should always upload a model 4.0.0 compatible version, but we might
> also transform the local pom to a more efficient file preferred by Maven 5.
>
> thanks,
> Robert
>
>
>
> On 27-9-2020 13:06:45, Slawomir Jaranowski  wrote:
> Ok.
> I did some research and spike.
>
> We need access to *FileTransformerManager*, it look like this is method,
> which we want:
>
> * org.eclipse.aether.RepositorySystemSession#getFileTransformerManager*
> We can use it from maven 3.6 (without overwriting the version of
> maven-resolver-api) ... so the plugin has a minimum maven requirement for
> this version. But even in 3.6 and 3.7-SNAPSHOT i have exception during
> execution:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign
> (with-method-call) on project test1: Execution with-method-call of goal
> org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign failed: A
> required class was missing while executing
> org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign:
> org/eclipse/aether/transform/FileTransformerManager
>
> So next I try by reflection ... (now looks not good) ... but I have
> expected result
>
> So when we must use reflection maybe this magic should be done in separate
> utils like
> *maven-resolver, maven-artifact-transfer *(where we have magic with
> reflections)
> When we prepare a method/class for transparent transformation in an
> external library we can simply use it in the gpg plugin and problems for
> the new version of maven will be solved.
> Gpg plugin already use *maven-resolver, maven-artifact-transfer*
>
> Of course we can continue work on the new plugin - but we need more time to
> develop the first production/beta version.
>
> Another question in about api for
>
> *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact*
> result is collection of *FileTransformer* so what should happen when we
> have more then one transformer.
> In
>
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246
> result file is overwrited by last transformer from list.
>
> You can look at what I did at my fork:
> https://github.com/slawekjaranowski/maven-studies/tree/maven-sign-plugin
>
> I'm waiting for a decision on what should be done next ...
>
> sob., 26 wrz 2020 o 11:46 Slawomir Jaranowski
> napisał(a):
>
> > Ok, I don't want to reinvent the wheels, so
> >
> > How to reach handle to project artifacts list, especially project pom
> > after transformation in plugin code?
> >
> > Some plugin examples, point which component should I use to achieve this
> > will be great.
> >
> > pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a):
> >
> >> There no plugin yet, but I suggest to start with a branch under
> >> https://github.com/apache/maven-studies before making an official new
> >> repository.
> >>
> >> Let me quote 2 points mentioned by Stephen Connolly, which we still need
> >> to address:
> >>
> >> - If we switch to bouncycastle based, we will now own the key storage.
> >> This is both good and bad.
> >> * People who have their keys stored in gpg2 will have a “fun time”
> >> extracting them... or else we will have to do the dance of extracting
> them
> >> ourselves.
> >> * If we “own” the key storage, publishing keys to a key registry and
> >> gene

Re: Maven Sign Plugin

[Slawomir Jaranowski]

But on the other side, plugins must sign other artifacts associated with a
given project.

So in this way we have two different processes - one for pom with
transformation and ather for rest artifacts.

Maybe all project artifacts should go through the transformation process
then we can have one way for all.

Anyway, first we should resolve how to access Transformers from the plugin.
And how (if we want) get comparability for old maven versions.


pt., 2 paź 2020 o 10:46 Robert Scholte  napisał(a):

> In the end a signer is just another file transformer, so we need to
> achieve something like this:
> local pom >> build/consumer pom (distribute) >> sign (distribute)
> The plugin must be able to register a SignFileTransformer, which should
> only be called during deploy. For the latter I can imagine we need to
> extend the API.
>
> thanks,
> Robert
> On 28-9-2020 00:35:45, Slawomir Jaranowski  wrote:
> In order to remove reflection and possibility to call:
>
> FileTransformerManager fileTransformerManager =
> repositorySystemSession.getFileTransformerManager();
>
> I must add:
>
> org.eclipse.aether.transform
>
> in:
>
> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58
>
> Without it I have:
> java.lang.ClassNotFoundException:
> org.eclipse.aether.transform.FileTransformerManager
>
> this change will be possible in the latest maven version, call above method
> on older maven version will cause ClassNotFoundException
>
> adding direct dependency to maven-resolver-api (even in newer version) in
> plugin not help,
> I suppose that classloader for plugin is prepare in special way according
> to META-INF/maven/extension.xml
>
> I don't know why reflection works ...
>
>
>
> niedz., 27 wrz 2020 o 20:30 Robert Scholte
> napisał(a):
>
> > For now I would focus on making it work for Maven 3.7.0 and above.
> > That would remove the need for reflection right?
> >
> > If there are multiple transfomers, in the end their result should all be
> > signed.
> > The reason behind this is that in the future we could upload multiple
> > files based on the same pom.
> > We should always upload a model 4.0.0 compatible version, but we might
> > also transform the local pom to a more efficient file preferred by Maven
> 5.
> >
> > thanks,
> > Robert
> >
> >
> >
> > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote:
> > Ok.
> > I did some research and spike.
> >
> > We need access to *FileTransformerManager*, it look like this is method,
> > which we want:
> >
> > * org.eclipse.aether.RepositorySystemSession#getFileTransformerManager*
> > We can use it from maven 3.6 (without overwriting the version of
> > maven-resolver-api) ... so the plugin has a minimum maven requirement for
> > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception during
> > execution:
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign
> > (with-method-call) on project test1: Execution with-method-call of goal
> > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign failed: A
> > required class was missing while executing
> > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign:
> > org/eclipse/aether/transform/FileTransformerManager
> >
> > So next I try by reflection ... (now looks not good) ... but I have
> > expected result
> >
> > So when we must use reflection maybe this magic should be done in
> separate
> > utils like
> > *maven-resolver, maven-artifact-transfer *(where we have magic with
> > reflections)
> > When we prepare a method/class for transparent transformation in an
> > external library we can simply use it in the gpg plugin and problems for
> > the new version of maven will be solved.
> > Gpg plugin already use *maven-resolver, maven-artifact-transfer*
> >
> > Of course we can continue work on the new plugin - but we need more time
> to
> > develop the first production/beta version.
> >
> > Another question in about api for
> >
> >
> *org.eclipse.aether.transform.FileTransformerManager#getTransformersForArtifact*
> > result is collection of *FileTransformer* so what should happen when we
> > have more then one transformer.
> > In
> >
> >
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultInstaller.java#L246
> > result file is overwrited by last transformer from list.
> >
> > Yo

Re: Maven Sign Plugin

[Slawomir Jaranowski]

Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer api.
So one issue is need to resolve:
https://issues.apache.org/jira/browse/MNG-6992

Of course it is clear that all "uploaded" files must be signed.
Question is - if we should use transformer api only for POM or for all?

pt., 2 paź 2020 o 15:57 Robert Scholte  napisał(a):

> All "uploaded" files must be signed, see for instance
> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/
> And don't care about older Maven versions, for now just set the
> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom.
>
> On 2-10-2020 14:21:02, Slawomir Jaranowski  wrote:
> But on the other side, plugins must sign other artifacts associated with a
> given project.
>
> So in this way we have two different processes - one for pom with
> transformation and ather for rest artifacts.
>
> Maybe all project artifacts should go through the transformation process
> then we can have one way for all.
>
> Anyway, first we should resolve how to access Transformers from the plugin.
> And how (if we want) get comparability for old maven versions.
>
>
> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a):
>
> > In the end a signer is just another file transformer, so we need to
> > achieve something like this:
> > local pom >> build/consumer pom (distribute) >> sign (distribute)
> > The plugin must be able to register a SignFileTransformer, which should
> > only be called during deploy. For the latter I can imagine we need to
> > extend the API.
> >
> > thanks,
> > Robert
> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote:
> > In order to remove reflection and possibility to call:
> >
> > FileTransformerManager fileTransformerManager =
> > repositorySystemSession.getFileTransformerManager();
> >
> > I must add:
> >
> > org.eclipse.aether.transform
> >
> > in:
> >
> >
> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58
> >
> > Without it I have:
> > java.lang.ClassNotFoundException:
> > org.eclipse.aether.transform.FileTransformerManager
> >
> > this change will be possible in the latest maven version, call above
> method
> > on older maven version will cause ClassNotFoundException
> >
> > adding direct dependency to maven-resolver-api (even in newer version) in
> > plugin not help,
> > I suppose that classloader for plugin is prepare in special way according
> > to META-INF/maven/extension.xml
> >
> > I don't know why reflection works ...
> >
> >
> >
> > niedz., 27 wrz 2020 o 20:30 Robert Scholte
> > napisał(a):
> >
> > > For now I would focus on making it work for Maven 3.7.0 and above.
> > > That would remove the need for reflection right?
> > >
> > > If there are multiple transfomers, in the end their result should all
> be
> > > signed.
> > > The reason behind this is that in the future we could upload multiple
> > > files based on the same pom.
> > > We should always upload a model 4.0.0 compatible version, but we might
> > > also transform the local pom to a more efficient file preferred by
> Maven
> > 5.
> > >
> > > thanks,
> > > Robert
> > >
> > >
> > >
> > > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote:
> > > Ok.
> > > I did some research and spike.
> > >
> > > We need access to *FileTransformerManager*, it look like this is
> method,
> > > which we want:
> > >
> > > * org.eclipse.aether.RepositorySystemSession#getFileTransformerManager*
> > > We can use it from maven 3.6 (without overwriting the version of
> > > maven-resolver-api) ... so the plugin has a minimum maven requirement
> for
> > > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception during
> > > execution:
> > >
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign
> > > (with-method-call) on project test1: Execution with-method-call of goal
> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign failed: A
> > > required class was missing while executing
> > > org.apache.maven.plugins:maven-sign-plugin:1.0-SNAPSHOT:sign:
> > > org/eclipse/aether/transform/FileTransformerManager
> > >
> > > So next I try by reflection ... (now looks not good) ... but I have
> > > expected result
> > 

Re: Maven Sign Plugin

[Slawomir Jaranowski]

First working version is ready:

https://github.com/apache/maven-studies/pull/2

I'm waiting for your opinion

pt., 2 paź 2020 o 17:05 Slawomir Jaranowski 
napisał(a):

> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer api.
> So one issue is need to resolve:
> https://issues.apache.org/jira/browse/MNG-6992
>
> Of course it is clear that all "uploaded" files must be signed.
> Question is - if we should use transformer api only for POM or for all?
>
> pt., 2 paź 2020 o 15:57 Robert Scholte  napisał(a):
>
>> All "uploaded" files must be signed, see for instance
>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/
>> And don't care about older Maven versions, for now just set the
>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom.
>>
>> On 2-10-2020 14:21:02, Slawomir Jaranowski 
>> wrote:
>> But on the other side, plugins must sign other artifacts associated with a
>> given project.
>>
>> So in this way we have two different processes - one for pom with
>> transformation and ather for rest artifacts.
>>
>> Maybe all project artifacts should go through the transformation process
>> then we can have one way for all.
>>
>> Anyway, first we should resolve how to access Transformers from the
>> plugin.
>> And how (if we want) get comparability for old maven versions.
>>
>>
>> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a):
>>
>> > In the end a signer is just another file transformer, so we need to
>> > achieve something like this:
>> > local pom >> build/consumer pom (distribute) >> sign (distribute)
>> > The plugin must be able to register a SignFileTransformer, which should
>> > only be called during deploy. For the latter I can imagine we need to
>> > extend the API.
>> >
>> > thanks,
>> > Robert
>> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote:
>> > In order to remove reflection and possibility to call:
>> >
>> > FileTransformerManager fileTransformerManager =
>> > repositorySystemSession.getFileTransformerManager();
>> >
>> > I must add:
>> >
>> > org.eclipse.aether.transform
>> >
>> > in:
>> >
>> >
>> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58
>> >
>> > Without it I have:
>> > java.lang.ClassNotFoundException:
>> > org.eclipse.aether.transform.FileTransformerManager
>> >
>> > this change will be possible in the latest maven version, call above
>> method
>> > on older maven version will cause ClassNotFoundException
>> >
>> > adding direct dependency to maven-resolver-api (even in newer version)
>> in
>> > plugin not help,
>> > I suppose that classloader for plugin is prepare in special way
>> according
>> > to META-INF/maven/extension.xml
>> >
>> > I don't know why reflection works ...
>> >
>> >
>> >
>> > niedz., 27 wrz 2020 o 20:30 Robert Scholte
>> > napisał(a):
>> >
>> > > For now I would focus on making it work for Maven 3.7.0 and above.
>> > > That would remove the need for reflection right?
>> > >
>> > > If there are multiple transfomers, in the end their result should all
>> be
>> > > signed.
>> > > The reason behind this is that in the future we could upload multiple
>> > > files based on the same pom.
>> > > We should always upload a model 4.0.0 compatible version, but we might
>> > > also transform the local pom to a more efficient file preferred by
>> Maven
>> > 5.
>> > >
>> > > thanks,
>> > > Robert
>> > >
>> > >
>> > >
>> > > On 27-9-2020 13:06:45, Slawomir Jaranowski wrote:
>> > > Ok.
>> > > I did some research and spike.
>> > >
>> > > We need access to *FileTransformerManager*, it look like this is
>> method,
>> > > which we want:
>> > >
>> > > *
>> org.eclipse.aether.RepositorySystemSession#getFileTransformerManager*
>> > > We can use it from maven 3.6 (without overwriting the version of
>> > > maven-resolver-api) ... so the plugin has a minimum maven requirement
>> for
>> > > this version. But even in 3.6 and 3.7-SNAPSHOT i have exception during
>> > > execution:
>> > >
&g

Re: Custom packaging

[Slawomir Jaranowski]

Hi,

It should be worked out of the box.

configuration for plugin wich add new packaging, in parent / super pom
should be defined in section:
build -> *pluginManagement*

and only in module when you can use custom packaging you add
   plugin in  build -> plugin


śr., 7 paź 2020 o 11:30 Alvaro Sanchez-Mariscal <
alvaro.sanchezmaris...@gmail.com> napisał(a):

> So far what I've done is change the parent POM to configure this additional
> plugin in the none phase, and then remap the jar packaging type and include
> it there.
>
> This seems to work, but I'm wondering whether there is better approach.
>
> On Wed, Oct 7, 2020 at 7:47 AM Alvaro Sanchez-Mariscal <
> alvaro.sanchezmaris...@gmail.com> wrote:
>
> > Hi,
> >
> > I'm writing a plugin that intends to support custom packaging types.
> >
> > The plugin's components.xml looks like:
> >
> > 
> > 
> > 
> >
> > org.apache.maven.lifecycle.mapping.LifecycleMapping
> > my-custom-type
> > 
> >
>  org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping
> > 
> > 
> > 
> > 
> > default
> > 
> > 
> > com.foo:foo-maven-plugin:bar
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > The user's project (where this plugin will be used) have a parent POM
> that
> > binds an additional plugin into the package phase.
> >
> > The problem is that, when executing mvn package, it runs not only
> > com.foo:foo-maven-plugin:bar, but also this additional plugin.
> >
> > Is there a way to avoid this?
> >
> > Note that the parent POM is under my control and I could make changes to
> > it as well if needed.
> >
> > Cheers,
> > --
> > Álvaro Sánchez-Mariscal
> > alvaro.sanchezmaris...@gmail.com
> > twitter.com/alvaro_sanchez
> >
>
>
> --
> Álvaro Sánchez-Mariscal
> alvaro.sanchezmaris...@gmail.com
> twitter.com/alvaro_sanchez
>


-- 
Sławomir Jaranowski

Filetrasformer design

[Slawomir Jaranowski]

Hi,


During a spike on maven-sign-plugin we discovered the chain feature in the
Transformation process will be useful.

Current transformation solution is dedicated to pom transformation, it will
be also useful to prepare more flexible solutions for another type of
transformation like preparing signatures for artefacts.

Present implementation of transformers cause of calling the whole
transformation process from beginning for all requests.

We process it twice - first for install and second for deploy.
So when we add more complicated and more resource demand (like computation
of signature) we can decrease performance in a visible way.

Now try to build a process with a chined transformer, we will have a
PomTransformer which can produce two kinds of pom.
Next transformer will be for signing SigTransformer, so we will have:

- pom.xml
-> PomTransformer
- pom.xml FileTransformer
-> SigTransformer
- pom.xml.asc FileTransformer
- pom5.xmlFileTransformer
-> SigTransformer
- pom5.xml.ascFileTransformer


In this example we can see that in output we need to produce 4 artifacts:
pom.xml, pom5.xml and pom.xml.asc, pom 5.xml.asc so we need 4 final
transformers and transformer from previous level was run twice.

The biggest problem which I see is that we need results from all
Transformers level.

I'm afraid that when we start to use transformers for all artifacts we can
decrease performance for projects with big artifacts.

And the end - summary:
1. problem of running transformers many times during project build
2.  multilevel / chained transformers - how to reuse output from previous
level

-- 
Sławomir Jaranowski

Re: Filetrasformer design

[Slawomir Jaranowski]

ok, duplicate transformer execution will be resolved by MNG-5667.

Of course the performance of signing with an external tool and internal is
not a good comparison, but with  external tool process was run once and now
will be run twice. So I thought about performance in this way that we will
do the same job many times.

I see that transformation should be changed, so can we define (if possible)
small steps which get us to the goal, but first we need this goal.

What I see:
- possibility to plug transformations for poms
- possibility to plug transformations for other artifacts (do we want?)
- possibility to plug transformations for signing/checksumming

So never mind we will have transformation in two levels:
pom -> signing/consuming
each of this level can produce new artefakt or something else which should
be attached / installed /deployed

When we use transformation like now we need to define all transformation
and output items from them before start, because the list of project
artifacts which will be installed/deployed is built before the
transformation process is started.


niedz., 11 paź 2020 o 11:59 Robert Scholte 
napisał(a):

> It is true that for both install and deploy the transformers will be
> executed, however in general there is no need to do both, this is how Maven
> still works, but should be solved with MNG-5667[1].
> This might be a good reason to give this a higher priority. (and to get
> "mvn clean install" out of everybody's system)
>
> I don't think there's a lot of need for transformers, so I could image
> Maven will predefine the available transformation hooks, i.e. pom
> transformers and checksum/signature transformers.
>
> I would like to see numbers of performance differences. (keep in mind it
> is probably an unfair comparison, because signing is now done by a third
> party program).
> To reduce memory consumption the transfomer is using PipedStreams, which
> should imply that size doesn't matter anymore.
>
> thanks,
> Robert
>
>
> [1] https://issues.apache.org/jira/browse/MNG-5667
> On 11-10-2020 09:06:11, Slawomir Jaranowski 
> wrote:
> Hi,
>
>
> During a spike on maven-sign-plugin we discovered the chain feature in the
> Transformation process will be useful.
>
> Current transformation solution is dedicated to pom transformation, it will
> be also useful to prepare more flexible solutions for another type of
> transformation like preparing signatures for artefacts.
>
> Present implementation of transformers cause of calling the whole
> transformation process from beginning for all requests.
>
> We process it twice - first for install and second for deploy.
> So when we add more complicated and more resource demand (like computation
> of signature) we can decrease performance in a visible way.
>
> Now try to build a process with a chined transformer, we will have a
> PomTransformer which can produce two kinds of pom.
> Next transformer will be for signing SigTransformer, so we will have:
>
> - pom.xml
> -> PomTransformer
> - pom.xml FileTransformer
> -> SigTransformer
> - pom.xml.asc FileTransformer
> - pom5.xml FileTransformer
> -> SigTransformer
> - pom5.xml.asc FileTransformer
>
>
> In this example we can see that in output we need to produce 4 artifacts:
> pom.xml, pom5.xml and pom.xml.asc, pom 5.xml.asc so we need 4 final
> transformers and transformer from previous level was run twice.
>
> The biggest problem which I see is that we need results from all
> Transformers level.
>
> I'm afraid that when we start to use transformers for all artifacts we can
> decrease performance for projects with big artifacts.
>
> And the end - summary:
> 1. problem of running transformers many times during project build
> 2. multilevel / chained transformers - how to reuse output from previous
> level
>
> --
> Sławomir Jaranowski
>


-- 
Sławomir Jaranowski

Re: [VOTE] Release Apache Maven Script Interpreter version 1.3

[Slawomir Jaranowski]

sob., 17 paź 2020 o 21:19 Sylwester Lachiewicz 
napisał(a):

> Hi,
>
> Apache Maven Script Interpreter - this component provides some utilities to
> interpret/execute some scripts for various implementations: Groovy or
> BeanShell.
> The project is used, among others in maven-invoker-plugin.
>
> We solved 15 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12341132&styleName=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1609/
>
> https://repository.apache.org/content/repositories/maven-1609/org/apache/maven/shared/maven-script-interpreter/1.3/maven-script-interpreter-1.3-source-release.zip
>
> Source release checksum(s):
> maven-script-interpreter-1.3-source-release.zip sha512:
>
> bb5c636efa28bd0e66049577aebff213156c85d87b8a1dcd0f1ea5bd17e12002ec2e5e19fb70303149c18eaf846869e126015e9235a9fd759874b5e332b47150
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-script-interpreter-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Many thanks especially for Sylwester.
I have tested this version with maven-invoker-plugin.
This version resolves the next issues in maven-invoker-plugin.

So +1 from me

-- 
Sławomir Jaranowski

Re: Maven Sign Plugin

[Slawomir Jaranowski]

Hi

What next step do you plan with this plugin?

I believe that can be usable even now for users.

It is not too much work to prepare a plugin to work with maven 3.6 so we
can publish it and take feedback from users.

I think that early release can help users to prepare their project to be
ready for maven 3.7.

If you wish I will take care about this plugin.

niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski 
napisał(a):

> First working version is ready:
>
> https://github.com/apache/maven-studies/pull/2
>
> I'm waiting for your opinion
>
> pt., 2 paź 2020 o 17:05 Slawomir Jaranowski 
> napisał(a):
>
>> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer api.
>> So one issue is need to resolve:
>> https://issues.apache.org/jira/browse/MNG-6992
>>
>> Of course it is clear that all "uploaded" files must be signed.
>> Question is - if we should use transformer api only for POM or for all?
>>
>> pt., 2 paź 2020 o 15:57 Robert Scholte  napisał(a):
>>
>>> All "uploaded" files must be signed, see for instance
>>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/
>>> And don't care about older Maven versions, for now just set the
>>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom.
>>>
>>> On 2-10-2020 14:21:02, Slawomir Jaranowski 
>>> wrote:
>>> But on the other side, plugins must sign other artifacts associated with
>>> a
>>> given project.
>>>
>>> So in this way we have two different processes - one for pom with
>>> transformation and ather for rest artifacts.
>>>
>>> Maybe all project artifacts should go through the transformation process
>>> then we can have one way for all.
>>>
>>> Anyway, first we should resolve how to access Transformers from the
>>> plugin.
>>> And how (if we want) get comparability for old maven versions.
>>>
>>>
>>> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a):
>>>
>>> > In the end a signer is just another file transformer, so we need to
>>> > achieve something like this:
>>> > local pom >> build/consumer pom (distribute) >> sign (distribute)
>>> > The plugin must be able to register a SignFileTransformer, which should
>>> > only be called during deploy. For the latter I can imagine we need to
>>> > extend the API.
>>> >
>>> > thanks,
>>> > Robert
>>> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote:
>>> > In order to remove reflection and possibility to call:
>>> >
>>> > FileTransformerManager fileTransformerManager =
>>> > repositorySystemSession.getFileTransformerManager();
>>> >
>>> > I must add:
>>> >
>>> > org.eclipse.aether.transform
>>> >
>>> > in:
>>> >
>>> >
>>> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58
>>> >
>>> > Without it I have:
>>> > java.lang.ClassNotFoundException:
>>> > org.eclipse.aether.transform.FileTransformerManager
>>> >
>>> > this change will be possible in the latest maven version, call above
>>> method
>>> > on older maven version will cause ClassNotFoundException
>>> >
>>> > adding direct dependency to maven-resolver-api (even in newer version)
>>> in
>>> > plugin not help,
>>> > I suppose that classloader for plugin is prepare in special way
>>> according
>>> > to META-INF/maven/extension.xml
>>> >
>>> > I don't know why reflection works ...
>>> >
>>> >
>>> >
>>> > niedz., 27 wrz 2020 o 20:30 Robert Scholte
>>> > napisał(a):
>>> >
>>> > > For now I would focus on making it work for Maven 3.7.0 and above.
>>> > > That would remove the need for reflection right?
>>> > >
>>> > > If there are multiple transfomers, in the end their result should
>>> all be
>>> > > signed.
>>> > > The reason behind this is that in the future we could upload multiple
>>> > > files based on the same pom.
>>> > > We should always upload a model 4.0.0 compatible version, but we
>>> might
>>> > > also transform the local pom to a more efficient file preferred by
>>> Maven
>>> > 5.
>>> > >

Re: Maven Sign Plugin

[Slawomir Jaranowski]

Hi,

The Idea of making a signature by java code without an external binary is
very good.

I have plans to automate some  of CI/CD and such plugin will be very useful
for me.
I can customise it for easy use with CI system

So waiting for you,
I will release it under my github organization, probably at the end of
year. If someone is interested please let me know.


pon., 2 lis 2020 o 21:36 Robert Scholte  napisał(a):

> I want to have another look at Maven Resolver. I don't want to store it as
> a file, but stream it directly to a repository.
> The goal is now bound to verify, but that's incorrect (it has nothing to
> do with verifying integration results).
> Looking at it, I think this should not be a maven-plugin, but a Maven
> extension, so it can hook itself during deploy, no need for an explicit
> goal to call
> I need to work it out a bit more.
>
> thanks,
> Robert
>
> On 19-10-2020 22:47:06, Slawomir Jaranowski 
> wrote:
> Hi
>
> What next step do you plan with this plugin?
>
> I believe that can be usable even now for users.
>
> It is not too much work to prepare a plugin to work with maven 3.6 so we
> can publish it and take feedback from users.
>
> I think that early release can help users to prepare their project to be
> ready for maven 3.7.
>
> If you wish I will take care about this plugin.
>
> niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski
> napisał(a):
>
> > First working version is ready:
> >
> > https://github.com/apache/maven-studies/pull/2
> >
> > I'm waiting for your opinion
> >
> > pt., 2 paź 2020 o 17:05 Slawomir Jaranowski
> > napisał(a):
> >
> >> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer
> api.
> >> So one issue is need to resolve:
> >> https://issues.apache.org/jira/browse/MNG-6992
> >>
> >> Of course it is clear that all "uploaded" files must be signed.
> >> Question is - if we should use transformer api only for POM or for all?
> >>
> >> pt., 2 paź 2020 o 15:57 Robert Scholte napisał(a):
> >>
> >>> All "uploaded" files must be signed, see for instance
> >>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/
> >>> And don't care about older Maven versions, for now just set the
> >>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom.
> >>>
> >>> On 2-10-2020 14:21:02, Slawomir Jaranowski
> >>> wrote:
> >>> But on the other side, plugins must sign other artifacts associated
> with
> >>> a
> >>> given project.
> >>>
> >>> So in this way we have two different processes - one for pom with
> >>> transformation and ather for rest artifacts.
> >>>
> >>> Maybe all project artifacts should go through the transformation
> process
> >>> then we can have one way for all.
> >>>
> >>> Anyway, first we should resolve how to access Transformers from the
> >>> plugin.
> >>> And how (if we want) get comparability for old maven versions.
> >>>
> >>>
> >>> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a):
> >>>
> >>> > In the end a signer is just another file transformer, so we need to
> >>> > achieve something like this:
> >>> > local pom >> build/consumer pom (distribute) >> sign (distribute)
> >>> > The plugin must be able to register a SignFileTransformer, which
> should
> >>> > only be called during deploy. For the latter I can imagine we need to
> >>> > extend the API.
> >>> >
> >>> > thanks,
> >>> > Robert
> >>> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote:
> >>> > In order to remove reflection and possibility to call:
> >>> >
> >>> > FileTransformerManager fileTransformerManager =
> >>> > repositorySystemSession.getFileTransformerManager();
> >>> >
> >>> > I must add:
> >>> >
> >>> > org.eclipse.aether.transform
> >>> >
> >>> > in:
> >>> >
> >>> >
> >>>
> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58
> >>> >
> >>> > Without it I have:
> >>> > java.lang.ClassNotFoundException:
> >>> > org.eclipse.aether.transform.FileTransformerManager
> >>> >
> >>> > 

Re: Maven Sign Plugin

[Slawomir Jaranowski]

Hi,

First version of Sign Maven Plugin was released -
https://github.com/s4u/sign-maven-plugin

It works with Maven 3.6.x and future version 4.x

If somebody is interested I invite them to test and collaborate.

pon., 14 gru 2020 o 21:42 Slawomir Jaranowski 
napisał(a):

> Hi,
>
> The Idea of making a signature by java code without an external binary is
> very good.
>
> I have plans to automate some  of CI/CD and such plugin will be very
> useful for me.
> I can customise it for easy use with CI system
>
> So waiting for you,
> I will release it under my github organization, probably at the end of
> year. If someone is interested please let me know.
>
>
> pon., 2 lis 2020 o 21:36 Robert Scholte  napisał(a):
>
>> I want to have another look at Maven Resolver. I don't want to store it
>> as a file, but stream it directly to a repository.
>> The goal is now bound to verify, but that's incorrect (it has nothing to
>> do with verifying integration results).
>> Looking at it, I think this should not be a maven-plugin, but a Maven
>> extension, so it can hook itself during deploy, no need for an explicit
>> goal to call
>> I need to work it out a bit more.
>>
>> thanks,
>> Robert
>>
>> On 19-10-2020 22:47:06, Slawomir Jaranowski 
>> wrote:
>> Hi
>>
>> What next step do you plan with this plugin?
>>
>> I believe that can be usable even now for users.
>>
>> It is not too much work to prepare a plugin to work with maven 3.6 so we
>> can publish it and take feedback from users.
>>
>> I think that early release can help users to prepare their project to be
>> ready for maven 3.7.
>>
>> If you wish I will take care about this plugin.
>>
>> niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski
>> napisał(a):
>>
>> > First working version is ready:
>> >
>> > https://github.com/apache/maven-studies/pull/2
>> >
>> > I'm waiting for your opinion
>> >
>> > pt., 2 paź 2020 o 17:05 Slawomir Jaranowski
>> > napisał(a):
>> >
>> >> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer
>> api.
>> >> So one issue is need to resolve:
>> >> https://issues.apache.org/jira/browse/MNG-6992
>> >>
>> >> Of course it is clear that all "uploaded" files must be signed.
>> >> Question is - if we should use transformer api only for POM or for all?
>> >>
>> >> pt., 2 paź 2020 o 15:57 Robert Scholte napisał(a):
>> >>
>> >>> All "uploaded" files must be signed, see for instance
>> >>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/
>> >>> And don't care about older Maven versions, for now just set the
>> >>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom.
>> >>>
>> >>> On 2-10-2020 14:21:02, Slawomir Jaranowski
>> >>> wrote:
>> >>> But on the other side, plugins must sign other artifacts associated
>> with
>> >>> a
>> >>> given project.
>> >>>
>> >>> So in this way we have two different processes - one for pom with
>> >>> transformation and ather for rest artifacts.
>> >>>
>> >>> Maybe all project artifacts should go through the transformation
>> process
>> >>> then we can have one way for all.
>> >>>
>> >>> Anyway, first we should resolve how to access Transformers from the
>> >>> plugin.
>> >>> And how (if we want) get comparability for old maven versions.
>> >>>
>> >>>
>> >>> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a):
>> >>>
>> >>> > In the end a signer is just another file transformer, so we need to
>> >>> > achieve something like this:
>> >>> > local pom >> build/consumer pom (distribute) >> sign (distribute)
>> >>> > The plugin must be able to register a SignFileTransformer, which
>> should
>> >>> > only be called during deploy. For the latter I can imagine we need
>> to
>> >>> > extend the API.
>> >>> >
>> >>> > thanks,
>> >>> > Robert
>> >>> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote:
>> >>> > In order to remove reflection and possibility to call:
>> >>> >
>> >>> > FileTransformerManager fileTransformerManager 

Re: Maven Sign Plugin

[Slawomir Jaranowski]

I'm really open to help developing / maintaining such a plugin under Apache
Organization.

But as we see the release process in Apache is very slow ... I need it now,
and I don't want to wait for years so I decided to release it by myself.

Probably it is another topic how to make Apache projects more agile and
more friendly for external contributors.

For example I did a few feature / fix for maven-invoker-plugin and I wait
about year for release next version, I don't have knowledge when it can
happen ...

pon., 28 gru 2020 o 14:04 Markus KARG  napisał(a):

> Please turn it into an official Maven plugin, as there are many people out
> there reluctant when it comes to third party due to sustained support etc.!
> :-)
> -Markus
>
>
> -Ursprüngliche Nachricht-
> Von: Slawomir Jaranowski [mailto:s.jaranow...@gmail.com]
> Gesendet: Montag, 28. Dezember 2020 13:09
> An: Maven Developers List
> Betreff: Re: Maven Sign Plugin
>
> Hi,
>
> First version of Sign Maven Plugin was released -
> https://github.com/s4u/sign-maven-plugin
>
> It works with Maven 3.6.x and future version 4.x
>
> If somebody is interested I invite them to test and collaborate.
>
> pon., 14 gru 2020 o 21:42 Slawomir Jaranowski 
> napisał(a):
>
> > Hi,
> >
> > The Idea of making a signature by java code without an external binary is
> > very good.
> >
> > I have plans to automate some  of CI/CD and such plugin will be very
> > useful for me.
> > I can customise it for easy use with CI system
> >
> > So waiting for you,
> > I will release it under my github organization, probably at the end of
> > year. If someone is interested please let me know.
> >
> >
> > pon., 2 lis 2020 o 21:36 Robert Scholte 
> napisał(a):
> >
> >> I want to have another look at Maven Resolver. I don't want to store it
> >> as a file, but stream it directly to a repository.
> >> The goal is now bound to verify, but that's incorrect (it has nothing to
> >> do with verifying integration results).
> >> Looking at it, I think this should not be a maven-plugin, but a Maven
> >> extension, so it can hook itself during deploy, no need for an explicit
> >> goal to call
> >> I need to work it out a bit more.
> >>
> >> thanks,
> >> Robert
> >>
> >> On 19-10-2020 22:47:06, Slawomir Jaranowski 
> >> wrote:
> >> Hi
> >>
> >> What next step do you plan with this plugin?
> >>
> >> I believe that can be usable even now for users.
> >>
> >> It is not too much work to prepare a plugin to work with maven 3.6 so we
> >> can publish it and take feedback from users.
> >>
> >> I think that early release can help users to prepare their project to be
> >> ready for maven 3.7.
> >>
> >> If you wish I will take care about this plugin.
> >>
> >> niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski
> >> napisał(a):
> >>
> >> > First working version is ready:
> >> >
> >> > https://github.com/apache/maven-studies/pull/2
> >> >
> >> > I'm waiting for your opinion
> >> >
> >> > pt., 2 paź 2020 o 17:05 Slawomir Jaranowski
> >> > napisał(a):
> >> >
> >> >> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer
> >> api.
> >> >> So one issue is need to resolve:
> >> >> https://issues.apache.org/jira/browse/MNG-6992
> >> >>
> >> >> Of course it is clear that all "uploaded" files must be signed.
> >> >> Question is - if we should use transformer api only for POM or for
> all?
> >> >>
> >> >> pt., 2 paź 2020 o 15:57 Robert Scholte napisał(a):
> >> >>
> >> >>> All "uploaded" files must be signed, see for instance
> >> >>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/
> >> >>> And don't care about older Maven versions, for now just set the
> >> >>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom.
> >> >>>
> >> >>> On 2-10-2020 14:21:02, Slawomir Jaranowski
> >> >>> wrote:
> >> >>> But on the other side, plugins must sign other artifacts associated
> >> with
> >> >>> a
> >> >>> given project.
> >> >>>
> >> >>> So in this way we have two different processes - one for pom with
> >> >>

Re: Maven 4 / @Inject

[Slawomir Jaranowski]

If you think about such a change - Maven 4 should support both namespaces
with warning about deprecating javax.inject.
In this way developers will have more time and possibility to switch their
plugins/extensions to new namespaces.
Finally Maven 5 can support only new namespaces.

pon., 28 gru 2020 o 15:02 Romain Manni-Bucau 
napisał(a):

> I agree javax will stay for years and doing any breaking change today would
> just be bad for end users, that said we can already encourage plugins to
> not use it and log a warning in maven plugin plugin.
> For maven core we don't care much since we can change it when we want, it
> will just impact extensions - and I agree again maven 5 can be the time to
> do it.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 28 déc. 2020 à 14:59, Michael Osipov  a
> écrit :
>
> > Am 2020-12-28 um 14:56 schrieb Markus KARG:
> > > We are used to "import javax.inject.*" in Maven, but that namespace if
> > dead
> > > since Jakarta EE 9. Since November the new namespace is released
> "import
> > > jakarta.inject.*". I wonder if Maven 4 really still wants to stick with
> > the
> > > dead namespace instead, or whether it makes sense that we adopt the new
> > > namespace now?
> >
> > That statement is very harsh. Both will co-exist for at least 10 years
> > due to the massive amount of applications in companies. Maven tries to
> > clean up stuff. I think this needs to be spared to Maven 5.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


-- 
Sławomir Jaranowski

Re: releasing maven-artifact-plugin

[Slawomir Jaranowski]

Hi,

I use

org.apache.maven.repository.RepositorySystem#createArtifactWithClassifier -
it is not

Maybe the java version can also be upgraded to 1.8 New plugin and start
with 1.7 is a special requirement for it?


pt., 15 sty 2021 o 12:50 Elliotte Rusty Harold 
napisał(a):

> I noticed this code in ReferenceBuildInfo:
>
> Artifact buildinfo =
> artifactFactory.createArtifactWithClassifier(
> project.getGroupId(), project.getArtifactId(),
>
> project.getVersion(), "buildinfo", "" );
>
>
> The problem is that ArtifactFactory is deprecated and has been for a
> while. However it doesn't have any information about what is supposed
> to be used instead.
>
> Since this is greenfield code, could this be replaced by the
> non-deprecated alternative? Or, if there is, no non-deprecated
> alternative, then can we consider undeprecating ArtifactFactory? It's
> woven pretty deeply into most of our plugins and APIs.
>
> On Thu, Jan 14, 2021 at 7:10 PM Hervé BOUTEMY 
> wrote:
> >
> > I want to release Maven Artifact Plugin soon, version 0.1
> >
> > I did a first documentation:
> > https://maven.apache.org/plugins-archives/maven-artifact-plugin-LATEST/
> >
> > review, feedback, PRs welcome
> >
> >
> > Regards,
> >
> > Hervé
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: releasing maven-artifact-plugin

[Slawomir Jaranowski]

I don't remember the discussion.

What do you think about JSR-330 in plugin code?

sob., 16 sty 2021 o 09:37 Hervé BOUTEMY  napisał(a):

> my strategy in this plugin was to use maven-shared-utils, of course when
> no
> API exists in JDK
> If I did it wrong in some cases, don't hesitate to provide a PR
> And if there is a newer version of JDK that provides APIs to replace maven-
> shared-utils, we should document it in maven-shared-utils, and that would
> finally give us some little reason to upgrade JDK prerequisite (when most
> of
> maven-shared-utils APIs can be replaced)
>
> I remember many discussions on this, I don't remember precisely if there
> was a
> consensus, I admit I just got the option that I personally  found the most
> adapted to a Maven plugin
>
> Le vendredi 15 janvier 2021, 12:57:01 CET Elliotte Rusty Harold a écrit :
> > Where possible I'd try to replace plexus utils such as StringUtils and
> > FileUtils with better maintained JDK or Apache commons alternatives.
> >
> > On Thu, Jan 14, 2021 at 7:10 PM Hervé BOUTEMY 
> wrote:
> > > I want to release Maven Artifact Plugin soon, version 0.1
> > >
> > > I did a first documentation:
> > >
> https://maven.apache.org/plugins-archives/maven-artifact-plugin-LATEST/
> > >
> > > review, feedback, PRs welcome
> > >
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Logging api in plugins

[Slawomir Jaranowski]

Hi,

For developers  logging api in plugin will can be misunderstood, we don't
have information that https://maven.apache.org/maven-logging.html is only
for maven core.

I think we should put information that plugins should only use
org.apache.maven.plugin.logging.Log and why, maybe at page:
https://maven.apache.org/developers/mojo-api-specification.html or
https://maven.apache.org/plugin-developers/common-bugs.html

Looking on org.apache.maven.plugin.logging.Log the Log has missing some
features like massage formatting to avoid string concatenation - do you
have a plan to extend it?


-- 
Sławomir Jaranowski

Loging api in JSR-330 component

[Slawomir Jaranowski]

Hi,

We can use the JSR-330 component for developing maven plugins -
https://maven.apache.org/maven-jsr330.html

There is not clear  how to access logging api from JSR-330 component. As I
found out last time, maven plugins should not directly use slf4j-api, so
what is recommended in this case.

-- 
Sławomir Jaranowski

Re: Loging api in JSR-330 component

[Slawomir Jaranowski]

It is not only an extension case.

For example I can write Mojo like:

@Mojo(name = "example")
public class ExampleMojo extends AbstractMojo {

@Inject
private MyService myService;

@Override
public void execute() {
}
}

and

@Named
public class MyService {

@Inject
private Logger??? logger;
}

So the question is what logger we should use in the component?

Another case is that components can be Singleton and their instance will be
created once.


pt., 22 sty 2021 o 12:36 Romain Manni-Bucau 
napisał(a):

> Do it means if we represent our classloading structure, all loaders on top
> of mojo use slf4j and others our maven abstraction.
> Sounds ok to me except for extensions which are not in maven land so
> subject to slf4j api breaking changes and undefined/ambiguous context -
> which is never true for maven code itself since we guarantee and own it.
> Should we promote the abstraction for extensions too?
>
> Le ven. 22 janv. 2021 à 11:41, Robert Scholte  a
> écrit :
>
> > I'm not so sure about this, it probably depends on the context.
> >
> > I think we should assume that JSR330 component are not aware of their
> > context.
> > They should not require a Maven context, hence in such case it makes
> sense
> > to use SLF4J API, while the application selects the logger
> implementation.
> > Think of Maven Extensions. I'd say they should be using the SLF4J API
> > because their context is not bound to 1 plugin.
> >
> > thanks,
> > Robert
> > On 18-1-2021 09:34:01, Romain Manni-Bucau  wrote:
> > Generally you want to propagate the mojo logger to have consistent logs
> but
> > worse case we should promote mojo logging api as injectable at injection
> > points if needed, avoids all the mess you can get in mojo with loggers to
> > respect that rule of dumb IMHO.
> >
> > Le dim. 17 janv. 2021 à 22:48, Slawomir Jaranowski
> > a écrit :
> >
> > > Hi,
> > >
> > > We can use the JSR-330 component for developing maven plugins -
> > > https://maven.apache.org/maven-jsr330.html
> > >
> > > There is not clear how to access logging api from JSR-330 component.
> As I
> > > found out last time, maven plugins should not directly use slf4j-api,
> so
> > > what is recommended in this case.
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>


-- 
Sławomir Jaranowski

Re: ICLA already signed?

[Slawomir Jaranowski]

Not commiters:
https://people.apache.org/unlistedclas.html

Commiters
https://people.apache.org/committer-index.html

wt., 26 sty 2021 o 12:18 Matthieu Brouillard 
napisał(a):

> Hi list,
>
> how can I check if I already have signed an ICLA for Apache.
> I do not remember, back in 2008/9, when we (as Jayasoft organization) gave
> back Ant Ivy to the Apache community how the licensing part was realized.
> Can someone verify using my name 'Matthieu Brouillard' if an ICLA already
> exists in Apache backoffice?
>
> Thanks,
>
> Matthieu
>


-- 
Sławomir Jaranowski

Re: [VOTE] Release Apache Maven Shared Invoker version 3.1.0

[Slawomir Jaranowski]

Tested with maven-invoker-plugin from branch maven-311, with my project
looks ok.

+1

niedz., 7 lut 2021 o 21:43 Sylwester Lachiewicz 
napisał(a):

> +1
>
> need more votes..
>
> sob., 6 lut 2021 o 13:56 Robert Scholte  napisał(a):
> >
> > +1
> > On 4-2-2021 16:40:08, Sylwester Lachiewicz 
> wrote:
> > Hi,
> >
> > We solved 4 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12344858&styleName=Text
> >
> > 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-invoker
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1626/
> >
> https://repository.apache.org/content/repositories/maven-1626/org/apache/maven/shared/maven-invoker/3.1.0/maven-invoker-3.1.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-invoker-3.1.0-source-release.zip sha512:
> >
> 92ba5308f5098fe06c0385980f48de15c06fb7b39f01e3aeec7d89fe4660ae265a7eee093a9783f90ebc0e16265fe87292216019880f18111b2df193ce67133a
> >
> > Staging site:
> > https://maven.apache.org/shared-archives/maven-invoker-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: maven-site-plugin and sisu-inject-plexus

[Slawomir Jaranowski]

Project used class like org.codehaus.plexus.PlexusContainer

We can remove direct dependency because we have transitive dependency
from other artifacts - of course we needn't remove it.

[INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
maven-site-plugin ---
[WARNING] Using Maven 2 dependency tree to get verbose output, which may be
inconsistent with actual Maven 3 resolution
[INFO]
org.apache.maven.plugins:maven-site-plugin:maven-plugin:3.10.0-SNAPSHOT
[INFO] +- org.apache.maven:maven-compat:jar:3.0.5:provided
[INFO] |  \- (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
scope updated from provided; omitted for duplicate)
[INFO] +- org.apache.maven:maven-core:jar:3.0.5:compile
[INFO] |  \- (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
omitted for conflict with 1.4.2)
[INFO] +- org.apache.maven:maven-plugin-api:jar:3.0.5:compile
[INFO] |  \- (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
omitted for duplicate)
[INFO] \- org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile

Another case is that the same classes are placed in two separate artifact,
so class org.codehaus.plexus.PlexusContainer
can be found in *org.sonatype.sisu:sisu-inject-plexus *and
*org.codehaus.plexus:plexus-container-default*

Project has dependency which provide
*org.codehaus.plexus:plexus-container-default*

[INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
maven-site-plugin ---
[WARNING] Using Maven 2 dependency tree to get verbose output, which may be
inconsistent with actual Maven 3 resolution
[INFO]
org.apache.maven.plugins:maven-site-plugin:maven-plugin:3.10.0-SNAPSHOT
[INFO] +- org.apache.maven.doxia:doxia-sink-api:jar:1.9.1:compile
[INFO] |  \- org.apache.maven.doxia:doxia-logging-api:jar:1.9.1:compile
[INFO] | \-
(org.codehaus.plexus:plexus-container-default:jar:1.7.1:compile - omitted
for duplicate)
[INFO] +- org.apache.maven.doxia:doxia-core:jar:1.9.1:compile
[INFO] |  \- org.codehaus.plexus:plexus-container-default:jar:1.7.1:compile
[INFO] +- org.apache.maven.doxia:doxia-site-renderer:jar:1.9.2:compile
[INFO] |  +-
(org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-30:compile -
omitted for conflict with 1.7.1)
[INFO] |  \- org.codehaus.plexus:plexus-velocity:jar:1.2:compile
[INFO] | \-
(org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
- omitted for conflict with 1.7.1)
[INFO] \- org.apache.maven.doxia:doxia-integration-tools:jar:1.9.2:compile
[INFO]\-
(org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile -
omitted for conflict with 1.7.1)


I don't know if it is good when a plugin has the same class
from different dependencies and which one will be used in runtime.

It is possible that unit tests will use different implementations than
plugin running by maven.

wt., 9 lut 2021 o 16:01 Elliotte Rusty Harold 
napisał(a):

> Seems maven dependency:analyze thinks we need this one. At least it
> doesn't call it out as unused:
>
> [WARNING] Used undeclared dependencies found:
> [WARNING]javax.servlet:javax.servlet-api:jar:3.1.0:compile
> [WARNING] Unused declared dependencies found:
> [WARNING]org.apache.maven.doxia:doxia-core:jar:1.9.1:compile
> [WARNING]org.apache.maven.doxia:doxia-module-xhtml:jar:1.9.1:compile
> [WARNING]org.apache.maven.doxia:doxia-module-xhtml5:jar:1.9.1:compile
> [WARNING]org.apache.maven.doxia:doxia-module-apt:jar:1.9.1:runtime
> [WARNING]org.apache.maven.doxia:doxia-module-fml:jar:1.9.1:runtime
> [WARNING]org.apache.maven.doxia:doxia-module-markdown:jar:1.9.1:runtime
> [WARNING]
> org.apache.maven.doxia:doxia-module-confluence:jar:1.9.1:runtime
> [WARNING]
> org.apache.maven.doxia:doxia-module-docbook-simple:jar:1.9.1:runtime
> [WARNING]org.apache.maven.doxia:doxia-module-twiki:jar:1.9.1:runtime
> [WARNING]org.apache.maven.wagon:wagon-webdav-jackrabbit:jar:3.3.1:test
> [WARNING]org.eclipse.jetty:jetty-client:jar:9.2.29.v20191105:test
> [WARNING]org.slf4j:slf4j-simple:jar:1.5.3:test
> [WARNING]org.slf4j:jcl-over-slf4j:jar:1.6.1:test
>
> On Tue, Feb 9, 2021 at 2:58 PM Elliotte Rusty Harold 
> wrote:
> >
> > What does maven dependency:analyze say?
> >
> > On Tue, Feb 9, 2021 at 2:25 PM Emmanuel Bourg  wrote:
> > >
> > > Hi,
> > >
> > > maven-site-plugin has a dependency on sisu-inject-plexus [1] but it
> > > doesn't seem to be used. The project still builds and the tests pass
> > > without it.
> > >
> > > Is it safe to assume it can be removed?
> > >
> > > Emmanuel Bourg
> > >
> > > [1]
> > >
> https://github.com/apache/maven-site-plugin/blob/maven-site-plugin-3.9.1/pom.xml#L284
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -

Re: [VOTE] Release Apache Maven Invoker Plugin version 3.2.2

[Slawomir Jaranowski]

+1

Tested with java 1.8, 11, 15 on MacOS, maven 3.6.3

New options *streamLogsOnFailures* and *parallelThreads* set to *1C* work
as expected.

niedz., 14 lut 2021 o 01:40 Sylwester Lachiewicz 
napisał(a):

> Hi,
>
> We solved 17 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317525&version=12346157&styleName=Text
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MINVOKER
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1628/
>
> https://repository.apache.org/content/repositories/maven-1628/org/apache/maven/plugins/maven-invoker-plugin/3.2.2/maven-invoker-plugin-3.2.2-source-release.zip
>
> Source release checksum(s):
> maven-invoker-plugin-3.2.2-source-release.zip sha512:
>
> 798ece4f7f83df0a4faf66d93bd65c63d7df0ee71911345ad51fbec955fa15d2f3bb473c1c130f85dea7919aa551820b1c8ae3ea871a11256c3f665e57680b4a
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-invoker-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: Doxia 1.10 and maven-site-plugin 3.10

[Slawomir Jaranowski]

Hi,
I have run test locally:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
OS name: "mac os x", version: "10.15.7", arch: "x86_64", family: "mac"

and
 - Java version: 1.8.0_282, vendor: AdoptOpenJDK  - PASS

- Java version: 11.0.9, vendor: Oracle Corporation
[ERROR] The following builds failed:
[ERROR] *  MSITE-665/pom.xml
[ERROR] *  MSITE-512/pom.xml
[ERROR] *  MSITE-506/pom.xml
[ERROR] *  MSITE-497/pom.xml
[ERROR] *  MSITE-484/pom.xml

- Java version: 15.0.1, vendor: N/A

[ERROR] The following builds failed:
[ERROR] *  MSITE-665/pom.xml
[ERROR] *  MSITE-512/pom.xml
[ERROR] *  MSITE-506/pom.xml
[ERROR] *  MSITE-497/pom.xml
[ERROR] *  MSITE-484/pom.xml

As I know - produced files during GitHub Actions are not available for
anyone.

We can use artifacts to share build result or use new option of
maven-invoker-plugin - streamLogsOnFailures [1]

[1]
https://maven.apache.org/plugins/maven-invoker-plugin/examples/logs-for-failed-tests.html


pon., 1 mar 2021 o 08:50 Maarten Mulders  napisał(a):

> I happen to have a MacBook and I can confirm the failures - they also
> happen on my machine with Java 11.
>
> Unfortunately I don't have much time on my hands right now to
> investigate, but I'd be happy to share the log files if somebody else
> needs them.
>
>  From what I've seen, three seem to be caused by a NullPointerException
> in the Maven Javadoc Plugin (MSITE-497, MSITE-506 and MSITE-665). The
> Maven Site Plugin uses version 3.0.0-M1 so maybe a quick check could
> involve upgrading that to see if those issues are solved.
>
> Thanks,
>
> Maarten
>
>
> On March 1st, 2021 at 00:33, Elliotte Rusty Harold wrote:
> > I don't know that either. Github tends to be configured so unless
> > you're a repo maintainer you can't see who's a repo maintainer. Not my
> > favorite github misfeature.
> >
> > On Sun, Feb 28, 2021 at 11:07 PM Bertrand Martin
> >  wrote:
> >>
> >> Hi Elliotte,
> >>
> >> The problem is that nobody is able to tell how these builds are
> failing: no error messages, no logs, nothing.
> >>
> >> Who has access to GitHub' Actions logs for maven-site-plugin?
> >>
> >> Bertrand Martin
> >> www.sentrysoftware.com
> >>
> >> -Original Message-
> >> From: Elliotte Rusty Harold 
> >> Sent: Sunday, February 28, 2021 23:26
> >> To: Maven Developers List 
> >> Subject: Re: Doxia 1.10 and maven-site-plugin 3.10
> >>
> >> At least six of the maven-st-plugin CI jobs seem broken at head,
> essentially all the Mac OS builds after JDK 8. Fixing these is the first
> step before we could safely consider a release.
> >>
> >> On Sun, Feb 28, 2021 at 6:38 PM Bertrand Martin <
> bertr...@sentrysoftware.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Is there a release planned for Doxia 1.10 and maven-site-plugin 3.10?
> >>>
> >>> We need it to leverage the new fenced code block, properly exposing
> the language:
> >>> ```java
> >>> System.out.println( "Hello, World!" ); ```
> >>>
> >>> Thank you!
> >>>
> >>> Bertrand Martin
> >>> www.sentrysoftware.com
> >>>
> >>>
> >>
> >>
> >> --
> >> Elliotte Rusty Harold
> >> elh...@ibiblio.org
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
> additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: testing pgpverify-maven-plugin

[Slawomir Jaranowski]

Hi Hervé

Thanks for good words about my project.

1. There is already a request for the feature of automatically generating
keys map file [2]
The keys map file format is described with examples at project page [3]
The keys map is similar to java properties with exception about ':'
(colon), in java properties colon separate key and value. Of course every
idea is welcome.


2.  For multi-module maven projects we have to challenge how to share one
resource with all project modules.
I know some ways:
- external project with resources
- special module in project, but in this case we must refactor project
structure like in IT test sigOkKeysMapMultiModule [4]
- we can also use assembly plugin to attach special artifact to project
root module like I did in project pgp-keys-map [5]

[2] https://github.com/s4u/pgpverify-maven-plugin/issues/84
[3] https://www.simplify4u.org/pgpverify-maven-plugin/keysmap-format.html
[4]
https://github.com/s4u/pgpverify-maven-plugin/tree/master/src/it/sigOkKeysMapMultiModule
[5] https://github.com/s4u/pgp-keys-map

śr., 10 mar 2021 o 21:48 Hervé BOUTEMY  napisał(a):

> Hi Slawomir,
>
> I just tested pgpverify-maven-plugin on maven-artifact-plugin [1].
> I was successful, really nice.
>
> From that experience, I have some questions on the keys map file:
>
> 1. is there a way to ease the creation of the file content?
> currently, I had to copy paste output, check that I trusted the keys
> (which of course can't be automated), and then had to do a lot of
> modifications to match the properties file format. Would it be possible to
> have a default output that matches properties format, so reviewing and
> injecting content would be easier?
>
> 2. I also tested on a multi-module project (like maven-archetype-bundles),
> and I could not configure the plugin to use one single keys map for the
> whole build: creating 1 file per module is really cumbersome.
> Did you imagine a way to share the same map file in a multi-module build?
>
> This plugin is really nice, the hard part is about writing keys map file...
>
> Regards,
>
> Hervé
>
>
> [1]
> https://github.com/apache/maven-artifact-plugin/commit/41df63adaf91f0c481fff9347abb2dbeb7022f5b
>
>
>

-- 
Sławomir Jaranowski

Re: Backporting 3.8.1 security fix in 3.6.x

[Slawomir Jaranowski]

>From a maven user, plugin developer perspective it is not important for me
if I upgrade maven to 3.6.x or 3.8.x if I have changelog for it.

More important is to know some of the release and support policies.
In other words, to know which version can contain new features, which only
bug fix, security updates and which version is not maintained any more.

I see that without such a policy you don't agree with yourself.
As many ideas as many people  for a version number ...

pt., 2 kwi 2021 o 12:44 Robert Scholte  napisał(a):

> If you're speaking on behalf of others, please let those people explain
> their situation. So far I've only heard you, that's not enough for me to
> support a backport.
>
> Robert
> On 2-4-2021 11:01:12, Romain Manni-Bucau  wrote:
> Le ven. 2 avr. 2021 à 10:44, Robert Scholte a écrit :
>
> > I think there are a couple of issues here:
> > - To me this shouldn't be done with a PR, but as a set of cherry-picks to
> > keep to original commit history and references.
> >
>
> Was the way it was created, PR is just to share it there.
>
>
> > - Branch 3.6.x contains commits that are unrelated to the 3.8.x branch
> >
>
> Not sure what you have in mind behind that except that if so 3.8 can need
> to be updated - but not sure I got it right.
>
>
> > - I still don't see the need for this backport. I really doubt that
> people
> > would pick the possible 3.6.4 over 3.8.1 if they want to protect
> themselves
> > and do the configuration themselves. As you keep pushing for such a
> > release, please let the community comment (including why they need it and
> > why using 3.8.1 is not an option) on MNG-7134[1] first.
> >
>
> I don't doubt about it, I have some contacts needing to stick to 3.6 + be
> CVE free at the same time for at least the coming 2 years, just trying to
> make these users happy.
> I already explained in previous posts why it was saner to do it on maven
> side (to avoid forks mainly which can lead to different "fixes" and
> behaviors - already saw it by the past + keep the common maven tooling as
> sdkman and ides plain support).
>
>
> >
> > Robert
> >
> > [1] https://issues.apache.org/jira/browse/MNG-7134
> > On 2-4-2021 09:21:04, Romain Manni-Bucau wrote:
> > Hi all,
> >
> > As explained in another thread, I created
> > https://github.com/apache/maven/pull/462 to backport the security fix on
> > 3.8 in 3.6.x.
> > Anyone able to review it?
> > Only change is that the default configuration is not there but it can be
> > enabled - idea is to document it instead of breaking by default.
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > | Old Blog
> > | Github |
> > LinkedIn | Book
> >
> >
>


-- 
Sławomir Jaranowski

codehaus-plexus - developers ...

[Slawomir Jaranowski]

Hi, I'm looking into code of plexus-resource, I use this component in my
application and I want to discuss some of the propositions before coding ...

The problem is that much information in codehaus-plexus [1] projects is
outdated like links and mailing lists addresses.

I ask here about how to contact codehaus-plexus developers because many
people from the maven team are also members of it [2].

[1] https://github.com/codehaus-plexus
[2] https://codehaus-plexus.github.io/team-list.html

-- 
Sławomir Jaranowski

Re: codehaus-plexus - developers ...

[Slawomir Jaranowski]

great idea - can you also enable "discussion" for other plexus projects.

So I started my first discussion on plexus-resource.

We will see how the reaction will be ... of course it will depend on how
many people are watching project.

sob., 17 kwi 2021 o 04:54 Olivier Lamy  napisał(a):

> most of plexus-* are maven dev folks.
> You can ask in the discussions tab maybe? I just setup it
> https://github.com/codehaus-plexus/plexus-resources/discussions
>
> but I saw you PR regarding gh actions feel free to start a thread in the
> discussions tab?
>
> On Sat, 17 Apr 2021 at 01:22, Slawomir Jaranowski 
> wrote:
>
> > Hi, I'm looking into code of plexus-resource, I use this component in my
> > application and I want to discuss some of the propositions before coding
> > ...
> >
> > The problem is that much information in codehaus-plexus [1] projects is
> > outdated like links and mailing lists addresses.
> >
> > I ask here about how to contact codehaus-plexus developers because many
> > people from the maven team are also members of it [2].
> >
> > [1] https://github.com/codehaus-plexus
> > [2] https://codehaus-plexus.github.io/team-list.html
> >
> > --
> > Sławomir Jaranowski
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>


-- 
Sławomir Jaranowski

Re: maven-site-plugin and sisu-inject-plexus

[Slawomir Jaranowski]

So maybe it is time to start removing unnecessary code ...

There is needed clear decision what component should be removed, what
replaces it.
In order to everybody know direction and target goal.

Eg. plexus-container-default - should be removed at all
org.codehaus.plexus.logging -> sl4j .. and so on



sob., 17 kwi 2021 o 14:02 Elliotte Rusty Harold 
napisał(a):

> plexus-container-default is used by Maven shared utils and thus by
> almost everything in Maven. Not that this is a good thing, but c'est
> la vie.
>
> There's a lot of over-engineered, unnecessary code splitting between
> Maven, Aether, Plexus, and Modello. Maven's a pretty classic example
> of why developers should resist the urge to build yet another
> framework. Code maintenance and development would be far simpler and
> less expensive today if 20 years ago the Maven developers had simply
> written a build tool without trying to extend it to a general purpose
> framework. YAGNI.
>
> On Tue, Feb 9, 2021 at 4:39 PM Tamás Cservenák 
> wrote:
> >
> > Howdy,
> >
> > my 5 cents:
> >
> > Something is stale, very stale in there, as plexus-container-default was
> > abandoned about 10 (maybe 12?) years ago, and sisu "shim"
> > (sisu-inject-plexus) was created as the direct replacement (as functional
> > and as API).
> >
> > If your project has Plexus "the old container" (plexus-container-default)
> > pulled in, it means something on project or it's transitive dependency
> hull
> > lags for about 10+ years if not more :)
> >
> > Given Plexus is "maven only" (mostly), it is most probably that some
> > dependency (governed by us, chance is 90%+) pulls it in, that has not
> been
> > touched for quite a long time.
> >
> > Plexus et al is one of the reasons why "maven pulls down the internet",
> > especially as we resolve/download it only to toss it away (drop it).
> >
> > HTH
> > T
> >
> > On Tue, Feb 9, 2021 at 5:13 PM Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > wrote:
> >
> > > Project used class like org.codehaus.plexus.PlexusContainer
> > >
> > > We can remove direct dependency because we have transitive dependency
> > > from other artifacts - of course we needn't remove it.
> > >
> > > [INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
> > > maven-site-plugin ---
> > > [WARNING] Using Maven 2 dependency tree to get verbose output, which
> may be
> > > inconsistent with actual Maven 3 resolution
> > > [INFO]
> > > org.apache.maven.plugins:maven-site-plugin:maven-plugin:3.10.0-SNAPSHOT
> > > [INFO] +- org.apache.maven:maven-compat:jar:3.0.5:provided
> > > [INFO] |  \- (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
> > > scope updated from provided; omitted for duplicate)
> > > [INFO] +- org.apache.maven:maven-core:jar:3.0.5:compile
> > > [INFO] |  \- (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
> > > omitted for conflict with 1.4.2)
> > > [INFO] +- org.apache.maven:maven-plugin-api:jar:3.0.5:compile
> > > [INFO] |  \- (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
> > > omitted for duplicate)
> > > [INFO] \- org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
> > >
> > > Another case is that the same classes are placed in two separate
> artifact,
> > > so class org.codehaus.plexus.PlexusContainer
> > > can be found in *org.sonatype.sisu:sisu-inject-plexus *and
> > > *org.codehaus.plexus:plexus-container-default*
> > >
> > > Project has dependency which provide
> > > *org.codehaus.plexus:plexus-container-default*
> > >
> > > [INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
> > > maven-site-plugin ---
> > > [WARNING] Using Maven 2 dependency tree to get verbose output, which
> may be
> > > inconsistent with actual Maven 3 resolution
> > > [INFO]
> > > org.apache.maven.plugins:maven-site-plugin:maven-plugin:3.10.0-SNAPSHOT
> > > [INFO] +- org.apache.maven.doxia:doxia-sink-api:jar:1.9.1:compile
> > > [INFO] |  \- org.apache.maven.doxia:doxia-logging-api:jar:1.9.1:compile
> > > [INFO] | \-
> > > (org.codehaus.plexus:plexus-container-default:jar:1.7.1:compile -
> omitted
> > > for duplicate)
> > > [INFO] +- org.apache.maven.doxia:doxia-core:jar:1.9.1:compile
> > > [INFO] |  \-
> org.codehaus.plexus:plexus-container-default:jar:1.7.1:compile
> > > [INFO] +- org.apache.maven.doxia:doxia-site-re

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.1.2

[Slawomir Jaranowski]

Hi,

GitHub Actions is recognized as an integration system.

+1 ( not binding )

niedz., 25 kwi 2021 o 21:46 Michael Osipov  napisał(a):

> Hi,
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12349521
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1642/
>
> https://repository.apache.org/content/repositories/maven-1642/org/apache/maven/plugins/maven-project-info-reports-plugin/3.1.2/maven-project-info-reports-plugin-3.1.2-source-release.zip
>
> Source release checksum(s):
> maven-project-info-reports-plugin-3.1.2-source-release.zip
> sha512:
>
> 9cd09f24de9a11530116f1b40c403557d0c9bfdbdca4f05be4db52ec9cdb9a75d1faa1104eae16c0ea7ece90b7c6fe09139f6738a4862ab67a0c57e695f1761f
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: [shade] which java version

[Slawomir Jaranowski]

Hi,

very interesting case but I can't see 1.8 streams in
https://github.com/apache/maven-shade-plugin/tree/master

Can you point where you found it?

By the way, maybe it's time to start switching plugins to 1.8 ...


śr., 21 lip 2021 o 08:09 Romain Manni-Bucau 
napisał(a):

> Hi all,
>
> shade plugin pom defines java version to 7 (1.7) but it uses streams which
> are java 8 only, should javaVersion property be updated?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>


-- 
Sławomir Jaranowski

Re: Feature proposal: Dependency deprecation indicators

[Slawomir Jaranowski]

Hi,

Changing status / metadata of artifacts will break "Release Stability" of
Central Repository
Once artifacts was release should never change ...
https://central.sonatype.org/faq/can-i-change-a-component/

Another case when we don't have source code of an artifact we can do a new
pom with relocation information and release the next version.
In this case I am afraid that the maintainer of the artifact doesn't want
to take care about its or not exist ... so nobody will not use deprecation
possibility for such artifacts ...


czw., 29 lip 2021 o 15:15 Chris Kilding 
napisał(a):

> I think we could begin by working out some constraints for the feature...
>
> First, I think it should be possible to deprecate (or undeprecate) an
> artifact without compiling a new version of it.
>
> This is because:
>
> - In some legacy code situations (e.g. when the code was not checked in to
> VCS), nobody can compile the artifact any more. We would not want this to
> prevent us deprecating the artifact.
> - Deprecation and undeprecation should be quick operations. Compiling and
> releasing new versions can take significant time.
>
> This constraint suggests that a deprecation indicator should be something
> applied *to* an artifact rather than part *of* an artifact. It would lead
> us towards putting the indicator in the repository metadata, not the POM.
>
> A comparison with other systems:
>
> - NPM puts deprecation indicators in repository metadata.
> - Nuget puts deprecation indicators in repository metadata.
> - Cocoapods puts its `deprecated` property in the Podspec (the equivalent
> of the POM). This means you have to compile a new version of a pod just to
> un/deprecate it. I believe it also means that Cocoapods clients must scan
> forward from a Podspec's current dependency versions to find the closest
> future versions that have a `deprecated` marker. I think is the wrong
> approach for the reasons explained above.
>
> Chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Maven 3.8.2 - site parent descriptor without locale

[Slawomir Jaranowski]

Hi,

Maven site parent descriptor is not resolved by maven 3.8.2.

Without changing in project, build on maven 3.8.1, I have in logs:

[INFO] Rendering site with default locale English (en)
[DEBUG] Computing decoration model of
org.simplify4u.plugins:sign-maven-plugin:maven-plugin:0.3.2-SNAPSHOT for
locale en
[DEBUG] Reading site descriptor from .../sign-maven-plugin/src/site/site.xml
[DEBUG] Looking for site descriptor of level 1 parent project:
org.simplify4u:parent:pom:2.13.0
[DEBUG] No site descriptor found for org.simplify4u:parent:pom:2.13.0 for
locale en, trying without locale...
[DEBUG] Reading parent level 1 site descriptor from
.../org/simplify4u/parent/2.13.0/parent-2.13.0-site.xml
[INFO] Rendering content with
org.apache.maven.skins:maven-fluido-skin:jar:1.9 skin.


And with maven 3.8.2

[INFO] Rendering site with default locale English (en)
[DEBUG] Computing decoration model of
org.simplify4u.plugins:sign-maven-plugin:maven-plugin:0.3.2-SNAPSHOT for
locale en
[DEBUG] Reading site descriptor from .../sign-maven-plugin/src/site/site.xml
[DEBUG] Looking for site descriptor of level 1 parent project:
org.simplify4u:parent:pom:2.13.0
[DEBUG] No parent level 1 site descriptor.
[INFO] Rendering content with
org.apache.maven.skins:maven-default-skin:jar:1.3 skin.


Only one difference I see in logs is that in maven 3.8.2 I don't have:
[DEBUG] No site descriptor found for org.simplify4u:parent:pom:2.13.0 for
locale en, trying without locale...


Does anybody confirm this behavior?
What else can I check?


-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Re: Maven 3.8.2 - site parent descriptor without locale

[Slawomir Jaranowski]

I confirm that maven from branch maven-3.8.x-revert-MNG-7170 resolves a
problem with site descriptor.

As I see
https://github.com/apache/maven-doxia-sitetools/blob/62d79df678e4ca9ba01d79efc0a1fef07c0d405d/doxia-integration-tools/src/main/java/org/apache/maven/doxia/tools/DefaultSiteTool.java#L1131

try to check if project is parent from repository or from local file by:

if ( project.getBasedir() == null )

the same as in
https://github.com/jdcasey/directory-maven-plugin/blob/cd432cfab79dc9ea0801980e9e6a44729c4b518d/src/main/java/org/commonjava/maven/plugins/execroot/HighestBasedirGoal.java#L80

I don't know where the problem is ... maybe plugins detect parent pom in
the wrong way ...
It also can have impact on another plugins


pon., 16 sie 2021 o 18:14 Michael Osipov  napisał(a):

> Am 2021-08-16 um 16:51 schrieb Michael Osipov:
> > Am 2021-08-16 um 13:26 schrieb Slawomir Jaranowski:
> >> Hi,
> >>
> >> Maven site parent descriptor is not resolved by maven 3.8.2.
> >>
> >> Without changing in project, build on maven 3.8.1, I have in logs:
> >>
> >> [INFO] Rendering site with default locale English (en)
> >> [DEBUG] Computing decoration model of
> >> org.simplify4u.plugins:sign-maven-plugin:maven-plugin:0.3.2-SNAPSHOT for
> >> locale en
> >> [DEBUG] Reading site descriptor from
> >> .../sign-maven-plugin/src/site/site.xml
> >> [DEBUG] Looking for site descriptor of level 1 parent project:
> >> org.simplify4u:parent:pom:2.13.0
> >> [DEBUG] No site descriptor found for org.simplify4u:parent:pom:2.13.0
> for
> >> locale en, trying without locale...
> >> [DEBUG] Reading parent level 1 site descriptor from
> >> .../org/simplify4u/parent/2.13.0/parent-2.13.0-site.xml
> >> [INFO] Rendering content with
> >> org.apache.maven.skins:maven-fluido-skin:jar:1.9 skin.
> >>
> >>
> >> And with maven 3.8.2
> >>
> >> [INFO] Rendering site with default locale English (en)
> >> [DEBUG] Computing decoration model of
> >> org.simplify4u.plugins:sign-maven-plugin:maven-plugin:0.3.2-SNAPSHOT for
> >> locale en
> >> [DEBUG] Reading site descriptor from
> >> .../sign-maven-plugin/src/site/site.xml
> >> [DEBUG] Looking for site descriptor of level 1 parent project:
> >> org.simplify4u:parent:pom:2.13.0
> >> [DEBUG] No parent level 1 site descriptor.
> >> [INFO] Rendering content with
> >> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> >>
> >>
> >> Only one difference I see in logs is that in maven 3.8.2 I don't have:
> >> [DEBUG] No site descriptor found for org.simplify4u:parent:pom:2.13.0
> for
> >> locale en, trying without locale...
> >>
> >>
> >> Does anybody confirm this behavior?
> >> What else can I check?
> >
> > Hi Slawek,
> >
> > the above is an ugliness existing in Doxia for a long time (MSITE-639).
> > I don't understand how it is related to this new release. I will try to
> > build the site of the project and get back to you.
> >
> > If you think you could bisect down to the issue that would be awesome!
>
> Found it:
> > mosipov@mikaw10 MINGW64 /d/Entwicklung/Projekte/maven
> ((5a8997312...)|BISECTING)
> > $ git bisect bad
> > 5a8997312680a4b9c69a129801524691bc546c08 is the first bad commit
> > commit 5a8997312680a4b9c69a129801524691bc546c08
> > Author: Mickael Istria 
> > Date:   Fri Jun 11 11:55:09 2021 +0200
> >
> > [MNG-7170] Allow to associate pomFile/${basedir} with
> DefaultProjectBuilder.build(ModelSource, ...)
> >
> > Actually a subset backport of MNG-5669
> (5cdb8332f99a36e5a1da202da43e3c7dfbb49322)
> >
> > Also-By: rfscholte 
> >
> > This closes #478
> >
> > :04 04 e34147123e781aeba66f4d1ae25519a56b1fa7de
> afaae4ffe359ab5a6d9fee8b3e3574166ae82675 M  maven-core
> > :04 04 4efdf35d4520af3b98d14f789a8369968afab1b8
> 835f107ac922ca4099277f7c9e9cefb4ca3550d3 M  maven-model-builder
>
>
> Try branch maven-3.8.x-revert-MNG-7170 or
>
> http://home.apache.org/~michaelo/apache-maven-3.8.x-revert-MNG-7170-bin.tar.gz
> .
>
> We need now to engage with Mickael Istria to figure to whether the
> appraoch is incorrect or really a bug in Doxia. A similar finding is here:
> https://github.com/eclipse-ee4j/eclipselink/issues/1242
>
> Please report a JIRA issue.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: Maven 3.8.2 - site parent descriptor without locale

[Slawomir Jaranowski]

and issue https://issues.apache.org/jira/browse/MNG-7215

pon., 16 sie 2021 o 20:41 Slawomir Jaranowski 
napisał(a):

> I confirm that maven from branch maven-3.8.x-revert-MNG-7170 resolves a
> problem with site descriptor.
>
> As I see
> https://github.com/apache/maven-doxia-sitetools/blob/62d79df678e4ca9ba01d79efc0a1fef07c0d405d/doxia-integration-tools/src/main/java/org/apache/maven/doxia/tools/DefaultSiteTool.java#L1131
>
> try to check if project is parent from repository or from local file by:
>
> if ( project.getBasedir() == null )
>
> the same as in
> https://github.com/jdcasey/directory-maven-plugin/blob/cd432cfab79dc9ea0801980e9e6a44729c4b518d/src/main/java/org/commonjava/maven/plugins/execroot/HighestBasedirGoal.java#L80
>
> I don't know where the problem is ... maybe plugins detect parent pom in
> the wrong way ...
> It also can have impact on another plugins
>
>
> pon., 16 sie 2021 o 18:14 Michael Osipov  napisał(a):
>
>> Am 2021-08-16 um 16:51 schrieb Michael Osipov:
>> > Am 2021-08-16 um 13:26 schrieb Slawomir Jaranowski:
>> >> Hi,
>> >>
>> >> Maven site parent descriptor is not resolved by maven 3.8.2.
>> >>
>> >> Without changing in project, build on maven 3.8.1, I have in logs:
>> >>
>> >> [INFO] Rendering site with default locale English (en)
>> >> [DEBUG] Computing decoration model of
>> >> org.simplify4u.plugins:sign-maven-plugin:maven-plugin:0.3.2-SNAPSHOT
>> for
>> >> locale en
>> >> [DEBUG] Reading site descriptor from
>> >> .../sign-maven-plugin/src/site/site.xml
>> >> [DEBUG] Looking for site descriptor of level 1 parent project:
>> >> org.simplify4u:parent:pom:2.13.0
>> >> [DEBUG] No site descriptor found for org.simplify4u:parent:pom:2.13.0
>> for
>> >> locale en, trying without locale...
>> >> [DEBUG] Reading parent level 1 site descriptor from
>> >> .../org/simplify4u/parent/2.13.0/parent-2.13.0-site.xml
>> >> [INFO] Rendering content with
>> >> org.apache.maven.skins:maven-fluido-skin:jar:1.9 skin.
>> >>
>> >>
>> >> And with maven 3.8.2
>> >>
>> >> [INFO] Rendering site with default locale English (en)
>> >> [DEBUG] Computing decoration model of
>> >> org.simplify4u.plugins:sign-maven-plugin:maven-plugin:0.3.2-SNAPSHOT
>> for
>> >> locale en
>> >> [DEBUG] Reading site descriptor from
>> >> .../sign-maven-plugin/src/site/site.xml
>> >> [DEBUG] Looking for site descriptor of level 1 parent project:
>> >> org.simplify4u:parent:pom:2.13.0
>> >> [DEBUG] No parent level 1 site descriptor.
>> >> [INFO] Rendering content with
>> >> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
>> >>
>> >>
>> >> Only one difference I see in logs is that in maven 3.8.2 I don't have:
>> >> [DEBUG] No site descriptor found for org.simplify4u:parent:pom:2.13.0
>> for
>> >> locale en, trying without locale...
>> >>
>> >>
>> >> Does anybody confirm this behavior?
>> >> What else can I check?
>> >
>> > Hi Slawek,
>> >
>> > the above is an ugliness existing in Doxia for a long time (MSITE-639).
>> > I don't understand how it is related to this new release. I will try to
>> > build the site of the project and get back to you.
>> >
>> > If you think you could bisect down to the issue that would be awesome!
>>
>> Found it:
>> > mosipov@mikaw10 MINGW64 /d/Entwicklung/Projekte/maven
>> ((5a8997312...)|BISECTING)
>> > $ git bisect bad
>> > 5a8997312680a4b9c69a129801524691bc546c08 is the first bad commit
>> > commit 5a8997312680a4b9c69a129801524691bc546c08
>> > Author: Mickael Istria 
>> > Date:   Fri Jun 11 11:55:09 2021 +0200
>> >
>> > [MNG-7170] Allow to associate pomFile/${basedir} with
>> DefaultProjectBuilder.build(ModelSource, ...)
>> >
>> > Actually a subset backport of MNG-5669
>> (5cdb8332f99a36e5a1da202da43e3c7dfbb49322)
>> >
>> > Also-By: rfscholte 
>> >
>> > This closes #478
>> >
>> > :04 04 e34147123e781aeba66f4d1ae25519a56b1fa7de
>> afaae4ffe359ab5a6d9fee8b3e3574166ae82675 M  maven-core
>> > :04 04 4efdf35d4520af3b98d14f789a8369968afab1b8
>> 835f107ac922ca4099277f7c9e9cefb4ca3550d3 M  maven-model-builder
>>
>>
>> Try branch maven-3.8.x-revert-MNG-7170 or
>>
>> http://home.apache.org/~michaelo/apache-maven-3.8.x-revert-MNG-7170-bin.tar.gz
>> .
>>
>> We need now to engage with Mickael Istria to figure to whether the
>> appraoch is incorrect or really a bug in Doxia. A similar finding is here:
>> https://github.com/eclipse-ee4j/eclipselink/issues/1242
>>
>> Please report a JIRA issue.
>>
>> Michael
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
> --
> Sławomir Jaranowski
>


-- 
Sławomir Jaranowski

Re: [VOTE] Release Apache Maven version 3.8.2

[Slawomir Jaranowski]

Hi,

I think that https://issues.apache.org/jira/browse/MNG-7215 is also
important, it breaks the build maven site for projects ...

Please don't extend the manual process ... nowadays we have everything to
do automatically, every (or most of)  plugin has IT tests ... so we need
just to run its


niedz., 22 sie 2021 o 23:48 Falko Modler  napisał(a):

> Unfortunately, this commit introduced another, more severe regression:
>
> https://issues.apache.org/jira/browse/MNG-7220
>
> I was able to fix it already: https://github.com/apache/maven/pull/527
>
> IMO, this warrants a timely 3.8.3 release. WDYT?
>
> PS: If there are no automated tests of the standard Maven plugins such
> as javadoc-plugin before a Maven release,
> maybe release votes should come with a checklist of plugins that need to
> pass their tests with that new release, before it's actually published?
>
> Cheers,
>
> Falko
>
> Am 11.08.2021 um 06:03 schrieb Olivier Lamy:
> > did the bisect and found this
> >
> > *➜  **maven-core* *git:(**42c99b45e**)* git bisect good
> >
> > 76d5f0d942f52650d3bdf775b6af42d23d69066b is the first bad commit
> >
> > commit 76d5f0d942f52650d3bdf775b6af42d23d69066b
> >
> > Author: Falko Modler 
> >
> > Date:   Fri Jun 25 19:28:40 2021 +0200
> >
> >
> >  [MNG-6843] Parallel build fails due to missing JAR artifacts in
> > compilePath
> >
> >
> >
> >  Signed-off-by: rfscholte 
> >
> >  (cherry picked from commit 73e00ed85df84ba0c557dd020740812b2453f2d3)
> >
> >
> >
> >  This closes #482
> >
> >
> >   .../org/apache/maven/project/MavenProject.java | 67 
> > --
> >
> >   1 file changed, 36 insertions(+), 31 deletions(-)
> >
> >
> >
> > There is a simple fix in the mentioned plugin (and btw the fix is needed
> :)
> > )
> > So if a mojo creates a new Thread and tries to get some values from
> > MavenProject the result might change (because of this new threadLocal
> > field).
> >
> > not changing my vote but it's still a change and possible failure
> >
> >
> > On Wed, 11 Aug 2021 at 11:29, Olivier Lamy  wrote:
> >
> >> interesting this code change in the plugin fix the issue with the staged
> >> 3.8.2
> >>
> >>
> https://github.com/jetty-project/h2spec-maven-plugin/commit/a752521d12c59347a0995d01160332af28e3f092
> >>
> >> looking at commits log not sure if we touched something related to
> thread
> >> context classloader?
> >>
> >> On Wed, 11 Aug 2021 at 09:11, Olivier Lamy  wrote:
> >>
> >>> found some breaking change.
> >>> this plugin is not working anymore:
> >>> https://github.com/jetty-project/h2spec-maven-plugin
> >>> mvn verify
> >>> got ClassNotFoundException
> >>>
> >>> On Wed, 11 Aug 2021 at 03:50, Falko Modler  wrote:
> >>>
>  I checked it briefly with Quarkus (almost 1k modules) and I couldn't
>  really see a difference.
> 
>  Cheers,
>  Falko
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>  For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> >>> --
> >>> Olivier Lamy
> >>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>
> >>
> >> --
> >> Olivier Lamy
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Testing staged release

[Slawomir Jaranowski]

Hi,

It looks like "Guide to Testing Staged Releases" [1] is something outdated
and not consistent with "Performing a Maven Project Release" [2]

In [1] we have example with repository location like 
http://people.apache.org/~dfabulich/stage-repo
but in [2] we heve staging repo as
https://repository.apache.org/content/repositories/maven-[YOUR REPOSITORY
ID]/

[2] point to [1] so both pages should be consistent.

I also found that Apache Repository [3] contains two groups: Maven Staging
Group [4] and Staging [5].
Both of this group contains new staged items like last Apache Maven Javadoc
Plugin version 3.3.1

So I prepare config with additional profiles pointing to one of this staged
repository and I can perform tests for the new plugin.
It will be easier to have one configuration for all stages testing -
without changing stage id.

When I use properties for version in project and have stage profile I can
simply run like

   mvn -P apache-stage -Dmaven-javadoc-plugin.version=3.3.1 javadoc:javadoc

without additional configuration.

Now questions:
 1. Can I use one of those repositories for testing staged releases (which
is preferred)?
 2. What is different in contend in Maven Staging Group [4] and Staging [5]?
 3. Are staged repository groups [4], [5]  cleaned - if yes when?

[1] https://maven.apache.org/guides/development/guide-testing-releases.html
[2]
https://maven.apache.org/developers/release/maven-project-release-procedure.html
[3] https://repository.apache.org/#view-repositories
[4] https://repository.apache.org/content/groups/maven-staging-group/
[5] https://repository.apache.org/content/groups/staging/

-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Re: Testing staged release

[Slawomir Jaranowski]

Hi,

Does anybody from infrastructure team can share knowledge about
configurations for:

https://repository.apache.org/content/groups/maven-staging-group/
https://repository.apache.org/content/groups/staging/

and confirm that, it can be used for testing staged maven plugins

Maybe I should ask on some different  mailing list, create ticket ...


niedz., 5 wrz 2021 o 18:21 Hervé BOUTEMY  napisał(a):

> good catch
>
> I did a first pass at using some of your points: don't hesitate to prpose
> other
> improvements
>
> Notice: on your questions, I don't really have any answer, these should
> probably be asked to infra who is managing the repository manager
> configuration
>
> Regards,
>
> Hervé
>
> Le samedi 4 septembre 2021, 16:40:44 CEST Slawomir Jaranowski a écrit :
> > Hi,
> >
> > It looks like "Guide to Testing Staged Releases" [1] is something
> outdated
> > and not consistent with "Performing a Maven Project Release" [2]
> >
> > In [1] we have example with repository location like 
> > http://people.apache.org/~dfabulich/stage-repo
> > but in [2] we heve staging repo as
> > https://repository.apache.org/content/repositories/maven-[YOUR
> REPOSITORY
> > ID]/
> >
> > [2] point to [1] so both pages should be consistent.
> >
> > I also found that Apache Repository [3] contains two groups: Maven
> Staging
> > Group [4] and Staging [5].
> > Both of this group contains new staged items like last Apache Maven
> Javadoc
> > Plugin version 3.3.1
> >
> > So I prepare config with additional profiles pointing to one of this
> staged
> > repository and I can perform tests for the new plugin.
> > It will be easier to have one configuration for all stages testing -
> > without changing stage id.
> >
> > When I use properties for version in project and have stage profile I can
> > simply run like
> >
> >mvn -P apache-stage -Dmaven-javadoc-plugin.version=3.3.1
> javadoc:javadoc
> >
> > without additional configuration.
> >
> > Now questions:
> >  1. Can I use one of those repositories for testing staged releases
> (which
> > is preferred)?
> >  2. What is different in contend in Maven Staging Group [4] and Staging
> [5]?
> > 3. Are staged repository groups [4], [5]  cleaned - if yes when?
> >
> > [1]
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > [2]
> >
> https://maven.apache.org/developers/release/maven-project-release-procedure
> .
> > html [3] https://repository.apache.org/#view-repositories
> > [4] https://repository.apache.org/content/groups/maven-staging-group/
> > [5] https://repository.apache.org/content/groups/staging/
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

GitHub Actions on Maven projects

[Slawomir Jaranowski]

Hi,

Many of maven, maven plugins projects have GutHub Action build configured.
It is very useful for contributors - we can verify PR early, especially on
many different operating systems - which can't be done locally, or is more
complicated.

Most of workflows have define build matrix like:

  matrix:
os: [ubuntu-latest, windows-latest, macOS-latest]
java: [8, 11, 16, 17-ea]

But some have:

  matrix:
   os: [ubuntu-latest, windows-latest, macOS-latest]
   java: [8, 11, 16, 17-ea]
   jdk: [adopt, zulu]


Question:

Are there some guidelines about how GitHub Action should be configured?
If no guidelines, which build matrix will be the most expected?

 I ask in conjunction to https://issues.apache.org/jira/browse/MDEP-768


-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Maven Code Style and imports layouts

[Slawomir Jaranowski]

Hi,

We have described many rules about code style on Maven Code Style And Code
Conventions [1].

One item missing for me is how java imports should be ordered and groped.
I can setup it in IDE and it is very useful to use code formatting with
tools.
I think that all propositions in this case will be ok - the most important
is to have one standard.
At the end we can even use checkstyle to verify it ... [2]

So first proposition:

- import javax.*
- import java.*

- blank line

- all other imports

- blank line

- import static all other imports


[1] https://maven.apache.org/developers/conventions/code.html
[2] https://checkstyle.sourceforge.io/config_imports.html#ImportOrder

-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Re: GitHub Actions on Maven projects

[Slawomir Jaranowski]

Hi,

Thanks for your response. I know that jenkins build is the master for
Apache projects,
but most of the projects have some GA workflows configuration which many
times are different.
This situation generates more work for maintainer.

Thanks to composite actions [1] we can create one global action which has
defined all required steps and one action for providing configurations
values like jkd list,
both of these actions can be in one repository.

In the rest of the project we can use those global actions, so when next
time we want to change, e.g. jdk list (it changes every 6 month ;-) ) we
only change it in one place.
This approach can make less maintenance work in maven projects.

If you are interested let me know, I can prepare some spikes for you and
provide more details.


[1]
https://docs.github.com/en/actions/creating-actions/creating-a-composite-action


sob., 18 wrz 2021 o 08:27 Martin Kanters 
napisał(a):

> Hi Slawomir, sorry for the late reply.
>
> Great that you see the value of the workflows.
> I don't think there are any strict rules or guidelines around how the
> workflow should be configured exactly, but I think it makes sense to have
> them in place.
> Perhaps we should also look into a way of reusing workflows in all or most
> of the projects (maven-core is a bit different).
>
> Just wanted to mention that for the Apache team the Apache Jenkins server
> is what matters most. GA are helpful for contributors and committers
> working via PRs, but in the end Apache Jenkins has to pass before a merge
> is allowed. Hence, I think we should go for a reasonable workflow
> configuration, it does not have to be more extensive than the Jenkins
> setup. Still, having macOS builds is very useful, Jenkins does not have
> that AFAIK.
>
> Martin
>
>
>
>
> Op za 11 sep. 2021 om 20:43 schreef Slawomir Jaranowski <
> s.jaranow...@gmail.com>:
>
> > Hi,
> >
> > Many of maven, maven plugins projects have GutHub Action build
> configured.
> > It is very useful for contributors - we can verify PR early, especially
> on
> > many different operating systems - which can't be done locally, or is
> more
> > complicated.
> >
> > Most of workflows have define build matrix like:
> >
> >   matrix:
> > os: [ubuntu-latest, windows-latest, macOS-latest]
> > java: [8, 11, 16, 17-ea]
> >
> > But some have:
> >
> >   matrix:
> >os: [ubuntu-latest, windows-latest, macOS-latest]
> >java: [8, 11, 16, 17-ea]
> >jdk: [adopt, zulu]
> >
> >
> > Question:
> >
> > Are there some guidelines about how GitHub Action should be configured?
> > If no guidelines, which build matrix will be the most expected?
> >
> >  I ask in conjunction to https://issues.apache.org/jira/browse/MDEP-768
> >
> >
> > --
> > Sławomir Jaranowski
> >
> > https://twitter.com/SlawekJaran
> > https://github.com/slawekjaranowski
> > https://linkedin.com/in/slawomirjaranowski
> >
>


-- 
Sławomir Jaranowski

Mojo Descriptor ... outdated documentation?

[Slawomir Jaranowski]

Hi,

We have documentation about the Mojo descriptor and plugin api... [1]

Its look like params:

 - executionStrategy
 - requiresDirectInvocation
 - inheritByDefault  (PluginDescriptorBuilder - use only inheritedByDefault)
 - requiresReports

are not used currently, I was looking in 3.8.x and master branch.

I'm looking for method to disable direct plugin execution so I've started
to read documentation 

[1]
https://maven.apache.org/developers/mojo-api-specification.html#the-descriptor-and-annotations


-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Re: Maven Code Style and imports layouts

[Slawomir Jaranowski]

Hi

I checked the maven core project to see how many files don't meet the
proposed layout.

All imports in each group are alphabetically sorted.


1,
- import javax.*
- import java.*
- blank line
- all other imports
- blank line
- import static all other imports

-> 285 files to change

2.
- static imports
- blank line
- all other imports alphabetically

-> 673 files to change

3.
- import javax.*
- blank line
- import java.*
- blank line
- all other imports
- blank line
- import static all other imports

-> 196 files to change

3.
- import static all other imports
- blank line
- import javax.*
- blank line
- import java.*
- blank line
- all other imports

-> 302 files to change


So option 3 seems the most popular in maven , but it is easy to change for
all files, or only looks in changed files.
In the first step, preparing documentation is most important - may be
enough.

I've created issue for it [1]

Please vote for a proposition or give another one.


[1] https://issues.apache.org/jira/browse/MNGSITE-465



sob., 18 wrz 2021 o 20:38 Elliotte Rusty Harold 
napisał(a):

> simpler is better, though perhaps the fundamental rule should be don't
> reporter what's already there. That is, avoid needless churn.
>
> My preferred style is:
>
> static imports
> blank line
> all other imports alphabetically
>
>
> On Fri, Sep 17, 2021 at 9:19 PM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > We have described many rules about code style on Maven Code Style And
> Code
> > Conventions [1].
> >
> > One item missing for me is how java imports should be ordered and groped.
> > I can setup it in IDE and it is very useful to use code formatting with
> > tools.
> > I think that all propositions in this case will be ok - the most
> important
> > is to have one standard.
> > At the end we can even use checkstyle to verify it ... [2]
> >
> > So first proposition:
> >
> > - import javax.*
> > - import java.*
> >
> > - blank line
> >
> > - all other imports
> >
> > - blank line
> >
> > - import static all other imports
> >
> >
> > [1] https://maven.apache.org/developers/conventions/code.html
> > [2] https://checkstyle.sourceforge.io/config_imports.html#ImportOrder
> >
> > --
> > Sławomir Jaranowski
> >
> > https://twitter.com/SlawekJaran
> > https://github.com/slawekjaranowski
> > https://linkedin.com/in/slawomirjaranowski
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: [VOTE] Release Apache Maven version 3.8.3

[Slawomir Jaranowski]

Hi

I confirm that issue MNG-7215 was fixed

I also see speed up of building project - I was tested on project with
about 300 modules and build is faster about 30 - 60s - great job

+1 non binding

wt., 28 wrz 2021 o 07:56 Romain Manni-Bucau 
napisał(a):

> -0 because MNG-7251 still leads to new bugs even in concurrency=1 (which is
> the minimal case we should cover before any concurrent case IMHO) so this
> is still a regression compared to 3.8.1 and previous releases.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 28 sept. 2021 à 07:50, Tamás Cservenák  a
> écrit :
>
> > +1
> >
> > On Mon, Sep 27, 2021 at 9:18 PM Michael Osipov 
> > wrote:
> >
> > > Hi,
> > >
> > > We solved 18 issues:
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12350518
> > >
> > > 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-1667/
> > >
> > > Dev dist directory:
> > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.3/
> > >
> > > Source release checksums:
> > > apache-maven-3.8.3-src.zip sha512:
> > >
> > >
> >
> 165c7ce9fbc1b20a0e826950f2acc6638abffbbcd0b2dda869b9b2612984c421c985844ec68b9d4f9d214df3d1531f3051bbe8edd29b22cf97ef4606f15761f7
> > > apache-maven-3.8.3-src.tar.gz sha512:
> > >
> > >
> >
> 7d7b6abf8f0407f95e35ccf857412b59c8ebfa0b2eef8cf52badf20d47e4be1e79f2412965d514314240184847b5bf5c20e63c7f4b8d6cce5d2f3bc5bd31d2f2
> > >
> > > Binary release checksums:
> > > apache-maven-3.8.3-bin.zip sha512:
> > >
> > >
> >
> 959de0db3e342ecf1c183b321799a836c3c10738126f3302b623376efa45c6769ccb5cd32a17f9a9a8eb64bb30f13a6a0e4170bf03a7707cfba6d41392107e93
> > > apache-maven-3.8.3-bin.tar.gz sha512:
> > >
> > >
> >
> 1c12a5df43421795054874fd54bb8b37d242949133b5bf6052a063a13a93f13a20e6e9dae2b3d85b9c7034ec977bbc2b6e7f66832182b9c863711d78bfe60faa
> > >
> > > Draft for release notes:
> > > https://github.com/apache/maven-site/pull/264
> > >
> > >
> > > Guide to testing staged releases:
> > > http://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open until Sunday.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>


-- 
Sławomir Jaranowski

Re: Mojo Descriptor ... outdated documentation?

[Slawomir Jaranowski]

I created issues for those: MPLUGIN-374, MPLUGIN-375

I see that you are in preparing some changes to maven-plugin-tools this
change can be done by the way,

please comment issue - I can fix it

Last time I searched for this information and I have some dubiou about how
it works, so actual tools and documentation can help other plugin
developers.

śr., 22 wrz 2021 o 21:33 Tamás Cservenák  napisał(a):

> Howdy,
>
> requiresReports  is unsupported since Maven 3, unsure if I would add it
> doco at all (rather would remove it).
>
> Thanks
> T
>
> On Wed, Sep 22, 2021 at 9:15 PM Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> wrote:
>
> > Hi,
> >
> > We have documentation about the Mojo descriptor and plugin api... [1]
> >
> > Its look like params:
> >
> >  - executionStrategy
> >  - requiresDirectInvocation
> >  - inheritByDefault  (PluginDescriptorBuilder - use only
> > inheritedByDefault)
> >  - requiresReports
> >
> > are not used currently, I was looking in 3.8.x and master branch.
> >
> > I'm looking for method to disable direct plugin execution so I've started
> > to read documentation 
> >
> > [1]
> >
> >
> https://maven.apache.org/developers/mojo-api-specification.html#the-descriptor-and-annotations
> >
> >
> > --
> > Sławomir Jaranowski
> >
> > https://twitter.com/SlawekJaran
> > https://github.com/slawekjaranowski
> > https://linkedin.com/in/slawomirjaranowski
> >
>


-- 
Sławomir Jaranowski

Re: GitHub Actions on Maven projects

[Slawomir Jaranowski]

Ok,

if we want have to implement shared  Github Action  (I hope we do) I see
such steps:

- create repository for share / common GitHub Actions like
maven-jenkins-lib maybe: maven-actions-lib - I need help what issue should
be created for it
- prepare proposition for shared workflows  - I can try to do it
- use and test in some project
- propagate for other project after confirm

Now (at last) GitHub support shared workflows [1] [2] not only composite
action - it is something new, so we can start real shared workflows

[1]
https://github.blog/changelog/2021-10-05-github-actions-dry-your-github-actions-configuration-by-reusing-workflows/
[2]
https://docs.github.com/en/actions/learn-github-actions/reusing-workflows


niedz., 19 wrz 2021 o 21:49 Slawomir Jaranowski 
napisał(a):

> Fo jlink on maven jenkins (a last log [1]) I don't see toolchains ... and
> on java 8 simple it tests are skipped ...
>
> Maybe instead complicate build configuration - drop unsupported java 8
> from matrix.
> I don't know this project, I may not see the reason for build it on java 8
> even then plugin require java 9+ for working
>
> I hope that most of projects can use common build steps. Of course we can
> prepare more than one build template.
>
>
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-jlink-plugin/job/master/112/execution/node/221/log/
>
> niedz., 19 wrz 2021 o 20:47 Benjamin Marwell 
> napisał(a):
>
>> That won't work for all plugins.
>> The jlink plugin and others are using complicated setups so they can use
>> toolchains on GitHub Actions. It's a little bit complicated there because
>> the plugin does work with java 8 as long as a java 9+ is configured via
>> toolchains.
>>
>> Please make sure those actions continue to work.
>>
>>
>>
>>
>> On Sun, 19 Sep 2021, 20:22 Martin Kanters, 
>> wrote:
>>
>> > Sounds like a great idea!
>> >
>> > Martin
>> >
>> > Op zo 19 sep. 2021 om 00:26 schreef Tamás Cservenák <
>> ta...@cservenak.net>:
>> >
>> > > +1 for global action
>> > >
>> > > T
>> > >
>> > > On Sat, Sep 18, 2021, 13:35 Slawomir Jaranowski <
>> s.jaranow...@gmail.com>
>> > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > Thanks for your response. I know that jenkins build is the master
>> for
>> > > > Apache projects,
>> > > > but most of the projects have some GA workflows configuration which
>> > many
>> > > > times are different.
>> > > > This situation generates more work for maintainer.
>> > > >
>> > > > Thanks to composite actions [1] we can create one global action
>> which
>> > has
>> > > > defined all required steps and one action for providing
>> configurations
>> > > > values like jkd list,
>> > > > both of these actions can be in one repository.
>> > > >
>> > > > In the rest of the project we can use those global actions, so when
>> > next
>> > > > time we want to change, e.g. jdk list (it changes every 6 month ;-)
>> )
>> > we
>> > > > only change it in one place.
>> > > > This approach can make less maintenance work in maven projects.
>> > > >
>> > > > If you are interested let me know, I can prepare some spikes for you
>> > and
>> > > > provide more details.
>> > > >
>> > > >
>> > > > [1]
>> > > >
>> > > >
>> > >
>> >
>> https://docs.github.com/en/actions/creating-actions/creating-a-composite-action
>> > > >
>> > > >
>> > > > sob., 18 wrz 2021 o 08:27 Martin Kanters 
>> > > > napisał(a):
>> > > >
>> > > > > Hi Slawomir, sorry for the late reply.
>> > > > >
>> > > > > Great that you see the value of the workflows.
>> > > > > I don't think there are any strict rules or guidelines around how
>> the
>> > > > > workflow should be configured exactly, but I think it makes sense
>> to
>> > > have
>> > > > > them in place.
>> > > > > Perhaps we should also look into a way of reusing workflows in
>> all or
>> > > > most
>> > > > > of the projects (maven-core is a bit different).
>> > > > >
>> > > > > Just wanted to mention th

Re: Maven Code Style and imports layouts

[Slawomir Jaranowski]

Hi,

In order to help make decisions, I prepared PR [1] with the most used order
layout in Maven Core.

Please look and vote / approve / choose another proposition.

[1] https://github.com/apache/maven-site/pull/269


czw., 23 wrz 2021 o 23:47 Slawomir Jaranowski 
napisał(a):

> Hi
>
> I checked the maven core project to see how many files don't meet the
> proposed layout.
>
> All imports in each group are alphabetically sorted.
>
>
> 1,
> - import javax.*
> - import java.*
> - blank line
> - all other imports
> - blank line
> - import static all other imports
>
> -> 285 files to change
>
> 2.
> - static imports
> - blank line
> - all other imports alphabetically
>
> -> 673 files to change
>
> 3.
> - import javax.*
> - blank line
> - import java.*
> - blank line
> - all other imports
> - blank line
> - import static all other imports
>
> -> 196 files to change
>
> 3.
> - import static all other imports
> - blank line
> - import javax.*
> - blank line
> - import java.*
> - blank line
> - all other imports
>
> -> 302 files to change
>
>
> So option 3 seems the most popular in maven , but it is easy to change for
> all files, or only looks in changed files.
> In the first step, preparing documentation is most important - may be
> enough.
>
> I've created issue for it [1]
>
> Please vote for a proposition or give another one.
>
>
> [1] https://issues.apache.org/jira/browse/MNGSITE-465
>
>
>
> sob., 18 wrz 2021 o 20:38 Elliotte Rusty Harold 
> napisał(a):
>
>> simpler is better, though perhaps the fundamental rule should be don't
>> reporter what's already there. That is, avoid needless churn.
>>
>> My preferred style is:
>>
>> static imports
>> blank line
>> all other imports alphabetically
>>
>>
>> On Fri, Sep 17, 2021 at 9:19 PM Slawomir Jaranowski
>>  wrote:
>> >
>> > Hi,
>> >
>> > We have described many rules about code style on Maven Code Style And
>> Code
>> > Conventions [1].
>> >
>> > One item missing for me is how java imports should be ordered and
>> groped.
>> > I can setup it in IDE and it is very useful to use code formatting with
>> > tools.
>> > I think that all propositions in this case will be ok - the most
>> important
>> > is to have one standard.
>> > At the end we can even use checkstyle to verify it ... [2]
>> >
>> > So first proposition:
>> >
>> > - import javax.*
>> > - import java.*
>> >
>> > - blank line
>> >
>> > - all other imports
>> >
>> > - blank line
>> >
>> > - import static all other imports
>> >
>> >
>> > [1] https://maven.apache.org/developers/conventions/code.html
>> > [2] https://checkstyle.sourceforge.io/config_imports.html#ImportOrder
>> >
>> > --
>> > Sławomir Jaranowski
>> >
>> > https://twitter.com/SlawekJaran
>> > https://github.com/slawekjaranowski
>> > https://linkedin.com/in/slawomirjaranowski
>>
>>
>>
>> --
>> Elliotte Rusty Harold
>> elh...@ibiblio.org
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
> --
> Sławomir Jaranowski
>


-- 
Sławomir Jaranowski

Re: Upcoming Maven 3.8.4

[Slawomir Jaranowski]

Hi,

Very strange release process for common components ... some of the
artifacts are published to the Central Repository and some of them are
published by svn repository ...
I don't see benefit for customizing maven core for one of case of usage

but it is discussion for another place, here I only point it


sob., 23 paź 2021 o 22:51 Gary Gregory  napisał(a):

> HI All:
>
> I discovered a regression this morning that prevents me from creating
> a release candidate for Apache Commons CLI:
>
> https://issues.apache.org/jira/browse/MNG-7316
> https://github.com/apache/maven/pull/601
>
> May this be included for 3.8.4 please?
>
> Gary
>
> On Sat, Oct 23, 2021 at 3:48 PM Falko Modler  wrote:
> >
> > Hi,
> >
> > > Given that we had two releases with regressions I tend *not* to merge
> > > #578. Give it more time and thought.
> >
> > As written before on GH, not merging #578 or a backport of #476 will
> > bring back MNG-6843.
> > This will catch users off guard that were happily benefitting from
> > MNG-6843 being fixed in 3.8.2 and 3.8.3.
> >
> > If you still want to do it this way, then please at least document that
> > MNG-6843 is back under "Known Issues" in 3.8.4 "Release Notes".
> > Additionally, MNG-6843 should be reopened.
> >
> > I'd really prefer if we could keep MNG-6843 fixed, by whichever PR
> > (doesn't need to be mine).
> >
> > Cheers,
> >
> > Falko
> >
> > Am 23.10.2021 um 21:22 schrieb Michael Osipov:
> > > Folks,
> > >
> > > all important tickets for Maven 3.8.4 have been addressed in
> > > maven-3.8.x branch.
> > >
> > > We have two open PRs:
> > > * #578: Alternative to the ThreadLocal approach
> > > * #476: As far as I understand a more global approach to the issue and
> > > supersedes #576, but requires Java 8. So Maven 3.9+
> > >
> > > Given that we had two releases with regressions I tend *not* to merge
> > > #578. Give it more time and thought. Maybe go over to #476 directly in
> > > 3.9.0 and 4.0.0.
> > >
> > > Please test and let me know whether you still see errors. If I don't
> > > read any objections I will start the new release somewhere around mid
> > > next week.
> > >
> > > Michael
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: Maven Code Style and imports layouts

[Slawomir Jaranowski]

Hi,

Benjamin - thanks for voting.

Can we finish this task?
I assume that there are no -1 votes so it should be processed ...

Any other suggestions, improvements?

pon., 18 paź 2021 o 08:28 Benjamin Marwell  napisał(a):

> +1!
>
>  Sandra and I tried similar Suggestions a while back.
> This will help new contributors a lot.
>
> Thanks for your efforts!
>
> On Mon, 18 Oct 2021, 07:10 Slawomir Jaranowski, 
> wrote:
>
> > Hi,
> >
> > In order to help make decisions, I prepared PR [1] with the most used
> order
> > layout in Maven Core.
> >
> > Please look and vote / approve / choose another proposition.
> >
> > [1] https://github.com/apache/maven-site/pull/269
> >
> >
> > czw., 23 wrz 2021 o 23:47 Slawomir Jaranowski 
> > napisał(a):
> >
> > > Hi
> > >
> > > I checked the maven core project to see how many files don't meet the
> > > proposed layout.
> > >
> > > All imports in each group are alphabetically sorted.
> > >
> > >
> > > 1,
> > > - import javax.*
> > > - import java.*
> > > - blank line
> > > - all other imports
> > > - blank line
> > > - import static all other imports
> > >
> > > -> 285 files to change
> > >
> > > 2.
> > > - static imports
> > > - blank line
> > > - all other imports alphabetically
> > >
> > > -> 673 files to change
> > >
> > > 3.
> > > - import javax.*
> > > - blank line
> > > - import java.*
> > > - blank line
> > > - all other imports
> > > - blank line
> > > - import static all other imports
> > >
> > > -> 196 files to change
> > >
> > > 3.
> > > - import static all other imports
> > > - blank line
> > > - import javax.*
> > > - blank line
> > > - import java.*
> > > - blank line
> > > - all other imports
> > >
> > > -> 302 files to change
> > >
> > >
> > > So option 3 seems the most popular in maven , but it is easy to change
> > for
> > > all files, or only looks in changed files.
> > > In the first step, preparing documentation is most important - may be
> > > enough.
> > >
> > > I've created issue for it [1]
> > >
> > > Please vote for a proposition or give another one.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/MNGSITE-465
> > >
> > >
> > >
> > > sob., 18 wrz 2021 o 20:38 Elliotte Rusty Harold 
> > > napisał(a):
> > >
> > >> simpler is better, though perhaps the fundamental rule should be don't
> > >> reporter what's already there. That is, avoid needless churn.
> > >>
> > >> My preferred style is:
> > >>
> > >> static imports
> > >> blank line
> > >> all other imports alphabetically
> > >>
> > >>
> > >> On Fri, Sep 17, 2021 at 9:19 PM Slawomir Jaranowski
> > >>  wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > We have described many rules about code style on Maven Code Style
> And
> > >> Code
> > >> > Conventions [1].
> > >> >
> > >> > One item missing for me is how java imports should be ordered and
> > >> groped.
> > >> > I can setup it in IDE and it is very useful to use code formatting
> > with
> > >> > tools.
> > >> > I think that all propositions in this case will be ok - the most
> > >> important
> > >> > is to have one standard.
> > >> > At the end we can even use checkstyle to verify it ... [2]
> > >> >
> > >> > So first proposition:
> > >> >
> > >> > - import javax.*
> > >> > - import java.*
> > >> >
> > >> > - blank line
> > >> >
> > >> > - all other imports
> > >> >
> > >> > - blank line
> > >> >
> > >> > - import static all other imports
> > >> >
> > >> >
> > >> > [1] https://maven.apache.org/developers/conventions/code.html
> > >> > [2]
> https://checkstyle.sourceforge.io/config_imports.html#ImportOrder
> > >> >
> > >> > --
> > >> > Sławomir Jaranowski
> > >> >
> > >> > https://twitter.com/SlawekJaran
> > >> > https://github.com/slawekjaranowski
> > >> > https://linkedin.com/in/slawomirjaranowski
> > >>
> > >>
> > >>
> > >> --
> > >> Elliotte Rusty Harold
> > >> elh...@ibiblio.org
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >>
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>


-- 
Sławomir Jaranowski

Re: Prepare maven-plugin-tools release 3.6.2

[Slawomir Jaranowski]

Hi

I tried in my plugin recommendation from
https://issues.apache.org/jira/browse/MPLUGIN-370

I put in the provided scope all org.apache.maven:maven-* artifacts 

I use in plugin org.sonatype.plexus.components.sec.dispatcher.SecDispatcher
which is in org.sonatype.plexus:plexus-sec-dispatcher
plexus-sec-dispatcher  is as transitive dependency from maven-core ->
maven-settings-builder
So when I had maven-core in the compile scope everything was working but
with provided scope it stopped working because  plexus-sec-dispatcher  is
not exported by maven.

I added plexus-sec-dispatcher as a direct dependency in the compile
scope and the problem is solved.

Question: Are we sure that all needed org.apache.maven:maven-* are exported
by maven?

We can have a situation when one of org.apache.maven:maven-* will not be
exported by maven and we can not use it in a plugin because plugin-tools
forbid it.

I don't know if some of org.apache.maven:maven-* which is not exported by
maven can be needed by plugin.





pt., 22 paź 2021 o 12:25 Eric Lilja  napisał(a):

> Now that's a good list of changes, thank you for doing that and I'm really
> looking forward to this release!
>
> - Eric L
>
> On Fri, Oct 22, 2021 at 10:12 AM Michael Osipov 
> wrote:
>
> > Am 2021-10-22 um 07:52 schrieb Tamás Cservenák:
> > > Howdy,
> > >
> > > I just wanted a heads up, that 3.6.2 of maven-plugin-tools is about to
> > > happen soon.
> > > If anyone has something more to add, please push it now.
> > >
> > > Planned changes (already merged):
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20fixVersion%20%3D%203.6.2
> >
> > *Fantastic*
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


-- 
Sławomir Jaranowski

Surefire - multiple tests framework on classpath

[Slawomir Jaranowski]

Hi,

When multiple test frameworks are present on project classpath surefire
chooses one framework for running the tests.

In such situations, some tests are silently skipped.


I've created issue [1] for it with a simple proposition.

After discussion on slack another proposition was in place to detect the
test framework with other dependencies and choose a proper provider.

Or use multiple providers instead of only one.


It will be good to choose how to solve this problem.


[1] https://issues.apache.org/jira/browse/SUREFIRE-1954

-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Re: Prepare maven-plugin-tools release 3.6.2

[Slawomir Jaranowski]

Thanks.

I corrected deprecated artifacts.

It can be a good idea that plugin-tools check also other good practices for
plugin developments like deprecated artifacts.


wt., 2 lis 2021 o 21:33 Tamás Cservenák  napisał(a):

> Slawomir,
>
> do NOT use o.s.p deprecated dependency. I don't know which is your plugin,
> but you may need some similar change like this:
> https://github.com/schrepfler/jira-maven-plugin/pull/178
>
> HTH
> T
>
> On Sun, Oct 31, 2021 at 10:33 AM Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> wrote:
>
> > Hi
> >
> > I tried in my plugin recommendation from
> > https://issues.apache.org/jira/browse/MPLUGIN-370
> >
> > I put in the provided scope all org.apache.maven:maven-* artifacts 
> >
> > I use in plugin
> org.sonatype.plexus.components.sec.dispatcher.SecDispatcher
> > which is in org.sonatype.plexus:plexus-sec-dispatcher
> > plexus-sec-dispatcher  is as transitive dependency from maven-core ->
> > maven-settings-builder
> > So when I had maven-core in the compile scope everything was working but
> > with provided scope it stopped working because  plexus-sec-dispatcher  is
> > not exported by maven.
> >
> > I added plexus-sec-dispatcher as a direct dependency in the compile
> > scope and the problem is solved.
> >
> > Question: Are we sure that all needed org.apache.maven:maven-* are
> exported
> > by maven?
> >
> > We can have a situation when one of org.apache.maven:maven-* will not be
> > exported by maven and we can not use it in a plugin because plugin-tools
> > forbid it.
> >
> > I don't know if some of org.apache.maven:maven-* which is not exported by
> > maven can be needed by plugin.
> >
> >
> >
> >
> >
> > pt., 22 paź 2021 o 12:25 Eric Lilja  napisał(a):
> >
> > > Now that's a good list of changes, thank you for doing that and I'm
> > really
> > > looking forward to this release!
> > >
> > > - Eric L
> > >
> > > On Fri, Oct 22, 2021 at 10:12 AM Michael Osipov 
> > > wrote:
> > >
> > > > Am 2021-10-22 um 07:52 schrieb Tamás Cservenák:
> > > > > Howdy,
> > > > >
> > > > > I just wanted a heads up, that 3.6.2 of maven-plugin-tools is about
> > to
> > > > > happen soon.
> > > > > If anyone has something more to add, please push it now.
> > > > >
> > > > > Planned changes (already merged):
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20fixVersion%20%3D%203.6.2
> > > >
> > > > *Fantastic*
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>


-- 
Sławomir Jaranowski

Re: Surefire - multiple tests framework on classpath

[Slawomir Jaranowski]

Hi,

I understand the difference  between framework and providers.
I also know that we can add specific providers as dependency to the plugin
and in the result we have manually selected providers.

When we don't configure any dependency the provider is chosen automatically
depending on what we have on classpath, what framework.

eg. When we have on classpath junit4 and junit5, but without junit5 vintage
- junit4 tests are silently skipped.

In most cases in the project we use one testing framework so
automatically choosing one provider is ok.

When we use more that one framework it is probably during migration, so we
should define proper dependency.
It is ok when we have control on what we do in a project, but there are
some situations when we can make mistakes, like
- user add second testing framework and forgot about configuration
- we change project dependency and in transitive dependency we got next
testing framework

So I want to mitigate the risk of skipped tests by warning / failing that
we have many frameworks and automatically provider selection takes place.

We can also try to choose many providers (not one) automatically, but I
think it will be more complicated and in standard usage is not needed.
For automatic detection we have many corner cases, like testng + junit4  -
testng by default runs junit4 tests, so without special configuration for
testng we run some of the tests twice.


śr., 3 lis 2021 o 15:09 Tibor Digana  napisał(a):

> Hi Slawomir,
>
> The reality is different.
> It's not the frameworks but providers.
> So the plugin iterates over providers.
> You may choose whether you will define the provider artifacts in plugin
> deps or you let the plugin to select the providers upon dependencies which
> means that there is some logic and JUnit5 deps may activate one provider
> for both the junit4 and 5.
>
> T
>
> On Tue, Nov 2, 2021 at 7:46 PM Slawomir Jaranowski  >
> wrote:
>
> > Hi,
> >
> > When multiple test frameworks are present on project classpath surefire
> > chooses one framework for running the tests.
> >
> > In such situations, some tests are silently skipped.
> >
> >
> > I've created issue [1] for it with a simple proposition.
> >
> > After discussion on slack another proposition was in place to detect the
> > test framework with other dependencies and choose a proper provider.
> >
> > Or use multiple providers instead of only one.
> >
> >
> > It will be good to choose how to solve this problem.
> >
> >
> > [1] https://issues.apache.org/jira/browse/SUREFIRE-1954
> >
> > --
> > Sławomir Jaranowski
> >
> > https://twitter.com/SlawekJaran
> > https://github.com/slawekjaranowski
> > https://linkedin.com/in/slawomirjaranowski
> >
>


-- 
Sławomir Jaranowski

Dependabot and jira issues

[Slawomir Jaranowski]

Hi,

Dependabot is a very useful tool as we know.

Most of (probably all) Maven / ASF projects have dedicated jira projects to
track changes.

When we create PR with  jira issue reference in the PR title then "ASF
GitHub Bot" links PR with jira issue.

Maybe it will be useful (posible) when Dependabot create PR with dependency
updates "ASF GitHub Bot" can create corresponding issue for it and link
with PR?

Sometime issue about dependency updates is created manually and it can
happen that can be resolved by Dependabot PR, eg: [1]
But in most of situations we have updated project dependency without jira
tracking, eg: [2]

What do you think about such automatically possibility,
manually creating issue for each Dependabot PR can not works as we see.

[1] https://issues.apache.org/jira/browse/MPOM-267
[2] https://github.com/apache/maven-apache-parent/pull/54


-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Re: GitHub Actions on Maven projects

[Slawomir Jaranowski]

Hi,

We have created maven-gh-actions-shared [1] with the first shared workflow.
I hope that will be usable and help with less maintenance work.

I'm starting to use this workflow in some of project [2]

Lastly, what I think we need is a jira project to track changes.

Thanks Olivier for supporting me.

[1] https://github.com/apache/maven-gh-actions-shared
[2]
https://github.com/search?l=YAML&q=%22apache%2Fmaven-gh-actions-shared%2F%22&type=Code


czw., 7 paź 2021 o 19:41 Slawomir Jaranowski 
napisał(a):

> Ok,
>
> if we want have to implement shared  Github Action  (I hope we do) I see
> such steps:
>
> - create repository for share / common GitHub Actions like
> maven-jenkins-lib maybe: maven-actions-lib - I need help what issue should
> be created for it
> - prepare proposition for shared workflows  - I can try to do it
> - use and test in some project
> - propagate for other project after confirm
>
> Now (at last) GitHub support shared workflows [1] [2] not only composite
> action - it is something new, so we can start real shared workflows
>
> [1]
> https://github.blog/changelog/2021-10-05-github-actions-dry-your-github-actions-configuration-by-reusing-workflows/
> [2]
> https://docs.github.com/en/actions/learn-github-actions/reusing-workflows
>
>
> niedz., 19 wrz 2021 o 21:49 Slawomir Jaranowski 
> napisał(a):
>
>> Fo jlink on maven jenkins (a last log [1]) I don't see toolchains ... and
>> on java 8 simple it tests are skipped ...
>>
>> Maybe instead complicate build configuration - drop unsupported java 8
>> from matrix.
>> I don't know this project, I may not see the reason for build it on java
>> 8 even then plugin require java 9+ for working
>>
>> I hope that most of projects can use common build steps. Of course we can
>> prepare more than one build template.
>>
>>
>> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-jlink-plugin/job/master/112/execution/node/221/log/
>>
>> niedz., 19 wrz 2021 o 20:47 Benjamin Marwell 
>> napisał(a):
>>
>>> That won't work for all plugins.
>>> The jlink plugin and others are using complicated setups so they can use
>>> toolchains on GitHub Actions. It's a little bit complicated there because
>>> the plugin does work with java 8 as long as a java 9+ is configured via
>>> toolchains.
>>>
>>> Please make sure those actions continue to work.
>>>
>>>
>>>
>>>
>>> On Sun, 19 Sep 2021, 20:22 Martin Kanters, 
>>> wrote:
>>>
>>> > Sounds like a great idea!
>>> >
>>> > Martin
>>> >
>>> > Op zo 19 sep. 2021 om 00:26 schreef Tamás Cservenák <
>>> ta...@cservenak.net>:
>>> >
>>> > > +1 for global action
>>> > >
>>> > > T
>>> > >
>>> > > On Sat, Sep 18, 2021, 13:35 Slawomir Jaranowski <
>>> s.jaranow...@gmail.com>
>>> > > wrote:
>>> > >
>>> > > > Hi,
>>> > > >
>>> > > > Thanks for your response. I know that jenkins build is the master
>>> for
>>> > > > Apache projects,
>>> > > > but most of the projects have some GA workflows configuration which
>>> > many
>>> > > > times are different.
>>> > > > This situation generates more work for maintainer.
>>> > > >
>>> > > > Thanks to composite actions [1] we can create one global action
>>> which
>>> > has
>>> > > > defined all required steps and one action for providing
>>> configurations
>>> > > > values like jkd list,
>>> > > > both of these actions can be in one repository.
>>> > > >
>>> > > > In the rest of the project we can use those global actions, so when
>>> > next
>>> > > > time we want to change, e.g. jdk list (it changes every 6 month
>>> ;-) )
>>> > we
>>> > > > only change it in one place.
>>> > > > This approach can make less maintenance work in maven projects.
>>> > > >
>>> > > > If you are interested let me know, I can prepare some spikes for
>>> you
>>> > and
>>> > > > provide more details.
>>> > > >
>>> > > >
>>> > > > [1]
>>> > > >
>>> > > >
>>> > >
>>> >
>>> https://docs.github.com/en

Re: Eat our own dogfood

[Slawomir Jaranowski]

Hi,

Good idea.

One of the resolutions can be to use maven wrapper to configure the Maven
version to use, and use wrapper to build a project.
Such a solution can be easily used in any CI system.

Using a wrapper we simply download the latest build and deployed Maven
version from the repository, we don't need to build the project twice.
I assume that deployment is done after all tests pass so the repository
will contain a working version.

Task to do before:
 - Make maven wrapper functional [1]
 - Support SNAPSHOT versions by wrapper [2]

[1] https://issues.apache.org/jira/browse/MWRAPPER-14
[2] https://issues.apache.org/jira/browse/MWRAPPER-15


wt., 9 lis 2021 o 11:52 Maarten Mulders  napisał(a):

> Hi all,
>
> In the last year, we've seen multiple situations where a change in
> Maven core prevented Maven from building itself [1][2].
>
> On the path to stabilising Maven towards Maven 4, I think this isn't
> helping us. That's why I propose we introduce an additional GitHub
> action. Let's call it the "eat our own dogfood" check: build Maven Core,
> then use that build to build Maven Core again.
>
> Maybe it's possible to do it on Jenkins, too. I'm less familiar with our
> Jenkins setup, that's all...
>
> What do you think?
>
>
> Thanks,
>
> Maarten
>
>
> [1] https://issues.apache.org/jira/browse/MNG-7087
> [2] https://issues.apache.org/jira/browse/MNG-7319
>


-- 
Sławomir Jaranowski

Re: Maven Assembly / Common Artifact Filters issues and defect

[Slawomir Jaranowski]

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

Re: [VOTE] Release Maven Plugin Tools version 3.6.2

[Slawomir Jaranowski]

+1 (not binding)

niedz., 21 lis 2021 o 16:42 Michael Osipov  napisał(a):

> Hi,
>
> We solved 11 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820&version=12350123
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1671/
>
> https://repository.apache.org/content/repositories/maven-1671/org/apache/maven/plugin-tools/maven-plugin-tools/3.6.2/maven-plugin-tools-3.6.2-source-release.zip
>
> Source release checksum(s):
> maven-plugin-tools-3.6.2-source-release.zip
> sha512:
>
> 53f48985061ad34ab605c194c7ce22bb74dadf17c4fccaba1ca8b7f15e5003ea89d4198ca47e21f2b36541a97f148e335f5f508c5766395bb4e12a4fde739356
>
> Staging site:
> https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: Different parent/child configuration without child located customization?

[Slawomir Jaranowski]

Hi,

Try something like in parent pom





maven-failsafe-plugin
3.0.0-M5


test-id

integration-test
verify









maven-failsafe-plugin


false
test-id
none






In build/pluginManagement I have executions and also can have configuration.

In build/plugins I bind execution to magic phase none with inherited set to
false, so plugin will not execute in parent pom only.


pt., 26 lis 2021 o 15:21 Romain Manni-Bucau 
napisał(a):

> Hi all,
>
> I regularly hit an issue with plugin definition: it is not possible to
> define the plugin for children in a parent.
> Let me detail a concrete case: i want a parent module to define the plugins
> for children modules but I don't want the parent to have these plugins.
> A common solution is to skip=true in the parent and skip=false in children
> but it requires N (number of children) undesired flag (vs 1 for the
> parent).
> An example is when I do an ui/ parent (pom packaging) i want to define "npm
> install && npm run build" using frontend-maven-plugin for all children
> (spa1, spa2 etc) but I don't want ui/ module itself to run npm since it
> does not contain any module.
>
> Side note: it is the same if you do an images/ subhierarchy or servers/
> subhierarchy.
>
> Indeed a trivial trick for the plugin would be to avoid pom packaging but
> the author rejected the PR doing that saying it is a tool feature not a
> plugin feature - a bit the same argument that skip should be handled by
> mojo executor and not each plugin.
>
> I did a quick extension workaround (
> https://github.com/rmannibucau/hierarchy-extension) to enable to configure
> the skip toggle the plugin luckily has from the parent and not redefine the
> chain/toggle in all children but I think we would need to solve it more
> cleanly at some point.
>
> I see a few options (and even if a single one would solve my particular
> issue, all can be nice feature IMHO):
>
> 1. support what I did in the extension in maven-core?
> 2. support implicit skip toggle for all mojo executions
> 3. add some virtual properties ${project.packaging.isPom},
> ${project.packaging.isNotPom} (potentially others with dynamic evaluations
> is[Not]XXX)
> 4. support implicit skipPackagings (list) property for all mojos
>
> Overall it ends to either define a pseudo language in placeholders and
> reuse what is in the plugins or add virutal properties in plugin about the
> project structure (what maven itself handles).
> Personally I think this last option is saner on the long run (so 2 and 4
> short term) but happy to get some feedback or even existing workaround
> which does not require to rewire some value in all child or write another
> extension ;).
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>


-- 
Sławomir Jaranowski

Re: Different parent/child configuration without child located customization?

[Slawomir Jaranowski]

Hi
It can be for both cases.

You want to configure everything in parent pom - right?
Some executions for all child only and some for parent only.

So everything can be done in one place, like:




frontend-maven-plugin


npm-build

npm






frontend-maven-plugin



false

npm-build
none



false
install-node-npm

install-node-and-npm








pt., 26 lis 2021 o 17:38 Romain Manni-Bucau 
napisał(a):

> Hi Sławomir,
>
> It solves the parent case but not the child one (the exact opposite). So i
> can install node only in parent but i can't run npm install && npm run in
> all children. Do I miss anything?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 26 nov. 2021 à 16:20, Slawomir Jaranowski 
> a écrit :
>
> > Hi,
> >
> > Try something like in parent pom
> >
> > 
> > 
> > 
> > 
> > maven-failsafe-plugin
> > 3.0.0-M5
> > 
> > 
> > test-id
> > 
> > integration-test
> > verify
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > 
> > 
> > maven-failsafe-plugin
> > 
> > 
> > false
> > test-id
> > none
> > 
> > 
> > 
> > 
> > 
> >
> > In build/pluginManagement I have executions and also can have
> > configuration.
> >
> > In build/plugins I bind execution to magic phase none with inherited set
> to
> > false, so plugin will not execute in parent pom only.
> >
> >
> > pt., 26 lis 2021 o 15:21 Romain Manni-Bucau 
> > napisał(a):
> >
> > > Hi all,
> > >
> > > I regularly hit an issue with plugin definition: it is not possible to
> > > define the plugin for children in a parent.
> > > Let me detail a concrete case: i want a parent module to define the
> > plugins
> > > for children modules but I don't want the parent to have these plugins.
> > > A common solution is to skip=true in the parent and skip=false in
> > children
> > > but it requires N (number of children) undesired flag (vs 1 for the
> > > parent).
> > > An example is when I do an ui/ parent (pom packaging) i want to define
> > "npm
> > > install && npm run build" using frontend-maven-plugin for all children
> > > (spa1, spa2 etc) but I don't want ui/ module itself to run npm since it
> > > does not contain any module.
> > >
> > > Side note: it is the same if you do an images/ subhierarchy or servers/
> > > subhierarchy.
> > >
> > > Indeed a trivial trick for the plugin would be to avoid pom packaging
> but
> > > the author rejected the PR doing that saying it is a tool feature not a
> > > plugin feature - a bit the same argument that skip should be handled by
> > > mojo executor and not each plugin.
> > >
> > > I did a quick extension workaround (
> > > https://github.com/rmannibucau/hierarchy-extension) to enable to
> > configure
> > > the skip toggle the plugin luckily has from the parent and not redefine
> > the
> > > chain/toggle in all children but I think we would need to solve it more
> > > cleanly at some point.
> > >
> > > I see a few options (and even if a single one would solve my particular
> > > issue, all can be nice feature IMHO):
> > >
> > > 1. support what I did

Empty jars in local .m2/repository

[Slawomir Jaranowski]

Hi,

>From time to time I have jars in .m2/repository of size 0.

Probably some network issues are the reason for this situation.

I can't reproduce this today.
I need some hints which component is responsible for storing artifacts in
.m2
Or some other hints which can help to reproduce, debug such a situation.

Does anybody else have a similar problem?

Please try on your system:
find ~/.m2/repository -type f -size 0

I use Maven 3.8.4

-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Re: Empty jars in local .m2/repository

[Slawomir Jaranowski]

With Maven 3.6.2 I had similar issues ... so last week I upgrade on my CI
system to 3.8.4 ... not fix

śr., 1 gru 2021 o 12:27 Romain Manni-Bucau 
napisał(a):

> Hi,
>
> I have a few coming from p2 plugins and .lock/.part files (missing cleanup
> but no big deal I guess). All other 0 sized artifacts are related to data
> exploded in .m2 by plugins but unrelated to maven (like graal distro
> exploded, npm tar.gz exploded etc).
>
> Side note: I mainly use 3.6.3 on projects so can be in a luck case too.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 1 déc. 2021 à 12:23, Slawomir Jaranowski 
> a
> écrit :
>
> > Hi,
> >
> > From time to time I have jars in .m2/repository of size 0.
> >
> > Probably some network issues are the reason for this situation.
> >
> > I can't reproduce this today.
> > I need some hints which component is responsible for storing artifacts in
> > .m2
> > Or some other hints which can help to reproduce, debug such a situation.
> >
> > Does anybody else have a similar problem?
> >
> > Please try on your system:
> > find ~/.m2/repository -type f -size 0
> >
> > I use Maven 3.8.4
> >
> > --
> > Sławomir Jaranowski
> >
> > https://twitter.com/SlawekJaran
> > https://github.com/slawekjaranowski
> > https://linkedin.com/in/slawomirjaranowski
> >
>


-- 
Sławomir Jaranowski

Re: Empty jars in local .m2/repository

[Slawomir Jaranowski]

Environment:
 - vanilla Maven - Apache Maven 3.8.4
(9b656c72d54e5bacbed989b64718c159fe39b537)
 - maven build in single thread mode
 - no change for locking
 - Artifactory 6.23.28 as MRM

in settings.xml I have defined one repository for private items and mirror
for the rest

but ... I found that the build uses custom maven plugins with custom or old
resolvers 
some of them execute maven in embedded mode and some fork new maven
instances ...
without logs  corpo way :-(

so thanks everybody for helping  probably it is only my problem.



śr., 1 gru 2021 o 15:09 Tamás Cservenák  napisał(a):

> Slawomir,
>
> Qs:
> - do you use only "vanilla" Maven? (so ASF one, no mvnd, takari smart
> builder, etc)
> - do you use maven single threaded or MT?
> - do you use some alternative than default locking?
> - I think you are "solo" user, not AV affected corporation, but still, do
> you use any MRM (and if yes, which one?)
>
> Thanks
> T
>
>
> On Wed, Dec 1, 2021 at 12:23 PM Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> wrote:
>
> > Hi,
> >
> > From time to time I have jars in .m2/repository of size 0.
> >
> > Probably some network issues are the reason for this situation.
> >
> > I can't reproduce this today.
> > I need some hints which component is responsible for storing artifacts in
> > .m2
> > Or some other hints which can help to reproduce, debug such a situation.
> >
> > Does anybody else have a similar problem?
> >
> > Please try on your system:
> > find ~/.m2/repository -type f -size 0
> >
> > I use Maven 3.8.4
> >
> > --
> > Sławomir Jaranowski
> >
> > https://twitter.com/SlawekJaran
> > https://github.com/slawekjaranowski
> > https://linkedin.com/in/slawomirjaranowski
> >
>


-- 
Sławomir Jaranowski

Re: reviewing Maven Wrapper before releasing

[Slawomir Jaranowski]

https://issues.apache.org/jira/browse/MWRAPPER-29

śr., 8 gru 2021 o 15:52 Robert Scholte  napisał(a):

> With mvn verify -Prun-its all ITs fail on my system. This should work
> out-of-the-box, so I'll need to investigate the issue.
>
> And I'm pretty sure we can remove the cli package: you can't pass System
> properties to Maven, only arguments. And they should be passed as is to
> mvn.
> IT's should confirm that.
>
> Robert
>
> -- Origineel bericht --
> Van: "Jason van Zyl" 
> Aan: "Maven Developers List" 
> Verzonden: 7-12-2021 14:55:32
> Onderwerp: Re: reviewing Maven Wrapper before releasing
>
> >Everything builds and it generates the wrapper for a project in a way
> will be familiar to existing users. The switch for current users should,
> hopefully, be painless and transparent.
> >
> >Nice work Robert and Hervé. I put a notice on the GitHub page for the
> Takari version about the impending release at Apache, and provided pointers
> to the new Git repository and JIRA project.
> >
> >jvz
> >
> >>  On Dec 6, 2021, at 6:07 PM, Hervé BOUTEMY 
> wrote:
> >>
> >>  Hi,
> >>
> >>  Maven Wrapper has been donated to Apache Maven, imported to
> >>https://github.com/apache/maven-wrapper
> >>
> >>  Documentation published to https://maven.apache.org/wrapper/
> >>
> >>  Here is the list of fixes from previous 0.5.6 release:
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721&version=12350068
> >>
> >>
> >>  Please test and review so we can do a release soon
> >>
> >>  Regards,
> >>
> >>  Hervé
> >>
> >>
> >>
> >>  -
> >>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>  For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> >
> >
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: reviewing Maven Wrapper before releasing

[Slawomir Jaranowski]

Next question:

 - why use java 5 in maven-wrapper module .. it is not possible build with
java > 8 [1]

[1]
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-wrapper/job/master/

śr., 8 gru 2021 o 19:05 Hervé BOUTEMY  napisał(a):

> Le mercredi 8 décembre 2021, 15:52:46 CET Robert Scholte a écrit :
> > With mvn verify -Prun-its all ITs fail on my system. This should work
> > out-of-the-box, so I'll need to investigate the issue.
> >
> > And I'm pretty sure we can remove the cli package: you can't pass System
> > properties to Maven, only arguments. And they should be passed as is to
> > mvn.
> I must admit I don't know: I suppose that if the code is here from the
> beginning, it's for some use, it's just me who did not imagine the use case
>
> if everybody is confident that it's never used, no problem to remove it
>
> > IT's should confirm that.
> >
> > Robert
> >
> > -- Origineel bericht --
> > Van: "Jason van Zyl" 
> > Aan: "Maven Developers List" 
> > Verzonden: 7-12-2021 14:55:32
> > Onderwerp: Re: reviewing Maven Wrapper before releasing
> >
> > >Everything builds and it generates the wrapper for a project in a way
> will
> > >be familiar to existing users. The switch for current users should,
> > >hopefully, be painless and transparent.
> > >
> > >Nice work Robert and Hervé. I put a notice on the GitHub page for the
> > >Takari version about the impending release at Apache, and provided
> > >pointers to the new Git repository and JIRA project.
> > >
> > >jvz
> > >
> > >>  On Dec 6, 2021, at 6:07 PM, Hervé BOUTEMY 
> wrote:
> > >>
> > >>  Hi,
> > >>
> > >>  Maven Wrapper has been donated to Apache Maven, imported to
> > >>
> > >>https://github.com/apache/maven-wrapper
> > >>
> > >>  Documentation published to https://maven.apache.org/wrapper/
> > >>
> > >>  Here is the list of fixes from previous 0.5.6 release:
> > >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721&;
> > >>version=12350068>>
> > >>  Please test and review so we can do a release soon
> > >>
> > >>  Regards,
> > >>
> > >>  Hervé
> > >>
> > >>
> > >>
> > >>  -
> > >>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >>  For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >-
> > >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: reviewing Maven Wrapper before releasing

[Slawomir Jaranowski]

I created issues with the proposition of improvement:

https://issues.apache.org/jira/browse/MWRAPPER-31
https://issues.apache.org/jira/browse/MWRAPPER-32
https://issues.apache.org/jira/browse/MWRAPPER-33

please assign a version to fix ... if it is applicable.

śr., 8 gru 2021 o 19:47 Hervé BOUTEMY  napisał(a):

> because it's as it was imported:
> https://github.com/takari/maven-wrapper/blob/master/pom.xml#L21
> I refactored but kept everything as equivalent as possible
>
> we can update the value if it has an interest, with associated Jira issue
>
> Regards,
>
> Hervé
>
> Le mercredi 8 décembre 2021, 19:14:55 CET Slawomir Jaranowski a écrit :
> > Next question:
> >
> >  - why use java 5 in maven-wrapper module .. it is not possible build
> with
> > java > 8 [1]
> >
> > [1]
> >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-wrapper/job/ma
> > ster/
> > śr., 8 gru 2021 o 19:05 Hervé BOUTEMY 
> napisał(a):
> > > Le mercredi 8 décembre 2021, 15:52:46 CET Robert Scholte a écrit :
> > > > With mvn verify -Prun-its all ITs fail on my system. This should work
> > > > out-of-the-box, so I'll need to investigate the issue.
> > > >
> > > > And I'm pretty sure we can remove the cli package: you can't pass
> System
> > > > properties to Maven, only arguments. And they should be passed as is
> to
> > > > mvn.
> > >
> > > I must admit I don't know: I suppose that if the code is here from the
> > > beginning, it's for some use, it's just me who did not imagine the use
> > > case
> > >
> > > if everybody is confident that it's never used, no problem to remove it
> > >
> > > > IT's should confirm that.
> > > >
> > > > Robert
> > > >
> > > > -- Origineel bericht --
> > > > Van: "Jason van Zyl" 
> > > > Aan: "Maven Developers List" 
> > > > Verzonden: 7-12-2021 14:55:32
> > > > Onderwerp: Re: reviewing Maven Wrapper before releasing
> > > >
> > > > >Everything builds and it generates the wrapper for a project in a
> way
> > >
> > > will
> > >
> > > > >be familiar to existing users. The switch for current users should,
> > > > >hopefully, be painless and transparent.
> > > > >
> > > > >Nice work Robert and Hervé. I put a notice on the GitHub page for
> the
> > > > >Takari version about the impending release at Apache, and provided
> > > > >pointers to the new Git repository and JIRA project.
> > > > >
> > > > >jvz
> > > > >
> > > > >>  On Dec 6, 2021, at 6:07 PM, Hervé BOUTEMY  >
> > >
> > > wrote:
> > > > >>  Hi,
> > > > >>
> > > > >>  Maven Wrapper has been donated to Apache Maven, imported to
> > > > >>
> > > > >>https://github.com/apache/maven-wrapper
> > > > >>
> > > > >>  Documentation published to https://maven.apache.org/wrapper/
> > >
> > > > >>  Here is the list of fixes from previous 0.5.6 release:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721&;
> > >
> > > > >>version=12350068>>
> > > > >>
> > > > >>  Please test and review so we can do a release soon
> > > > >>
> > > > >>  Regards,
> > > > >>
> > > > >>  Hervé
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> 
> > > > >>  -
> > > > >>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > >>  For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > >
> >-
> > > > >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > >For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: reviewing Maven Wrapper before releasing

[Slawomir Jaranowski]

In current project configuration it is a bug rather ... We can use a
wrapper with java 5 but we can't install it because the plugin requires
java 8 ...

śr., 8 gru 2021 o 20:18 Xeno Amess  napisał(a):

> +1 for forcing more people quit java 5,6,7， as even 17 is out.
> 8 is the minimum version normal people can accept，others be zombies who do
> not need to be maintained IMO. They can use original wrapper plugin anyway.
> If we do not force them when beginning，it is harder to add the liminition
> later.
>
> XenoAmess
> ____
> From: Slawomir Jaranowski 
> Sent: Thursday, December 9, 2021 3:11:42 AM
> To: Maven Developers List 
> Subject: Re: reviewing Maven Wrapper before releasing
>
> I created issues with the proposition of improvement:
>
> https://issues.apache.org/jira/browse/MWRAPPER-31
> https://issues.apache.org/jira/browse/MWRAPPER-32
> https://issues.apache.org/jira/browse/MWRAPPER-33
>
> please assign a version to fix ... if it is applicable.
>
> śr., 8 gru 2021 o 19:47 Hervé BOUTEMY  napisał(a):
>
> > because it's as it was imported:
> > https://github.com/takari/maven-wrapper/blob/master/pom.xml#L21
> > I refactored but kept everything as equivalent as possible
> >
> > we can update the value if it has an interest, with associated Jira issue
> >
> > Regards,
> >
> > Hervé
> >
> > Le mercredi 8 décembre 2021, 19:14:55 CET Slawomir Jaranowski a écrit :
> > > Next question:
> > >
> > >  - why use java 5 in maven-wrapper module .. it is not possible build
> > with
> > > java > 8 [1]
> > >
> > > [1]
> > >
> >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-wrapper/job/ma
> > > ster/
> > > śr., 8 gru 2021 o 19:05 Hervé BOUTEMY 
> > napisał(a):
> > > > Le mercredi 8 décembre 2021, 15:52:46 CET Robert Scholte a écrit :
> > > > > With mvn verify -Prun-its all ITs fail on my system. This should
> work
> > > > > out-of-the-box, so I'll need to investigate the issue.
> > > > >
> > > > > And I'm pretty sure we can remove the cli package: you can't pass
> > System
> > > > > properties to Maven, only arguments. And they should be passed as
> is
> > to
> > > > > mvn.
> > > >
> > > > I must admit I don't know: I suppose that if the code is here from
> the
> > > > beginning, it's for some use, it's just me who did not imagine the
> use
> > > > case
> > > >
> > > > if everybody is confident that it's never used, no problem to remove
> it
> > > >
> > > > > IT's should confirm that.
> > > > >
> > > > > Robert
> > > > >
> > > > > -- Origineel bericht --
> > > > > Van: "Jason van Zyl" 
> > > > > Aan: "Maven Developers List" 
> > > > > Verzonden: 7-12-2021 14:55:32
> > > > > Onderwerp: Re: reviewing Maven Wrapper before releasing
> > > > >
> > > > > >Everything builds and it generates the wrapper for a project in a
> > way
> > > >
> > > > will
> > > >
> > > > > >be familiar to existing users. The switch for current users
> should,
> > > > > >hopefully, be painless and transparent.
> > > > > >
> > > > > >Nice work Robert and Hervé. I put a notice on the GitHub page for
> > the
> > > > > >Takari version about the impending release at Apache, and provided
> > > > > >pointers to the new Git repository and JIRA project.
> > > > > >
> > > > > >jvz
> > > > > >
> > > > > >>  On Dec 6, 2021, at 6:07 PM, Hervé BOUTEMY <
> herve.bout...@free.fr
> > >
> > > >
> > > > wrote:
> > > > > >>  Hi,
> > > > > >>
> > > > > >>  Maven Wrapper has been donated to Apache Maven, imported to
> > > > > >>
> > > > > >>https://github.com/apache/maven-wrapper
> > > > > >>
> > > > > >>  Documentation published to https://maven.apache.org/wrapper/
> > > >
> > > > > >>  Here is the list of fixes from previous 0.5.6 release:
> > > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?project

Re: reviewing Maven Wrapper before releasing

[Slawomir Jaranowski]

In order to run proper IT test by maven-invoker-plugin we should provide
invoker.properties like:

invoker.goals.1 = wraper:wrapper

invoker.goals.2 = validate
invoker.mavenExecutable.2 = ./mvnw
invoker.os.family.2 = unix, mac

invoker.goals.3 = validate
invoker.mavenExecutable.3 = ./mvnw.cmd
invoker.os.family.3 = windows

but 
  - mavenExecutable - can be set on global configuration only
  - invoker.os.family - not support indexing ...

So first improvement on  maven-invoker-plugin will be needed ...
or switch to another tools for IT testing
or try to complicate maven-invoker configuration - I don't sure if will be
posible

I can take care about changes in maven-invoker-plugin if you wish


pt., 10 gru 2021 o 11:03 Robert Scholte  napisał(a):

> I need more time.
>
> e.g. it looks like type=source doesn't use the Java sourcefile to
> download the wrapper.
> now that the plugin and wrapper are combined in one project, the ITs are
> incomplete.
> They should call both the wrapper-goal and something like 'mvnw
> --version' to ensure it is working (this used to be done in
> maven-integration-testing)
>
> thanks,
> Robert
>
> -- Origineel bericht --
> Van: "Hervé BOUTEMY" 
> Aan: "Maven Developers List" 
> Verzonden: 10-12-2021 08:08:57
> Onderwerp: Re: reviewing Maven Wrapper before releasing
>
> >thank you to everybody who reviewed, discussed, contributed
> >
> >we now have 16 issues fixed, everything seems stable
> >
> >if nobody objects, I'll start a release over the week-end
> >
> >Regards,
> >
> >Hervé
> >
> >Le mardi 7 décembre 2021, 00:07:41 CET Hervé BOUTEMY a écrit :
> >>  Hi,
> >>
> >>  Maven Wrapper has been donated to Apache Maven, imported to
> >>https://github.com/apache/maven-wrapper
> >>
> >>  Documentation published to https://maven.apache.org/wrapper/
> >>
> >>  Here is the list of fixes from previous 0.5.6 release:
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721&ve
> >>  rsion=12350068
> >>
> >>
> >>  Please test and review so we can do a release soon
> >>
> >>  Regards,
> >>
> >>  Hervé
> >>
> >>
> >>
> >>  -
> >>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>  For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> >
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: reviewing Maven Wrapper before releasing

[Slawomir Jaranowski]

Maybe mrm-maven-plugin can be used for mock Central for downloading wrapper.

sob., 11 gru 2021 o 09:03 Hervé BOUTEMY  napisał(a):

> I'm trying an "exec:exec" approach
> https://github.com/apache/maven-wrapper/tree/it_run_mvnw
>
> the only tricky case is for source distribution type to download the
> wrapper
> that is not available on central
>
> perhaps I'll simply skip that one for now: we'll have time to improve later
>
> Le vendredi 10 décembre 2021, 12:56:23 CET Slawomir Jaranowski a écrit :
> > In order to run proper IT test by maven-invoker-plugin we should provide
> > invoker.properties like:
> >
> > invoker.goals.1 = wraper:wrapper
> >
> > invoker.goals.2 = validate
> > invoker.mavenExecutable.2 = ./mvnw
> > invoker.os.family.2 = unix, mac
> >
> > invoker.goals.3 = validate
> > invoker.mavenExecutable.3 = ./mvnw.cmd
> > invoker.os.family.3 = windows
> >
> > but 
> >   - mavenExecutable - can be set on global configuration only
> >   - invoker.os.family - not support indexing ...
> >
> > So first improvement on  maven-invoker-plugin will be needed ...
> > or switch to another tools for IT testing
> > or try to complicate maven-invoker configuration - I don't sure if will
> be
> > posible
> >
> > I can take care about changes in maven-invoker-plugin if you wish
> >
> > pt., 10 gru 2021 o 11:03 Robert Scholte 
> napisał(a):
> > > I need more time.
> > >
> > > e.g. it looks like type=source doesn't use the Java sourcefile to
> > > download the wrapper.
> > > now that the plugin and wrapper are combined in one project, the ITs
> are
> > > incomplete.
> > > They should call both the wrapper-goal and something like 'mvnw
> > > --version' to ensure it is working (this used to be done in
> > > maven-integration-testing)
> > >
> > > thanks,
> > > Robert
> > >
> > > -- Origineel bericht --
> > > Van: "Hervé BOUTEMY" 
> > > Aan: "Maven Developers List" 
> > > Verzonden: 10-12-2021 08:08:57
> > > Onderwerp: Re: reviewing Maven Wrapper before releasing
> > >
> > > >thank you to everybody who reviewed, discussed, contributed
> > > >
> > > >we now have 16 issues fixed, everything seems stable
> > > >
> > > >if nobody objects, I'll start a release over the week-end
> > > >
> > > >Regards,
> > > >
> > > >Hervé
> > > >
> > > >Le mardi 7 décembre 2021, 00:07:41 CET Hervé BOUTEMY a écrit :
> > > >>  Hi,
> > > >>
> > > >>  Maven Wrapper has been donated to Apache Maven, imported to
> > > >>
> > > >>https://github.com/apache/maven-wrapper
> > > >>
> > > >>  Documentation published to https://maven.apache.org/wrapper/
> > >
> > > >>  Here is the list of fixes from previous 0.5.6 release:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721&;
> > > ve>
> > > >>  rsion=12350068
> > > >>
> > > >>
> > > >>  Please test and review so we can do a release soon
> > > >>
> > > >>  Regards,
> > > >>
> > > >>  Hervé
> > > >>
> > > >>
> > > >>
> > > >>
> -
> > > >>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >>  For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >-
> > > >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: Welcome Sławomir Jaranowski as Maven Committer

[Slawomir Jaranowski]

Thanks everybody for the warm welcome.

wt., 14 gru 2021 o 14:59 Arnaud Héritier  napisał(a):

> Welcome Slawomir !
>
>
> On Tue, Dec 14, 2021 at 2:23 PM Karl Heinz Marbaise 
> wrote:
>
> > Hi to Sławomir,
> >
> > Welcome to the team.
> >
> > Glad to have you on board.
> >
> > Enjoy..
> >
> > Kind regards
> > Karl Heinz Marbaise
> > On 14.12.21 11:10, Robert Scholte wrote:
> > > The Maven PMC invited Sławomir to become a committer and he has
> accepted
> > > it.
> > >
> > > Enjoy improving Apache Maven!
> > >
> > > thanks,
> > > Robert
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Arnaud Héritier
> Twitter/GitHub/... : aheritier
>


-- 
Sławomir Jaranowski

Using of Travis

[Slawomir Jaranowski]

Hi,

As the primary CI environment we use Jenkins.
Now also using GH Actions  ...
I think that those both are enough.

Some projects contain scripts for Travis, like surefire.

Do we want to still use Travis?

-- 
Sławomir Jaranowski

Supported versions policy - Maven Plugins

[Slawomir Jaranowski]

Hi,

On example of the Surefire project I would build some policy /
documentation / information about which versions are supported and what for.
It can be generally for all maintenanced Maven Plugins by AFS.

=

First topic what version of plugin should be supported, in the Surefire I
see opened releases in jira [1] for
- Backlog (???)
- 3.0
- 3.0.1
- 3.0.0-M6
- 2.22.3
- 2.21.1

I'm not sure if we can support so many versions at the same time ...

In the Surefire case Tibor's opinion will be very appreciated.

We should should clear message for user which version and with scope is
supported, eg:
3.x - only latest version for bug fixes and new feature
2.x - only for security vulnerability

Currently Surefire has reported 269 issues without clear policy it is not
possible to support them.

=

Second topic - what JDK and Maven Api should be supported by plugins.
I see that - Since June 2020, Maven Plugin API used by plugins >= 3.1.0 +
Java 8 prerequisites [2]

But also I see that some of plugin in last time has updated api to 3.2.5

In this topic we should list supported matrix, like
Maven: 3.2.x, 3.3.x ... JDK: 1.8, 11, 17, ...
and use the same matrix on CI to be sure

=

After decision taken I think that such information should be on page:
"Maven Plugins" [3]

Probably the topic was discussed ... but I don't see the result ... so try
to start again.

[1]
https://issues.apache.org/jira/projects/SUREFIRE?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
[2] https://maven.apache.org/developers/compatibility-plan.html
[3] https://maven.apache.org/plugins/index.html

-- 
Sławomir Jaranowski

Re: Supported versions policy - Maven Plugins

[Slawomir Jaranowski]

Hi,

Ok, so for surefire
3.x will be the target version and all new features will be merged here
2.x -  what potential future work do you see - Romani?



pt., 17 gru 2021 o 14:25 Romain Manni-Bucau 
napisał(a):

> Hi,
>
> Think we already discussed it partially and said we were in a bad state
> because only 3.x is supported/worked but no final release is available and
> that 2.x would be best effort only (not even any guarantee about CVE fixes
> until somebody does the job like last time).
> So 3.0.0 is required, M6 is optional IMHO - several of us want to go final
> directly but Tibor can want another milestone maybe?, and a 2.x to handle
> potential future work can be desired but others can be dropped I think.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 17 déc. 2021 à 12:55, Slawomir Jaranowski 
> a écrit :
>
> > Hi,
> >
> > On example of the Surefire project I would build some policy /
> > documentation / information about which versions are supported and what
> > for.
> > It can be generally for all maintenanced Maven Plugins by AFS.
> >
> > =
> >
> > First topic what version of plugin should be supported, in the Surefire I
> > see opened releases in jira [1] for
> > - Backlog (???)
> > - 3.0
> > - 3.0.1
> > - 3.0.0-M6
> > - 2.22.3
> > - 2.21.1
> >
> > I'm not sure if we can support so many versions at the same time ...
> >
> > In the Surefire case Tibor's opinion will be very appreciated.
> >
> > We should should clear message for user which version and with scope is
> > supported, eg:
> > 3.x - only latest version for bug fixes and new feature
> > 2.x - only for security vulnerability
> >
> > Currently Surefire has reported 269 issues without clear policy it is not
> > possible to support them.
> >
> > =
> >
> > Second topic - what JDK and Maven Api should be supported by plugins.
> > I see that - Since June 2020, Maven Plugin API used by plugins >= 3.1.0 +
> > Java 8 prerequisites [2]
> >
> > But also I see that some of plugin in last time has updated api to 3.2.5
> >
> > In this topic we should list supported matrix, like
> > Maven: 3.2.x, 3.3.x ... JDK: 1.8, 11, 17, ...
> > and use the same matrix on CI to be sure
> >
> > =
> >
> > After decision taken I think that such information should be on page:
> > "Maven Plugins" [3]
> >
> > Probably the topic was discussed ... but I don't see the result ... so
> try
> > to start again.
> >
> > [1]
> >
> >
> https://issues.apache.org/jira/projects/SUREFIRE?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
> > [2] https://maven.apache.org/developers/compatibility-plan.html
> > [3] https://maven.apache.org/plugins/index.html
> >
> > --
> > Sławomir Jaranowski
> >
>


-- 
Sławomir Jaranowski

Re: Surefire next release

[Slawomir Jaranowski]

What do you think about:

https://issues.apache.org/jira/browse/SUREFIRE-1959 - even 3.2.5
https://issues.apache.org/jira/browse/SUREFIRE-1955 ... yes i know not all
like it, but when ... if we think about 3.0.0 version it be ok i think

before release ...

niedz., 19 gru 2021 o 19:02 Romain Manni-Bucau 
napisał(a):

> AFAIK there was no real change since "Cutting a release for Surefire?" from
> april where work was not production ready.
> That said I'm happy to get a 3.0.0 and maybe a 3.1.0 later since we
> abandonned 2 officially and 3 looks quite stable enough.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 19 déc. 2021 à 18:58, Gary Gregory  a
> écrit :
>
> > At work, some of my colleagues balk at seeing milestone versions in our
> > builds. What is preventing the next version from being "3.0.0", no "M". I
> > thought I read here a while back that the code was production ready.
> >
> > Gary
> >
> > On Sun, Dec 19, 2021, 12:26 Olivier Lamy  wrote:
> >
> > > Sounds good.
> > > I'd really like to review/include this PR as well
> > > https://github.com/apache/maven-surefire/pull/400
> > > I hope to finish the review for this one during the week.
> > >
> > > On Sun, 19 Dec 2021 at 18:22, Slawomir Jaranowski <
> > s.jaranow...@gmail.com>
> > > wrote:
> > >
> > > > Hi
> > > >
> > > > Last time I did the surefire build more stable.
> > > >
> > > > Now build looks ok on Jenkins
> > > >
> > > >
> > >
> >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-surefire/job/master/
> > > >
> > > > I prepared proposition for using shared GitHub action for project
> > > > https://github.com/apache/maven-surefire/pull/410
> > > >
> > > > Most of the tests look stable now.
> > > >
> > > > There are still about 260 issues on Jira.
> > > > Many of them was create some year ago ... so probably are not actual
> or
> > > are
> > > > duplicated
> > > > Some look like they are in progress without finishing,
> > > > I will work with Jira. I will try to ask about current issue status.
> > > >
> > > > The last release was in Jun 2020 so 1 and half year ago.
> > > > I think that we should plan the next release for Surefire which can
> > help
> > > > resolve some of the issues.
> > > >
> > > > I don't know what the next version should be - in code we have
> > > > 3.0.0-M6-SNAPSHOT.
> > > >
> > > > There are also about 30 PRs, some of them also created a years ago ..
> > > > should be closed or merged.
> > > >
> > > > I need your help to plan and finally prepare for release.
> > > >
> > > >
> > > > Below is the result of the investigation for project status from
> > > repository
> > > > perspective and Jira perspective.
> > > >
> > > >
> > > > Current repository status
> > > >
> > > > ===
> > > > branch release/2.22.3
> > > >
> > > > f14da3b89 [SUREFIRE-1764] Upgrade JUnit Platform to 1.6.1
> > > > https://github.com/apache/maven-surefire/commit/f14da3b89
> > > >
> > > > current version in master is 1.3.2 for junit-platform-launcher - the
> > > newest
> > > > available version is 1.8.2
> > > > SUREFIRE-1764 - reopened
> > > >
> > > > ===
> > > > branch release/3.0.0-M6
> > > >
> > > > 8a6b33453 (upstream/release/3.0.0-M6, origin/release/3.0.0-M6)
> > > > [SUREFIRE-1432] Add extension interface with two implementations for
> > > > trimStackTrace
> > > > https://github.com/apache/maven-surefire/commit/8a6b33453
> > > >
> > > > SUREFIRE-1432 - reopened
> > > >
> > > > ===
> > > > There is about 130 commit to