Re: Multi-releases support in compiler plugin 4.0-beta-3

[Romain Manni-Bucau]

Hmm, I still think it is an abuse to think that, javadoc is a good example
which, except the location, often override the rest of options.

That said the point is more that if we go with generic groups of
dependencies we should go with generic source sets and enable to attach
them attributes, not attributes specific to some plugins (which are not
even the majority of a build nowdays) and just standardize their usages in
our built-in plugins no?

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book



Le lun. 24 mars 2025 à 20:42, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2025-03-24 à 20 h 32, Romain Manni-Bucau a écrit :
>
> > any reason to move a plugin configuration from plugin to ?
> > (concretely why do we go that way instead of dropping sources concept
> > from build)?
> >
> Because that configuration is used by many plugins. The same information
> is needed by Javadoc plugin, by resource plugin (for deciding if a
> resource must be copied under META-INF/versions/), and maybe other that
> I'm forgetting.
>
>  Martin
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Multi-releases support in compiler plugin 4.0-beta-3

[Romain Manni-Bucau]

Hi Martin,

Topic way older than this change - so really not blaming at all  but this
change makes it more obvious: any reason to move a plugin configuration
from plugin to ? (concretely why do we go that way instead of
dropping sources concept from build)?

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book



Le lun. 24 mars 2025 à 18:41, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Hello all
>
> A development branch of maven-compiler-plugin 4.0 can now support the
>  property of the new  element introduced in Maven 4.
> The creation of multi-release JAR files for non-modular projects
> should hopefully become easier (support for modular projects will be
> added later). Includes/excludes filters are also supported. The page
> at [1] takes some Maven 3 use cases and shows their Maven 4
> equivalent. The page at [2] is the same thing but as a user-guide
> without comparison with Maven 3. The work has not yet been merged to
> the Maven repository as it depends on the release of
> maven-plugin-testing-harness 4.0.0-beta-4. In the meantime, if there
> is any comment about the approaches shown in [1] and [2], we can do
> modification. Note: the configuration shown in those pages may be
> slightly simplified with [3].
>
> Work not yet done: complete the support of modular projects (there is
> currently partial support) and string filtering.
>
> Martin
>
> [1] https://github.com/Geomatys/maven-compiler-plugin/wiki/Migration
> [2] https://github.com/Geomatys/maven-compiler-plugin/wiki/User-guide
> [3] https://github.com/apache/maven/pull/2180
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POC for improved DOT output for maven-dependency-plugin

[Bear Giles]

One of the benefits (to me) is that it makes mismatches in dependency
versions stand out.

I've been able to figure out how to rotate the graph yet keep it relatively
(cough) narrow. There's still a few unwanted empty boxes but it now has
nested groupIds. If you look carefully at the com.faster.jackson you'll
notice that there's one subgroup that has a single version but two other
subgroups with multiple versions. Earlier I could see that these
dependencies were pulled in from two locations and that's why there was a
difference. Even if couldn't see the exact reason I know that this larger
group of dependencies usually have the same version and if not I should
take a closer look.

At other places I've had to spend some time tracking down unnecessary
transitive dependencies and fix them with a combination of "optional" and
exclusions. Something like this would probably be easier to examine than a
text listing of several hundred lines.

(BTW the scope and 'optional' will be encoded as color and italics,
respectively.)

The latest version is attached. It's clear that it make sense to move
"common-*" under the "org.apache.commons" group. I'm not sure about the
org.google group - doing this kept some dependencies in the same subgraph
but it also brought in some one-offs.

[image: tree2.png]


On Mon, Mar 24, 2025 at 7:37 PM Tomo Suzuki 
wrote:

> That’s a beautiful diagram. Would you share the background you wanted to
> visualize it in that way? Did it get some tasks done?
>
> Regards,
> Tomo
>
> On Mon, Mar 24, 2025 at 19:02 Bear Giles  wrote:
>
> > I should be clear - the glitch is the column of empty boxes above the
> root
> > dependency. They should not appear.
> >
> > The grayed areas, with one exception, have the same groupId. If they also
> > have the same version then the artifacts will be listed in a single
> stack.
> > The 'type' is omitted if it's "jar", otherwise it will be included on
> that
> > line.
> >
> > If there are multiple versions in the cluster then there will be
> > multiple "records" with same structure as the standalone dependencies.
> The
> > only difference is that they''ll drop the groupId.
> >
> > The one exception is the "Database Drivers" in the bottom left - that's
> an
> > experiment specific to this pom - sometimes you might have a group
> > independent dependencies that serve the same role, e.g., database JDBC
> > drivers. Does it make sense to put them into their own cluster?
> >
> > Bear
> >
> > On Mon, Mar 24, 2025 at 4:52 PM Bear Giles 
> wrote:
> >
> >> The maven-dependency-plugin has a '.dot' option but because of the
> layout
> >> it's useless for anything other than the most trivial dependency
> trees.  I
> >> know we can't replace existing functionality but this could be added as
> >> "dot2", or a 'variant" property could be added to the mojo.
> >>
> >> There are some few obvious tweaks but some of them hit the limitations
> of
> >> the graphviz
> >> library, or at least my understand of it. However I think I have
> >> something very close to a good alternative to the standard layout - I
> just
> >> need to ask the graphviz people as question first.
> >>
> >> I've attached a sample pom and the generated png file. This is the pom I
> >> use for an application that creates a document listing the database
> >> metadata for multiple databases.
> >>
> >> Bear Giles
> >> [image: tree2.png]
> >>
> >
>

Re: Multi-releases support in compiler plugin 4.0-beta-3

[Martin Desruisseaux]

Le 2025-03-24 à 20 h 32, Romain Manni-Bucau a écrit :

any reason to move a plugin configuration from plugin to ? 
(concretely why do we go that way instead of dropping sources concept 
from build)?


Because that configuration is used by many plugins. The same information 
is needed by Javadoc plugin, by resource plugin (for deciding if a 
resource must be copied under META-INF/versions/), and maybe other that 
I'm forgetting.


    Martin



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

Multi-releases support in compiler plugin 4.0-beta-3

[Martin Desruisseaux]

Hello all

A development branch of maven-compiler-plugin 4.0 can now support the
 property of the new  element introduced in Maven 4.
The creation of multi-release JAR files for non-modular projects
should hopefully become easier (support for modular projects will be
added later). Includes/excludes filters are also supported. The page
at [1] takes some Maven 3 use cases and shows their Maven 4
equivalent. The page at [2] is the same thing but as a user-guide
without comparison with Maven 3. The work has not yet been merged to
the Maven repository as it depends on the release of
maven-plugin-testing-harness 4.0.0-beta-4. In the meantime, if there
is any comment about the approaches shown in [1] and [2], we can do
modification. Note: the configuration shown in those pages may be
slightly simplified with [3].

Work not yet done: complete the support of modular projects (there is
currently partial support) and string filtering.

Martin

[1] https://github.com/Geomatys/maven-compiler-plugin/wiki/Migration
[2] https://github.com/Geomatys/maven-compiler-plugin/wiki/User-guide
[3] https://github.com/apache/maven/pull/2180

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

Re: POC for improved DOT output for maven-dependency-plugin

[Bear Giles]

I should be clear - the glitch is the column of empty boxes above the root
dependency. They should not appear.

The grayed areas, with one exception, have the same groupId. If they also
have the same version then the artifacts will be listed in a single stack.
The 'type' is omitted if it's "jar", otherwise it will be included on that
line.

If there are multiple versions in the cluster then there will be
multiple "records" with same structure as the standalone dependencies. The
only difference is that they''ll drop the groupId.

The one exception is the "Database Drivers" in the bottom left - that's an
experiment specific to this pom - sometimes you might have a group
independent dependencies that serve the same role, e.g., database JDBC
drivers. Does it make sense to put them into their own cluster?

Bear

On Mon, Mar 24, 2025 at 4:52 PM Bear Giles  wrote:

> The maven-dependency-plugin has a '.dot' option but because of the layout
> it's useless for anything other than the most trivial dependency trees.  I
> know we can't replace existing functionality but this could be added as
> "dot2", or a 'variant" property could be added to the mojo.
>
> There are some few obvious tweaks but some of them hit the limitations of
> the graphviz
> library, or at least my understand of it. However I think I have something
> very close to a good alternative to the standard layout - I just need to
> ask the graphviz people as question first.
>
> I've attached a sample pom and the generated png file. This is the pom I
> use for an application that creates a document listing the database
> metadata for multiple databases.
>
> Bear Giles
> [image: tree2.png]
>

Re: POC for improved DOT output for maven-dependency-plugin

[Elliotte Rusty Harold]

I'm not sure I believe that the current dot layout is or should be a
reliable part of the public API. if there's a better layout, use it. Unless
maybe devs are somewhere consuming the .dot files themselves to understand
the graph? I hope not, but you never know.

On Mon, Mar 24, 2025 at 10:53 PM Bear Giles  wrote:

> The maven-dependency-plugin has a '.dot' option but because of the layout
> it's useless for anything other than the most trivial dependency trees.  I
> know we can't replace existing functionality but this could be added as
> "dot2", or a 'variant" property could be added to the mojo.
>
> There are some few obvious tweaks but some of them hit the limitations of
> the graphviz
> library, or at least my understand of it. However I think I have something
> very close to a good alternative to the standard layout - I just need to
> ask the graphviz people as question first.
>
> I've attached a sample pom and the generated png file. This is the pom I
> use for an application that creates a document listing the database
> metadata for multiple databases.
>
> Bear Giles
> [image: tree2.png]
>
> -
> 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

Re: POC for improved DOT output for maven-dependency-plugin

[Tomo Suzuki]

That’s a beautiful diagram. Would you share the background you wanted to
visualize it in that way? Did it get some tasks done?

Regards,
Tomo

On Mon, Mar 24, 2025 at 19:02 Bear Giles  wrote:

> I should be clear - the glitch is the column of empty boxes above the root
> dependency. They should not appear.
>
> The grayed areas, with one exception, have the same groupId. If they also
> have the same version then the artifacts will be listed in a single stack.
> The 'type' is omitted if it's "jar", otherwise it will be included on that
> line.
>
> If there are multiple versions in the cluster then there will be
> multiple "records" with same structure as the standalone dependencies. The
> only difference is that they''ll drop the groupId.
>
> The one exception is the "Database Drivers" in the bottom left - that's an
> experiment specific to this pom - sometimes you might have a group
> independent dependencies that serve the same role, e.g., database JDBC
> drivers. Does it make sense to put them into their own cluster?
>
> Bear
>
> On Mon, Mar 24, 2025 at 4:52 PM Bear Giles  wrote:
>
>> The maven-dependency-plugin has a '.dot' option but because of the layout
>> it's useless for anything other than the most trivial dependency trees.  I
>> know we can't replace existing functionality but this could be added as
>> "dot2", or a 'variant" property could be added to the mojo.
>>
>> There are some few obvious tweaks but some of them hit the limitations of
>> the graphviz
>> library, or at least my understand of it. However I think I have
>> something very close to a good alternative to the standard layout - I just
>> need to ask the graphviz people as question first.
>>
>> I've attached a sample pom and the generated png file. This is the pom I
>> use for an application that creates a document listing the database
>> metadata for multiple databases.
>>
>> Bear Giles
>> [image: tree2.png]
>>
>

Re: New Life Cycles Maven 4.0.0-rc3

[Guillaume Nodet]

Could you raise issues for the `all` phase not containing children
subprojects, and eventually for a new `each` phase ?

Le lun. 17 mars 2025 à 21:13, Karl Heinz Marbaise 
a écrit :

> Hi,
>
> I'm trying to build a project with a number of subprojects..
>
> I'm binding a plugin (just echoing) like this to new life cylce phases:
>
> like this:
>
>
>
>  com.soebes.maven.plugins
>  echo-maven-plugin
>  
>
>  before-ready
>  before:ready
>  
>echo
>  
>  
>
>  Hallo 'before:ready' phase.
>
>  
>
>
>  before-all
>  before:all
>  
>echo
>  
>  
>
>  Hallo 'before:all' phase.
>
>  
>
>
>  all
>  all
>  
>echo
>  
>  
>
>  Hallo 'all' phase.
>
>  
>
>
>  after-all
>  after:all
>  
>echo
>  
>  
>
>  Hallo 'after:all' phase.
>
>  
>
>
>
> What I can observe while calling maven like this:
>
> mvn -B -b concurrent verify
>
> What I can observe that for each module the phase:
>
>
> [INFO] --- echo:0.5.0:echo (before-all) @ appasm ---
> [INFO] Hallo 'before:all' phase.
> [INFO]
> [INFO] --- echo:0.5.0:echo (before-all) @ assembly ---
> [INFO] Hallo 'before:all' phase.
> [INFO]
> [INFO] --- echo:0.5.0:echo (before-all) @ shade ---
> [INFO] Hallo 'before:all' phase.
> [INFO]
> [INFO] --- echo:0.5.0:echo (before-all) @ app ---
> [INFO] Hallo 'before:all' phase.
> [INFO]
> [INFO] --- echo:0.5.0:echo (before-all) @ service ---
> [INFO] Hallo 'before:all' phase.
> [INFO]
> [INFO] --- echo:0.5.0:echo (before-all) @ webgui ---
> [INFO] Hallo 'before:all' phase.
> [INFO]
> [INFO] --- echo:0.5.0:echo (before-all) @ service-client ---
> [INFO] Hallo 'before:all' phase.
> 
> is being called..also
> "after:all" the same way..
>
> Based on my assumption (coming from the name) would be called exactly
> once "before:all" ... "after:all" also..
> Because that would not solve the problem to bind a plugin like JaCoCo
> (for coverage for an aggregate) or JavaDoc for an aggregate for a whole
> project in it...
>
> Or do we have a solution for that which I'm not yet aware of?
>
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 

Guillaume Nodet