Re: [VOTE] Release Apache Maven 3.9.7

[Andres Almiray]

Got it.

I'd suggest raising a ticket on the Maven Wrapper project to support sha512
checks if one does not already exist.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
https://andresalmiray.com
https://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Fri, May 24, 2024 at 6:28 PM Jorge Solórzano  wrote:

> On Fri, May 24, 2024 at 6:19 PM Andres Almiray  wrote:
>
> > Looks like sha1 and sha512 are published already. Do you also need sha256
> > explicitly?
> >
>
> Well, until Maven Wrapper also supports verifying sha512, yes, having
> sha256 will be helpful.
>
> Right now you can only set wrapperSha256Sum and distributionSha256Sum.
>
> This is not for this release since is in the process of voting and that
> will require a new release, but just for consideration.
>
>
> > 
> >
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/4.0.0-alpha-13/
> >
> > Cheers,
> > Andres
> >
> >
>

Re: [VOTE] Release Apache Maven 3.9.7

[Andres Almiray]

Looks like sha1 and sha512 are published already. Do you also need sha256
explicitly?


https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/4.0.0-alpha-13/

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
https://andresalmiray.com
https://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Fri, May 24, 2024 at 6:15 PM Jorge Solórzano  wrote:

> +1
>
> Can I kindly ask that Maven releases also contain sha256 checksums? This
> could help to quickly check the checksum used in the wrapper.
>
> Thanks!
>
> On Fri, May 24, 2024 at 12:39 AM Guillaume Nodet 
> wrote:
>
> > +1
> >
> > Le mer. 22 mai 2024 à 12:10, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > We solved 21 issues:
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353964
> > >
> > > 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
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-2125/
> > >
> > > Dev dist directory (binary bundles updated):
> > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.7/
> > >
> > > Source release checksums:
> > > apache-maven-3.9.7-src.tar.gz.sha512
> > >
> > >
> >
> a3c211ce683afbde9c4becf8b32397d14d3e7d8e8261094da037dcf27a697a93134440e055e7a9e7e26af2db543d4d9c4e7b0296560f5193df7ba90b9a68d1d1
> > >
> > > apache-maven-3.9.7-src.zip.sha512
> > >
> > >
> >
> cdd8249807e251d07c613a65120058993e47a4cbf7f6dbda8599c7ca7ab4ed3fedc727e651f43cba0e9b0d604055c1106c1243be64a1d52c5ddf72dbec5e65dc
> > >
> > > Staged site:
> > > https://maven.apache.org/ref/3-LATEST/
> > >
> > > Draft for release notes:
> > > https://github.com/apache/maven-site/pull/521
> > >
> > > Guide to testing staged releases:
> > > http://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for 72h
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> >
> >
> > --
> > 
> > Guillaume Nodet
> >
>

Re: Publish Via the Central Portal

[Andres Almiray]

Hello everyone,

In the meantime JReleaser offers support for both publishing to the Portal
and handling build poms

https://github.com/jreleaser/jreleaser/issues/1612
https://github.com/jreleaser/jreleaser/issues/1632

FWIW the Portal API is publicly available at
https://central.sonatype.org/publish/publish-portal-api/
Sonatype's plugin may not offer source code but JReleaser does. However,
it's implementation relies on Feign. You may study and adapt the code if
you feel like it, after all it's licensed under ASL v2

https://github.com/jreleaser/jreleaser/tree/main/sdks/jreleaser-mavencentral-java-sdk

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
https://andresalmiray.com
https://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Tue, Apr 30, 2024 at 12:05 PM Romain Manni-Bucau 
wrote:

> Hi,
>
> AFAIK and if I got right the info from Brian, this is not yet promoted and
> the primary solution but will become soon.
>
> Personally I'm not that shocked we were not consulted - we build plugin API
> for that exact purpose, let people do what they need to do.
>
> About maven-compat it i mainly about us making it obvious it will fail but
> I think it will be fixed for the final GA release.
>
> So from my small window there is no concern even if most of us using
> central outside the asf will be impacted sometime next year probably.
>
> 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. 30 avr. 2024 à 10:32, Slawomir Jaranowski 
> a écrit :
>
> > Hi,
> >
> > Does anyone try the new Sonatype Central Portal?
> > https://central.sonatype.org/publish-ea/publish-ea-guide/
> >
> > There is a new (*) Maven plugin provided by Sonatype for deployments:
> > https://central.sonatype.org/publish/publish-portal-maven/
> >
> > But I am afraid that this plugin will be similar
> > to nexus-staging-maven-plugin and still use maven-compat ...
> > Probably it will have a problem with Maven 4 ...
> > Also Sonatype did not publish a source code for it ...
> >
> >
> https://central.sonatype.com/artifact/org.sonatype.central/central-publishing-maven-plugin
> >
> > Also Sonatype did not publish a source code for it ...
> >
> > It also looks as standard Maven deployment will not work with the new
> > Central Portal API.
> >
> > I'm surprised that Sonatype did not consult or even announce such a new
> way
> > with the Maven community.
> >
> > --
> > Sławomir Jaranowski
> >
>

Re: User friendly release notes

[Andres Almiray]

First, I’d suggest following a commit message convention. You may define your 
own or follow an existing one such as 
https://www.conventionalcommits.org/en/v1.0.0/

Next, use a tool that can read, parse, and format commit messages. You’ll find 
plenty of options out there. I can pitch https://jreleaser.org/ 

Cheers
Andres

Sent from my primitive tricorder

> On 13 Mar 2024, at 23:58, Slawomir Jaranowski  wrote:
> 
> Hi,
> 
> Today's facts:
> 
> - We manage our issues in jira and all officala release notes are also in
> jira.
> - We sent an email in text  format to announce mailing list.
> - In project documentation we don't have a release notes
> 
> But as we see in:
> https://lists.apache.org/thread/pzd36lo6rtfn7c5s0x60xbj296xt1mvf
> today it is not a user-friendly way.
> 
> It looks as most usable will be to manage release notes also in GitHub at
> least as link to jira public url for release notes.
> Yes I know we don't have (or have old one like maven-changes-plugin)
> perfect tools to help with this process.
> 
> Any other propositions, ideas ?
> 
> --
> Sławomir Jaranowski

[MRESOLVER] AbstractMethodError in BasicRepositoryConnector

[Andres Almiray]

Hello everyone!

2 days ago I encountered a weird issue with maven-resolver 1.9.2 running
with MAven 3.8.6 (also checked with 3.8.7, same error) and Zulu 17. The
error is as follows

```

[ERROR] [nexus2] Exception in thread "main"
java.lang.AbstractMethodError: Receiver class
org.eclipse.aether.internal.impl.Maven2RepositoryLayoutFactory$Maven2RepositoryLayoutEx
does not define or inherit an implementation of the resolved method
'abstract java.util.List getChecksumAlgorithmFactories()' of interface
org.eclipse.aether.spi.connector.layout.RepositoryLayout.
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:220)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:514)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:402)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:229)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:207)
at 
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:262)
at 
org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:192)
at 
org.apache.maven.model.building.DefaultModelBuilder.importDependencyManagement(DefaultModelBuilder.java:1347)
at 
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:544)
at 
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:454)
at 
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:267)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:173)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:124)
at 
org.kordamp.maven.checker.cli.internal.PomParser.createMavenProject(PomParser.java:99)
at 
org.kordamp.maven.checker.cli.internal.PomParser.createMavenProject(PomParser.java:66)
at 
org.kordamp.maven.checker.cli.CheckMavenCentral.execute(CheckMavenCentral.java:45)
at 
org.kordamp.maven.checker.cli.AbstractCommand.call(AbstractCommand.java:99)
at 
org.kordamp.maven.checker.cli.CheckMavenCentral.call(CheckMavenCentral.java:30)
at 
org.kordamp.maven.checker.cli.AbstractCommand.call(AbstractCommand.java:33)
at picocli.CommandLine.executeUserObject(CommandLine.java:2041)
at picocli.CommandLine.access$1500(CommandLine.java:148)
at 
picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
at 
picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
at picocli.CommandLine.execute(CommandLine.java:2170)
at org.kordamp.maven.checker.cli.Main.execute(Main.java:69)
at org.kordamp.maven.checker.cli.Main.run(Main.java:55)
at org.kordamp.maven.checker.cli.Main.main(Main.java:47)

```

More details can be found here
https://github.com/jreleaser/jreleaser/issues/1149

In this case pomchecker is run as a CLI tool, with Maven 3.8.7 APIs bundled
in. I'm able to successfully run the tool with Java 11 on other projects.
Just wanted to see if anyone has seen a similar thing happening before
raising an issue at https://issues.apache.org/jira/projects/MRESOLVER/

I'm aware that resolver 1.9.3 didn't go through and that another release
may be coming soon.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
https://andresalmiray.com
https://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

Re: POC using release-drafter for github release

[Andres Almiray]

Hello everyone,

For what’s worth JReleaser supports a similar set of features for creating a 
changelog based on Git history.

For the time being JReleaser categorizes commit messages following your own 
conventions. The rules are inspired by release-drafter.

The pros are:
- set up your own conventions
- generated changelog can be stored anywhere, not just at the GH mirror
- may be used via jreleaser-maven-plugin
- works locally and on CI
- can post releases as drafts to allow manual edits
- can use templates to tweak parts or the whole changelog
- initial tag/release is configurable. Matter of fact may be uses to 
retroactively generate Git releases + changelog on projects that only have tags
- works with any Git service as it only requires reading local commit 
information

The cons are:
- does not read issue/PR labels to categorize commits. This feature may be 
added in the future
- some features require a local GH token for read access (when resolving 
username/emails from GH)

A PR is currently underway at the mvnd project to test it out 
https://github.com/apache/maven-mvnd/pull/574

Disclaimer: I’m the author of JReleaser. 

Cheers
Andres


Sent from my primitive tricorder

> On 9 Feb 2022, at 17:04, Tamás Cservenák  wrote:
> 
> Howdy,
> 
> Yes, looks good, but one thing bothers me:
> Does this mean that Maven projects -- if release-drafter is to be used --
> will have their release notes stored and accessible in their mirror
> repositories only?
> 
> T
> 
>> On Wed, Feb 9, 2022 at 4:57 PM Slawomir Jaranowski 
>> wrote:
>> 
>> Looks great.
>> 
>> To avoid all PR in the first release we can add an empty release note for
>> the latest release tag and then the new release draft should contains only
>> PR from the latest release not all.
>> 
>> śr., 9 lut 2022 o 05:10 Olivier Lamy  napisał(a):
>> 
>>> Hi
>>> Github has a feature to attach a release note to tag/release.
>>> The content is then used when dependabot generates his famous PR all
>>> over the world!! (yup a maven plugin generates a lot!!)
>>> Our current content is not very user friendly
>>> 
>>> While preparing the maven-compiler-plugin new release I have made some
>>> tests using release-drafter tool [1].
>>> This generates the content here:
>>> https://github.com/apache/maven-compiler-plugin/releases
>>> The release notes will automatically contains only content from PRs (PR
>>> must have a label to appear in a dedicated section otherwise they will be
>>> in the top, see mapping label/section here [2])
>>> This mapping is a default which can be shared between all project so the
>>> configuration is very simple see [3].
>>> Please note the first time it's used the first release will
>>> contain everything (all PRs) from the start as there is no first release.
>>> The process is manual at the end, after all of our release process steps,
>>> you just need to go to GH ui then publish the release (manual.
>>> modifications still possible).
>>> 
>>> comments? thoughts? complaints :)?
>>> 
>>> cheers
>>> Olivier
>>> 
>>> PS: if you want to use this be sure to modify manually the content before
>>> the publish as the content is regenerated for every merge PR
>>> 
>>> [1] https://github.com/release-drafter/release-drafter
>>> [2]
>>> 
>>> 
>> https://github.com/apache/maven-gh-actions-shared/blob/main/.github/release-drafter.yml
>>> [3]
>>> 
>>> 
>> https://github.com/apache/maven-compiler-plugin/blob/master/.github/release-drafter.yml
>>> and
>>> 
>>> 
>> https://github.com/apache/maven-compiler-plugin/blob/master/.github/workflows/release-drafter.yml
>>> 
>> 
>> 
>> --
>> Sławomir Jaranowski
>> 

Re: [VOTE] Release Maven Shade Plugin version 3.3.0

[Andres Almiray]

I'd appreciate if MSHADE-382 were to make the cut. A PR is ready for
(hopefully the last) review

https://github.com/apache/maven-shade-plugin/pull/90

Cheers,
Andres
---
Java Champion; Groovy Enthusiast
https://andresalmiray.com
https://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Wed, Jul 14, 2021 at 5:40 PM Elliotte Rusty Harold 
wrote:

> https://github.com/apache/maven-shade-plugin/pull/95 looks like it
> could be merged before release.
>
> On Wed, Jul 14, 2021 at 11:41 AM Michael Osipov 
> wrote:
> >
> > Hi,
> >
> > We solved 9 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12348391
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1655/
> >
> https://repository.apache.org/content/repositories/maven-1655/org/apache/maven/plugins/maven-shade-plugin/3.3.0/maven-shade-plugin-3.3.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-shade-plugin-3.3.0-source-release.zip
> > sha512:
> >
> eb84e09106febe41388903f7fbc66d7e85888005d78c075f2291a05a19eb22f53c3fd6953ec864d41c44f869dd13706126bac632d5d9511b75bbdc71a63b01ba
> >
> > Staging site:
> > http://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > http://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
> >
>
>
> --
> 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
>
>

Re: JPMS, Maven and test jars

[Andres Almiray]

Ralph,

Once you move test code to their own Maven module they become a top level 
module, that is, they have a life of their own as any other top level module.

In contrast -tests jars are not top level, but a “variant” (that’s why they 
have a classifier) of their owning top level module. 

Test jars must be published to a repository in order to be consumed, just like 
any other jar, variant or not. The only difference (at least that I can see) is 
that test jars may be downloaded using the coordinates of the owning module 
(plus test classifier) and their release cycle is tightly coupled with their 
owning module.

But if you take away the owning relationship you’re left with, well, just 
another regular Maven module.

Personally I prefer the use of explicit dependencies and modules, barely make 
use of test jar support, but I do recognize others feel differently about them 
and prefer the workflow enables by such jars and conventions

Cheers
Andres

Sent from my primitive tricorder

> On 22 Jun 2021, at 23:20, Ralph Goers  wrote:
> 
> 
> 
>> On Jun 22, 2021, at 11:16 AM, Robert Scholte  wrote:
>> 
>> If I understand correctly you want both log4j-core main classes and test 
>> classes be distributed as modularized jars.
>> To me with JPMS you should move the modularized test-classes to a separate 
>> Maven module as a first citizen artifact.
>> That should make it a lot easier.
> 
> Robert,
> 
> I have a question on the above. I am generating log4j-core-3.0.0-SNAPSHOT.jar 
> and log4j-core-3.0.0-SNAPSHOT-tests.jar. 
> If the source is left in log4j-core and I create a log4j-core-tests module 
> what would I specify in the pom to get it to create the
> test jar as log4j-core-3.0.0-SNAPSHOT-tests.jar? I would not want it to be 
> log4j-core-tests-3.0.0-SNAPSHOT.jar as that 
> would not be understood to be a test jar.
> 
> Ralph
> 
> 
> 
> 
> -
> 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

Re: JPMS, Maven and test jars

[Andres Almiray]

Ralph,

Apologies. I did not link to Jipsy as a suggestion to be used as a dependency 
but rather as an example of how the ModiTect plugin may be applied to a project 
that produces and tests an APT. 

I believe Jipsy has a 2nd Maven module that produces a “test” jar without it 
being an actual test jar, that is, with the -tests classifier. This is the 
approach mentioned by Robert. 

ModiTect helps you keep a codebase compatible with Java 8 while also supporting 
JPMS with full module descriptors added to the final jar as an MRJAR. 

Hope this helps. 

Cheers
Andres

Sent from my primitive tricorder

> On 22 Jun 2021, at 22:42, Ralph Goers  wrote:
> 
> Andres,
> 
> I looked at moditect when I first started doing the work. I’m afraid I am not 
> understanding how 
> it could help solve the problem with the test jar and unit tests. Could you 
> please explain that?
> 
> I am also not sure I understand how Jipsy will help. Log4j generates the file 
> in META-INF/services 
> when it generates the service class. It does not add the provides statement 
> to module-info.java. 
> Perhaps if it also did that it would bypass the compiler error saying the 
> service can’t be found. 
> 
> That is certainly worth looking into.
> 
> Ralph
> 
> 
> 
>> On Jun 22, 2021, at 12:41 AM, Andres Almiray  wrote:
>> 
>> Have you tried using the ModiTect Maven plugin?
>> 
>> 
>> https://github.com/moditect/moditect
>> 
>> There are many ways to use it:
>> - with explicit module-info.java
>> - with an embedded DSL in the pom.xml
>> - with an embedded module descriptor in the pom.xml
>> 
>> Ii use the last option on Jipsy [https://github.com/kordamp/jipsy/], which
>> happens to define an APT as well.
>> 
>> https://github.com/kordamp/jipsy/blob/master/jipsy-processor/pom.xml
>> 
>> Cheers,
>> Andres
>> 
>> ---
>> Java Champion; Groovy Enthusiast
>> http://andresalmiray.com
>> http://www.linkedin.com/in/aalmiray
>> --
>> What goes up, must come down. Ask any system administrator.
>> There are 10 types of people in the world: Those who understand binary, and
>> those who don't.
>> To understand recursion, we must first understand recursion.
>> 
>> 
>>> On Tue, Jun 22, 2021 at 7:02 AM Ralph Goers 
>>> wrote:
>>> 
>>> Sorry for posting again. I really need to proof-read better. Please ignore
>>> the prior email.
>>> 
>>> I have recently had quite an adventure modifying several of Log4j’s Maven
>>> modules to
>>> implement JPMS on our master branch. It was an adventure due to a few
>>> issues:
>>> 
>>> 1. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826 <
>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826>.
>>>  This bug has been fixed in Java 17 but Log4j uses Java 11 to build.
>>> 2. Log4j-plugins builds an annotation processor, packages it with the
>>> annotations
>>>  and classes necessary to build and run plugins, creates and test jar
>>> and runs unit tests.
>>> 3. It is not possible to compile an annotation processor with a
>>> module-info.java present.
>>>  The compile will fail because it can’t find the annotation processor
>>> “service” when
>>>  compiling module-info.java.
>>> 4. It is very difficult to compile an annotation processor and then use it
>>> in the same Maven
>>>  module. JPMS expects the annotation processor to either be on the
>>> classpath or specified
>>>  with the processorpath option. When a module-info.java is present,
>>> Maven automatically
>>>  moves everything to the module path. Maven only supports using
>>> coordinates to specify the
>>>  processor path, which don’t exist when the processor is in the same
>>> module. The only way
>>>  to solve this is to compile all the classes with proc=only without a
>>> module-info.java present.
>>> 5. Although number 4 might seem bad, it really doesn’t matter because
>>> javac will fail if a
>>>  module-info.java is present because module-info.java will have a
>>> reference to the service
>>>  class being generated by the annotation processor and for some reason
>>> module-info.java
>>>  is resolved before the annotation processor runs.
>>> 6. If the main set of classes are compiled with a module-info.java every
>>> other compile
>>>  in the Maven module must also be modularized. Likewise, if the main
>>> module does
>

Re: JPMS, Maven and test jars

[Andres Almiray]

Have you tried using the ModiTect Maven plugin?


https://github.com/moditect/moditect

There are many ways to use it:
- with explicit module-info.java
- with an embedded DSL in the pom.xml
- with an embedded module descriptor in the pom.xml

Ii use the last option on Jipsy [https://github.com/kordamp/jipsy/], which
happens to define an APT as well.

https://github.com/kordamp/jipsy/blob/master/jipsy-processor/pom.xml

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Tue, Jun 22, 2021 at 7:02 AM Ralph Goers 
wrote:

> Sorry for posting again. I really need to proof-read better. Please ignore
> the prior email.
>
> I have recently had quite an adventure modifying several of Log4j’s Maven
> modules to
> implement JPMS on our master branch. It was an adventure due to a few
> issues:
>
> 1. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826 <
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826>.
>This bug has been fixed in Java 17 but Log4j uses Java 11 to build.
> 2. Log4j-plugins builds an annotation processor, packages it with the
> annotations
>and classes necessary to build and run plugins, creates and test jar
> and runs unit tests.
> 3. It is not possible to compile an annotation processor with a
> module-info.java present.
>The compile will fail because it can’t find the annotation processor
> “service” when
>compiling module-info.java.
> 4. It is very difficult to compile an annotation processor and then use it
> in the same Maven
>module. JPMS expects the annotation processor to either be on the
> classpath or specified
>with the processorpath option. When a module-info.java is present,
> Maven automatically
>moves everything to the module path. Maven only supports using
> coordinates to specify the
>processor path, which don’t exist when the processor is in the same
> module. The only way
>to solve this is to compile all the classes with proc=only without a
> module-info.java present.
> 5. Although number 4 might seem bad, it really doesn’t matter because
> javac will fail if a
>module-info.java is present because module-info.java will have a
> reference to the service
>class being generated by the annotation processor and for some reason
> module-info.java
>is resolved before the annotation processor runs.
> 6. If the main set of classes are compiled with a module-info.java every
> other compile
>in the Maven module must also be modularized. Likewise, if the main
> module does
>not contain a module-info.java no other compile can either.
> 7. JPMS requires that every module have its own package space with no
> overlap
> with any other JPMS module.
>
> So while generating the log4j-plugins module is quite painful, generating
> log4j-core isn’t
> much better. That is actually the primary focus for this list.
>
> Log4j-core consists of the main classes packaged in the jar, a test jar
> that is used by
> downstream Maven modules, and the unit tests. Prior to JPMS one would just
> create
> the main jar and then package all the test classes and unit tests in a
> test jar. This can
> no longer be done with JPMS.
>
> When a project publishes a test jar along with the main jar, just like any
> other JPMS
> module. the test jar cannot use the package space of the main classes.
> Log4j core
> uses org.apache.logging.log4j.core so I placed all the test utility
> classes under
> org.apache.logging.log4j.core.test. However, the unit tests all need to be
> packaged
> in the main package space since its module-info.java “extends” the main
> module and
> several unit tests are required to be in the same main package so that
> they can access
> package private methods specifically provided for testing.
>
> In order to get this to work I had to perform the following steps:
>
> • Compile all the main classes except module-info.java with the
> Plugin annotation processor.
> • Compile the main module-info.java.
> • Compile the test classes used by other modules with
> module-info.java and
>   using the plugin preprocessor.
> • Package these test classes in a test jar.
> • Delete the module-info and generated source for the test classes.
> • Move the main module-info to a temp location.
> • Compile the unit test classes without module-info.java.
> • Move the main module-info back to the classes directory.
> • Compile module-info.java for unit tests.
> • Run the unit tests.
> • Create the main jar if the unit tests pass.
>
> Were it not for JDK-8265826 I believe this could have been simplified
> somewhat to:
>
> 

Re: [ANN] Apache Maven JXR Plugin 3.1.1 Released

[Andres Almiray]

Woohoo!

Just reading the issue list and immediately JXR-142 jumped and scared me.

CDI != JSR-330

CDI is much, much more than that (bigger, fatter, etc) and requires more
dependencies and setup to work.

It looks like the change makes use of SISU which is already in use at other
places. phew.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Thu, Apr 22, 2021 at 6:27 PM Robert Scholte  wrote:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven JXR Plugin, version 3.1.1
>
> The JXR Plugin produces a cross-reference of the project's sources. The
> generated reports make it easier for the user to reference or find specific
> lines of code. It is also handy when used with the PMD Plugin for
> referencing errors found in the code.
>
> https://maven.apache.org/jxr/maven-jxr-plugin/
>
> You should specify the version in your project's plugin configuration:
>
> 
> org.apache.maven.plugins
> maven-jxr-plugin
> 3.1.1
> 
>
> You can download the appropriate sources etc. from the download page:
>
> https://maven.apache.org/jxr/download.html
>
>
>
> Release Notes - Maven JXR - Version 3.1.1
>
> ** Bug
> * [JXR-141] - Invalid HTML generation when having multiple occurences
> of the same class on one line
> * [JXR-153] - JxrReportTest depends on platform default encoding
> * [JXR-154] - xref-test package summary lists also classes from main
> source directories
> * [JXR-158] - StringEntry shouldn't be Comparable
>
> ** Improvement
>
> * [JXR-142] - Switch to CDI
> * [JXR-143] - New goals jxr-no-fork and test-jxr-no-fork which will
> not invoke generate-*-sources
> * [JXR-144] - Require Maven 3.1.0
> * [JXR-147] - make build Reproducible
> * [JXR-150] - AbstractJxrReport.java uses or overrides a deprecated
> API.
> * [JXR-151] - Update apache commons
>
> ** Dependency upgrade
> * [JXR-146] - upgrade Doxia Sitetools to 1.9.2 to remove dependency on
> Struts
> * [JXR-159] - Prerequisites - Maven 3.1.1
>
>
> Enjoy,
>
>
> -The Apache Maven team
>

Re: Resolving plugin dependency versions from

[Andres Almiray]

Oliver,

A ticket already exists: https://issues.apache.org/jira/browse/MNG-5588

Coincidentally, Hervé and I did a quick spike last week and have a PoC
(with red tests at the moment).

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Tue, Apr 13, 2021 at 10:55 PM Romain Manni-Bucau 
wrote:

> Hi Oliver,
>
> Did you try to write this feature as an extension?
> For plugins it sounds more relevant since not transitive nor consumed
> (compared to dependencies).
> You fully control it this way and can potentially kind of inject a bom in
> plugin dependencies.
>
> Hope it helps,
> Romain
>
>
> Le mar. 13 avr. 2021 à 22:41, Oliver Drotbohm  a
> écrit :
>
> > Hi all,
> >
> > I was wondering if you have ever discussed to apply versions defined in
> >  to plugin dependencies? BOMs have become a
> > ubiquitous thing today but as a BOM author, you currently have no way to
> > define the version for dependencies to be used with plugins.
> >
> > Happy to file a ticket if you think it's worthwhile discussing.
> >
> > Cheers,
> > Ollie
> >
>

Re: JDeprscan plugin 3.0.0 ?

[Andres Almiray]

Indeed. Scanning compile & runtime dependencies is a feature Robert and I
discussed back at JCrete 2018 if not mistaken.
For comparison the Gradle jdeprscan plugin (for which I'm the author) has
this feature.

I believe this feature was even added to the issue tracker at some point.

Cheers,
Andres

On Wed, Feb 24, 2021 at 12:08 PM Benjamin Marwell 
wrote:

> Sounds interesting! Is anyone using this yet?
>
> Seems to be a reasonable default plugin for builds, additional to
> -Dmaven.compiler.showDeprecation=true
>
> Probably another (maybe even more useful) goal would be to scan
> compile- and runtime dependencies as well.
>
> Am Di., 23. Feb. 2021 um 20:40 Uhr schrieb Andres Almiray <
> aalmi...@gmail.com>:
> >
> > Hello everyone,
> >
> > While doing research on Maven plugins hat help you work with modular
> > applications I couldn't fail to notice that the jdeprscan plugin is
> listed
> > at version 3.0.0-alpha-1 and its page marks it as prerelease since 2017
> >
> > https://maven.apache.org/plugins/maven-jdeprscan-plugin/
> >
> > As you may be aware this was the case for the jlink plugin which received
> > some love from Benjamin, Sandra, Karl-Heinz and co. and was able to cross
> > the 3.0.0 line in late 2020. It's actually now at 3.1.0.
> >
> > I wonder what's missing in the current state to turn it into 3.0.0? What
> > can be done to make this plugin cross the 3.0.0 line as well? Happy to
> help.
> >
> > Cheers,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

JDeprscan plugin 3.0.0 ?

[Andres Almiray]

Hello everyone,

While doing research on Maven plugins hat help you work with modular
applications I couldn't fail to notice that the jdeprscan plugin is listed
at version 3.0.0-alpha-1 and its page marks it as prerelease since 2017

https://maven.apache.org/plugins/maven-jdeprscan-plugin/

As you may be aware this was the case for the jlink plugin which received
some love from Benjamin, Sandra, Karl-Heinz and co. and was able to cross
the 3.0.0 line in late 2020. It's actually now at 3.1.0.

I wonder what's missing in the current state to turn it into 3.0.0? What
can be done to make this plugin cross the 3.0.0 line as well? Happy to help.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

Re: Official Maven Github Actions

[Andres Almiray]

FWIW there’s an sdkman GHA in case you’d like to explore that option 

https://github.com/sdkman/sdkman-action

Cheers
Andres

Sent from my primitive tricorder

> On 12 Feb 2021, at 20:52, Romain Manni-Bucau  wrote:
> 
> Hi César,
> 
> Any interesting feature compared to using a plain sh script with sdkman?
> Looks like saner since it will enable you to setup java and maven properly
> at the same stage which is the actual prerequisite of a maven build vs
> using multiple random actions.
> Did you investigate this option?
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
>> Le ven. 12 févr. 2021 à 20:39, Robert Scholte  a
>> écrit :
>> 
>> I'm only aware of MNG-6887.
>> 
>> Robert
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/MNG-6887
>> On 12-2-2021 19:40:24, Gary Gregory  wrote:
>> I've been wanting such an GH action myself!
>> 
>> Gary
>> 
>> On Fri, Feb 12, 2021 at 12:52 PM Cesar Hernandez
>> wrote:
>> 
>>> Hi,
>>> 
>>> The problems:
>>> 
>>> Currently, the official Github actions for building and testing Java with
>>> Maven [1] don't offer a way to specify the Maven version a workflow can
>>> use.
>>> Adding this support seems to be out of the scope of the
>>> current actions/checkout@v2. [2].
>>> 
>>> In the Github actions market are already a couple of alternatives to
>>> perform this setup [3] but are non-verified third parties actions.
>>> 
>>> Currently, in the Github actions market are cero verified Maven related
>>> actions [5] but there are already a couple really useful maven related
>>> actions beyond just the version settings [6]
>>> 
>>> Since early 2021, Apache related projects allows only verified actions to
>>> be used in workflows.
>>> 
>>> 
>>> The opportunity:
>>> Base on the interaction with the Actions team [2] it seems Actions
>>> verification can be done if the actions are created as part of the
>> official
>>> projects. For example Ruby setup action [4].
>>> 
>>> Before brainstorming in solution, creating a JIRA or a PR with draft
>>> implementation, I would like to know if there is any interest within the
>>> Maven community to offer to users certified Maven Github actions?
>>> 
>>> 
>>> [1]
>>> 
>>> 
>> https://docs.github.com/en/actions/guides/building-and-testing-java-with-maven
>>> [2]
>> https://github.com/actions/setup-java/issues/40#issuecomment-778028611
>>> [3] https://github.com/stCarolas/setup-maven
>>> [4] https://github.com/ruby/setup-ruby
>>> [5]
>>> 
>>> 
>> https://github.com/marketplace?query=maven=actions=verified
>>> [6] https://github.com/marketplace?after=Y3Vyc29yOjIw=maven
>>> --
>>> Atentamente:
>>> César Hernández.
>>> 
>> 

Re: Official Maven Github Actions

[Andres Almiray]

Cesar,

Maven 4 will include a wrapper script that should take care of this issue.

For Maven 3.x you may use Takari's Maven Wrapper[1] to get similar behavior.

However for those that can't set a wrapper for several reasons (for example
Apache projects do not allow JARs in their repositories those the wrapper
cannot be set before hand).
the a Github Action may be thew way to go.

Cheers,
Andres

[1] https://github.com/takari/maven-wrapper

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Fri, Feb 12, 2021 at 6:52 PM Cesar Hernandez 
wrote:

> Hi,
>
> The problems:
>
> Currently, the official Github actions for building and testing Java with
> Maven [1] don't offer a way to specify the Maven version a workflow can
> use.
> Adding this support seems to be out of the scope of the
> current actions/checkout@v2. [2].
>
> In the Github actions market are already a couple of alternatives to
> perform this setup [3] but are non-verified third parties actions.
>
> Currently, in the Github actions market are cero verified Maven related
> actions [5] but there are already a couple really useful maven related
> actions beyond just the version settings [6]
>
> Since early 2021, Apache related projects allows only verified actions to
> be used in workflows.
>
>
> The opportunity:
> Base on the interaction with the Actions team [2] it seems Actions
> verification can be done if the actions are created as part of the official
> projects. For example Ruby setup action [4].
>
> Before brainstorming in solution, creating a JIRA or a PR with draft
> implementation, I would like to know if there is any interest within the
> Maven community to offer to users certified Maven Github actions?
>
>
> [1]
>
> https://docs.github.com/en/actions/guides/building-and-testing-java-with-maven
> [2] https://github.com/actions/setup-java/issues/40#issuecomment-778028611
> [3] https://github.com/stCarolas/setup-maven
> [4] https://github.com/ruby/setup-ruby
> [5]
>
> https://github.com/marketplace?query=maven=actions=verified
> [6] https://github.com/marketplace?after=Y3Vyc29yOjIw=maven
> --
> Atentamente:
> César Hernández.
>

Re: APT vs Markdown formats for site docs

[Andres Almiray]

FWIW Doxia supports Asciidoc pretty well. You just have to add an extra
dependency for it to find Asciidoctorj, as demonstrated at

https://github.com/kordamp/pomchecker/blob/master/pom.xml#L200-L227

You can mix all kind of supported formats if needed. Or use only asciidoc,
the choice is yours ;-)

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Mon, Feb 1, 2021 at 12:29 PM Artem Krosheninnikov <
artem.krosheninni...@gmail.com> wrote:

> I agree that there are several implementations thus it may be not a good
> choice.
>
> FML looks very ancient from my point of view but asciidoc is more or less a
> standard format in docops community.
>
> It's not that everything should be immediately converted to another format,
> just trying to understand whether apt is convenient for all and is a
> standard for all maven projects.
>
> пн, 1 февр. 2021 г. в 13:32, Benjamin Marwell :
>
> > Markdown is not a "standard" or "standardized".
> > Even worse, different implementations have different feature sets.
> > Thus my -1 for md.
> >
> > But another format might be feasible, really. fml looks verbose.
> >
> > Asciidoc might be a sane choice here. It was specially designed for
> > technical documentation and
> > has neat features which are handy for exactly those cases.
> > Besides, it is also supported on GitHub.
> >
> > ---
> >
> > A quick check revealed there was no such discussion in the last 12
> > months on the mailing list.
> >
> > - Ben
> >
> >
>
> --
> Sincerely yours,
> Krosheninnikov Artem.
>

Re: [MJLINK] Move from 3.0.1 to 3.1.0

[Andres Almiray]

Hi Ben,

Nice!

https://github.com/apache/maven-jlink-plugin/blob/master/src/it/projects/MJLINK-52_classifiers_jarproject/pom.xml

This is what I as looking for, even if an explicit
jlink has t be defined.
Thanks!

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Wed, Dec 16, 2020 at 8:12 AM Benjamin Marwell 
wrote:

> > Not that I want to hijack this thread
> No worries! It is always good to have an extra pair of eyes look at
> the work of a new committer. ;-)
>
> > However for single project builds the jlink would
> > prevent other packaging options, wouldn't it?
> I created ITs, but this set-up is not an the list:
> https://github.com/apache/maven-jlink-plugin/tree/master/src/it/projects
> (Especially MJLINK-52_*).
> I would not know why this would prevent other packaging options.
> I will create another IT which will be packaging=jlink and
> add a jar execution. Note that you will need to define the execution
> manually.
>
> > Say I want to have single JAR, shaded JAR, and jlink image on the same
> > single project build. Is it possible to do so?
> This is why MJLINK-52 adds classifiers.
> The check of existing artifacts was broken before then.
> Most ITs from the link above already show a single jar project
> with an extra jlink execution. Add as many shaded jars as you like…
>
> Does that help?
>
> Thanks,
> Ben
>
> On 15.12.20 22:53, Andres Almiray wrote:
> > Hello,
> >
> > Not that I want to hijack this thread but considering that the move is
> from
> > a fix release to a minor release I wonder about the use of
> > jlink.
> >
> > For a multi-module project having this packaging option is not much of a
> > problem, as if the project produces more than one artifact (such as a
> > shaded JAR, jar with classpath, assemble/assembler, jlink) then an extra
> > module can perform the jlink packaging.
> >
> > However for single project builds the jlink would
> > prevent other packaging options, wouldn't it?
> > Say I want to have single JAR, shaded JAR, and jlink image on the same
> > single project build. Is it possible to do so?
> >
> > If it is, then I missed it in the docs.
> > It it's not allowed then I'd suggest if JAR packaging is also enabled
> when
> > jlink is defined, so keep them both active. Then
> > remove jlink in 4.0.0.
> >
> > As reference the Helidon maven plugin supports creating jlink and Graal
> > native images while keeping jar
> >
> >
> https://github.com/oracle/helidon-build-tools/tree/master/helidon-maven-plugin
> >
> > All this being said, this comment is to weight in a possible change that
> > would merit a minor release instead of a fix release.
> >
> > Cheers,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
> >
> > On Tue, Dec 15, 2020 at 10:38 PM Benjamin Marwell 
> > wrote:
> >
> >> Hello everyone,
> >>
> >> looking at the issues already solved and soon-be-solved, the next
> release
> >> feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
> >>
> >> If you agree, I would like to update the git repository to 3.1.0 and
> create
> >> a 3.0.x branch from the last release, if needed.
> >>
> >> I would also like to request some help with the documentation [2].
> >> Currently it says that an extra 'dist' project is needed, but with the
> >> introduction of classifiers (or moving the main jar away using a
> >> classifier), this does not hold true anymore.
> >>
> >> Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even
> >> "won’t fix"), as the 'vm' option only applies to 32bit vms and is not
> even
> >> documented anymore – only 'jlink --plugin-list' shows its usage.
> >>
> >> Summary:
> >> 4 issues left, of which are:
> >> 1 with PR to be merged (update plexus-utils)
> >> 1 with PR h

Re: [MJLINK] Move from 3.0.1 to 3.1.0

[Andres Almiray]

Hello,

Not that I want to hijack this thread but considering that the move is from
a fix release to a minor release I wonder about the use of
jlink.

For a multi-module project having this packaging option is not much of a
problem, as if the project produces more than one artifact (such as a
shaded JAR, jar with classpath, assemble/assembler, jlink) then an extra
module can perform the jlink packaging.

However for single project builds the jlink would
prevent other packaging options, wouldn't it?
Say I want to have single JAR, shaded JAR, and jlink image on the same
single project build. Is it possible to do so?

If it is, then I missed it in the docs.
It it's not allowed then I'd suggest if JAR packaging is also enabled when
jlink is defined, so keep them both active. Then
remove jlink in 4.0.0.

As reference the Helidon maven plugin supports creating jlink and Graal
native images while keeping jar

https://github.com/oracle/helidon-build-tools/tree/master/helidon-maven-plugin

All this being said, this comment is to weight in a possible change that
would merit a minor release instead of a fix release.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Tue, Dec 15, 2020 at 10:38 PM Benjamin Marwell 
wrote:

> Hello everyone,
>
> looking at the issues already solved and soon-be-solved, the next release
> feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
>
> If you agree, I would like to update the git repository to 3.1.0 and create
> a 3.0.x branch from the last release, if needed.
>
> I would also like to request some help with the documentation [2].
> Currently it says that an extra 'dist' project is needed, but with the
> introduction of classifiers (or moving the main jar away using a
> classifier), this does not hold true anymore.
>
> Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even
> "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even
> documented anymore – only 'jlink --plugin-list' shows its usage.
>
> Summary:
> 4 issues left, of which are:
> 1 with PR to be merged (update plexus-utils)
> 1 with PR half-way done (--add-options for launcher script)
> 1 documentation to be done
> 1 to be moved away or "wont’t fix".
>
> Thanks in advance,
> Ben
>
> [1]
>
> https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%20AND%20fixVersion%20%3D%203.0.1
> [2] https://issues.apache.org/jira/browse/MJLINK-49
> [3] https://issues.apache.org/jira/browse/MJLINK-39
>

Re: [DISCUSS] Next release should a pre Maven 4.0.0

[Andres Almiray]

Hi Robert,

Understood. I remember our discussion at JAlba last year about the
resolution strategy options at hand.

Do you think it would be possible to expose the resolution strategy hooks
in a way that may be overridden by an extension/plugin?
That way alternate RS can be prototyped and tested during 4's lifespan
before changing the core RS in 5.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Thu, Nov 12, 2020 at 9:33 PM Robert Scholte  wrote:

> Hi Andres,
>
> BanDuplicatePomDependencyVersions is easy to add. IIRC now it is a
> warning, I don't mind changing it to make it break the build.
>
> DependencyConvergence is way too difficult to achieve with the larger
> projects.
>
> RequireUpperBoundDeps sounds reasonable as warning, although I'm sure if
> the ModelValidator has enough context.
> Instead I would prefer to change the resolution strategy from Nearest to
> DirectOverHighest (or something similar), but that's definitely 5.0.0.
>
>
> thanks,
> Robert
> On 12-11-2020 21:08:35, Andres Almiray  wrote:
> Woohoo!
>
> While I'd love for Maven moving forward to 4 I was hoping to see the
> enforcer plugin (or at least some of its rules) baked into core, for
> example
>
> BanDuplicatePomDependencyVersions
> DependencyConvergence
> RequireUpperBoundDeps
>
> I'm sure that enabling these rules by default will break thousands of
> builds upon upgrade, but at the very least having the behavior available
> with a simple turn of a switch/flag is better than having to configure the
> enforcer plugin by hand.
> I'm also aware that there are those among this group that are not fond of
> enforcer, so yeah.
>
> So, if this behavior can't be added to 4, at least put it in the bucket for
> 5 ;-)
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Thu, Nov 12, 2020 at 9:00 PM Robert Scholte wrote:
>
> > I don't expect that signing will work with the the first alpha, but that
> > shouldn't stop us of collecting feedback.
> > Also we need to have a look at all plugins that do something with the
> pom,
> > like every packaging plugin, maven-source-plugin, maven-release-plugin to
> > ensure the "right" pom is added.
> >
> > And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> > though they are stable).
> > There's still enough work to reach 4.0.0, but most likely the first
> alphas
> > are already good enough for the majority.
> >
> > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> > Did we already do mvn or mvn plugins (multimodules) release with the
> > consumer/producer pom feature?
> > If so +1 to do a v4 with this new feature "for us" and v5 with real user
> > features and align it with the xsd.
> >
> > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> > écrit :
> >
> > > Hi,
> > >
> > > It is already several years ago where we started discussing about Maven
> > > Next Generations.
> > > Clearly we needed to work on the pom, because over time we're facing
> more
> > > and more limitations.
> > > For (Maven) Central the Model 4.0.0 will be required pom format,
> there's
> > > no discussion about that. So we needed a new architecture where
> there's a
> > > local pom that is transformed to Model 4.0.0 or where it can be
> > generated.
> > > With the implementation of MNG-6656 and the improvement with MNG-6957
> > > we've made the first and important steps based on pom transformation.
> If
> > > this concept proofs itself, we can start thinking about enhancing the
> pom
> > > model.
> > >
> > > When talking about Model 5.0.0 it looked like it would be great to
> > > introduce it for Maven 5. There was even a period where we thought
> about
> > > skipping Maven 4, just to sync the Model version with the Maven
> version.
> > > However, we discovered that this would be a huge change, and that we
> > would
> > > probabl

Re: [DISCUSS] Next release should a pre Maven 4.0.0

[Andres Almiray]

Woohoo!

While I'd love for Maven moving forward to 4 I was hoping to see the
enforcer plugin (or at least some of its rules) baked into core, for
example

BanDuplicatePomDependencyVersions
DependencyConvergence
RequireUpperBoundDeps

I'm sure that enabling these rules by default will break thousands of
builds upon upgrade, but at the very least having the behavior available
with a simple turn of a switch/flag is better than having to configure the
enforcer plugin by hand.
I'm also aware that there are those among this group that are not fond of
enforcer, so yeah.

So, if this behavior can't be added to 4, at least put it in the bucket for
5 ;-)

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Thu, Nov 12, 2020 at 9:00 PM Robert Scholte  wrote:

> I don't expect that signing will work with the the first alpha, but that
> shouldn't stop us of collecting feedback.
> Also we need to have a look at all plugins that do something with the pom,
> like every packaging plugin, maven-source-plugin, maven-release-plugin to
> ensure the "right" pom is added.
>
> And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> though they are stable).
> There's still enough work to reach 4.0.0, but most likely the first alphas
> are already good enough for the majority.
>
> On 12-11-2020 20:45:09, Romain Manni-Bucau  wrote:
> Did we already do mvn or mvn plugins (multimodules) release with the
> consumer/producer pom feature?
> If so +1 to do a v4 with this new feature "for us" and v5 with real user
> features and align it with the xsd.
>
> Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> écrit :
>
> > Hi,
> >
> > It is already several years ago where we started discussing about Maven
> > Next Generations.
> > Clearly we needed to work on the pom, because over time we're facing more
> > and more limitations.
> > For (Maven) Central the Model 4.0.0 will be required pom format, there's
> > no discussion about that. So we needed a new architecture where there's a
> > local pom that is transformed to Model 4.0.0 or where it can be
> generated.
> > With the implementation of MNG-6656 and the improvement with MNG-6957
> > we've made the first and important steps based on pom transformation. If
> > this concept proofs itself, we can start thinking about enhancing the pom
> > model.
> >
> > When talking about Model 5.0.0 it looked like it would be great to
> > introduce it for Maven 5. There was even a period where we thought about
> > skipping Maven 4, just to sync the Model version with the Maven version.
> > However, we discovered that this would be a huge change, and that we
> would
> > probably need a couple of Maven 4 releases before moving to Maven 5.
> Maven
> > 4 would consist of preparation releases.
> > I've started writing the build/consumer to proof that the it is indeed
> > possible to separate the local pom from the distributed pom, even though
> > they both are currently still Model 4.0.0 compatible.
> > The original idea was:
> > Maven 3: build/consumer feature disabled by default
> > Maven 4: build/consumer feature enabled by default
> >
> > Maven 5: Model 5
> >
> > We were worried that this wouldn't give us enough feedback.
> > maven-integration-testing shows that build/consumer does work. There
> should
> > be enough trust to enable it by default, it shouldn't impact existing
> > projects (the last find by Michael was actually great. It demonstrated
> the
> > effect when using threads. The fix made sense and Maven was stable
> again).
> > But it is simply not enough. We need much more feedback.
> >
> > Meanwhile other improvements have been done, that has impact:
> > - new behavior of reactor commandline arguments
> > - upgrade of default versions of plugins per packaging type
> > - requiring Java 8
> > - Maven wrapper
> > - there's a PR waiting that will shift the logic of the
> > ProjectBuilder/ModelBuilder. As this is quite important for more people
> to
> > understand, I'll record a Q with Maarten+Martin soon and share it with
> > you.
> > There are probably more, but all these already defend my opinion about
> the
> > next Maven version.
> >
> > To me it is not a Maven 3 anymore, we're reached a point where we should
> > start calling it Maven 4.
> > The next release should probably have an alpha suffix, just to give users
> > the chance to do alpha testing.
> >
> > WDYT?
> > Robert
> >
> >
>

Re: Hello from mvnd

[Andres Almiray]

If an agreement between the projects can't be reached, have you considered
renaming _your_ script to mvnc?

On Tue, Oct 13, 2020 at 9:55 PM Peter Palaga  wrote:

> Hi,
>
> as some of you may know already, Guillaume (cc'd) and me are working on
> a Daemon for Maven [1].
>
> As with Gradle daemon, the main idea is to keep the JVM and the Maven
> plugins' code warm in a long living process so that during repeated
> builds the JIT-optimized code is available immediately.
>
> In addition to that, the builds are run with -T1C by default, there are
> some improvements in how the build progress is presented to the user and
> the `mvnd` command line client is a GraalVM native executable.
>
> Our main motivation to work on this was to make the building of our
> primary work projects faster. We work on Apache Camel, Camel Quarkus,
> Quarkus, etc. - all those are rather large projects with hundreds of
> Maven modules.
>
> I think we can say that the project left the PoC phase recently. We use
> it for our daily work, we made it available via SDKMAN and we are
> solving issues coming from the users.
>
> We'd like to contribute our code to Maven at some point when we believe
> that it is stable and battle tested enough.
>
> mvnd existed without mvn script for some time and therefore it could
> peacefully co-exist with stock Maven. Now it looks like we have to add
> our own mvn for reasons mentioned in
> https://github.com/mvndaemon/mvnd/pull/89 . Due to that, mvnd got some
> potential to clash with stock Maven when installed on the same machine.
> I am not especially happy about that and I wanted to assure the Maven
> community that we do it for technical reasons and that our ultimate aim
> is to contribute rather than hijack the ecosystem.
>
> Of course you are welcome to try mvnd and give feedback.
>
> Thanks,
>
> -- Peter
>
> [1] https://github.com/mvndaemon/mvnd
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: provided as compileOnly

[Andres Almiray]

Well the use case appears to be the same as Gradle’s compileOnly, which as the 
name states, it’s used for compilation only and it’s not required for 
execution. Also, dependencies set in compileOnly are never exported to 
consumers, so in a way, with current Maven semantics Gradle’s compileOnly ~= 
Maven provided scope + true. 

Sent from my primitive tricorder

> On 29 Jul 2020, at 12:22, Michael Osipov  wrote:
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Twitter handles of committers

[Andres Almiray]

Maarten,

I don't think these social accounts have anything to do with mirrors of
Apache on a particular service, rather to increase visibility on the
developers themselves.

What if I wanted to link to my Linkedin or Patreon profiles? Personal blog?
Would that we allowed?
What would be the limits?

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Sun, May 24, 2020 at 7:44 PM Maarten Mulders  wrote:

> Great initiative!
>
> Deeplinking to the profile would be nice, too, I guess.
> I would start with Twitter and GitHub. GitLab makes less sense to me,
> AFAIK there are no mirrors of Maven hosted at GitLab?
>
> May I also suggest to do it the other way round: a Twitter list [1] of
> people who are Maven committer? Or maybe it already exists?
>
> Maarten
>
> [1] https://help.twitter.com/en/using-twitter/twitter-lists
>
> On May 24, 2020 at 19:40, Robert Scholte wrote:
>
> > Sure we could do that too.
> > Would be nice to improve the team pages for well known properties, but
> > at the moment there's a vote on the maven-project-info-reports-plugin.
> > Maybe an up-for-grabs to include with the next release.
> >
> > Robert
> > On 24-5-2020 19:27:08, Andres Almiray  wrote:
> > Good idea Robert!
> > May I suggest adding GitHub account as well? Not everyone follows
> > Twitter
> > or has an account (shocking, I know) but they may have a Github account
> > or
> > consider browsing through an author's profile.
> >
> > And why stop with Github? Let's add Gitlab.
> > I guess, s long as there's no "explicit" or "stardard" social media |
> > social coding column team members are free to choose which accounts
> > they'd
> > like to link, right?
> >
> > Cheers,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> > and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
> > On Sun, May 24, 2020 at 7:18 PM Robert Scholte wrote:
> >
> >> I had a chat with Chandra (@CGuntur) regarding exposure of Maven
> >> committers.
> >> My experience is that most Maven users just use it, without knowing
> >> the
> >> people behind and (yes, people, not a company). Twitter has been a
> >> good way
> >> to share information regarding Maven.
> >> To get more attention, I've added a twitter-property to my profile in
> >> the
> >> maven parent pom.
> >> After triggering the website the team-list[1] has been expanded with a
> >> properties-column.
> >> Not the nicest look and feel, but having my twitter handle here is
> >> more
> >> important to me.
> >>
> >> I could add all known twitter handles, but I leave it up to every
> >> committer to add this property as well.
> >> Simply update your profile in the maven-parent if you want.
> >>
> >> thanks,
> >> Robert
> >>
> >> [1] https://maven.apache.org/team.html
> >>
> >> [2] https://github.com/apache/maven-parent/blob/master/pom.xml
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Twitter handles of committers

[Andres Almiray]

Good idea Robert!
May I suggest adding GitHub account as well? Not everyone follows Twitter
or has an account (shocking, I know) but they may have a Github account or
consider browsing through an author's profile.

And why stop with Github? Let's add Gitlab.
I guess, s long as there's no "explicit" or "stardard" social media |
social coding column team members are free to choose which accounts they'd
like to link, right?

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Sun, May 24, 2020 at 7:18 PM Robert Scholte  wrote:

> I had a chat with Chandra (@CGuntur) regarding exposure of Maven
> committers.
> My experience is that most Maven users just use it, without knowing the
> people behind and (yes, people, not a company). Twitter has been a good way
> to share information regarding Maven.
> To get more attention, I've added a twitter-property to my profile in the
> maven parent pom.
> After triggering the website the team-list[1] has been expanded with a
> properties-column.
> Not the nicest look and feel, but having my twitter handle here is more
> important to me.
>
>
> I could add all known twitter handles, but I leave it up to every
> committer to add this property as well.
> Simply update your profile in the maven-parent if you want.
>
> thanks,
> Robert
>
> [1] https://maven.apache.org/team.html
>
> [2] https://github.com/apache/maven-parent/blob/master/pom.xml

Re: Additional Maturity Metadata in artifacts (especially in the pom)?

[Andres Almiray]

Indeed.

I'm willing to work as liaison for Gradle :-)
Let's make it work!

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Mon, May 6, 2019 at 8:03 PM Robert Scholte  wrote:

> Some already know about my plan/wish to bring experts representing the
> different buildtools, IDEs and artifact repositories together and work an
> a new specification.
> I am aware of the Gradle papers, haven't compared them yet with our first
> proposals yet.
> I'm sure we have the same goal, but this will only work if all related
> parties join.
>
> thanks,
> Robert
>
>
> On Mon, 06 May 2019 19:53:58 +0200, Andres Almiray 
> wrote:
>
> > Hello everyone,
> >
> > FWIW Gradle has come up with its own metadata format (announced at
> > https://blog.gradle.org/gradle-metadata-1.0, explained at
> >
> https://github.com/gradle/gradle/blob/f6a98158e75a636245f70d46604fcab3152361e8/subprojects/docs/src/docs/design/gradle-module-metadata-1.0-specification.md
> > )
> >
> > Perhaps here's an opportunity to collaborate and decide on a common
> > format
> > and/or features that benefit all of us, what do you think?
> >
> > Cheers,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > JCP EC Associate Seat
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> > and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
> >
> > On Mon, May 6, 2019 at 7:15 PM Robert Scholte 
> > wrote:
> >
> >> Assuming we need a new metadatafile in the future to extend/enrich the
> >> current pom file, do you think it would fit in something like a PDT
> >> file[1]?
> >>
> >> If so, please at a comment so we can take it into account when working
> >> on
> >> new specifications.
> >>
> >> Robert
> >>
> >> [1]
> >>
> >>
> https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema
> >>
> >> On Mon, 06 May 2019 10:03:33 +0200, Christofer Dutz
> >>  wrote:
> >>
> >> > Hi all,
> >> >
> >> > I am currently working hard on adding support for other languages in
> >> the
> >> > PLC4X maven build. While working on the python I noticed that they
> >> have
> >> > some sort of maturity self-assessment metadata in their artifacts
> and
> >> I
> >> > think that actually quite a good thing.
> >> >
> >> > Doing some research I couldn’t find any means to provide similar data
> >> > for maven.
> >> >
> >> > In PLC4X we have a lot of modules. Some are older and mature, but
> >> others
> >> > we’d like to mark as experimental.
> >> > It would be great if we could also provide enforcer rules to for
> >> example
> >> > allow only mature modules or modules with a maturity scoring of at
> >> least
> >> > X …
> >> >
> >> > I thing we could achieve something like this manually, by providing
> >> > metadata in form of resources in the jars and custom enforcer modules,
> >> > but that would be an island solution only working in our domain. I
> >> think
> >> > this could be beneficial to the entire Maven ecosystem to have
> >> something
> >> > more generic in the system itself.
> >> >
> >> > Any thoughts & suggestions on this?
> >> >
> >> > Chris
> >>
> >> -
> >> 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
>
>

Re: Additional Maturity Metadata in artifacts (especially in the pom)?

[Andres Almiray]

Hello everyone,

FWIW Gradle has come up with its own metadata format (announced at
https://blog.gradle.org/gradle-metadata-1.0, explained at
https://github.com/gradle/gradle/blob/f6a98158e75a636245f70d46604fcab3152361e8/subprojects/docs/src/docs/design/gradle-module-metadata-1.0-specification.md
)

Perhaps here's an opportunity to collaborate and decide on a common format
and/or features that benefit all of us, what do you think?

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Mon, May 6, 2019 at 7:15 PM Robert Scholte  wrote:

> Assuming we need a new metadatafile in the future to extend/enrich the
> current pom file, do you think it would fit in something like a PDT
> file[1]?
>
> If so, please at a comment so we can take it into account when working on
> new specifications.
>
> Robert
>
> [1]
>
> https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema
>
> On Mon, 06 May 2019 10:03:33 +0200, Christofer Dutz
>  wrote:
>
> > Hi all,
> >
> > I am currently working hard on adding support for other languages in
> the
> > PLC4X maven build. While working on the python I noticed that they have
> > some sort of maturity self-assessment metadata in their artifacts and I
> > think that actually quite a good thing.
> >
> > Doing some research I couldn’t find any means to provide similar data
> > for maven.
> >
> > In PLC4X we have a lot of modules. Some are older and mature, but
> others
> > we’d like to mark as experimental.
> > It would be great if we could also provide enforcer rules to for
> example
> > allow only mature modules or modules with a maturity scoring of at
> least
> > X …
> >
> > I thing we could achieve something like this manually, by providing
> > metadata in form of resources in the jars and custom enforcer modules,
> > but that would be an island solution only working in our domain. I
> think
> > this could be beneficial to the entire Maven ecosystem to have
> something
> > more generic in the system itself.
> >
> > Any thoughts & suggestions on this?
> >
> > Chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Parsing pom.xml

[Andres Almiray]

Hi Laird,

Thanks, this all is very useful :-)

One more thing, if I needed to read the contents of a settings.xml file, I
suppose there's a similar API that make this work?

Best,
Andres

---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Sat, Dec 8, 2018 at 11:10 PM Laird Nelson  wrote:

> I forgot to mention: if you want to do this all "by hand", i.e. not rely on
> JSR 330 containers, you want to look here (
>
> https://maven.apache.org/resolver/apidocs/index.html?org/eclipse/aether/impl/DefaultServiceLocator.html
> )
> and work backwards.
>
> Best,
> Laird
> --
> https://about.me/lairdnelson
>
> On Sat, Dec 8, 2018 at 2:05 PM Laird Nelson  wrote:
>
> > This is all near and dear to my heart.
> >
> > First, some terminology clearing up: the Maven internals rely on a
> JSR-330
> > implementation (javax.inject.*), not CDI (javax.enterprise.inject.*).
> CDI
> > is a JSR-330 implementation, but so is Guice, HK2, etc.  I believe that
> the
> > internals of Maven rely on Guice, but as Robert says, if you're not
> > rebuilding the innards of Maven then using the facilities of JSR-330 make
> > the code really simple.
> >
> > I did actually put parts of Maven in CDI (
> > https://microbean.github.io/microbean-maven-cdi/).  You may find some of
> > the implementation classes in question that you need in there.  Start
> here:
> >
> https://github.com/microbean/microbean-maven-cdi/blob/c5abd2e3c321020c419442c44ef726e48952d983/src/main/java/org/microbean/maven/cdi/MavenExtension.java#L317
> >
> > Best,
> > Laird
> > --
> > https://about.me/lairdnelson
> >
>

Re: Parsing pom.xml

[Andres Almiray]

So far so good, I can parse POM files and read data. This works fine as
long as I don't have to access a parent POM.

@Robert: I suspect your first suggestion may be needed in order to resolve
parent POM files as artifacts, isn't that right?

Best,
Andres

---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Sat, Dec 8, 2018 at 7:22 PM Robert Scholte  wrote:

> Ah, you might be lucky with this solution :)
>
> On Sat, 08 Dec 2018 19:20:59 +0100, Andres Almiray 
> wrote:
>
> > Looks like I found the answer to instantiating the ModelBuilder
> >
> > new DefaultModelBuilderFactory().newInstance()
> >
> > From the javadoc:
> >
> >  * A factory to create model builder instances when no dependency
> > injection
> > is available. Note: This class is
> >  * only meant as a utility for developers that want to employ the model
> > builder outside of the Maven build system, Maven
> >  * plugins should always acquire model builder instances via dependency
> > injection. Developers might want to subclass
> >  * this factory to provide custom implementations for some of the
> > components used by the model builder.
> >
> > Great, I think this will work :-)
> >
> > Best,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > JCP EC Associate Seat
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> > and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
> >
> > On Sat, Dec 8, 2018 at 6:47 PM Andres Almiray 
> wrote:
> >
> >> Thank you Robert!
> >>
> >> It looks like org.apache.maven.model.Model.DefaultModelBuilder provides
> >> the behavior I need given this method found in its contract
> >>
> >>ModelBuildingResult build( ModelBuildingRequest request )
> >> throws ModelBuildingException;
> >>
> >> ModelBuildingResult gives me access to the raw model (as read form the
> >> pom.xml file) and the effective model. This is exactly what I need :-)
> >>
> >> Is there a special way to initialize an instance of such type?
> >> Theoretically I'd like to call something like
> >>
> >> ModelBuildingRequest request = new DefaultModelBuildingRequest();
> >> request.setPomFile(...);
> >> ModelBuilder builder = ... // instantiate builder (??)
> >> ModelBuldingResult result = builder.build(request);
> >>
> >> Thanks for your help.
> >>
> >> Best,
> >> Andres
> >>
> >> ---
> >> Java Champion; Groovy Enthusiast
> >> JCP EC Associate Seat
> >> http://andresalmiray.com
> >> http://www.linkedin.com/in/aalmiray
> >> --
> >> What goes up, must come down. Ask any system administrator.
> >> There are 10 types of people in the world: Those who understand binary,
> >> and those who don't.
> >> To understand recursion, we must first understand recursion.
> >>
> >>
> >> On Sat, Dec 8, 2018 at 6:33 PM Robert Scholte 
> >> wrote:
> >>
> >>> The ModelBuilder[1] is what you are looking for, and yes it does a
> LOT
> >>> :)
> >>>
> >>> Be aware that it is using CDI, so to make use of it you'll need
> >>> sisu/guice
> >>> too.
> >>>
> >>> Robert
> >>>
> >>> [1] https://maven.apache.org/ref/3.6.0/maven-model-builder/
> >>>
> >>> On Sat, 08 Dec 2018 18:20:51 +0100, Andres Almiray  >
> >>> wrote:
> >>>
> >>> > Of course.
> >>> >
> >>> > This is definitely not a plugin project. My goal is to have an
> >>> in-memory
> >>> > representation of the POM as defined by a source pom.xml, to later
> >>> > transform/enrich it and write it back.
> >>> > As a side effect this tool can calculate statics on usage patterns
> >>> and
> >>> > recommend some oth

Re: Parsing pom.xml

[Andres Almiray]

Looks like I found the answer to instantiating the ModelBuilder

new DefaultModelBuilderFactory().newInstance()

>From the javadoc:

 * A factory to create model builder instances when no dependency injection
is available. Note: This class is
 * only meant as a utility for developers that want to employ the model
builder outside of the Maven build system, Maven
 * plugins should always acquire model builder instances via dependency
injection. Developers might want to subclass
 * this factory to provide custom implementations for some of the
components used by the model builder.

Great, I think this will work :-)

Best,
Andres

---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Sat, Dec 8, 2018 at 6:47 PM Andres Almiray  wrote:

> Thank you Robert!
>
> It looks like org.apache.maven.model.Model.DefaultModelBuilder provides
> the behavior I need given this method found in its contract
>
>ModelBuildingResult build( ModelBuildingRequest request )
> throws ModelBuildingException;
>
> ModelBuildingResult gives me access to the raw model (as read form the
> pom.xml file) and the effective model. This is exactly what I need :-)
>
> Is there a special way to initialize an instance of such type?
> Theoretically I'd like to call something like
>
> ModelBuildingRequest request = new DefaultModelBuildingRequest();
> request.setPomFile(...);
> ModelBuilder builder = ... // instantiate builder (??)
> ModelBuldingResult result = builder.build(request);
>
> Thanks for your help.
>
> Best,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> JCP EC Associate Seat
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Sat, Dec 8, 2018 at 6:33 PM Robert Scholte 
> wrote:
>
>> The ModelBuilder[1] is what you are looking for, and yes it does a LOT :)
>>
>> Be aware that it is using CDI, so to make use of it you'll need
>> sisu/guice
>> too.
>>
>> Robert
>>
>> [1] https://maven.apache.org/ref/3.6.0/maven-model-builder/
>>
>> On Sat, 08 Dec 2018 18:20:51 +0100, Andres Almiray 
>> wrote:
>>
>> > Of course.
>> >
>> > This is definitely not a plugin project. My goal is to have an in-memory
>> > representation of the POM as defined by a source pom.xml, to later
>> > transform/enrich it and write it back.
>> > As a side effect this tool can calculate statics on usage patterns and
>> > recommend some others.
>> >
>> > Best,
>> > Andres
>> >
>> > ---
>> > Java Champion; Groovy Enthusiast
>> > JCP EC Associate Seat
>> > http://andresalmiray.com
>> > http://www.linkedin.com/in/aalmiray
>> > --
>> > What goes up, must come down. Ask any system administrator.
>> > There are 10 types of people in the world: Those who understand
>> binary,
>> > and
>> > those who don't.
>> > To understand recursion, we must first understand recursion.
>> >
>> >
>> > On Sat, Dec 8, 2018 at 6:17 PM Enrico Olivelli 
>> > wrote:
>> >
>> >> Il sab 8 dic 2018, 18:09 Andres Almiray  ha
>> scritto:
>> >>
>> >> > Hello everyone,
>> >> >
>> >> > I have the need of building a model based on the data defined in a
>> >> pom.xml
>> >> > file.
>> >> > What would be the best way to read, parse, and obtain such model
>> using
>> >> > standard Maven APIs?
>> >> >
>> >>
>> >> Could you given some more context?
>> >>
>> >> I guess you are not writing a plugin.
>> >>
>> >> Using the internal API may be useful depending on your case.
>> >>
>> >> Enrico
>> >>
>> >> >
>> >> > Best,
>> >> > Andres
>> >> >
>> >> > ---
>> >> > Java Champion; Groovy Enthusiast
>> >> > JCP EC Associate Seat
>> >> > http://andresalmiray.com
>> >> > http://www.linkedin.com/in/aalmiray
>> >> > --
>> >> > What goes up, must come down. Ask any system administrator.
>> >> > There are 10 types of people in the world: Those who understand
>> >> binary,
>> >> and
>> >> > those who don't.
>> >> > To understand recursion, we must first understand recursion.
>> >> >
>> >> --
>> >>
>> >>
>> >> -- Enrico Olivelli
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: Parsing pom.xml

[Andres Almiray]

HI Oliver,

Nice! However that approach may require mapping all possible elements,
including plugins and more. The ModelBuilder should take care of that,
isn't it?

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Sat, Dec 8, 2018 at 6:58 PM Oliver Drotbohm  wrote:

> If it's about pure XML parsing and tweaking the information and building
> the model is not required, XmlBeam [0] is a lightweight alternative to map
> the entire file to a Java object. We use that in the Spring Data release
> automation. Declare an interface containing accessors backed by XPath
> expressions, use the API to create instances and read and write data from
> and to the XML file.
>
> Here [1] is the interface we use to access the parts of the POM relevant
> to our use case.
>
> Cheers,
> Ollie
>
> [0] https://xmlbeam.org/
> [1]
> https://github.com/spring-projects/spring-data-dev-tools/blob/82252be5d7c11a137a68c7fe985b53e04d91cb18/release-tools/src/main/java/org/springframework/data/release/build/Pom.java
>
> > Am 08.12.2018 um 18:47 schrieb Andres Almiray :
> >
> > Thank you Robert!
> >
> > It looks like org.apache.maven.model.Model.DefaultModelBuilder provides
> the
> > behavior I need given this method found in its contract
> >
> >   ModelBuildingResult build( ModelBuildingRequest request )
> >throws ModelBuildingException;
> >
> > ModelBuildingResult gives me access to the raw model (as read form the
> > pom.xml file) and the effective model. This is exactly what I need :-)
> >
> > Is there a special way to initialize an instance of such type?
> > Theoretically I'd like to call something like
> >
> >ModelBuildingRequest request = new DefaultModelBuildingRequest();
> >request.setPomFile(...);
> >ModelBuilder builder = ... // instantiate builder (??)
> >ModelBuldingResult result = builder.build(request);
> >
> > Thanks for your help.
> >
> > Best,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > JCP EC Associate Seat
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__andresalmiray.com=DwIBaQ=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw=7iLfhC17FN-CWhuzo2HX1g0LRD1P0huXh9Zkd3m6MZ0=IxYdo3ScIXOSlnfw8tbvEDuE1wDPwLfKRtL_lYOz0zs=pWrsdUJpQnH-DJXIDk-VNgy7wfo1-h6nGxVaeazNdJI=
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_aalmiray=DwIBaQ=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw=7iLfhC17FN-CWhuzo2HX1g0LRD1P0huXh9Zkd3m6MZ0=IxYdo3ScIXOSlnfw8tbvEDuE1wDPwLfKRtL_lYOz0zs=UGKJpSnO9O4VH5cvMfn7ZTk5m9sFXqHsplwnlS1nbpk=
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
> >
> > On Sat, Dec 8, 2018 at 6:33 PM Robert Scholte 
> wrote:
> >
> >> The ModelBuilder[1] is what you are looking for, and yes it does a LOT
> :)
> >>
> >> Be aware that it is using CDI, so to make use of it you'll need
> >> sisu/guice
> >> too.
> >>
> >> Robert
> >>
> >> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.apache.org_ref_3.6.0_maven-2Dmodel-2Dbuilder_=DwIBaQ=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw=7iLfhC17FN-CWhuzo2HX1g0LRD1P0huXh9Zkd3m6MZ0=IxYdo3ScIXOSlnfw8tbvEDuE1wDPwLfKRtL_lYOz0zs=nOkaCJH3dSvCiihbxfBQKXKE-I2GunCrdaIK9gjbVJs=
> >>
> >> On Sat, 08 Dec 2018 18:20:51 +0100, Andres Almiray 
> >> wrote:
> >>
> >>> Of course.
> >>>
> >>> This is definitely not a plugin project. My goal is to have an
> in-memory
> >>> representation of the POM as defined by a source pom.xml, to later
> >>> transform/enrich it and write it back.
> >>> As a side effect this tool can calculate statics on usage patterns and
> >>> recommend some others.
> >>>
> >>> Best,
> >>> Andres
> >>>
> >>> ---
> >>> Java Champion; Groovy Enthusiast
> >>> JCP EC Associate Seat
> >>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__andresalmiray.com=DwIBaQ=lnl9vOaLMzsy2niBC8-

Re: Parsing pom.xml

[Andres Almiray]

Thank you Robert!

It looks like org.apache.maven.model.Model.DefaultModelBuilder provides the
behavior I need given this method found in its contract

   ModelBuildingResult build( ModelBuildingRequest request )
throws ModelBuildingException;

ModelBuildingResult gives me access to the raw model (as read form the
pom.xml file) and the effective model. This is exactly what I need :-)

Is there a special way to initialize an instance of such type?
Theoretically I'd like to call something like

ModelBuildingRequest request = new DefaultModelBuildingRequest();
request.setPomFile(...);
ModelBuilder builder = ... // instantiate builder (??)
ModelBuldingResult result = builder.build(request);

Thanks for your help.

Best,
Andres

---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Sat, Dec 8, 2018 at 6:33 PM Robert Scholte  wrote:

> The ModelBuilder[1] is what you are looking for, and yes it does a LOT :)
>
> Be aware that it is using CDI, so to make use of it you'll need
> sisu/guice
> too.
>
> Robert
>
> [1] https://maven.apache.org/ref/3.6.0/maven-model-builder/
>
> On Sat, 08 Dec 2018 18:20:51 +0100, Andres Almiray 
> wrote:
>
> > Of course.
> >
> > This is definitely not a plugin project. My goal is to have an in-memory
> > representation of the POM as defined by a source pom.xml, to later
> > transform/enrich it and write it back.
> > As a side effect this tool can calculate statics on usage patterns and
> > recommend some others.
> >
> > Best,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > JCP EC Associate Seat
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> > and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
> >
> > On Sat, Dec 8, 2018 at 6:17 PM Enrico Olivelli 
> > wrote:
> >
> >> Il sab 8 dic 2018, 18:09 Andres Almiray  ha
> scritto:
> >>
> >> > Hello everyone,
> >> >
> >> > I have the need of building a model based on the data defined in a
> >> pom.xml
> >> > file.
> >> > What would be the best way to read, parse, and obtain such model using
> >> > standard Maven APIs?
> >> >
> >>
> >> Could you given some more context?
> >>
> >> I guess you are not writing a plugin.
> >>
> >> Using the internal API may be useful depending on your case.
> >>
> >> Enrico
> >>
> >> >
> >> > Best,
> >> > Andres
> >> >
> >> > ---
> >> > Java Champion; Groovy Enthusiast
> >> > JCP EC Associate Seat
> >> > http://andresalmiray.com
> >> > http://www.linkedin.com/in/aalmiray
> >> > --
> >> > What goes up, must come down. Ask any system administrator.
> >> > There are 10 types of people in the world: Those who understand
> >> binary,
> >> and
> >> > those who don't.
> >> > To understand recursion, we must first understand recursion.
> >> >
> >> --
> >>
> >>
> >> -- Enrico Olivelli
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Parsing pom.xml

[Andres Almiray]

Of course.

This is definitely not a plugin project. My goal is to have an in-memory
representation of the POM as defined by a source pom.xml, to later
transform/enrich it and write it back.
As a side effect this tool can calculate statics on usage patterns and
recommend some others.

Best,
Andres

---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Sat, Dec 8, 2018 at 6:17 PM Enrico Olivelli  wrote:

> Il sab 8 dic 2018, 18:09 Andres Almiray  ha scritto:
>
> > Hello everyone,
> >
> > I have the need of building a model based on the data defined in a
> pom.xml
> > file.
> > What would be the best way to read, parse, and obtain such model using
> > standard Maven APIs?
> >
>
> Could you given some more context?
>
> I guess you are not writing a plugin.
>
> Using the internal API may be useful depending on your case.
>
> Enrico
>
> >
> > Best,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > JCP EC Associate Seat
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
> --
>
>
> -- Enrico Olivelli
>

Parsing pom.xml

[Andres Almiray]

Hello everyone,

I have the need of building a model based on the data defined in a pom.xml
file.
What would be the best way to read, parse, and obtain such model using
standard Maven APIs?

Best,
Andres

---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.