More rigorous terminology - Was: Terminology proposal: "Maven module" -> "Maven sub-project"

2024-08-16 Thread Andreas Sewe 

Hi,

just a long term Maven user here, but I'd like to chime, as I don't
think renaming module to subproject is that big an improvement. In fact,
it may actually lead to *more* confusion. Here's why:

Maven has two *orthogonal* ways how to projects can relate to each
other: aggregation and inheritance.

As they are frequently used together, terminology is unfortunately often
used in a somewhat sloppy fashion, even within the official
documentation (example below). As they are distinct concepts, however, I
think it is important to be precise.

When explaining Maven aggregation and inheritance to a co-worker, I
hence use the following glossary (my own, not in any way official):

- *project*:
  Anything that has a POM (whose root element is /project)

- *aggregator* (project):
  A POM with non-empty /project/modules element
  (always has /project /packaging = "pom")

- *module*:
  A POM referenced by an aggregator project
  (note that the same POM may be referenced by multiple aggregators,
  e.g., to select different "slices" of projects to build)

- *child* (project):
  A POM with /project/parent element

- *parent* (project):
  A POM referenced by a child project
  (always has /project/packaging = "pom")

Subject to the constraint that some projects must have packaging "pom",
you can combine these, so you may have a child module, i.e., a project
that is both a child project and a module (albeit not necessarily with
the same project as parent and aggregator, respectively).

But as I said, even the official documentation is not always that
precise. An example from the maven-site-plugin's FAQ [1]:


Why don't the links between parent and child modules work when I run
"mvn site"?

What "mvn site" will do for you, in a multi-project build, is to run
"mvn site" for the parent and all its modules individually. The
links between parent and child will not work here.


It really should be "*aggregator* and all its modules". Also, there may
be both links from an aggregator to its modules (/site/body/menu/@ref =
"modules") *and* from a child to its parent (/site/body/menu/@ref =
"parent").

Coming back from this tangent to Martin's proposal, I don't think using
the term "Maven sub-project" improves things. In fact, it makes it even
easier to mistake a module (aggregation) for a child project
(inheritance), as the difference between sub-project and child project
is very subtle.

I would hence restrict the use of "sub-something" to inheritance (think
"sub-class") and never use it to discussion aggregation. In particular,
"submodule" is really redundant, as a module is always below an
aggregator by definition.)

What I would have rather like to see is the following:

1. Some kind of glossary (maybe as part of the POM Reference [2], which
   ATM discussion these terms in only passing)

2. More rigor when talking about modules vs. children in the official
   documentation. (Would be willing to create PRs once an official
   glossary exists that the PRs can follow.)

IMHO, this would avoid a lot more confusion than a hypothetical mixup of
Maven modules with JPMS modules. (FWIW, my past Maven projects have
build JPMS modules, OSGi bundles, NetBeans modules, Eclipse plug-ins and
more without much confusion.)

Just my 2 cents.

Best wishes,

Andreas

[1]

[2] 

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

Re: Terminology proposal: "Maven module" -> "Maven sub-project"

2024-08-16 Thread Andreas Sewe 

Guillaume Nodet wrote:

Maybe now is the time to re(de)fine our terminology:
https://maven.apache.org/glossary.html.


Yes, please!

In fact, I didn't even know about the glossary (after 10+ years of using 
Maven). It's not linked from the POM Reference, for example.


At any rate, I have just proposed some terms for a hypothetical glossary 
in my 'More rigorous terminology - Was: Terminology proposal: "Maven 
module" -> "Maven sub-project' post to this very thread.


Best wishes,

Andreas

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

Re: More rigorous terminology - Was: Terminology proposal: "Maven module" -> "Maven sub-project"

2024-08-16 Thread Kemal Soysal 
Hi Andreas,

it took me some years to find relevant articles and documentation on the maven 
site.
And still it is not easy to find documentation in the depth needed.

I would regret if "module" was changed. It is, as it is now, the best 
description and semantics of what it is.

Maybe we should provide a couple of UML-Diagrams to make those roles better 
visible.


> Am 16.08.2024 um 09:51 schrieb Andreas Sewe :
> 
> Hi,
> 
> just a long term Maven user here, but I'd like to chime, as I don't
> think renaming module to subproject is that big an improvement. In fact,
> it may actually lead to *more* confusion. Here's why:
> 
> Maven has two *orthogonal* ways how to projects can relate to each
> other: aggregation and inheritance.
> 
> As they are frequently used together, terminology is unfortunately often
> used in a somewhat sloppy fashion, even within the official
> documentation (example below). As they are distinct concepts, however, I
> think it is important to be precise.
> 
> When explaining Maven aggregation and inheritance to a co-worker, I
> hence use the following glossary (my own, not in any way official):
> 
> - *project*:
>  Anything that has a POM (whose root element is /project)
> 
> - *aggregator* (project):
>  A POM with non-empty /project/modules element
>  (always has /project /packaging = "pom")
> 
> - *module*:
>  A POM referenced by an aggregator project
>  (note that the same POM may be referenced by multiple aggregators,
>  e.g., to select different "slices" of projects to build)
> 
> - *child* (project):
>  A POM with /project/parent element
> 
> - *parent* (project):
>  A POM referenced by a child project
>  (always has /project/packaging = "pom")
> 
> Subject to the constraint that some projects must have packaging "pom",
> you can combine these, so you may have a child module, i.e., a project
> that is both a child project and a module (albeit not necessarily with
> the same project as parent and aggregator, respectively).
> 
> But as I said, even the official documentation is not always that
> precise. An example from the maven-site-plugin's FAQ [1]:
> 
>> Why don't the links between parent and child modules work when I run
>> "mvn site"?
>> What "mvn site" will do for you, in a multi-project build, is to run
>> "mvn site" for the parent and all its modules individually. The
>> links between parent and child will not work here.
> 
> It really should be "*aggregator* and all its modules". Also, there may
> be both links from an aggregator to its modules (/site/body/menu/@ref =
> "modules") *and* from a child to its parent (/site/body/menu/@ref =
> "parent").
> 
> Coming back from this tangent to Martin's proposal, I don't think using
> the term "Maven sub-project" improves things. In fact, it makes it even
> easier to mistake a module (aggregation) for a child project
> (inheritance), as the difference between sub-project and child project
> is very subtle.
> 
> I would hence restrict the use of "sub-something" to inheritance (think
> "sub-class") and never use it to discussion aggregation. In particular,
> "submodule" is really redundant, as a module is always below an
> aggregator by definition.)
> 
> What I would have rather like to see is the following:
> 
> 1. Some kind of glossary (maybe as part of the POM Reference [2], which
>   ATM discussion these terms in only passing)
> 
> 2. More rigor when talking about modules vs. children in the official
>   documentation. (Would be willing to create PRs once an official
>   glossary exists that the PRs can follow.)
> 
> IMHO, this would avoid a lot more confusion than a hypothetical mixup of
> Maven modules with JPMS modules. (FWIW, my past Maven projects have
> build JPMS modules, OSGi bundles, NetBeans modules, Eclipse plug-ins and
> more without much confusion.)
> 
> Just my 2 cents.
> 
> Best wishes,
> 
> Andreas
> 
> [1]
> 
> [2] 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Best Regards
Kemal

Kemal Soysall

Re: More rigorous terminology - Was: Terminology proposal: "Maven module" -> "Maven sub-project"

2024-08-16 Thread Christoph Läubrich 
I agree that subproject is odd and even more confusing, because the real 
project (== those with packaging != pom) can't contain 


Of course a parent can also include  but this is not required 
and often separated also a single project might occur in different 
aggregators and so on.


Am 16.08.24 um 09:51 schrieb Andreas Sewe:

Hi,

just a long term Maven user here, but I'd like to chime, as I don't
think renaming module to subproject is that big an improvement. In fact,
it may actually lead to *more* confusion. Here's why:

Maven has two *orthogonal* ways how to projects can relate to each
other: aggregation and inheritance.

As they are frequently used together, terminology is unfortunately often
used in a somewhat sloppy fashion, even within the official
documentation (example below). As they are distinct concepts, however, I
think it is important to be precise.

When explaining Maven aggregation and inheritance to a co-worker, I
hence use the following glossary (my own, not in any way official):

- *project*:
   Anything that has a POM (whose root element is /project)

- *aggregator* (project):
   A POM with non-empty /project/modules element
   (always has /project /packaging = "pom")

- *module*:
   A POM referenced by an aggregator project
   (note that the same POM may be referenced by multiple aggregators,
   e.g., to select different "slices" of projects to build)

- *child* (project):
   A POM with /project/parent element

- *parent* (project):
   A POM referenced by a child project
   (always has /project/packaging = "pom")

Subject to the constraint that some projects must have packaging "pom",
you can combine these, so you may have a child module, i.e., a project
that is both a child project and a module (albeit not necessarily with
the same project as parent and aggregator, respectively).

But as I said, even the official documentation is not always that
precise. An example from the maven-site-plugin's FAQ [1]:


Why don't the links between parent and child modules work when I run
"mvn site"?

What "mvn site" will do for you, in a multi-project build, is to run
"mvn site" for the parent and all its modules individually. The
links between parent and child will not work here.


It really should be "*aggregator* and all its modules". Also, there may
be both links from an aggregator to its modules (/site/body/menu/@ref =
"modules") *and* from a child to its parent (/site/body/menu/@ref =
"parent").

Coming back from this tangent to Martin's proposal, I don't think using
the term "Maven sub-project" improves things. In fact, it makes it even
easier to mistake a module (aggregation) for a child project
(inheritance), as the difference between sub-project and child project
is very subtle.

I would hence restrict the use of "sub-something" to inheritance (think
"sub-class") and never use it to discussion aggregation. In particular,
"submodule" is really redundant, as a module is always below an
aggregator by definition.)

What I would have rather like to see is the following:

1. Some kind of glossary (maybe as part of the POM Reference [2], which
    ATM discussion these terms in only passing)

2. More rigor when talking about modules vs. children in the official
    documentation. (Would be willing to create PRs once an official
    glossary exists that the PRs can follow.)

IMHO, this would avoid a lot more confusion than a hypothetical mixup of
Maven modules with JPMS modules. (FWIW, my past Maven projects have
build JPMS modules, OSGi bundles, NetBeans modules, Eclipse plug-ins and
more without much confusion.)

Just my 2 cents.

Best wishes,

Andreas

[1]

[2] 

-
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: More rigorous terminology - Was: Terminology proposal: "Maven module" -> "Maven sub-project"

2024-08-16 Thread Richard Eckart de Castilho 


> On 16. Aug 2024, at 10:24, Christoph Läubrich  wrote:
> 
>> I would hence restrict the use of "sub-something" to inheritance (think
>> "sub-class") and never use it to discussion aggregation. In particular,
>> "submodule" is really redundant, as a module is always below an
>> aggregator by definition.)

Actually, a module is just a relative path and can in fact go up.
So the definition of "below" is not necessarily synonymous with
"nested" or "inside". 

Wild suggestion...

Instead of 


  a
  ../b


use terminology that we know (e.g. aggregate) and re-use terminology from the 
parent element for relative project/POM references


  a
  ../b



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

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

2024-08-16 Thread Tamás Cservenák 
+1

On Thu, Aug 15, 2024 at 2:11 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> We solved 9 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12344384
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-jarsigner%20ORDER%20BY%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2183/
>
> https://repository.apache.org/content/repositories/maven-2183/org/apache/maven/shared/maven-jarsigner/3.1.0/maven-jarsigner-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-jarsigner-3.1.0-source-release.zip - SHA-512 :
>
> e55b331af99b2487d38ed1a9ae30515c5054be75ad8ae12c8e03ea89593098133a620b6c219163f9a9fc886f0e1c35b496cbb6993b9b12f7367d2c5b452a2c27
>
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-jarsigner-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski
>

Re: [VOTE] Release Apache Maven 3.9.9 (respin #1)

2024-08-16 Thread Slawomir Jaranowski 
+1

śr., 14 sie 2024 o 11:01 Tamás Cservenák  napisał(a):

> Howdy,
>
> Respin #1: mvn shell script fix, removal of "bashism":
> https://github.com/apache/maven/pull/1653
>
> We solved 13 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12354823
>
> 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-2180/
>
> Dev dist directory (binary bundles updated):
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.9/
>
> Source release checksums:
> apache-maven-3.9.9-src.tar.gz.sha512
>
> 2f395661e7a48c454dd526f2800df209169a253e7980f6fbfbf5f63546fe726a45935f14b151a2737159c9574b5b0f223ea8cd0f62232dd47b47a6863df790d5
>
> apache-maven-3.9.9-src.zip.sha512
>
> 8b8db402b4469aa2570dcb3ad5aba5869ef186b0ef3f061ca9654bebc9d0a967d75eba1c77f5e269a4447936df3cb1ae6deaf09248469060b98091966acb6653
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/554
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>


-- 
Sławomir Jaranowski

Re: [DISCUSS] maven-core-plugin

2024-08-16 Thread Ozgun Oz 
Just an outsider here, but I agree with Guillaume. Also I think Tamas'
proposal is to merge the existing plugins, so the repo of the old plugins
will be probably archived and the old plugins code will be moved to the new
plugin repo.

Since the old plugins will not evolve and maintained by ASF, and honestly
as Tamas said I doubt anyone will try to fork the old plugin and compete
with ASF, I don't think we can talk about a risk of having "duplicate
standards competing" here.

Maybe we should wait Tamas' clarification on the proposal. Is it about just
creating a new plugin on top of existing ones ? or merge the existing ones
into a new one ?


On Thu, Aug 15, 2024, 9:30 PM Guillaume Nodet  wrote:

> Well this would be the same plugins, not duplicates….
>
> 
> Guillaume Nodet
>
>
>
> Le jeu. 15 août 2024 à 20:10, Elliotte Rusty Harold  a
> écrit :
>
> > On Thu, Aug 15, 2024 at 1:24 PM Delany 
> wrote:
> >
> > > The $5000 question is how can the old plugins still even exist if the
> > code
> > > for them has been moved to a new core plugin?
> >
> >
> > In the git repo. In Maven central. In absolutely every existing plugin
> > and build that depends on these today. They aren't going away. Where
> > do I collect my $5000? :-)
> >
> > --
> > 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: [VOTE] Release Apache Maven 3.9.9 (respin #1)

2024-08-16 Thread Michael Osipov 

Am 2024-08-14 um 11:00 schrieb Tamás Cservenák:

Howdy,

Respin #1: mvn shell script fix, removal of "bashism":
https://github.com/apache/maven/pull/1653

We solved 13 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12354823

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-2180/

Dev dist directory (binary bundles updated):
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.9/

Source release checksums:
apache-maven-3.9.9-src.tar.gz.sha512
2f395661e7a48c454dd526f2800df209169a253e7980f6fbfbf5f63546fe726a45935f14b151a2737159c9574b5b0f223ea8cd0f62232dd47b47a6863df790d5

apache-maven-3.9.9-src.zip.sha512
8b8db402b4469aa2570dcb3ad5aba5869ef186b0ef3f061ca9654bebc9d0a967d75eba1c77f5e269a4447936df3cb1ae6deaf09248469060b98091966acb6653

Staged site:
https://maven.apache.org/ref/3-LATEST/

Draft for release notes:
https://github.com/apache/maven-site/pull/554

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72h


+1

Re: [VOTE] Release Maven Surefire version 3.4.0

2024-08-16 Thread Michael Osipov 

Am 2024-08-15 um 22:06 schrieb Michael Osipov:

Hi,

we solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12354945

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-2185/
https://repository.apache.org/content/repositories/maven-2185/org/apache/maven/surefire/surefire/3.4.0/surefire-3.4.0-source-release.zip

Source release checksum(s):
surefire-3.4.0-source-release.zip
sha512: 
b29c620f7b98bdd013b29ed0b5d451960f217fd78354af83ea03b4b3e54ff38290ac1a29c0ce1cda298557ef49bcc4c390422f7cf2feeeadc76654897ba051ac


Staging site:
https://maven.apache.org/surefire-archives/surefire-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1


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

Re: [VOTE] Release Maven Fluido Skin version 2.0.0-M10

2024-08-16 Thread Michael Osipov 

Am 2024-08-15 um 19:36 schrieb Michael Osipov:

Hi,

we solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317926&version=12354803

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSKINS%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20%22Fluido%20Skin%22

Staging repo:
https://repository.apache.org/content/repositories/maven-2184/
https://repository.apache.org/content/repositories/maven-2184/org/apache/maven/skins/maven-fluido-skin/2.0.0-M10/maven-fluido-skin-2.0.0-M10-source-release.zip

Source release checksum(s):
maven-fluido-skin-2.0.0-M10-source-release.zip
sha512: 
8d99e13cb0be2021c00bcbdb44b91674729b57a021baf2f390b4a4336aabf42d8b428fafe0fed48b961daa7ef7c6de3e8f3f62734de81e37163e3fa1f5f1ade3


Staging site:
https://maven.apache.org/components/skins-archives/maven-fluido-skin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1


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

Re: [VOTE] Release Maven Site Plugin version 3.20.0

2024-08-16 Thread Slawomir Jaranowski 
Ok, with Fluido 2.0.0-M9 is better ...

But with Maven 4 I have:

[DEBUG] Looking for site descriptor of level 1 parent project:
org.apache.maven.plugins:maven-plugins:pom:44-SNAPSHOT
[DEBUG] No parent level 1 site descriptor
[DEBUG] Looking for site descriptor of level 2 parent project:
org.apache.maven:maven-parent:pom:44-SNAPSHOT
[DEBUG] No parent level 2 site descriptor
[DEBUG] Looking for site descriptor of level 3 parent project:
org.apache:apache:pom:34-SNAPSHOT
[DEBUG] No parent level 3 site descriptor

There was an issue for it but I can not find it now.


czw., 15 sie 2024 o 19:20 Michael Osipov  napisał(a):

> Am 2024-08-15 um 12:53 schrieb Slawomir Jaranowski:
> > Hi,
> >
> > I'm try to build site in maven-parent with new version
> >
> > mvn clean site -f docs -Dversion.maven-site-plugin=3.20.0 -Papache-stage
> -e
> >
> > - apache-stage - my profile with staging repo ...
> >
> > I have:
> >
> > [WARNING] Site model of 'org.apache.maven:docs:pom:44-SNAPSHOT' for
> default
> > locale is still using the old pre-version 2.0.0 model. You MUST migrate
> to
> > the new model as soon as possible otherwise your build will break in the
> > future!
> > [WARNING] Site model of 'org.apache.maven:maven-parent:pom:44-SNAPSHOT'
> for
> > default locale is still using the old pre-version 2.0.0 model. You MUST
> > migrate to the new model as soon as possible otherwise your build will
> > break in the future!
> > [INFO] Relativizing site links with respect to localized project URL:
> > https://maven.apache.org/pom/maven/
> > [INFO] Rendering content with
> > org.apache.maven.skins:maven-fluido-skin:jar:1.12.0 skin
> > ...
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-site-plugin:3.20.0:site (default-site) on
> > project docs: Failed to create context for skin: Cannot use skin: has
> > [1.11.1,2.0.0-M1) Doxia Sitetools prerequisite, but current is 2.0.0-M19
> ->
> > [Help 1]
> >
> > Should we update something for the new maven-site-plugin?
>
> The behvior your see is correct since the Fluido skin 1.x is not
> compatible with Doxia 2.0.0. Try out version 2.0.0-M9 and it will work.
>
> I'd recommend holding off ugprades until I have complete the release
> according to my description from the HEADS UP.
>
> Michael
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: [VOTE] Release Maven Site Plugin version 3.20.0

2024-08-16 Thread Michael Osipov 

Am 2024-08-16 um 21:08 schrieb Slawomir Jaranowski:

Ok, with Fluido 2.0.0-M9 is better ...

But with Maven 4 I have:

[DEBUG] Looking for site descriptor of level 1 parent project:
org.apache.maven.plugins:maven-plugins:pom:44-SNAPSHOT
[DEBUG] No parent level 1 site descriptor
[DEBUG] Looking for site descriptor of level 2 parent project:
org.apache.maven:maven-parent:pom:44-SNAPSHOT
[DEBUG] No parent level 2 site descriptor
[DEBUG] Looking for site descriptor of level 3 parent project:
org.apache:apache:pom:34-SNAPSHOT
[DEBUG] No parent level 3 site descriptor

There was an issue for it but I can not find it now.


https://github.com/apache/maven/pull/1594 and 
https://issues.apache.org/jira/browse/DOXIASITETOOLS-343. I haven't 
reviewed the former and have no clue how to solve the latter, therefore 
I need help to resolve this.


M


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

Re: [VOTE] Release Maven Site Plugin version 3.20.0

2024-08-16 Thread Slawomir Jaranowski 
+1

We should add info about migration, like requirement for Fluido 2.x
But can be as first step

śr., 14 sie 2024 o 18:06 Michael Osipov  napisał(a):

> Hi,
>
> NOTE: Read the details on this release here:
>
> https://cwiki.apache.org/confluence/display/MAVEN/Towards+Doxia+2.0.0+Stack#TowardsDoxia2.0.0Stack-MavenSitePlugin3.20.0/4.0.0
>
> we solved 85 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12354960
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2182/
>
> https://repository.apache.org/content/repositories/maven-2182/org/apache/maven/plugins/maven-site-plugin/3.20.0/maven-site-plugin-3.20.0-source-release.zip
>
> Source release checksum(s):
> maven-site-plugin-3.20.0-source-release.zip
> sha512:
>
> bb086f101d9fda9e959db7e3e46775e3f825f8ecd8103adc1747155216d62c3e6bca808b416d71d10d8071a5b0218cf5dfc01dfe67d8e383a6f77088e3e943e7
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: [VOTE] Release Apache Maven 3.9.9 (respin #1)

2024-08-16 Thread Olivier Lamy 
+1

On Wed, 14 Aug 2024 at 7:01 PM, Tamás Cservenák  wrote:

> Howdy,
>
> Respin #1: mvn shell script fix, removal of "bashism":
> https://github.com/apache/maven/pull/1653
>
> We solved 13 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12354823
>
> 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-2180/
>
> Dev dist directory (binary bundles updated):
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.9/
>
> Source release checksums:
> apache-maven-3.9.9-src.tar.gz.sha512
>
> 2f395661e7a48c454dd526f2800df209169a253e7980f6fbfbf5f63546fe726a45935f14b151a2737159c9574b5b0f223ea8cd0f62232dd47b47a6863df790d5
>
> apache-maven-3.9.9-src.zip.sha512
>
> 8b8db402b4469aa2570dcb3ad5aba5869ef186b0ef3f061ca9654bebc9d0a967d75eba1c77f5e269a4447936df3cb1ae6deaf09248469060b98091966acb6653
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/554
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [VOTE] Release Apache Maven 3.9.9 (respin #1)

2024-08-16 Thread Mark Derricutt 
+1 non-binding from me.

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 17 Aug 2024 at 4:35:57 PM, Olivier Lamy  wrote:

> +1
>
>
>

Re: More rigorous terminology - Was: Terminology proposal: "Maven module" -> "Maven sub-project"

2024-08-16 Thread Guillaume Nodet 
Le ven. 16 août 2024 à 09:51, Andreas Sewe 
a écrit :
>
> Hi,
>
> just a long term Maven user here, but I'd like to chime, as I don't
> think renaming module to subproject is that big an improvement. In fact,
> it may actually lead to *more* confusion. Here's why:
>
> Maven has two *orthogonal* ways how to projects can relate to each
> other: aggregation and inheritance.
>
> As they are frequently used together, terminology is unfortunately often
> used in a somewhat sloppy fashion, even within the official
> documentation (example below). As they are distinct concepts, however, I
> think it is important to be precise.
>
> When explaining Maven aggregation and inheritance to a co-worker, I
> hence use the following glossary (my own, not in any way official):
>
> - *project*:
>Anything that has a POM (whose root element is /project)
>
> - *aggregator* (project):
>A POM with non-empty /project/modules element
>(always has /project /packaging = "pom")

Aggregator is also used to refer to a project which “aggregates” multiple
standalone projects:
*
https://docs.redhat.com/en/documentation/red_hat_jboss_fuse/6.3/html/developing_and_deploying_applications/develop-aggregator
* https://www.smartics.eu/confluence/pages/viewpage.action?pageId=24511533

If we keep aggregator/module, we may have to find another term for these
kind of projects.

>
> - *module*:
>A POM referenced by an aggregator project
>(note that the same POM may be referenced by multiple aggregators,
>e.g., to select different "slices" of projects to build)
>
> - *child* (project):
>A POM with /project/parent element
>
> - *parent* (project):
>A POM referenced by a child project
>(always has /project/packaging = "pom")
>
> Subject to the constraint that some projects must have packaging "pom",
> you can combine these, so you may have a child module, i.e., a project
> that is both a child project and a module (albeit not necessarily with
> the same project as parent and aggregator, respectively).

Nice glossary, we should be able to leverage that.


> But as I said, even the official documentation is not always that
> precise. An example from the maven-site-plugin's FAQ [1]:
>
> > Why don't the links between parent and child modules work when I run
> > "mvn site"?
> >
> > What "mvn site" will do for you, in a multi-project build, is to run
> > "mvn site" for the parent and all its modules individually. The
> > links between parent and child will not work here.
>
> It really should be "*aggregator* and all its modules". Also, there may
> be both links from an aggregator to its modules (/site/body/menu/@ref =
> "modules") *and* from a child to its parent (/site/body/menu/@ref =
> "parent").
>
> Coming back from this tangent to Martin's proposal, I don't think using
> the term "Maven sub-project" improves things. In fact, it makes it even
> easier to mistake a module (aggregation) for a child project
> (inheritance), as the difference between sub-project and child project
> is very subtle.
>
> I would hence restrict the use of "sub-something" to inheritance (think
> "sub-class") and never use it to discussion aggregation. In particular,
> "submodule" is really redundant, as a module is always below an
> aggregator by definition.)
>
> What I would have rather like to see is the following:
>
> 1. Some kind of glossary (maybe as part of the POM Reference [2], which
> ATM discussion these terms in only passing)
>
> 2. More rigor when talking about modules vs. children in the official
> documentation. (Would be willing to create PRs once an official
> glossary exists that the PRs can follow.)



> IMHO, this would avoid a lot more confusion than a hypothetical mixup of
> Maven modules with JPMS modules. (FWIW, my past Maven projects have
> build JPMS modules, OSGi bundles, NetBeans modules, Eclipse plug-ins and
> more without much confusion.)
>
> Just my 2 cents.
>
> Best wishes,
>
> Andreas
>
> [1]
> <
https://maven.apache.org/plugins/maven-site-plugin/faq.html#Why_dont_the_links_between_parent_and_child_modules_work_when_I_run_mvn_site
>
> [2] 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 

Guillaume Nodet