You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2025/01/03 16:07:43 UTC
[LAZY][VOTE] Release Apache Commons Parent 79 based on RC2
We have fixed a few bugs and added enhancements since Apache Commons Parent
78 was released, so I would like to release Apache Commons Parent 79.
The most important change is the migration to Doxia 2 which allows
using current Maven plugins.
Apache Commons Parent 79 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2 (svn
revision 73958)
The Git tag commons-parent-79-RC2 commit for this RC is
b8d7c5be2505e3f669ecf202261f36511f39009b which you can browse here:
https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=b8d7c5be2505e3f669ecf202261f36511f39009b
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-parent.git
--branch commons-parent-79-RC2 commons-parent-79-RC2
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1798/org/apache/commons/commons-parent/79/
These are the artifacts and their hashes:
#Release SHA-512s
#Fri Jan 03 15:58:47 UTC 2025
commons-parent-79-bom.json=4e7fb23db62d038cf535ed679b8721ef07aa9738e9c0d14ff5412698e9d829f35232aba31b554997148a8aa87b67dfee2d7d822bb4220c8399f68afaadf1538d
commons-parent-79-bom.xml=0807a3b8956729680c7477ab92bb04db6cb9615088dc941e2c9e91e8b1ae402c6f7be479c24e6a8775935e6e5bf2f7b59ec0e68ca6c79be513fe4a1ee3bcbf66
commons-parent-79-site.xml=1c4e77414868a5a026a49302efbb2b629d86f210ca2430d1996e7e540706f1ed1906d36a4118b93580d7eaec7440c70ef22dfae280e568df77ae8e165b2cc159
commons-parent-79-src.tar.gz=760c8ef251cb5812a7d8fe4d5acb33e8f7478010e01a81912915b84b83368da2cc6bb80e40abe9729369dd517f3f0ee76d6dc0dcb38103397d9dbf7ebc1fa187
commons-parent-79-src.zip=44ac8cd89cd4ff270e4ddf239a7e9134bcc5c186fa0249195ad64878648dd8204ea0cf4d141245425091186d07b2df282c012ebfcd7b2c2e8f2c190fc3ef6a11
org.apache.commons_commons-parent-79.spdx.json=f2c070ea4716ab7f3fd46f44c6cff462761d64526d5a69d15efe75629a0cced9c83305167af52d6dfab8c74ef3df4d77edd0f9ccd7d30c5f5b4c71093aedf940
I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P
jacoco -P japicmp clean package site deploy' using:
openjdk version "17.0.13" 2024-10-15
OpenJDK Runtime Environment Homebrew (build 17.0.13+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.13+0, mixed mode, sharing)
Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
Maven home: /opt/homebrew/Cellar/maven/3.9.9/libexec
Java version: 17.0.13, vendor: Homebrew, runtime:
/opt/homebrew/Cellar/openjdk@17/17.0.13/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "15.2", arch: "aarch64", family: "mac"
Darwin ****.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec 6 19:03:40
PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6041 arm64
Docker version 27.3.1, build ce12230
Details of changes since 79 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/RELEASE-NOTES.txt
https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/changes.html
Site:
https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/index.html
(note some *relative* links are broken and the 79 directories are not
yet created - these will be OK once the site is deployed.)
RAT Report:
https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/rat-report.html
KEYS:
https://downloads.apache.org/commons/KEYS
Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thank you,
Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)
The following is intended as a helper and refresher for reviewers.
Validating a release candidate
==============================
These guidelines are NOT complete.
Requirements: Git, Java, Maven.
You can validate a release from a release candidate (RC) tag as follows.
1a) Clone and checkout the RC tag
git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch
commons-parent-79-RC2 commons-parent-79-RC2
cd commons-parent-79-RC2
1b) Download and unpack the source archive from:
https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/source
2) Check Apache licenses
This step is not required if the site includes a RAT report page which you
then must check.
mvn apache-rat:check
3) Check binary compatibility
Older components still use Apache Clirr:
This step is not required if the site includes a Clirr report page which
you then must check.
mvn clirr:check
Newer components use JApiCmp with the japicmp Maven Profile:
This step is not required if the site includes a JApiCmp report page which
you then must check.
mvn install -DskipTests -P japicmp japicmp:cmp
4) Build the package
mvn -V clean package
You can record the Maven and Java version produced by -V in your VOTE reply.
To gather OS information from a command line:
Windows: ver
Linux: uname -a
5) Build the site for a single module project
Note: Some plugins require the components to be installed instead of
packaged.
mvn site
Check the site reports in:
- Windows: target\site\index.html
- Linux: target/site/index.html
-the end-
Re: Using Git for websites
Posted by sebb <se...@gmail.com>.
On Sat, 18 Jan 2025 at 17:18, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le sam. 18 janv. 2025 à 17:22, Gary Gregory <ga...@gmail.com> a écrit :
> >
> > On Sat, Jan 18, 2025 at 11:05 AM sebb <se...@gmail.com> wrote:
> > >
> > > On Sat, 18 Jan 2025 at 15:03, Gilles Sadowski <gi...@gmail.com> wrote:
> > > >
> > > > > > TL;DR; Quite some time ago, INFRA offered the possibility to move
> > > > > > the website(s) under "git" control. Is this related?
> > > > > > If not, and there is a big change, should we reconsider the move?
> > > > >
> > > > > This is not related AFAICT.
> > > > >
> > > > > Moving the sites to git would not remove the need to use Subversion to
> > > > > manage releasing components since there are other bits and pieces that
> > > > > are in Subversion.
> > > > >
> > > > > For example, https://dist.apache.org/repos/dist/release/commons/ is
> > > > > under Subversion
> > > >
> > > > I don't mind using subversion for this; it has nothing to do
> > > > with moving to "git" for managing the web sites.
> > >
> > > Someone would need to work out how to migrate all the websites.
> > >
> > > Components don't have their own sites; they are subdirectories of the main site.
> > >
> > > These all have to be merged together, which was quite tricky to set up.
> > >
> > > Changing this is not going to be easy.
> > >
> > > I don't know if it would be possible to migrate individual components,
> > > or whether it would be necessary to do them all at once to avoid
> > > breaking things.
> > >
> > > Is anyone offering to do this work?
> > > And fix any issues that occur?
> >
> > What problem are we wanting to solve here?
>
> One problem is the mix of SVN (for the site itself) and
> git (for the source code).
The site source is in Git in the same repos as the component.
[Apart from the DORMANT and SANDBOX components.]
At present the generated sites are committed to SVN.
AIUI there is no technical reason why the generated output should not
be in Git as well.
It's obviously possible to merge multiple components into a single
site in Git, as that is what Logging does.
The issue here is how to migrate everything across.
Can it be done piecemeal?
> AFAIK the migration is supposedly a progress and will
> perhaps be better supported by tools provided by INFRA.
> A likely consequence could be a better separation of
> contents and layout, and a website with a nicer look.
That does not follow, unless the website is redesigned.
> Just compare
> https://logging.apache.org/
> with
> https://commons.apache.org/
> There is no advantage that those sites look so different.
???
> It's not a priority task, for sure, but if someone can pull
> it off, it would be great IMHO.
>
> > Especially considering
> > Subversion is still needed to manage releases.
>
> That's not a reason for not migrating; otherwise, no
> project would have done so.
Agreed, that is irrelevant.
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by Gilles Sadowski <gi...@gmail.com>.
Le sam. 18 janv. 2025 à 17:22, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Sat, Jan 18, 2025 at 11:05 AM sebb <se...@gmail.com> wrote:
> >
> > On Sat, 18 Jan 2025 at 15:03, Gilles Sadowski <gi...@gmail.com> wrote:
> > >
> > > > > TL;DR; Quite some time ago, INFRA offered the possibility to move
> > > > > the website(s) under "git" control. Is this related?
> > > > > If not, and there is a big change, should we reconsider the move?
> > > >
> > > > This is not related AFAICT.
> > > >
> > > > Moving the sites to git would not remove the need to use Subversion to
> > > > manage releasing components since there are other bits and pieces that
> > > > are in Subversion.
> > > >
> > > > For example, https://dist.apache.org/repos/dist/release/commons/ is
> > > > under Subversion
> > >
> > > I don't mind using subversion for this; it has nothing to do
> > > with moving to "git" for managing the web sites.
> >
> > Someone would need to work out how to migrate all the websites.
> >
> > Components don't have their own sites; they are subdirectories of the main site.
> >
> > These all have to be merged together, which was quite tricky to set up.
> >
> > Changing this is not going to be easy.
> >
> > I don't know if it would be possible to migrate individual components,
> > or whether it would be necessary to do them all at once to avoid
> > breaking things.
> >
> > Is anyone offering to do this work?
> > And fix any issues that occur?
>
> What problem are we wanting to solve here?
One problem is the mix of SVN (for the site itself) and
git (for the source code).
AFAIK the migration is supposedly a progress and will
perhaps be better supported by tools provided by INFRA.
A likely consequence could be a better separation of
contents and layout, and a website with a nicer look.
Just compare
https://logging.apache.org/
with
https://commons.apache.org/
There is no advantage that those sites look so different.
It's not a priority task, for sure, but if someone can pull
it off, it would be great IMHO.
> Especially considering
> Subversion is still needed to manage releases.
That's not a reason for not migrating; otherwise, no
project would have done so.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Jan 18, 2025 at 11:05 AM sebb <se...@gmail.com> wrote:
>
> On Sat, 18 Jan 2025 at 15:03, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > > > TL;DR; Quite some time ago, INFRA offered the possibility to move
> > > > the website(s) under "git" control. Is this related?
> > > > If not, and there is a big change, should we reconsider the move?
> > >
> > > This is not related AFAICT.
> > >
> > > Moving the sites to git would not remove the need to use Subversion to
> > > manage releasing components since there are other bits and pieces that
> > > are in Subversion.
> > >
> > > For example, https://dist.apache.org/repos/dist/release/commons/ is
> > > under Subversion
> >
> > I don't mind using subversion for this; it has nothing to do
> > with moving to "git" for managing the web sites.
>
> Someone would need to work out how to migrate all the websites.
>
> Components don't have their own sites; they are subdirectories of the main site.
>
> These all have to be merged together, which was quite tricky to set up.
>
> Changing this is not going to be easy.
>
> I don't know if it would be possible to migrate individual components,
> or whether it would be necessary to do them all at once to avoid
> breaking things.
>
> Is anyone offering to do this work?
> And fix any issues that occur?
What problem are we wanting to solve here? Especially considering
Subversion is still needed to manage releases.
Gary
>
> There was a related discussion here:
> https://lists.apache.org/thread/zpzfjkdmms4gs6dk0bxpl5z08oco2wbg
>
> It's not clear if the approach taken by logging would work for Commons.
>
> Sebb
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by Gary Gregory <ga...@gmail.com>.
Also, if someone is thinking about doing this, they better be ready to
take on updating and testing our Maven Commons Release Plugin which
checks in the site and deliverables to Subversion.
Gary
On Sun, Jan 19, 2025 at 6:35 PM sebb <se...@gmail.com> wrote:
>
> On Sun, 19 Jan 2025 at 17:28, Piotr P. Karwasz
> <pi...@mailing.copernik.eu> wrote:
> >
> > Hi Gilles,
> >
> > On 19.01.2025 14:30, Gilles Sadowski wrote:
> > > Hi.
> > >
> > > Le sam. 18 janv. 2025 à 19:14, Piotr P. Karwasz
> > > <pi...@mailing.copernik.eu> a écrit :
> > >> The changes in `logging.apache.org` took close to 1000 work hours (2
> > >> developers for 3 months) and were financed by the Sovereign Tech Fund
> > >> (now Agency). Commons has also several critical projects, so we could
> > >> apply for one of its programs.
> > > It's clear what "Log4J" does; I'm pretty sure that there won't be
> > > a consensus here about what the scope of "Commons" is. My
> > > impression is that it would be difficult to explain what the funding
> > > will be used for.
> > > E.g. they may not be interested in rarely used components;
> > > but does that make them less "critical"?
> > > A slick website is "nice" but not really "critical" (as long as it is
> > > not tampered with).
> > > Of course, I'm certainly not opposed to someone trying to get
> > > resources to do <something>.
> >
> > In general most Commons projects fulfill the criteria for funding, while
> > `commons-lang`, `commons-io` and `commons-codec` are on multiple lists
> > of critical Open Source projects. It would be mostly up to us to define,
> > which changes in Commons are most needed and to translate those changes
> > in well defined milestones and funding needs.
> >
> > [1] https://www.sovereign.tech/programs/fund#criteria
> >
> > > I was going to ask "why Asciidoc", but most of the answers is there
> > > https://asciidoc.org/#about
> > >
> > > A primary question is then: Do we want to normalize the "Commons"
> > > documentation so that all components use "Asciidoc"?
> > Personally I don't have a preference between markup languages, as long
> > as we use the same markup language for all the documentation. Using
> > Javadoc as Gary suggests is fine with me too.
> > >> 3. Replacing `maven-site-plugin` with Antora can reuse the work done in
> > >> Log4j.
> > > I don't know what "Antora" is. But if "Log4J" did the work already and
> > > people are happy with the result, it's a strong incentive to indeed follow
> > > that path.
> >
> > Antora[2] is a static website generator that can build a website from
> > multiple Git repositories/branches and helps creating cross-references
> > between the different websites.
> >
> > In Log4j we were mostly interested in replacing `maven-site-plugin` and
> > speeding up the site generation. Most reports generated by
> > `maven-site-plugin` (e.g. PMD, Dependency Convergence, etc.) are not
> > really useful for the general public and they slow down site generation
> > considerably.
>
> Commons components are low level, and the audience is not the general
> public, rather developers.
> I think many of the reports *are* needed, for example changes,
> japicmp, dependencies.
>
> > The same remarks apply as for the markup languages, we could have chosen
> > any other website generator (including `maven-site-plugin`, if we remove
> > all the reports), but we chose Antora.
> >
> > Piotr
> >
> > [2] https://antora.org/
> >
> > [3]
> > https://github.com/apache/infrastructure-asfyaml?tab=readme-ov-file#subdir
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by sebb <se...@gmail.com>.
On Sun, 19 Jan 2025 at 17:28, Piotr P. Karwasz
<pi...@mailing.copernik.eu> wrote:
>
> Hi Gilles,
>
> On 19.01.2025 14:30, Gilles Sadowski wrote:
> > Hi.
> >
> > Le sam. 18 janv. 2025 à 19:14, Piotr P. Karwasz
> > <pi...@mailing.copernik.eu> a écrit :
> >> The changes in `logging.apache.org` took close to 1000 work hours (2
> >> developers for 3 months) and were financed by the Sovereign Tech Fund
> >> (now Agency). Commons has also several critical projects, so we could
> >> apply for one of its programs.
> > It's clear what "Log4J" does; I'm pretty sure that there won't be
> > a consensus here about what the scope of "Commons" is. My
> > impression is that it would be difficult to explain what the funding
> > will be used for.
> > E.g. they may not be interested in rarely used components;
> > but does that make them less "critical"?
> > A slick website is "nice" but not really "critical" (as long as it is
> > not tampered with).
> > Of course, I'm certainly not opposed to someone trying to get
> > resources to do <something>.
>
> In general most Commons projects fulfill the criteria for funding, while
> `commons-lang`, `commons-io` and `commons-codec` are on multiple lists
> of critical Open Source projects. It would be mostly up to us to define,
> which changes in Commons are most needed and to translate those changes
> in well defined milestones and funding needs.
>
> [1] https://www.sovereign.tech/programs/fund#criteria
>
> > I was going to ask "why Asciidoc", but most of the answers is there
> > https://asciidoc.org/#about
> >
> > A primary question is then: Do we want to normalize the "Commons"
> > documentation so that all components use "Asciidoc"?
> Personally I don't have a preference between markup languages, as long
> as we use the same markup language for all the documentation. Using
> Javadoc as Gary suggests is fine with me too.
> >> 3. Replacing `maven-site-plugin` with Antora can reuse the work done in
> >> Log4j.
> > I don't know what "Antora" is. But if "Log4J" did the work already and
> > people are happy with the result, it's a strong incentive to indeed follow
> > that path.
>
> Antora[2] is a static website generator that can build a website from
> multiple Git repositories/branches and helps creating cross-references
> between the different websites.
>
> In Log4j we were mostly interested in replacing `maven-site-plugin` and
> speeding up the site generation. Most reports generated by
> `maven-site-plugin` (e.g. PMD, Dependency Convergence, etc.) are not
> really useful for the general public and they slow down site generation
> considerably.
Commons components are low level, and the audience is not the general
public, rather developers.
I think many of the reports *are* needed, for example changes,
japicmp, dependencies.
> The same remarks apply as for the markup languages, we could have chosen
> any other website generator (including `maven-site-plugin`, if we remove
> all the reports), but we chose Antora.
>
> Piotr
>
> [2] https://antora.org/
>
> [3]
> https://github.com/apache/infrastructure-asfyaml?tab=readme-ov-file#subdir
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Gilles,
On 19.01.2025 14:30, Gilles Sadowski wrote:
> Hi.
>
> Le sam. 18 janv. 2025 à 19:14, Piotr P. Karwasz
> <pi...@mailing.copernik.eu> a écrit :
>> The changes in `logging.apache.org` took close to 1000 work hours (2
>> developers for 3 months) and were financed by the Sovereign Tech Fund
>> (now Agency). Commons has also several critical projects, so we could
>> apply for one of its programs.
> It's clear what "Log4J" does; I'm pretty sure that there won't be
> a consensus here about what the scope of "Commons" is. My
> impression is that it would be difficult to explain what the funding
> will be used for.
> E.g. they may not be interested in rarely used components;
> but does that make them less "critical"?
> A slick website is "nice" but not really "critical" (as long as it is
> not tampered with).
> Of course, I'm certainly not opposed to someone trying to get
> resources to do <something>.
In general most Commons projects fulfill the criteria for funding, while
`commons-lang`, `commons-io` and `commons-codec` are on multiple lists
of critical Open Source projects. It would be mostly up to us to define,
which changes in Commons are most needed and to translate those changes
in well defined milestones and funding needs.
[1] https://www.sovereign.tech/programs/fund#criteria
> I was going to ask "why Asciidoc", but most of the answers is there
> https://asciidoc.org/#about
>
> A primary question is then: Do we want to normalize the "Commons"
> documentation so that all components use "Asciidoc"?
Personally I don't have a preference between markup languages, as long
as we use the same markup language for all the documentation. Using
Javadoc as Gary suggests is fine with me too.
>> 3. Replacing `maven-site-plugin` with Antora can reuse the work done in
>> Log4j.
> I don't know what "Antora" is. But if "Log4J" did the work already and
> people are happy with the result, it's a strong incentive to indeed follow
> that path.
Antora[2] is a static website generator that can build a website from
multiple Git repositories/branches and helps creating cross-references
between the different websites.
In Log4j we were mostly interested in replacing `maven-site-plugin` and
speeding up the site generation. Most reports generated by
`maven-site-plugin` (e.g. PMD, Dependency Convergence, etc.) are not
really useful for the general public and they slow down site generation
considerably.
The same remarks apply as for the markup languages, we could have chosen
any other website generator (including `maven-site-plugin`, if we remove
all the reports), but we chose Antora.
Piotr
[2] https://antora.org/
[3]
https://github.com/apache/infrastructure-asfyaml?tab=readme-ov-file#subdir
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by sebb <se...@gmail.com>.
On Sun, 19 Jan 2025 at 13:22, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hi.
>
> Le sam. 18 janv. 2025 à 19:14, Piotr P. Karwasz
> <pi...@mailing.copernik.eu> a écrit :
> >
> > Hi Gilles,
> >
> > On 18.01.2025 18:09, Gilles Sadowski wrote:
> > > Yes, it's likely a lot of work.
> > > Maybe a GSoC project (for which the candidate should somehow
> > > demonstrate the capacity to achieve the result _before_ being
> > > accepted, so that we don't end up doing twice as much work...)?
> >
> > The changes in `logging.apache.org` took close to 1000 work hours (2
> > developers for 3 months) and were financed by the Sovereign Tech Fund
> > (now Agency). Commons has also several critical projects, so we could
> > apply for one of its programs.
>
> It's clear what "Log4J" does; I'm pretty sure that there won't be
> a consensus here about what the scope of "Commons" is. My
> impression is that it would be difficult to explain what the funding
> will be used for.
> E.g. they may not be interested in rarely used components;
> but does that make them less "critical"?
> A slick website is "nice" but not really "critical" (as long as it is
> not tampered with).
> Of course, I'm certainly not opposed to someone trying to get
> resources to do <something>.
>
> >
> > How much time would Commons take, depends on what we want to do:
> >
> > 1. Moving from SVN to Git should be easy.
> >
> > 2. Converting from a variety of formats to Asciidoc can also be done
> > almost automatically.
>
> I was going to ask "why Asciidoc", but most of the answers is there
> https://asciidoc.org/#about
>
> A primary question is then: Do we want to normalize the "Commons"
> documentation so that all components use "Asciidoc"?
>
> >
> > 3. Replacing `maven-site-plugin` with Antora can reuse the work done in
> > Log4j.
>
> I don't know what "Antora" is. But if "Log4J" did the work already and
> people are happy with the result, it's a strong incentive to indeed follow
> that path.
Antora appears to be a way to create a website from lots of Asciidoc sources.
The maven-site-plugin has a similar focus, but supports several
document sources including Asciidoc and Markdown.
The site plugin also has a tight binding with the report plugin, which
is used to generate reports such as JavaDoc, Changes, Japicmp etc.
The site plugin also supports generation of pages for mailing lists,
issue management, dependencies etc.
I don't think these are directly supported by Antora, and I think at
least some of the reports are essential for utility libraries such as
Commons.
Antora looks to be powerful and easy to use, but would probably
require extra work to add the extra reports we need.
> >
> > 4. Proofreading and expanding the documentation is the part that really
> > takes time.
>
> I guess that in "Commons" it would strongly depend on the component.
> Some are in pretty good shape thanks to a lot of time having been put
> into it and/or the scope is very focussed. Others contain a lot of code
> that is (probably) rarely used so that issues could go unseen for a long
> time...
>
> Anyways, your points 1, 2, 3 seem a good plan for a GSoC project.
> Now would be the time to define such a project:
> https://community.apache.org/gsoc/
>
> Regards,
> Gilles
>
> >
> > Note: after the refactoring of the Log4j website we noticed a lot of
> > issue reports against documentation. It is probably a good sign: it mean
> > people actually read the docs.
> >
> > Piotr
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Gilles,
On 19.01.2025 17:42, Gilles Sadowski wrote:
> Le dim. 19 janv. 2025 à 15:06, Gary Gregory <ga...@gmail.com> a écrit :
>> This means writing documentation in Javadoc or Markdown which is now
>> supported by the JDK.
> We could still consider Piotr's proposal (a general move to "Asciidoc"):
> https://asciidoctor.org/news/2013/06/03/asciidoclet-announcement/
>
> At first sight (for me), it definitely looks like a significant improvement
> in that we could eventually "normalize" the documentation style over
> all the components. [Something I had been wondering about for as
> long as I was here...]
We thought about writing our Javadoc in AsciiDoc, but the AsciiDoclet
has no support in IDEs, which complicates the work on documentation.
On the other hand, we wrote a (simple) Javadoc-to-AsciiDoc converter[1],
that covers most of our needs. We use it to generate a Log4j Plugin
Reference[2], which is basically an extract of the Javadoc that
concentrates on the classes and fields that can be used directly in a
Log4j configuration file. Log4j 1 components were Java Beans, so it was
easy to find all the configuration knobs from the Javadoc. Log4j Core 2
uses a builder pattern, which makes the Javadoc less easy to read.
Piotr
[1]
https://github.com/apache/logging-log4j-tools/blob/main/log4j-docgen/src/main/java/org/apache/logging/log4j/docgen/processor/AsciiDocConverter.java
[2] https://logging.apache.org/log4j/2.x/plugin-reference.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le dim. 19 janv. 2025 à 15:06, Gary Gregory <ga...@gmail.com> a écrit :
>
> Hi all,
>
> I don't think we need a site beyond a "simple" Maven site, let me explain...
>
> I like what projects like Juneau did which is to put all the documentation
> in Javadoc.
>
> When you go to https://juneau.apache.org/ and click "Documenation", you go
> to https://juneau.apache.org/site/apidocs-9.0.1/index.html and you get the
> full user manual and Javadoc.
>
> We do this in Commons with BeanUtils:
> https://commons.apache.org/proper/commons-beanutils/apidocs/org/apache/commons/beanutils2/package-summary.html
>
> The advantage is simple (to me): You get the documentation for the version
> you care about, especially if you look at the Javadoc for an older version
> (using javadoc.io or our own archives). See also the PostgreSQL docs for
> the same idea but not in the Java world:
> https://www.postgresql.org/docs/current/index.html
It looks like a fine idea, best applicable to modularized components
(where each "module" is strongly focussed).
For example, much of what is in
https://commons.apache.org/proper/commons-rng/userguide/rng.html#a2._Usage_overview
and in
https://commons.apache.org/proper/commons-rng/userguide/rng.html#a3._Library_layout
could be moved to the respective "package-info.java" files of the
concerned modules:
https://commons.apache.org/proper/commons-rng/commons-rng-docs/apidocs/org/apache/commons/rng/simple/package-summary.html
and
https://commons.apache.org/proper/commons-rng/commons-rng-docs/apidocs/org/apache/commons/rng/core/package-summary.html
In this instance we could still have a top-level userguide but it would
mostly consist in a table-of-contents and links to the javadoc-generated
files.
>
> This means writing documentation in Javadoc or Markdown which is now
> supported by the JDK.
We could still consider Piotr's proposal (a general move to "Asciidoc"):
https://asciidoctor.org/news/2013/06/03/asciidoclet-announcement/
At first sight (for me), it definitely looks like a significant improvement
in that we could eventually "normalize" the documentation style over
all the components. [Something I had been wondering about for as
long as I was here...]
> And yes it's ok to use moder Java to build components
> that target older byte code.
>
> I'd also like our Commons sites to be something like our BeanUtils site
> with a menu somewhere that points to the Javadoc for each version
> (alievating the need to rely on javadoc.io).
>
> This avoids the need for a User Manual link and pages on the site which
> will not match old versions. I also am not a fan of docs that are have
> version tags all over the place with "this was added in version foo", just
> show me what I care about.
This still does not solve the issue of carrying documentation cruft that
does not match what that version is actually doing.
I suppose that we won't mandate that an older version's documentation
should be corrected when something is found in it...
Refactoring the documentation in such a way still seems to be a fairly
simple (but time-consuming) task for a GSoC project. [To be conducted
in some "experimental" branch of course, not "master".]
Regards,
Gilles
>> [...]
>>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by Gary Gregory <ga...@gmail.com>.
Hi all,
I don't think we need a site beyond a "simple" Maven site, let me explain...
I like what projects like Juneau did which is to put all the documentation
in Javadoc.
When you go to https://juneau.apache.org/ and click "Documenation", you go
to https://juneau.apache.org/site/apidocs-9.0.1/index.html and you get the
full user manual and Javadoc.
We do this in Commons with BeanUtils:
https://commons.apache.org/proper/commons-beanutils/apidocs/org/apache/commons/beanutils2/package-summary.html
The advantage is simple (to me): You get the documentation for the version
you care about, especially if you look at the Javadoc for an older version
(using javadoc.io or our own archives). See also the PostgreSQL docs for
the same idea but not in the Java world:
https://www.postgresql.org/docs/current/index.html
This means writing documentation in Javadoc or Markdown which is now
supported by the JDK. And yes it's ok to use moder Java to build components
that target older byte code.
I'd also like our Commons sites to be something like our BeanUtils site
with a menu somewhere that points to the Javadoc for each version
(alievating the need to rely on javadoc.io).
This avoids the need for a User Manual link and pages on the site which
will not match old versions. I also am not a fan of docs that are have
version tags all over the place with "this was added in version foo", just
show me what I care about.
Many pennies,
Gary
On Sun, Jan 19, 2025, 08:22 Gilles Sadowski <gi...@gmail.com> wrote:
> Hi.
>
> Le sam. 18 janv. 2025 à 19:14, Piotr P. Karwasz
> <pi...@mailing.copernik.eu> a écrit :
> >
> > Hi Gilles,
> >
> > On 18.01.2025 18:09, Gilles Sadowski wrote:
> > > Yes, it's likely a lot of work.
> > > Maybe a GSoC project (for which the candidate should somehow
> > > demonstrate the capacity to achieve the result _before_ being
> > > accepted, so that we don't end up doing twice as much work...)?
> >
> > The changes in `logging.apache.org` took close to 1000 work hours (2
> > developers for 3 months) and were financed by the Sovereign Tech Fund
> > (now Agency). Commons has also several critical projects, so we could
> > apply for one of its programs.
>
> It's clear what "Log4J" does; I'm pretty sure that there won't be
> a consensus here about what the scope of "Commons" is. My
> impression is that it would be difficult to explain what the funding
> will be used for.
> E.g. they may not be interested in rarely used components;
> but does that make them less "critical"?
> A slick website is "nice" but not really "critical" (as long as it is
> not tampered with).
> Of course, I'm certainly not opposed to someone trying to get
> resources to do <something>.
>
> >
> > How much time would Commons take, depends on what we want to do:
> >
> > 1. Moving from SVN to Git should be easy.
> >
> > 2. Converting from a variety of formats to Asciidoc can also be done
> > almost automatically.
>
> I was going to ask "why Asciidoc", but most of the answers is there
> https://asciidoc.org/#about
>
> A primary question is then: Do we want to normalize the "Commons"
> documentation so that all components use "Asciidoc"?
>
> >
> > 3. Replacing `maven-site-plugin` with Antora can reuse the work done in
> > Log4j.
>
> I don't know what "Antora" is. But if "Log4J" did the work already and
> people are happy with the result, it's a strong incentive to indeed follow
> that path.
>
> >
> > 4. Proofreading and expanding the documentation is the part that really
> > takes time.
>
> I guess that in "Commons" it would strongly depend on the component.
> Some are in pretty good shape thanks to a lot of time having been put
> into it and/or the scope is very focussed. Others contain a lot of code
> that is (probably) rarely used so that issues could go unseen for a long
> time...
>
> Anyways, your points 1, 2, 3 seem a good plan for a GSoC project.
> Now would be the time to define such a project:
> https://community.apache.org/gsoc/
>
> Regards,
> Gilles
>
> >
> > Note: after the refactoring of the Log4j website we noticed a lot of
> > issue reports against documentation. It is probably a good sign: it mean
> > people actually read the docs.
> >
> > Piotr
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Using Git for websites
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le sam. 18 janv. 2025 à 19:14, Piotr P. Karwasz
<pi...@mailing.copernik.eu> a écrit :
>
> Hi Gilles,
>
> On 18.01.2025 18:09, Gilles Sadowski wrote:
> > Yes, it's likely a lot of work.
> > Maybe a GSoC project (for which the candidate should somehow
> > demonstrate the capacity to achieve the result _before_ being
> > accepted, so that we don't end up doing twice as much work...)?
>
> The changes in `logging.apache.org` took close to 1000 work hours (2
> developers for 3 months) and were financed by the Sovereign Tech Fund
> (now Agency). Commons has also several critical projects, so we could
> apply for one of its programs.
It's clear what "Log4J" does; I'm pretty sure that there won't be
a consensus here about what the scope of "Commons" is. My
impression is that it would be difficult to explain what the funding
will be used for.
E.g. they may not be interested in rarely used components;
but does that make them less "critical"?
A slick website is "nice" but not really "critical" (as long as it is
not tampered with).
Of course, I'm certainly not opposed to someone trying to get
resources to do <something>.
>
> How much time would Commons take, depends on what we want to do:
>
> 1. Moving from SVN to Git should be easy.
>
> 2. Converting from a variety of formats to Asciidoc can also be done
> almost automatically.
I was going to ask "why Asciidoc", but most of the answers is there
https://asciidoc.org/#about
A primary question is then: Do we want to normalize the "Commons"
documentation so that all components use "Asciidoc"?
>
> 3. Replacing `maven-site-plugin` with Antora can reuse the work done in
> Log4j.
I don't know what "Antora" is. But if "Log4J" did the work already and
people are happy with the result, it's a strong incentive to indeed follow
that path.
>
> 4. Proofreading and expanding the documentation is the part that really
> takes time.
I guess that in "Commons" it would strongly depend on the component.
Some are in pretty good shape thanks to a lot of time having been put
into it and/or the scope is very focussed. Others contain a lot of code
that is (probably) rarely used so that issues could go unseen for a long
time...
Anyways, your points 1, 2, 3 seem a good plan for a GSoC project.
Now would be the time to define such a project:
https://community.apache.org/gsoc/
Regards,
Gilles
>
> Note: after the refactoring of the Log4j website we noticed a lot of
> issue reports against documentation. It is probably a good sign: it mean
> people actually read the docs.
>
> Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Gilles,
On 18.01.2025 18:09, Gilles Sadowski wrote:
> Yes, it's likely a lot of work.
> Maybe a GSoC project (for which the candidate should somehow
> demonstrate the capacity to achieve the result _before_ being
> accepted, so that we don't end up doing twice as much work...)?
The changes in `logging.apache.org` took close to 1000 work hours (2
developers for 3 months) and were financed by the Sovereign Tech Fund
(now Agency). Commons has also several critical projects, so we could
apply for one of its programs.
How much time would Commons take, depends on what we want to do:
1. Moving from SVN to Git should be easy.
2. Converting from a variety of formats to Asciidoc can also be done
almost automatically.
3. Replacing `maven-site-plugin` with Antora can reuse the work done in
Log4j.
4. Proofreading and expanding the documentation is the part that really
takes time.
Note: after the refactoring of the Log4j website we noticed a lot of
issue reports against documentation. It is probably a good sign: it mean
people actually read the docs.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Using Git for websites
Posted by Gilles Sadowski <gi...@gmail.com>.
Le sam. 18 janv. 2025 à 17:05, sebb <se...@gmail.com> a écrit :
>
> On Sat, 18 Jan 2025 at 15:03, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > > > TL;DR; Quite some time ago, INFRA offered the possibility to move
> > > > the website(s) under "git" control. Is this related?
> > > > If not, and there is a big change, should we reconsider the move?
> > >
> > > This is not related AFAICT.
> > >
> > > Moving the sites to git would not remove the need to use Subversion to
> > > manage releasing components since there are other bits and pieces that
> > > are in Subversion.
> > >
> > > For example, https://dist.apache.org/repos/dist/release/commons/ is
> > > under Subversion
> >
> > I don't mind using subversion for this; it has nothing to do
> > with moving to "git" for managing the web sites.
>
> Someone would need to work out how to migrate all the websites.
>
> Components don't have their own sites; they are subdirectories of the main site.
>
> These all have to be merged together, which was quite tricky to set up.
>
> Changing this is not going to be easy.
>
> I don't know if it would be possible to migrate individual components,
> or whether it would be necessary to do them all at once to avoid
> breaking things.
>
> Is anyone offering to do this work?
> And fix any issues that occur?
>
> There was a related discussion here:
> https://lists.apache.org/thread/zpzfjkdmms4gs6dk0bxpl5z08oco2wbg
>
> It's not clear if the approach taken by logging would work for Commons.
>
Yes, it's likely a lot of work.
Maybe a GSoC project (for which the candidate should somehow
demonstrate the capacity to achieve the result _before_ being
accepted, so that we don't end up doing twice as much work...)?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Using Git for websites
Posted by sebb <se...@gmail.com>.
On Sat, 18 Jan 2025 at 15:03, Gilles Sadowski <gi...@gmail.com> wrote:
>
> > > TL;DR; Quite some time ago, INFRA offered the possibility to move
> > > the website(s) under "git" control. Is this related?
> > > If not, and there is a big change, should we reconsider the move?
> >
> > This is not related AFAICT.
> >
> > Moving the sites to git would not remove the need to use Subversion to
> > manage releasing components since there are other bits and pieces that
> > are in Subversion.
> >
> > For example, https://dist.apache.org/repos/dist/release/commons/ is
> > under Subversion
>
> I don't mind using subversion for this; it has nothing to do
> with moving to "git" for managing the web sites.
Someone would need to work out how to migrate all the websites.
Components don't have their own sites; they are subdirectories of the main site.
These all have to be merged together, which was quite tricky to set up.
Changing this is not going to be easy.
I don't know if it would be possible to migrate individual components,
or whether it would be necessary to do them all at once to avoid
breaking things.
Is anyone offering to do this work?
And fix any issues that occur?
There was a related discussion here:
https://lists.apache.org/thread/zpzfjkdmms4gs6dk0bxpl5z08oco2wbg
It's not clear if the approach taken by logging would work for Commons.
Sebb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RESULT][LAZY][VOTE] Release Apache Commons Parent 79 based on RC2
Posted by Gilles Sadowski <gi...@gmail.com>.
Le sam. 18 janv. 2025 à 15:37, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Sat, Jan 18, 2025 at 9:20 AM Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Hi.
> >
> > Le sam. 18 janv. 2025 à 14:50, Gary Gregory <ga...@gmail.com> a écrit :
> > >
> > > On Sat, Jan 18, 2025 at 8:47 AM Gary Gregory <ga...@gmail.com> wrote:
> > > >
> > > > On Sat, Jan 18, 2025 at 7:57 AM sebb <se...@gmail.com> wrote:
> > > > >
> > > > > Has it been released? I cannot find an ANNOUNCE email.
> > > >
> > > > It looks like I forgot, sending ASAP...
> > > >
> > > > >
> > > > > It looks as though updating to this version may require significant
> > > > > changes to files used to build the site; it would be helpful to
> > > > > document these in the announce email and RN.
> > > >
> > > > I'll point it out.
> > > >
> > > > All components have already been updated except Jelly IIRC.
> > >
> > > Oh, I don't think I touched the mathy components (Math, Numbers, ...)
> >
> > TL;DR; Quite some time ago, INFRA offered the possibility to move
> > the website(s) under "git" control. Is this related?
> > If not, and there is a big change, should we reconsider the move?
>
> This is not related AFAICT.
>
> Moving the sites to git would not remove the need to use Subversion to
> manage releasing components since there are other bits and pieces that
> are in Subversion.
>
> For example, https://dist.apache.org/repos/dist/release/commons/ is
> under Subversion
I don't mind using subversion for this; it has nothing to do
with moving to "git" for managing the web sites.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RESULT][LAZY][VOTE] Release Apache Commons Parent 79 based on RC2
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Jan 18, 2025 at 9:20 AM Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hi.
>
> Le sam. 18 janv. 2025 à 14:50, Gary Gregory <ga...@gmail.com> a écrit :
> >
> > On Sat, Jan 18, 2025 at 8:47 AM Gary Gregory <ga...@gmail.com> wrote:
> > >
> > > On Sat, Jan 18, 2025 at 7:57 AM sebb <se...@gmail.com> wrote:
> > > >
> > > > Has it been released? I cannot find an ANNOUNCE email.
> > >
> > > It looks like I forgot, sending ASAP...
> > >
> > > >
> > > > It looks as though updating to this version may require significant
> > > > changes to files used to build the site; it would be helpful to
> > > > document these in the announce email and RN.
> > >
> > > I'll point it out.
> > >
> > > All components have already been updated except Jelly IIRC.
> >
> > Oh, I don't think I touched the mathy components (Math, Numbers, ...)
>
> TL;DR; Quite some time ago, INFRA offered the possibility to move
> the website(s) under "git" control. Is this related?
> If not, and there is a big change, should we reconsider the move?
This is not related AFAICT.
Moving the sites to git would not remove the need to use Subversion to
manage releasing components since there are other bits and pieces that
are in Subversion.
For example, https://dist.apache.org/repos/dist/release/commons/ is
under Subversion
Gary
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RESULT][LAZY][VOTE] Release Apache Commons Parent 79 based on RC2
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le sam. 18 janv. 2025 à 14:50, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Sat, Jan 18, 2025 at 8:47 AM Gary Gregory <ga...@gmail.com> wrote:
> >
> > On Sat, Jan 18, 2025 at 7:57 AM sebb <se...@gmail.com> wrote:
> > >
> > > Has it been released? I cannot find an ANNOUNCE email.
> >
> > It looks like I forgot, sending ASAP...
> >
> > >
> > > It looks as though updating to this version may require significant
> > > changes to files used to build the site; it would be helpful to
> > > document these in the announce email and RN.
> >
> > I'll point it out.
> >
> > All components have already been updated except Jelly IIRC.
>
> Oh, I don't think I touched the mathy components (Math, Numbers, ...)
TL;DR; Quite some time ago, INFRA offered the possibility to move
the website(s) under "git" control. Is this related?
If not, and there is a big change, should we reconsider the move?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RESULT][LAZY][VOTE] Release Apache Commons Parent 79 based on RC2
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Jan 18, 2025 at 8:47 AM Gary Gregory <ga...@gmail.com> wrote:
>
> On Sat, Jan 18, 2025 at 7:57 AM sebb <se...@gmail.com> wrote:
> >
> > Has it been released? I cannot find an ANNOUNCE email.
>
> It looks like I forgot, sending ASAP...
>
> >
> > It looks as though updating to this version may require significant
> > changes to files used to build the site; it would be helpful to
> > document these in the announce email and RN.
>
> I'll point it out.
>
> All components have already been updated except Jelly IIRC.
Oh, I don't think I touched the mathy components (Math, Numbers, ...)
Gary
>
> There are still bullet-proofing to do like adding XSD declarations
> where missing.
>
> Gary
>
> >
> > On Tue, 7 Jan 2025 at 20:01, Gary Gregory <ga...@gmail.com> wrote:
> > >
> > > This lazy vote passes with the following binding vote:
> > >
> > > - Gary Gregory (ggregory)
> > >
> > > TY,
> > > Gary
> > >
> > > On Mon, Jan 6, 2025 at 7:07 AM Gary Gregory <ga...@gmail.com> wrote:
> > > >
> > > > My +1
> > > >
> > > > Gary
> > > >
> > > >
> > > > On Fri, Jan 3, 2025 at 11:07 AM Gary Gregory <ga...@gmail.com> wrote:
> > > >>
> > > >> We have fixed a few bugs and added enhancements since Apache Commons Parent 78 was released, so I would like to release Apache Commons Parent 79.
> > > >>
> > > >> The most important change is the migration to Doxia 2 which allows using current Maven plugins.
> > > >>
> > > >> Apache Commons Parent 79 RC2 is available for review here:
> > > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2 (svn revision 73958)
> > > >>
> > > >> The Git tag commons-parent-79-RC2 commit for this RC is b8d7c5be2505e3f669ecf202261f36511f39009b which you can browse here:
> > > >> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=b8d7c5be2505e3f669ecf202261f36511f39009b
> > > >> You may checkout this tag using:
> > > >> git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-79-RC2 commons-parent-79-RC2
> > > >>
> > > >> Maven artifacts are here:
> > > >> https://repository.apache.org/content/repositories/orgapachecommons-1798/org/apache/commons/commons-parent/79/
> > > >>
> > > >> These are the artifacts and their hashes:
> > > >>
> > > >> #Release SHA-512s
> > > >> #Fri Jan 03 15:58:47 UTC 2025
> > > >> commons-parent-79-bom.json=4e7fb23db62d038cf535ed679b8721ef07aa9738e9c0d14ff5412698e9d829f35232aba31b554997148a8aa87b67dfee2d7d822bb4220c8399f68afaadf1538d
> > > >> commons-parent-79-bom.xml=0807a3b8956729680c7477ab92bb04db6cb9615088dc941e2c9e91e8b1ae402c6f7be479c24e6a8775935e6e5bf2f7b59ec0e68ca6c79be513fe4a1ee3bcbf66
> > > >> commons-parent-79-site.xml=1c4e77414868a5a026a49302efbb2b629d86f210ca2430d1996e7e540706f1ed1906d36a4118b93580d7eaec7440c70ef22dfae280e568df77ae8e165b2cc159
> > > >> commons-parent-79-src.tar.gz=760c8ef251cb5812a7d8fe4d5acb33e8f7478010e01a81912915b84b83368da2cc6bb80e40abe9729369dd517f3f0ee76d6dc0dcb38103397d9dbf7ebc1fa187
> > > >> commons-parent-79-src.zip=44ac8cd89cd4ff270e4ddf239a7e9134bcc5c186fa0249195ad64878648dd8204ea0cf4d141245425091186d07b2df282c012ebfcd7b2c2e8f2c190fc3ef6a11
> > > >> org.apache.commons_commons-parent-79.spdx.json=f2c070ea4716ab7f3fd46f44c6cff462761d64526d5a69d15efe75629a0cced9c83305167af52d6dfab8c74ef3df4d77edd0f9ccd7d30c5f5b4c71093aedf940
> > > >>
> > > >> I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> > > >>
> > > >> openjdk version "17.0.13" 2024-10-15
> > > >> OpenJDK Runtime Environment Homebrew (build 17.0.13+0)
> > > >> OpenJDK 64-Bit Server VM Homebrew (build 17.0.13+0, mixed mode, sharing)
> > > >>
> > > >> Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> > > >> Maven home: /opt/homebrew/Cellar/maven/3.9.9/libexec
> > > >> Java version: 17.0.13, vendor: Homebrew, runtime: /opt/homebrew/Cellar/openjdk@17/17.0.13/libexec/openjdk.jdk/Contents/Home
> > > >> Default locale: en_US, platform encoding: UTF-8
> > > >> OS name: "mac os x", version: "15.2", arch: "aarch64", family: "mac"
> > > >>
> > > >> Darwin ****.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec 6 19:03:40 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6041 arm64
> > > >> Docker version 27.3.1, build ce12230
> > > >>
> > > >> Details of changes since 79 are in the release notes:
> > > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/RELEASE-NOTES.txt
> > > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/changes.html
> > > >>
> > > >> Site:
> > > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/index.html
> > > >> (note some *relative* links are broken and the 79 directories are not yet created - these will be OK once the site is deployed.)
> > > >>
> > > >> RAT Report:
> > > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/rat-report.html
> > > >>
> > > >> KEYS:
> > > >> https://downloads.apache.org/commons/KEYS
> > > >>
> > > >> Please review the release candidate and vote.
> > > >> This vote will close no sooner than 72 hours from now.
> > > >>
> > > >> [ ] +1 Release these artifacts
> > > >> [ ] +0 OK, but...
> > > >> [ ] -0 OK, but really should fix...
> > > >> [ ] -1 I oppose this release because...
> > > >>
> > > >> Thank you,
> > > >>
> > > >> Gary Gregory,
> > > >> Release Manager (using key 86fdc7e2a11262cb)
> > > >>
> > > >> The following is intended as a helper and refresher for reviewers.
> > > >>
> > > >> Validating a release candidate
> > > >> ==============================
> > > >>
> > > >> These guidelines are NOT complete.
> > > >>
> > > >> Requirements: Git, Java, Maven.
> > > >>
> > > >> You can validate a release from a release candidate (RC) tag as follows.
> > > >>
> > > >> 1a) Clone and checkout the RC tag
> > > >>
> > > >> git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-79-RC2 commons-parent-79-RC2
> > > >> cd commons-parent-79-RC2
> > > >>
> > > >> 1b) Download and unpack the source archive from:
> > > >>
> > > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/source
> > > >>
> > > >> 2) Check Apache licenses
> > > >>
> > > >> This step is not required if the site includes a RAT report page which you then must check.
> > > >>
> > > >> mvn apache-rat:check
> > > >>
> > > >> 3) Check binary compatibility
> > > >>
> > > >> Older components still use Apache Clirr:
> > > >>
> > > >> This step is not required if the site includes a Clirr report page which you then must check.
> > > >>
> > > >> mvn clirr:check
> > > >>
> > > >> Newer components use JApiCmp with the japicmp Maven Profile:
> > > >>
> > > >> This step is not required if the site includes a JApiCmp report page which you then must check.
> > > >>
> > > >> mvn install -DskipTests -P japicmp japicmp:cmp
> > > >>
> > > >> 4) Build the package
> > > >>
> > > >> mvn -V clean package
> > > >>
> > > >> You can record the Maven and Java version produced by -V in your VOTE reply.
> > > >> To gather OS information from a command line:
> > > >> Windows: ver
> > > >> Linux: uname -a
> > > >>
> > > >> 5) Build the site for a single module project
> > > >>
> > > >> Note: Some plugins require the components to be installed instead of packaged.
> > > >>
> > > >> mvn site
> > > >> Check the site reports in:
> > > >> - Windows: target\site\index.html
> > > >> - Linux: target/site/index.html
> > > >>
> > > >> -the end-
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RESULT][LAZY][VOTE] Release Apache Commons Parent 79 based on RC2
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Jan 18, 2025 at 7:57 AM sebb <se...@gmail.com> wrote:
>
> Has it been released? I cannot find an ANNOUNCE email.
It looks like I forgot, sending ASAP...
>
> It looks as though updating to this version may require significant
> changes to files used to build the site; it would be helpful to
> document these in the announce email and RN.
I'll point it out.
All components have already been updated except Jelly IIRC.
There are still bullet-proofing to do like adding XSD declarations
where missing.
Gary
>
> On Tue, 7 Jan 2025 at 20:01, Gary Gregory <ga...@gmail.com> wrote:
> >
> > This lazy vote passes with the following binding vote:
> >
> > - Gary Gregory (ggregory)
> >
> > TY,
> > Gary
> >
> > On Mon, Jan 6, 2025 at 7:07 AM Gary Gregory <ga...@gmail.com> wrote:
> > >
> > > My +1
> > >
> > > Gary
> > >
> > >
> > > On Fri, Jan 3, 2025 at 11:07 AM Gary Gregory <ga...@gmail.com> wrote:
> > >>
> > >> We have fixed a few bugs and added enhancements since Apache Commons Parent 78 was released, so I would like to release Apache Commons Parent 79.
> > >>
> > >> The most important change is the migration to Doxia 2 which allows using current Maven plugins.
> > >>
> > >> Apache Commons Parent 79 RC2 is available for review here:
> > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2 (svn revision 73958)
> > >>
> > >> The Git tag commons-parent-79-RC2 commit for this RC is b8d7c5be2505e3f669ecf202261f36511f39009b which you can browse here:
> > >> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=b8d7c5be2505e3f669ecf202261f36511f39009b
> > >> You may checkout this tag using:
> > >> git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-79-RC2 commons-parent-79-RC2
> > >>
> > >> Maven artifacts are here:
> > >> https://repository.apache.org/content/repositories/orgapachecommons-1798/org/apache/commons/commons-parent/79/
> > >>
> > >> These are the artifacts and their hashes:
> > >>
> > >> #Release SHA-512s
> > >> #Fri Jan 03 15:58:47 UTC 2025
> > >> commons-parent-79-bom.json=4e7fb23db62d038cf535ed679b8721ef07aa9738e9c0d14ff5412698e9d829f35232aba31b554997148a8aa87b67dfee2d7d822bb4220c8399f68afaadf1538d
> > >> commons-parent-79-bom.xml=0807a3b8956729680c7477ab92bb04db6cb9615088dc941e2c9e91e8b1ae402c6f7be479c24e6a8775935e6e5bf2f7b59ec0e68ca6c79be513fe4a1ee3bcbf66
> > >> commons-parent-79-site.xml=1c4e77414868a5a026a49302efbb2b629d86f210ca2430d1996e7e540706f1ed1906d36a4118b93580d7eaec7440c70ef22dfae280e568df77ae8e165b2cc159
> > >> commons-parent-79-src.tar.gz=760c8ef251cb5812a7d8fe4d5acb33e8f7478010e01a81912915b84b83368da2cc6bb80e40abe9729369dd517f3f0ee76d6dc0dcb38103397d9dbf7ebc1fa187
> > >> commons-parent-79-src.zip=44ac8cd89cd4ff270e4ddf239a7e9134bcc5c186fa0249195ad64878648dd8204ea0cf4d141245425091186d07b2df282c012ebfcd7b2c2e8f2c190fc3ef6a11
> > >> org.apache.commons_commons-parent-79.spdx.json=f2c070ea4716ab7f3fd46f44c6cff462761d64526d5a69d15efe75629a0cced9c83305167af52d6dfab8c74ef3df4d77edd0f9ccd7d30c5f5b4c71093aedf940
> > >>
> > >> I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> > >>
> > >> openjdk version "17.0.13" 2024-10-15
> > >> OpenJDK Runtime Environment Homebrew (build 17.0.13+0)
> > >> OpenJDK 64-Bit Server VM Homebrew (build 17.0.13+0, mixed mode, sharing)
> > >>
> > >> Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> > >> Maven home: /opt/homebrew/Cellar/maven/3.9.9/libexec
> > >> Java version: 17.0.13, vendor: Homebrew, runtime: /opt/homebrew/Cellar/openjdk@17/17.0.13/libexec/openjdk.jdk/Contents/Home
> > >> Default locale: en_US, platform encoding: UTF-8
> > >> OS name: "mac os x", version: "15.2", arch: "aarch64", family: "mac"
> > >>
> > >> Darwin ****.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec 6 19:03:40 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6041 arm64
> > >> Docker version 27.3.1, build ce12230
> > >>
> > >> Details of changes since 79 are in the release notes:
> > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/RELEASE-NOTES.txt
> > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/changes.html
> > >>
> > >> Site:
> > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/index.html
> > >> (note some *relative* links are broken and the 79 directories are not yet created - these will be OK once the site is deployed.)
> > >>
> > >> RAT Report:
> > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/rat-report.html
> > >>
> > >> KEYS:
> > >> https://downloads.apache.org/commons/KEYS
> > >>
> > >> Please review the release candidate and vote.
> > >> This vote will close no sooner than 72 hours from now.
> > >>
> > >> [ ] +1 Release these artifacts
> > >> [ ] +0 OK, but...
> > >> [ ] -0 OK, but really should fix...
> > >> [ ] -1 I oppose this release because...
> > >>
> > >> Thank you,
> > >>
> > >> Gary Gregory,
> > >> Release Manager (using key 86fdc7e2a11262cb)
> > >>
> > >> The following is intended as a helper and refresher for reviewers.
> > >>
> > >> Validating a release candidate
> > >> ==============================
> > >>
> > >> These guidelines are NOT complete.
> > >>
> > >> Requirements: Git, Java, Maven.
> > >>
> > >> You can validate a release from a release candidate (RC) tag as follows.
> > >>
> > >> 1a) Clone and checkout the RC tag
> > >>
> > >> git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-79-RC2 commons-parent-79-RC2
> > >> cd commons-parent-79-RC2
> > >>
> > >> 1b) Download and unpack the source archive from:
> > >>
> > >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/source
> > >>
> > >> 2) Check Apache licenses
> > >>
> > >> This step is not required if the site includes a RAT report page which you then must check.
> > >>
> > >> mvn apache-rat:check
> > >>
> > >> 3) Check binary compatibility
> > >>
> > >> Older components still use Apache Clirr:
> > >>
> > >> This step is not required if the site includes a Clirr report page which you then must check.
> > >>
> > >> mvn clirr:check
> > >>
> > >> Newer components use JApiCmp with the japicmp Maven Profile:
> > >>
> > >> This step is not required if the site includes a JApiCmp report page which you then must check.
> > >>
> > >> mvn install -DskipTests -P japicmp japicmp:cmp
> > >>
> > >> 4) Build the package
> > >>
> > >> mvn -V clean package
> > >>
> > >> You can record the Maven and Java version produced by -V in your VOTE reply.
> > >> To gather OS information from a command line:
> > >> Windows: ver
> > >> Linux: uname -a
> > >>
> > >> 5) Build the site for a single module project
> > >>
> > >> Note: Some plugins require the components to be installed instead of packaged.
> > >>
> > >> mvn site
> > >> Check the site reports in:
> > >> - Windows: target\site\index.html
> > >> - Linux: target/site/index.html
> > >>
> > >> -the end-
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RESULT][LAZY][VOTE] Release Apache Commons Parent 79 based on RC2
Posted by sebb <se...@gmail.com>.
Has it been released? I cannot find an ANNOUNCE email.
It looks as though updating to this version may require significant
changes to files used to build the site; it would be helpful to
document these in the announce email and RN.
On Tue, 7 Jan 2025 at 20:01, Gary Gregory <ga...@gmail.com> wrote:
>
> This lazy vote passes with the following binding vote:
>
> - Gary Gregory (ggregory)
>
> TY,
> Gary
>
> On Mon, Jan 6, 2025 at 7:07 AM Gary Gregory <ga...@gmail.com> wrote:
> >
> > My +1
> >
> > Gary
> >
> >
> > On Fri, Jan 3, 2025 at 11:07 AM Gary Gregory <ga...@gmail.com> wrote:
> >>
> >> We have fixed a few bugs and added enhancements since Apache Commons Parent 78 was released, so I would like to release Apache Commons Parent 79.
> >>
> >> The most important change is the migration to Doxia 2 which allows using current Maven plugins.
> >>
> >> Apache Commons Parent 79 RC2 is available for review here:
> >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2 (svn revision 73958)
> >>
> >> The Git tag commons-parent-79-RC2 commit for this RC is b8d7c5be2505e3f669ecf202261f36511f39009b which you can browse here:
> >> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=b8d7c5be2505e3f669ecf202261f36511f39009b
> >> You may checkout this tag using:
> >> git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-79-RC2 commons-parent-79-RC2
> >>
> >> Maven artifacts are here:
> >> https://repository.apache.org/content/repositories/orgapachecommons-1798/org/apache/commons/commons-parent/79/
> >>
> >> These are the artifacts and their hashes:
> >>
> >> #Release SHA-512s
> >> #Fri Jan 03 15:58:47 UTC 2025
> >> commons-parent-79-bom.json=4e7fb23db62d038cf535ed679b8721ef07aa9738e9c0d14ff5412698e9d829f35232aba31b554997148a8aa87b67dfee2d7d822bb4220c8399f68afaadf1538d
> >> commons-parent-79-bom.xml=0807a3b8956729680c7477ab92bb04db6cb9615088dc941e2c9e91e8b1ae402c6f7be479c24e6a8775935e6e5bf2f7b59ec0e68ca6c79be513fe4a1ee3bcbf66
> >> commons-parent-79-site.xml=1c4e77414868a5a026a49302efbb2b629d86f210ca2430d1996e7e540706f1ed1906d36a4118b93580d7eaec7440c70ef22dfae280e568df77ae8e165b2cc159
> >> commons-parent-79-src.tar.gz=760c8ef251cb5812a7d8fe4d5acb33e8f7478010e01a81912915b84b83368da2cc6bb80e40abe9729369dd517f3f0ee76d6dc0dcb38103397d9dbf7ebc1fa187
> >> commons-parent-79-src.zip=44ac8cd89cd4ff270e4ddf239a7e9134bcc5c186fa0249195ad64878648dd8204ea0cf4d141245425091186d07b2df282c012ebfcd7b2c2e8f2c190fc3ef6a11
> >> org.apache.commons_commons-parent-79.spdx.json=f2c070ea4716ab7f3fd46f44c6cff462761d64526d5a69d15efe75629a0cced9c83305167af52d6dfab8c74ef3df4d77edd0f9ccd7d30c5f5b4c71093aedf940
> >>
> >> I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> >>
> >> openjdk version "17.0.13" 2024-10-15
> >> OpenJDK Runtime Environment Homebrew (build 17.0.13+0)
> >> OpenJDK 64-Bit Server VM Homebrew (build 17.0.13+0, mixed mode, sharing)
> >>
> >> Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> >> Maven home: /opt/homebrew/Cellar/maven/3.9.9/libexec
> >> Java version: 17.0.13, vendor: Homebrew, runtime: /opt/homebrew/Cellar/openjdk@17/17.0.13/libexec/openjdk.jdk/Contents/Home
> >> Default locale: en_US, platform encoding: UTF-8
> >> OS name: "mac os x", version: "15.2", arch: "aarch64", family: "mac"
> >>
> >> Darwin ****.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec 6 19:03:40 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6041 arm64
> >> Docker version 27.3.1, build ce12230
> >>
> >> Details of changes since 79 are in the release notes:
> >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/RELEASE-NOTES.txt
> >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/changes.html
> >>
> >> Site:
> >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/index.html
> >> (note some *relative* links are broken and the 79 directories are not yet created - these will be OK once the site is deployed.)
> >>
> >> RAT Report:
> >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/rat-report.html
> >>
> >> KEYS:
> >> https://downloads.apache.org/commons/KEYS
> >>
> >> Please review the release candidate and vote.
> >> This vote will close no sooner than 72 hours from now.
> >>
> >> [ ] +1 Release these artifacts
> >> [ ] +0 OK, but...
> >> [ ] -0 OK, but really should fix...
> >> [ ] -1 I oppose this release because...
> >>
> >> Thank you,
> >>
> >> Gary Gregory,
> >> Release Manager (using key 86fdc7e2a11262cb)
> >>
> >> The following is intended as a helper and refresher for reviewers.
> >>
> >> Validating a release candidate
> >> ==============================
> >>
> >> These guidelines are NOT complete.
> >>
> >> Requirements: Git, Java, Maven.
> >>
> >> You can validate a release from a release candidate (RC) tag as follows.
> >>
> >> 1a) Clone and checkout the RC tag
> >>
> >> git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-79-RC2 commons-parent-79-RC2
> >> cd commons-parent-79-RC2
> >>
> >> 1b) Download and unpack the source archive from:
> >>
> >> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/source
> >>
> >> 2) Check Apache licenses
> >>
> >> This step is not required if the site includes a RAT report page which you then must check.
> >>
> >> mvn apache-rat:check
> >>
> >> 3) Check binary compatibility
> >>
> >> Older components still use Apache Clirr:
> >>
> >> This step is not required if the site includes a Clirr report page which you then must check.
> >>
> >> mvn clirr:check
> >>
> >> Newer components use JApiCmp with the japicmp Maven Profile:
> >>
> >> This step is not required if the site includes a JApiCmp report page which you then must check.
> >>
> >> mvn install -DskipTests -P japicmp japicmp:cmp
> >>
> >> 4) Build the package
> >>
> >> mvn -V clean package
> >>
> >> You can record the Maven and Java version produced by -V in your VOTE reply.
> >> To gather OS information from a command line:
> >> Windows: ver
> >> Linux: uname -a
> >>
> >> 5) Build the site for a single module project
> >>
> >> Note: Some plugins require the components to be installed instead of packaged.
> >>
> >> mvn site
> >> Check the site reports in:
> >> - Windows: target\site\index.html
> >> - Linux: target/site/index.html
> >>
> >> -the end-
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[RESULT][LAZY][VOTE] Release Apache Commons Parent 79 based on RC2
Posted by Gary Gregory <ga...@gmail.com>.
This lazy vote passes with the following binding vote:
- Gary Gregory (ggregory)
TY,
Gary
On Mon, Jan 6, 2025 at 7:07 AM Gary Gregory <ga...@gmail.com> wrote:
>
> My +1
>
> Gary
>
>
> On Fri, Jan 3, 2025 at 11:07 AM Gary Gregory <ga...@gmail.com> wrote:
>>
>> We have fixed a few bugs and added enhancements since Apache Commons Parent 78 was released, so I would like to release Apache Commons Parent 79.
>>
>> The most important change is the migration to Doxia 2 which allows using current Maven plugins.
>>
>> Apache Commons Parent 79 RC2 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2 (svn revision 73958)
>>
>> The Git tag commons-parent-79-RC2 commit for this RC is b8d7c5be2505e3f669ecf202261f36511f39009b which you can browse here:
>> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=b8d7c5be2505e3f669ecf202261f36511f39009b
>> You may checkout this tag using:
>> git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-79-RC2 commons-parent-79-RC2
>>
>> Maven artifacts are here:
>> https://repository.apache.org/content/repositories/orgapachecommons-1798/org/apache/commons/commons-parent/79/
>>
>> These are the artifacts and their hashes:
>>
>> #Release SHA-512s
>> #Fri Jan 03 15:58:47 UTC 2025
>> commons-parent-79-bom.json=4e7fb23db62d038cf535ed679b8721ef07aa9738e9c0d14ff5412698e9d829f35232aba31b554997148a8aa87b67dfee2d7d822bb4220c8399f68afaadf1538d
>> commons-parent-79-bom.xml=0807a3b8956729680c7477ab92bb04db6cb9615088dc941e2c9e91e8b1ae402c6f7be479c24e6a8775935e6e5bf2f7b59ec0e68ca6c79be513fe4a1ee3bcbf66
>> commons-parent-79-site.xml=1c4e77414868a5a026a49302efbb2b629d86f210ca2430d1996e7e540706f1ed1906d36a4118b93580d7eaec7440c70ef22dfae280e568df77ae8e165b2cc159
>> commons-parent-79-src.tar.gz=760c8ef251cb5812a7d8fe4d5acb33e8f7478010e01a81912915b84b83368da2cc6bb80e40abe9729369dd517f3f0ee76d6dc0dcb38103397d9dbf7ebc1fa187
>> commons-parent-79-src.zip=44ac8cd89cd4ff270e4ddf239a7e9134bcc5c186fa0249195ad64878648dd8204ea0cf4d141245425091186d07b2df282c012ebfcd7b2c2e8f2c190fc3ef6a11
>> org.apache.commons_commons-parent-79.spdx.json=f2c070ea4716ab7f3fd46f44c6cff462761d64526d5a69d15efe75629a0cced9c83305167af52d6dfab8c74ef3df4d77edd0f9ccd7d30c5f5b4c71093aedf940
>>
>> I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
>>
>> openjdk version "17.0.13" 2024-10-15
>> OpenJDK Runtime Environment Homebrew (build 17.0.13+0)
>> OpenJDK 64-Bit Server VM Homebrew (build 17.0.13+0, mixed mode, sharing)
>>
>> Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
>> Maven home: /opt/homebrew/Cellar/maven/3.9.9/libexec
>> Java version: 17.0.13, vendor: Homebrew, runtime: /opt/homebrew/Cellar/openjdk@17/17.0.13/libexec/openjdk.jdk/Contents/Home
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "15.2", arch: "aarch64", family: "mac"
>>
>> Darwin ****.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec 6 19:03:40 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6041 arm64
>> Docker version 27.3.1, build ce12230
>>
>> Details of changes since 79 are in the release notes:
>> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/RELEASE-NOTES.txt
>> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/changes.html
>>
>> Site:
>> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/index.html
>> (note some *relative* links are broken and the 79 directories are not yet created - these will be OK once the site is deployed.)
>>
>> RAT Report:
>> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/rat-report.html
>>
>> KEYS:
>> https://downloads.apache.org/commons/KEYS
>>
>> Please review the release candidate and vote.
>> This vote will close no sooner than 72 hours from now.
>>
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>>
>> Thank you,
>>
>> Gary Gregory,
>> Release Manager (using key 86fdc7e2a11262cb)
>>
>> The following is intended as a helper and refresher for reviewers.
>>
>> Validating a release candidate
>> ==============================
>>
>> These guidelines are NOT complete.
>>
>> Requirements: Git, Java, Maven.
>>
>> You can validate a release from a release candidate (RC) tag as follows.
>>
>> 1a) Clone and checkout the RC tag
>>
>> git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-79-RC2 commons-parent-79-RC2
>> cd commons-parent-79-RC2
>>
>> 1b) Download and unpack the source archive from:
>>
>> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/source
>>
>> 2) Check Apache licenses
>>
>> This step is not required if the site includes a RAT report page which you then must check.
>>
>> mvn apache-rat:check
>>
>> 3) Check binary compatibility
>>
>> Older components still use Apache Clirr:
>>
>> This step is not required if the site includes a Clirr report page which you then must check.
>>
>> mvn clirr:check
>>
>> Newer components use JApiCmp with the japicmp Maven Profile:
>>
>> This step is not required if the site includes a JApiCmp report page which you then must check.
>>
>> mvn install -DskipTests -P japicmp japicmp:cmp
>>
>> 4) Build the package
>>
>> mvn -V clean package
>>
>> You can record the Maven and Java version produced by -V in your VOTE reply.
>> To gather OS information from a command line:
>> Windows: ver
>> Linux: uname -a
>>
>> 5) Build the site for a single module project
>>
>> Note: Some plugins require the components to be installed instead of packaged.
>>
>> mvn site
>> Check the site reports in:
>> - Windows: target\site\index.html
>> - Linux: target/site/index.html
>>
>> -the end-
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LAZY][VOTE] Release Apache Commons Parent 79 based on RC2
Posted by Gary Gregory <ga...@gmail.com>.
My +1
Gary
On Fri, Jan 3, 2025 at 11:07 AM Gary Gregory <ga...@gmail.com> wrote:
> We have fixed a few bugs and added enhancements since Apache Commons
> Parent 78 was released, so I would like to release Apache Commons Parent 79.
>
> The most important change is the migration to Doxia 2 which allows
> using current Maven plugins.
>
> Apache Commons Parent 79 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2 (svn
> revision 73958)
>
> The Git tag commons-parent-79-RC2 commit for this RC is
> b8d7c5be2505e3f669ecf202261f36511f39009b which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=b8d7c5be2505e3f669ecf202261f36511f39009b
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-79-RC2 commons-parent-79-RC2
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1798/org/apache/commons/commons-parent/79/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri Jan 03 15:58:47 UTC 2025
>
> commons-parent-79-bom.json=4e7fb23db62d038cf535ed679b8721ef07aa9738e9c0d14ff5412698e9d829f35232aba31b554997148a8aa87b67dfee2d7d822bb4220c8399f68afaadf1538d
>
> commons-parent-79-bom.xml=0807a3b8956729680c7477ab92bb04db6cb9615088dc941e2c9e91e8b1ae402c6f7be479c24e6a8775935e6e5bf2f7b59ec0e68ca6c79be513fe4a1ee3bcbf66
>
> commons-parent-79-site.xml=1c4e77414868a5a026a49302efbb2b629d86f210ca2430d1996e7e540706f1ed1906d36a4118b93580d7eaec7440c70ef22dfae280e568df77ae8e165b2cc159
>
> commons-parent-79-src.tar.gz=760c8ef251cb5812a7d8fe4d5acb33e8f7478010e01a81912915b84b83368da2cc6bb80e40abe9729369dd517f3f0ee76d6dc0dcb38103397d9dbf7ebc1fa187
>
> commons-parent-79-src.zip=44ac8cd89cd4ff270e4ddf239a7e9134bcc5c186fa0249195ad64878648dd8204ea0cf4d141245425091186d07b2df282c012ebfcd7b2c2e8f2c190fc3ef6a11
>
> org.apache.commons_commons-parent-79.spdx.json=f2c070ea4716ab7f3fd46f44c6cff462761d64526d5a69d15efe75629a0cced9c83305167af52d6dfab8c74ef3df4d77edd0f9ccd7d30c5f5b4c71093aedf940
>
> I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P
> jacoco -P japicmp clean package site deploy' using:
>
> openjdk version "17.0.13" 2024-10-15
> OpenJDK Runtime Environment Homebrew (build 17.0.13+0)
> OpenJDK 64-Bit Server VM Homebrew (build 17.0.13+0, mixed mode, sharing)
>
> Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> Maven home: /opt/homebrew/Cellar/maven/3.9.9/libexec
> Java version: 17.0.13, vendor: Homebrew, runtime:
> /opt/homebrew/Cellar/openjdk@17/17.0.13/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "15.2", arch: "aarch64", family: "mac"
>
> Darwin ****.local 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec 6 19:03:40
> PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6041 arm64
> Docker version 27.3.1, build ce12230
>
> Details of changes since 79 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/changes.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/index.html
> (note some *relative* links are broken and the 79 directories are not
> yet created - these will be OK once the site is deployed.)
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/site/rat-report.html
>
> KEYS:
> https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
>
> The following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==============================
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1a) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch
> commons-parent-79-RC2 commons-parent-79-RC2
> cd commons-parent-79-RC2
>
> 1b) Download and unpack the source archive from:
>
> https://dist.apache.org/repos/dist/dev/commons/parent/79-RC2/source
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which you
> then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site includes a Clirr report page which
> you then must check.
>
> mvn clirr:check
>
> Newer components use JApiCmp with the japicmp Maven Profile:
>
> This step is not required if the site includes a JApiCmp report page which
> you then must check.
>
> mvn install -DskipTests -P japicmp japicmp:cmp
>
> 4) Build the package
>
> mvn -V clean package
>
> You can record the Maven and Java version produced by -V in your VOTE
> reply.
> To gather OS information from a command line:
> Windows: ver
> Linux: uname -a
>
> 5) Build the site for a single module project
>
> Note: Some plugins require the components to be installed instead of
> packaged.
>
> mvn site
> Check the site reports in:
> - Windows: target\site\index.html
> - Linux: target/site/index.html
>
> -the end-
>
>