Re: Quo Vadis Maven?
Btw, I feel really strange to have to explain to a long term maven contributor, that he can do maven release whenever he feels so T On Mon, May 6, 2024 at 11:59 AM Tamás Cservenák wrote: > Howdy, > > I think you reversed the question... 3.9.7 was done and ready to go until > you stepped in. > > IMHO the real question is: > Is your issue (using overloaded methods in mojo config) really so urgent > to halt 3.9.7 release? > What is the problem with doing 3.9.8 maybe even two weeks later? > > > Thanks > T > > On Mon, May 6, 2024 at 7:45 AM Olivier Lamy wrote: > >> Is 3.9.7 really so urgent? >> Maybe we can wait a couple of days. >> I have been asking the sisu dev mailing list for a release. >> This should not be too long. >> I can see you are in the committers list >> (https://projects.eclipse.org/projects/technology.sisu/who) with >> Konrad so maybe you can help to expedite this? >> >> regards >> Olivier >> >> >> On Sun, 5 May 2024 at 21:05, Tamás Cservenák wrote: >> > >> > Howdy, >> > >> > Maven 3.9.7 was ready to be released 3 days ago and contains multiple >> fixes >> > contributed by non committers. >> > >> > MNG-8116 was added 2 days ago. I really see no reason to be blocked, to >> > "stop and wait" for a bugfix, as we can always spin 3.9.8. >> > Releases are cheap, and can be done whenever we (anyone of us) feels >> right >> > to do so... >> > >> > 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a >> "now >> > or never" situation. Just spin 3.9.8 whenever you think is ready. >> > >> > My 5 cents >> > T >> > >> > On Sun, May 5, 2024 at 2:14 AM Olivier Lamy wrote: >> > >> > > Hi >> > > Can we please integrate >> https://issues.apache.org/jira/browse/MNG-8116 >> > > The fix is ready and really simple. >> > > >> > > thanks >> > > Olivier >> > > >> > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák >> wrote: >> > > > >> > > > Howdy, >> > > > >> > > > This is just a short newsflash about upcoming planned releases >> related to >> > > > Maven. >> > > > >> > > > Recently we got a huge spike in plugin releases, with various fixes >> and >> > > > improvements. I will not enumerate all of them here, just use `mvn >> > > > versions:display-plugin-updates` to pick them up ;) >> > > > (and more plugins to come). >> > > > >> > > > What I do want to share is about our upcoming Maven releases... >> > > > >> > > > Maven 3.9.7 is nearing (read: coming soon), and will have an >> important >> > > > Resolver update and other important fixes. Most importantly, the >> > > file-locks >> > > > are getting nice improvement (feedback VERY welcome). >> > > > >> > > > Maven 3.9.7 issues: >> > > > >> > > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 >> > > > >> > > > Resolver 1.9.19 issues (mostly bug fixes): >> > > > >> > > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 >> > > > >> > > > At the same time, we plan to release Maven Daemon (m39) as well, to >> have >> > > it >> > > > aligned with Maven 3,9,7: with many bug fixes and >> improvements/alignments >> > > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) >> > > > interchangeable on workstations. >> > > > >> > > > Next, Maven 4 is turning beta, so the next release will be beta1! >> And >> > > > again, same thing for Maven Damon (m40), we will have a release >> that will >> > > > include Maven 4 beta-1. >> > > > >> > > > Maven 4 beta-1 >> > > > >> > > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 >> > > > >> > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 >> beta-1 >> > > > release): >> > > > >> > > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 >> > > > >> > > > Keep your eyes on our upcoming releases, >> > > > and have fun! >> > > > - The Apache Maven team >> > > >> > > - >> > > 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: Quo Vadis Maven?
if you think it's urgent do whatever you want.. On Mon, 6 May 2024 at 20:01, Tamás Cservenák wrote: > > Howdy, > > I think you reversed the question... 3.9.7 was done and ready to go until > you stepped in. > > IMHO the real question is: > Is your issue (using overloaded methods in mojo config) really so urgent to > halt 3.9.7 release? > What is the problem with doing 3.9.8 maybe even two weeks later? > > > Thanks > T > > On Mon, May 6, 2024 at 7:45 AM Olivier Lamy wrote: > > > Is 3.9.7 really so urgent? > > Maybe we can wait a couple of days. > > I have been asking the sisu dev mailing list for a release. > > This should not be too long. > > I can see you are in the committers list > > (https://projects.eclipse.org/projects/technology.sisu/who) with > > Konrad so maybe you can help to expedite this? > > > > regards > > Olivier > > > > > > On Sun, 5 May 2024 at 21:05, Tamás Cservenák wrote: > > > > > > Howdy, > > > > > > Maven 3.9.7 was ready to be released 3 days ago and contains multiple > > fixes > > > contributed by non committers. > > > > > > MNG-8116 was added 2 days ago. I really see no reason to be blocked, to > > > "stop and wait" for a bugfix, as we can always spin 3.9.8. > > > Releases are cheap, and can be done whenever we (anyone of us) feels > > right > > > to do so... > > > > > > 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a "now > > > or never" situation. Just spin 3.9.8 whenever you think is ready. > > > > > > My 5 cents > > > T > > > > > > On Sun, May 5, 2024 at 2:14 AM Olivier Lamy wrote: > > > > > > > Hi > > > > Can we please integrate https://issues.apache.org/jira/browse/MNG-8116 > > > > The fix is ready and really simple. > > > > > > > > thanks > > > > Olivier > > > > > > > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák > > wrote: > > > > > > > > > > Howdy, > > > > > > > > > > This is just a short newsflash about upcoming planned releases > > related to > > > > > Maven. > > > > > > > > > > Recently we got a huge spike in plugin releases, with various fixes > > and > > > > > improvements. I will not enumerate all of them here, just use `mvn > > > > > versions:display-plugin-updates` to pick them up ;) > > > > > (and more plugins to come). > > > > > > > > > > What I do want to share is about our upcoming Maven releases... > > > > > > > > > > Maven 3.9.7 is nearing (read: coming soon), and will have an > > important > > > > > Resolver update and other important fixes. Most importantly, the > > > > file-locks > > > > > are getting nice improvement (feedback VERY welcome). > > > > > > > > > > Maven 3.9.7 issues: > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 > > > > > > > > > > Resolver 1.9.19 issues (mostly bug fixes): > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 > > > > > > > > > > At the same time, we plan to release Maven Daemon (m39) as well, to > > have > > > > it > > > > > aligned with Maven 3,9,7: with many bug fixes and > > improvements/alignments > > > > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) > > > > > interchangeable on workstations. > > > > > > > > > > Next, Maven 4 is turning beta, so the next release will be beta1! And > > > > > again, same thing for Maven Damon (m40), we will have a release that > > will > > > > > include Maven 4 beta-1. > > > > > > > > > > Maven 4 beta-1 > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 > > > > > > > > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 > > beta-1 > > > > > release): > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 > > > > > > > > > > Keep your eyes on our upcoming releases, > > > > > and have fun! > > > > > - The Apache Maven team > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Quo Vadis Maven?
Howdy, I think you reversed the question... 3.9.7 was done and ready to go until you stepped in. IMHO the real question is: Is your issue (using overloaded methods in mojo config) really so urgent to halt 3.9.7 release? What is the problem with doing 3.9.8 maybe even two weeks later? Thanks T On Mon, May 6, 2024 at 7:45 AM Olivier Lamy wrote: > Is 3.9.7 really so urgent? > Maybe we can wait a couple of days. > I have been asking the sisu dev mailing list for a release. > This should not be too long. > I can see you are in the committers list > (https://projects.eclipse.org/projects/technology.sisu/who) with > Konrad so maybe you can help to expedite this? > > regards > Olivier > > > On Sun, 5 May 2024 at 21:05, Tamás Cservenák wrote: > > > > Howdy, > > > > Maven 3.9.7 was ready to be released 3 days ago and contains multiple > fixes > > contributed by non committers. > > > > MNG-8116 was added 2 days ago. I really see no reason to be blocked, to > > "stop and wait" for a bugfix, as we can always spin 3.9.8. > > Releases are cheap, and can be done whenever we (anyone of us) feels > right > > to do so... > > > > 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a "now > > or never" situation. Just spin 3.9.8 whenever you think is ready. > > > > My 5 cents > > T > > > > On Sun, May 5, 2024 at 2:14 AM Olivier Lamy wrote: > > > > > Hi > > > Can we please integrate https://issues.apache.org/jira/browse/MNG-8116 > > > The fix is ready and really simple. > > > > > > thanks > > > Olivier > > > > > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák > wrote: > > > > > > > > Howdy, > > > > > > > > This is just a short newsflash about upcoming planned releases > related to > > > > Maven. > > > > > > > > Recently we got a huge spike in plugin releases, with various fixes > and > > > > improvements. I will not enumerate all of them here, just use `mvn > > > > versions:display-plugin-updates` to pick them up ;) > > > > (and more plugins to come). > > > > > > > > What I do want to share is about our upcoming Maven releases... > > > > > > > > Maven 3.9.7 is nearing (read: coming soon), and will have an > important > > > > Resolver update and other important fixes. Most importantly, the > > > file-locks > > > > are getting nice improvement (feedback VERY welcome). > > > > > > > > Maven 3.9.7 issues: > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 > > > > > > > > Resolver 1.9.19 issues (mostly bug fixes): > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 > > > > > > > > At the same time, we plan to release Maven Daemon (m39) as well, to > have > > > it > > > > aligned with Maven 3,9,7: with many bug fixes and > improvements/alignments > > > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) > > > > interchangeable on workstations. > > > > > > > > Next, Maven 4 is turning beta, so the next release will be beta1! And > > > > again, same thing for Maven Damon (m40), we will have a release that > will > > > > include Maven 4 beta-1. > > > > > > > > Maven 4 beta-1 > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 > > > > > > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 > beta-1 > > > > release): > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 > > > > > > > > Keep your eyes on our upcoming releases, > > > > and have fun! > > > > - The Apache Maven team > > > > > > - > > > 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: Quo Vadis Maven?
Is 3.9.7 really so urgent? Maybe we can wait a couple of days. I have been asking the sisu dev mailing list for a release. This should not be too long. I can see you are in the committers list (https://projects.eclipse.org/projects/technology.sisu/who) with Konrad so maybe you can help to expedite this? regards Olivier On Sun, 5 May 2024 at 21:05, Tamás Cservenák wrote: > > Howdy, > > Maven 3.9.7 was ready to be released 3 days ago and contains multiple fixes > contributed by non committers. > > MNG-8116 was added 2 days ago. I really see no reason to be blocked, to > "stop and wait" for a bugfix, as we can always spin 3.9.8. > Releases are cheap, and can be done whenever we (anyone of us) feels right > to do so... > > 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a "now > or never" situation. Just spin 3.9.8 whenever you think is ready. > > My 5 cents > T > > On Sun, May 5, 2024 at 2:14 AM Olivier Lamy wrote: > > > Hi > > Can we please integrate https://issues.apache.org/jira/browse/MNG-8116 > > The fix is ready and really simple. > > > > thanks > > Olivier > > > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák wrote: > > > > > > Howdy, > > > > > > This is just a short newsflash about upcoming planned releases related to > > > Maven. > > > > > > Recently we got a huge spike in plugin releases, with various fixes and > > > improvements. I will not enumerate all of them here, just use `mvn > > > versions:display-plugin-updates` to pick them up ;) > > > (and more plugins to come). > > > > > > What I do want to share is about our upcoming Maven releases... > > > > > > Maven 3.9.7 is nearing (read: coming soon), and will have an important > > > Resolver update and other important fixes. Most importantly, the > > file-locks > > > are getting nice improvement (feedback VERY welcome). > > > > > > Maven 3.9.7 issues: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 > > > > > > Resolver 1.9.19 issues (mostly bug fixes): > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 > > > > > > At the same time, we plan to release Maven Daemon (m39) as well, to have > > it > > > aligned with Maven 3,9,7: with many bug fixes and improvements/alignments > > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) > > > interchangeable on workstations. > > > > > > Next, Maven 4 is turning beta, so the next release will be beta1! And > > > again, same thing for Maven Damon (m40), we will have a release that will > > > include Maven 4 beta-1. > > > > > > Maven 4 beta-1 > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 > > > > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1 > > > release): > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 > > > > > > Keep your eyes on our upcoming releases, > > > and have fun! > > > - The Apache Maven team > > > > - > > 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: Quo Vadis Maven?
Howdy, Maven 3.9.7 was ready to be released 3 days ago and contains multiple fixes contributed by non committers. MNG-8116 was added 2 days ago. I really see no reason to be blocked, to "stop and wait" for a bugfix, as we can always spin 3.9.8. Releases are cheap, and can be done whenever we (anyone of us) feels right to do so... 3.9.7 is not the "last Maven 3.9.x" or anything like that, to have a "now or never" situation. Just spin 3.9.8 whenever you think is ready. My 5 cents T On Sun, May 5, 2024 at 2:14 AM Olivier Lamy wrote: > Hi > Can we please integrate https://issues.apache.org/jira/browse/MNG-8116 > The fix is ready and really simple. > > thanks > Olivier > > On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák wrote: > > > > Howdy, > > > > This is just a short newsflash about upcoming planned releases related to > > Maven. > > > > Recently we got a huge spike in plugin releases, with various fixes and > > improvements. I will not enumerate all of them here, just use `mvn > > versions:display-plugin-updates` to pick them up ;) > > (and more plugins to come). > > > > What I do want to share is about our upcoming Maven releases... > > > > Maven 3.9.7 is nearing (read: coming soon), and will have an important > > Resolver update and other important fixes. Most importantly, the > file-locks > > are getting nice improvement (feedback VERY welcome). > > > > Maven 3.9.7 issues: > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 > > > > Resolver 1.9.19 issues (mostly bug fixes): > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 > > > > At the same time, we plan to release Maven Daemon (m39) as well, to have > it > > aligned with Maven 3,9,7: with many bug fixes and improvements/alignments > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) > > interchangeable on workstations. > > > > Next, Maven 4 is turning beta, so the next release will be beta1! And > > again, same thing for Maven Damon (m40), we will have a release that will > > include Maven 4 beta-1. > > > > Maven 4 beta-1 > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 > > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1 > > release): > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 > > > > Keep your eyes on our upcoming releases, > > and have fun! > > - The Apache Maven team > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Quo Vadis Maven?
Hi Can we please integrate https://issues.apache.org/jira/browse/MNG-8116 The fix is ready and really simple. thanks Olivier On Wed, 24 Apr 2024 at 07:12, Tamás Cservenák wrote: > > Howdy, > > This is just a short newsflash about upcoming planned releases related to > Maven. > > Recently we got a huge spike in plugin releases, with various fixes and > improvements. I will not enumerate all of them here, just use `mvn > versions:display-plugin-updates` to pick them up ;) > (and more plugins to come). > > What I do want to share is about our upcoming Maven releases... > > Maven 3.9.7 is nearing (read: coming soon), and will have an important > Resolver update and other important fixes. Most importantly, the file-locks > are getting nice improvement (feedback VERY welcome). > > Maven 3.9.7 issues: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 > > Resolver 1.9.19 issues (mostly bug fixes): > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 > > At the same time, we plan to release Maven Daemon (m39) as well, to have it > aligned with Maven 3,9,7: with many bug fixes and improvements/alignments > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) > interchangeable on workstations. > > Next, Maven 4 is turning beta, so the next release will be beta1! And > again, same thing for Maven Damon (m40), we will have a release that will > include Maven 4 beta-1. > > Maven 4 beta-1 > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1 > release): > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 > > Keep your eyes on our upcoming releases, > and have fun! > - The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Quo Vadis Maven?
Le 2024-05-04 à 13 h 42, Tamás Cservenák a écrit : MNG-8041: I moved it out MNG-8073: done, thanks to Sylwester and Slawek If not too late, can the following be considered for 4.0.0-beta? https://github.com/apache/maven/pull/1501 This pull request (PR) contains adjustments to the PathType API based on experience gained with the compiler plugin. The PR description gives more details. Regarding the compiler plugin, the development part is almost completed and I'm about to start working on the tests. Martin
Re: Quo Vadis Maven?
MNG-8041: I moved it out MNG-8073: done, thanks to Sylwester and Slawek T On Fri, May 3, 2024 at 5:33 PM Tamás Cservenák wrote: > MNG-8041: can be moved out, needs a bit more verification > MNG-8073: needs modello release, and can be done. but beta-2 is fine as > well > > So IMHO both can be pushed to beta-2 > > T > > On Fri, May 3, 2024 at 5:32 PM Guillaume Nodet wrote: > >> I'd like to release beta-1 next week. >> Maven Daemon is ready to be upgrade to it with >> https://github.com/apache/maven-mvnd/pull/974 >> >> Tamás, what's your plan regarding the two remaining issues: >> * https://issues.apache.org/jira/browse/MNG-8041 >> * https://issues.apache.org/jira/browse/MNG-8073 >> >> Cheers, >> Guillaume >> >> Le mar. 23 avr. 2024 à 23:12, Tamás Cservenák a >> écrit : >> >> > Howdy, >> > >> > This is just a short newsflash about upcoming planned releases related >> to >> > Maven. >> > >> > Recently we got a huge spike in plugin releases, with various fixes and >> > improvements. I will not enumerate all of them here, just use `mvn >> > versions:display-plugin-updates` to pick them up ;) >> > (and more plugins to come). >> > >> > What I do want to share is about our upcoming Maven releases... >> > >> > Maven 3.9.7 is nearing (read: coming soon), and will have an important >> > Resolver update and other important fixes. Most importantly, the >> file-locks >> > are getting nice improvement (feedback VERY welcome). >> > >> > Maven 3.9.7 issues: >> > >> > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 >> > >> > Resolver 1.9.19 issues (mostly bug fixes): >> > >> > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 >> > >> > At the same time, we plan to release Maven Daemon (m39) as well, to >> have it >> > aligned with Maven 3,9,7: with many bug fixes and >> improvements/alignments >> > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) >> > interchangeable on workstations. >> > >> > Next, Maven 4 is turning beta, so the next release will be beta1! And >> > again, same thing for Maven Damon (m40), we will have a release that >> will >> > include Maven 4 beta-1. >> > >> > Maven 4 beta-1 >> > >> > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 >> > >> > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1 >> > release): >> > >> > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 >> > >> > Keep your eyes on our upcoming releases, >> > and have fun! >> > - The Apache Maven team >> > >> >> >> -- >> >> Guillaume Nodet >> >
Re: Quo Vadis Maven?
MNG-8041: can be moved out, needs a bit more verification MNG-8073: needs modello release, and can be done. but beta-2 is fine as well So IMHO both can be pushed to beta-2 T On Fri, May 3, 2024 at 5:32 PM Guillaume Nodet wrote: > I'd like to release beta-1 next week. > Maven Daemon is ready to be upgrade to it with > https://github.com/apache/maven-mvnd/pull/974 > > Tamás, what's your plan regarding the two remaining issues: > * https://issues.apache.org/jira/browse/MNG-8041 > * https://issues.apache.org/jira/browse/MNG-8073 > > Cheers, > Guillaume > > Le mar. 23 avr. 2024 à 23:12, Tamás Cservenák a > écrit : > > > Howdy, > > > > This is just a short newsflash about upcoming planned releases related to > > Maven. > > > > Recently we got a huge spike in plugin releases, with various fixes and > > improvements. I will not enumerate all of them here, just use `mvn > > versions:display-plugin-updates` to pick them up ;) > > (and more plugins to come). > > > > What I do want to share is about our upcoming Maven releases... > > > > Maven 3.9.7 is nearing (read: coming soon), and will have an important > > Resolver update and other important fixes. Most importantly, the > file-locks > > are getting nice improvement (feedback VERY welcome). > > > > Maven 3.9.7 issues: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 > > > > Resolver 1.9.19 issues (mostly bug fixes): > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 > > > > At the same time, we plan to release Maven Daemon (m39) as well, to have > it > > aligned with Maven 3,9,7: with many bug fixes and improvements/alignments > > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) > > interchangeable on workstations. > > > > Next, Maven 4 is turning beta, so the next release will be beta1! And > > again, same thing for Maven Damon (m40), we will have a release that will > > include Maven 4 beta-1. > > > > Maven 4 beta-1 > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 > > > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1 > > release): > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 > > > > Keep your eyes on our upcoming releases, > > and have fun! > > - The Apache Maven team > > > > > -- > > Guillaume Nodet >
Re: Quo Vadis Maven?
I'd like to release beta-1 next week. Maven Daemon is ready to be upgrade to it with https://github.com/apache/maven-mvnd/pull/974 Tamás, what's your plan regarding the two remaining issues: * https://issues.apache.org/jira/browse/MNG-8041 * https://issues.apache.org/jira/browse/MNG-8073 Cheers, Guillaume Le mar. 23 avr. 2024 à 23:12, Tamás Cservenák a écrit : > Howdy, > > This is just a short newsflash about upcoming planned releases related to > Maven. > > Recently we got a huge spike in plugin releases, with various fixes and > improvements. I will not enumerate all of them here, just use `mvn > versions:display-plugin-updates` to pick them up ;) > (and more plugins to come). > > What I do want to share is about our upcoming Maven releases... > > Maven 3.9.7 is nearing (read: coming soon), and will have an important > Resolver update and other important fixes. Most importantly, the file-locks > are getting nice improvement (feedback VERY welcome). > > Maven 3.9.7 issues: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 > > Resolver 1.9.19 issues (mostly bug fixes): > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 > > At the same time, we plan to release Maven Daemon (m39) as well, to have it > aligned with Maven 3,9,7: with many bug fixes and improvements/alignments > to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) > interchangeable on workstations. > > Next, Maven 4 is turning beta, so the next release will be beta1! And > again, same thing for Maven Damon (m40), we will have a release that will > include Maven 4 beta-1. > > Maven 4 beta-1 > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 > > Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1 > release): > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 > > Keep your eyes on our upcoming releases, > and have fun! > - The Apache Maven team > -- Guillaume Nodet
Re: Quo Vadis Maven?
Awesome work everyone. It is great to see all the progress Maven and related tooling is making. Manfred On 2024-04-23 2:12 p.m., Tamás Cservenák wrote: Howdy, This is just a short newsflash about upcoming planned releases related to Maven. Recently we got a huge spike in plugin releases, with various fixes and improvements. I will not enumerate all of them here, just use `mvn versions:display-plugin-updates` to pick them up ;) (and more plugins to come). What I do want to share is about our upcoming Maven releases... Maven 3.9.7 is nearing (read: coming soon), and will have an important Resolver update and other important fixes. Most importantly, the file-locks are getting nice improvement (feedback VERY welcome). Maven 3.9.7 issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 Resolver 1.9.19 issues (mostly bug fixes): https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 At the same time, we plan to release Maven Daemon (m39) as well, to have it aligned with Maven 3,9,7: with many bug fixes and improvements/alignments to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) interchangeable on workstations. Next, Maven 4 is turning beta, so the next release will be beta1! And again, same thing for Maven Damon (m40), we will have a release that will include Maven 4 beta-1. Maven 4 beta-1 https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1 release): https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 Keep your eyes on our upcoming releases, and have fun! - The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Quo Vadis Maven?
Howdy, This is just a short newsflash about upcoming planned releases related to Maven. Recently we got a huge spike in plugin releases, with various fixes and improvements. I will not enumerate all of them here, just use `mvn versions:display-plugin-updates` to pick them up ;) (and more plugins to come). What I do want to share is about our upcoming Maven releases... Maven 3.9.7 is nearing (read: coming soon), and will have an important Resolver update and other important fixes. Most importantly, the file-locks are getting nice improvement (feedback VERY welcome). Maven 3.9.7 issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7 Resolver 1.9.19 issues (mostly bug fixes): https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19 At the same time, we plan to release Maven Daemon (m39) as well, to have it aligned with Maven 3,9,7: with many bug fixes and improvements/alignments to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd) interchangeable on workstations. Next, Maven 4 is turning beta, so the next release will be beta1! And again, same thing for Maven Damon (m40), we will have a release that will include Maven 4 beta-1. Maven 4 beta-1 https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1 Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1 release): https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11 Keep your eyes on our upcoming releases, and have fun! - The Apache Maven team
Re: [DISCUSS] Quo Vadis Maven Site
; > > > the main content of a page > > > > > > > > > - long time on build site is caused by multiple executing the same > > > > > > Maven > > > > > > > > phase for many reports [1] > > > > > > > > true > > > > thinking at "why": because the maven-site-plugin does the report goals > > > > invocation, it's not Maven core > > > > that's one of the reasons why I love Tamas idea about having Maven > > > > > > generate > > > > > > > "*-reports.jar" then the new site rending process just rendering to > > > > HTML > > > > > > > > I don't like some words of Tamas on the topic, but there are also very > > > > > > good > > > > > > > ideas that could halp a better new site generation architecture :) > > > > > > > > > - some reports, like tests result, static code analize is not usable > > > > > > for > > > > > > > > static documentation - such reports should be generated by CI > > > > > nowadays > > > > > > > > as you know, I disagree: it is usable for some use cases, which are > > > > not > > > > > > the > > > > > > > use cases you are interested in > > > > > > > > > [1] https://issues.apache.org/jira/browse/MSHARED-1044 > > > > > > > > > > śr., 16 lis 2022 o 11:19 Tamás Cservenák > > > > > > napisał(a): > > > > > > Howdy, > > > > > > > > > > > > This is really just a brainstorming thread I'd like to spin, > > > > > > regarding > > > > > > > > > Maven Site stuff. > > > > > > > > > > > > Again, the message is in wiki > > > > > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > > > > > > But I would like to make discussion happen here on dev ML. > > > > > > > > > > > > Thanks > > > > > > T > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Quo Vadis Maven Site
yes, using a nowadays de-facto standard Markup language like asciidoc or Markdown as a pivot is one the the good ideas from this discussion and I feel it could be a concrete step implemented independently, going in the right direction without being disruptive, that could open tests for tests on next steps = trying to change the rendering steps (currently implemented in Doxia Sitetools + associated skins) implementation ideas: given many reports are implemented using Doxia Sink API to describe the generated content, generating the markup instead of direct Maven site html is just about injecting a Sink implementation Sadly, Markdown and Asciidoc are the 2 markups where there is no Sink implementation available yet https://maven.apache.org/doxia/references/index.html - for markdown, issue is there waiting for implementation https://issues.apache.org/jira/projects/DOXIA/issues/DOXIA-569 - for AsciiDoc, equivalent is necessary Once we have a Sink implementation available, injecting it for any plugin could be done in Maven Site Plugin I suppose, or even in maven-reporting-impl for direct goal invocation -- i.e. "mvn project-info-reports:index" (probably with a "-DoutputFormat=adoc") could generate a .md or .adoc instead of generating .html it looks really feasible... Le mardi 22 novembre 2022, 08:04:18 CET Romain Manni-Bucau a écrit : > Well, think the point of a pivot format (adoc) is mainly the composability > and reusability. With doxia we are very far even if it can be sexy (theme). > The other fact is the adoption of the technology - whatever its quality. > Doxia is a maven solution at the end, adoc (or md strictly speaking) is a > tech guys + writers solution so it covers multiple languages but also > people so solutions are way wider. > So being able to render anything in this pivot format then convert it or > not to html sounds like a move forward to me - but also agree people > already do it so it is mainly a question for maven to get it as a first > citizen feature or not IMHO. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance > > > Le mar. 22 nov. 2022 à 00:20, Olivier Lamy a écrit : > > On Sat, 19 Nov 2022 at 09:08, Hervé Boutemy wrote: > > > Le vendredi 18 novembre 2022, 07:57:59 CET Slawomir Jaranowski a écrit : > > > > Hi, > > > > > > > > some my thoughts > > > > - site looks can be changed be skins - so can be more modern > > > > > > yes > > > it seems people don't understand the menu generation with it's > > > > "decoration > > > > > model", then we don't see many people doing more skins > > > > there are still some (more modern than the one we are using...) > > look here https://devacfr.github.io/reflow-maven-skin/ > > I forked one here https://github.com/olamy/reflow-maven-skin to make > > it work with a recent version of doxia. > > > > > Having graphic people being able to do skins would be awesome, that's > > > > one of > > > > > the benefits I see in Tamas proposal: I still need to understand how the > > > > other > > > > > static generation tools manage the menu creation and overall > > > > "decoration" of > > > > > the main content of a page > > > > > > > - long time on build site is caused by multiple executing the same > > > > Maven > > > > > > phase for many reports [1] > > > > > > true > > > thinking at "why": because the maven-site-plugin does the report goals > > > invocation, it's not Maven core > > > that's one of the reasons why I love Tamas idea about having Maven > > > > generate > > > > > "*-reports.jar" then the new site rending process just rendering to HTML > > > > > > I don't like some words of Tamas on the topic, but there are also very > > > > good > > > > > ideas that could halp a better new site generation architecture :) > > > > > > > - some reports, like tests result, static code analize is not usable > > > > for > > > > > > static documentation - such reports should be generated by CI nowadays > > > > > > as yo
Re: [DISCUSS] Quo Vadis Maven Site
Le mardi 22 novembre 2022, 00:20:00 CET Olivier Lamy a écrit : > On Sat, 19 Nov 2022 at 09:08, Hervé Boutemy wrote: > > Le vendredi 18 novembre 2022, 07:57:59 CET Slawomir Jaranowski a écrit : > > > Hi, > > > > > > some my thoughts > > > - site looks can be changed be skins - so can be more modern > > > > yes > > it seems people don't understand the menu generation with it's "decoration > > model", then we don't see many people doing more skins > > there are still some (more modern than the one we are using...) > look here https://devacfr.github.io/reflow-maven-skin/ > I forked one here https://github.com/olamy/reflow-maven-skin to make > it work with a recent version of doxia. you're right, there are a few external skins available https://maven.apache.org/skins/ we should probably put the retired section at the end of the page... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Quo Vadis Maven Site
Well, think the point of a pivot format (adoc) is mainly the composability and reusability. With doxia we are very far even if it can be sexy (theme). The other fact is the adoption of the technology - whatever its quality. Doxia is a maven solution at the end, adoc (or md strictly speaking) is a tech guys + writers solution so it covers multiple languages but also people so solutions are way wider. So being able to render anything in this pivot format then convert it or not to html sounds like a move forward to me - but also agree people already do it so it is mainly a question for maven to get it as a first citizen feature or not IMHO. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 22 nov. 2022 à 00:20, Olivier Lamy a écrit : > On Sat, 19 Nov 2022 at 09:08, Hervé Boutemy wrote: > > > > Le vendredi 18 novembre 2022, 07:57:59 CET Slawomir Jaranowski a écrit : > > > Hi, > > > > > > some my thoughts > > > - site looks can be changed be skins - so can be more modern > > yes > > it seems people don't understand the menu generation with it's > "decoration > > model", then we don't see many people doing more skins > > > there are still some (more modern than the one we are using...) > look here https://devacfr.github.io/reflow-maven-skin/ > I forked one here https://github.com/olamy/reflow-maven-skin to make > it work with a recent version of doxia. > > > Having graphic people being able to do skins would be awesome, that's > one of > > the benefits I see in Tamas proposal: I still need to understand how the > other > > static generation tools manage the menu creation and overall > "decoration" of > > the main content of a page > > > > > - long time on build site is caused by multiple executing the same > Maven > > > phase for many reports [1] > > true > > thinking at "why": because the maven-site-plugin does the report goals > > invocation, it's not Maven core > > that's one of the reasons why I love Tamas idea about having Maven > generate > > "*-reports.jar" then the new site rending process just rendering to HTML > > > > I don't like some words of Tamas on the topic, but there are also very > good > > ideas that could halp a better new site generation architecture :) > > > > > - some reports, like tests result, static code analize is not usable > for > > > static documentation - such reports should be generated by CI nowadays > > as you know, I disagree: it is usable for some use cases, which are not > the > > use cases you are interested in > > > > > > > > [1] https://issues.apache.org/jira/browse/MSHARED-1044 > > > > > > śr., 16 lis 2022 o 11:19 Tamás Cservenák > napisał(a): > > > > Howdy, > > > > > > > > This is really just a brainstorming thread I'd like to spin, > regarding > > > > Maven Site stuff. > > > > > > > > Again, the message is in wiki > > > > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > > > > > But I would like to make discussion happen here on dev ML. > > > > > > > > Thanks > > > > T > > > > > > > > > > > > - > > 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: [DISCUSS] Quo Vadis Maven Site
On Sat, 19 Nov 2022 at 09:08, Hervé Boutemy wrote: > > Le vendredi 18 novembre 2022, 07:57:59 CET Slawomir Jaranowski a écrit : > > Hi, > > > > some my thoughts > > - site looks can be changed be skins - so can be more modern > yes > it seems people don't understand the menu generation with it's "decoration > model", then we don't see many people doing more skins > there are still some (more modern than the one we are using...) look here https://devacfr.github.io/reflow-maven-skin/ I forked one here https://github.com/olamy/reflow-maven-skin to make it work with a recent version of doxia. > Having graphic people being able to do skins would be awesome, that's one of > the benefits I see in Tamas proposal: I still need to understand how the other > static generation tools manage the menu creation and overall "decoration" of > the main content of a page > > > - long time on build site is caused by multiple executing the same Maven > > phase for many reports [1] > true > thinking at "why": because the maven-site-plugin does the report goals > invocation, it's not Maven core > that's one of the reasons why I love Tamas idea about having Maven generate > "*-reports.jar" then the new site rending process just rendering to HTML > > I don't like some words of Tamas on the topic, but there are also very good > ideas that could halp a better new site generation architecture :) > > > - some reports, like tests result, static code analize is not usable for > > static documentation - such reports should be generated by CI nowadays > as you know, I disagree: it is usable for some use cases, which are not the > use cases you are interested in > > > > > [1] https://issues.apache.org/jira/browse/MSHARED-1044 > > > > śr., 16 lis 2022 o 11:19 Tamás Cservenák napisał(a): > > > Howdy, > > > > > > This is really just a brainstorming thread I'd like to spin, regarding > > > Maven Site stuff. > > > > > > Again, the message is in wiki > > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > > > But I would like to make discussion happen here on dev ML. > > > > > > Thanks > > > T > > > > > > - > 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: [DISCUSS] Quo Vadis Maven Site
it looks like one key issue you're facing is specific to https://maven.apache.org site, = our own site that is: 1. an aggregation of near 100 subsites representing each one Maven subproject (see https://maven.apache.org/scm.html#maven-sources-overview) 2. that uses Apache infra's svnpubsub engine to push the html to live site, then adds some delays and quirks that bite you good news, I wrote documentation on these 2 aspects: https://maven.apache.org/developers/website/index.html https://maven.apache.org/developers/website/deploy-component-reference-documentation.html with a "component helper" to ease component deployment without really understanding all the nitty gritty details under the hood: https://maven.apache.org/developers/website/component-reference-documentation-helper.html I'd be pleased to have as much as Maven maintainers read these docs, try to understand and tell me what I need to explain more, because it seems I wrote doc that nobody reads and even understand that they are hit by some quirks at this Apache publication and sub-projects sub-sites aggregation level all other discussions about one project site publication (Doxia, formats, reporting, etc) are also valid, and even more impactful because they impact any project that uses Maven Site Plugin to generate their website It's just 2 distinct discussions to have (and at some point converge back) Le vendredi 18 novembre 2022, 23:56:37 CET Hervé Boutemy a écrit : > +1000 > this evaluation is much more fair > > it does not mean that looking at rearchitecturing a new site generation > would not be useful > > key is > > > I like some parts of this. I don't agree with others. > > I suppose the good ideas from the Wiki should be prototyped: > - on a basic mono-module project > - on a multi-module project > - and eventually on an aggregation of sites (seeing if it can scale to the > Maven site itself) > > Le mercredi 16 novembre 2022, 13:08:08 CET Elliotte Rusty Harold a écrit : > > I like some parts of this. I don't agree with others. I agree that > > maven site isn't competitive with other site builders, but that was > > never really its purpose. I think it's OK for generating a site for a > > Maven project. I wouldn't expect it to be used for anything else. As a > > maintainer of one such site <http://www.cafeconleche.org/jaxen/> it > > would be very inconvenient for me if this plugin disappeared or > > changed in a major way. > > > > The old site design just works. We don't need so-called modern, > > responsive sites. For our purposes — documenting code — the 20 year > > old classic HTML we use is just fine. In fact, I'd say it's superior > > to modern designs as implemented in practice. > > > > I do wish Maven hadn't gone its own way with NIH components like > > Plexus, APT, and Doxia that are all essentially used today by maven > > and no one else. However in fairness this all happened twenty years > > ago when alternatives that have become de facto standards was not > > obviously better or simply did not exist. We should modernize our > > dependencies where possible, but I don't think a rewrite is worth the > > effort and I would oppose anything that broke existing sites, links, > > and workflows. > > > > When counting "wasted engineering hours spent on it", these are at > > least a couple of orders of magnitude lower than would be spent on a > > radical replacement of the sort being proposed. It's like proposing we > > build a new Lamborghini to save the money we spend on oil changes for > > our 2002 Ford pickup. Of course this is open source, so if anyone has > > the time and money to spend on an alternative site plugin that > > scratches their itch, by all means they can do it. However this should > > be a new plugin projects can adopt or not at a time that's convenient > > for them. It should not replace the existing plugin so many projects > > already use. > > > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák wrote: > > > Howdy, > > > > > > This is really just a brainstorming thread I'd like to spin, regarding > > > Maven Site stuff. > > > > > > Again, the message is in wiki > > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > > > But I would like to make discussion happen here on dev ML. > > > > > > Thanks > > > T > > - > 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: [DISCUSS] Quo Vadis Maven Site
Le vendredi 18 novembre 2022, 07:57:59 CET Slawomir Jaranowski a écrit : > Hi, > > some my thoughts > - site looks can be changed be skins - so can be more modern yes it seems people don't understand the menu generation with it's "decoration model", then we don't see many people doing more skins Having graphic people being able to do skins would be awesome, that's one of the benefits I see in Tamas proposal: I still need to understand how the other static generation tools manage the menu creation and overall "decoration" of the main content of a page > - long time on build site is caused by multiple executing the same Maven > phase for many reports [1] true thinking at "why": because the maven-site-plugin does the report goals invocation, it's not Maven core that's one of the reasons why I love Tamas idea about having Maven generate "*-reports.jar" then the new site rending process just rendering to HTML I don't like some words of Tamas on the topic, but there are also very good ideas that could halp a better new site generation architecture :) > - some reports, like tests result, static code analize is not usable for > static documentation - such reports should be generated by CI nowadays as you know, I disagree: it is usable for some use cases, which are not the use cases you are interested in > > [1] https://issues.apache.org/jira/browse/MSHARED-1044 > > śr., 16 lis 2022 o 11:19 Tamás Cservenák napisał(a): > > Howdy, > > > > This is really just a brainstorming thread I'd like to spin, regarding > > Maven Site stuff. > > > > Again, the message is in wiki > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > But I would like to make discussion happen here on dev ML. > > > > Thanks > > T - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Quo Vadis Maven Site
+1000 this evaluation is much more fair it does not mean that looking at rearchitecturing a new site generation would not be useful key is > I like some parts of this. I don't agree with others. I suppose the good ideas from the Wiki should be prototyped: - on a basic mono-module project - on a multi-module project - and eventually on an aggregation of sites (seeing if it can scale to the Maven site itself) Le mercredi 16 novembre 2022, 13:08:08 CET Elliotte Rusty Harold a écrit : > I like some parts of this. I don't agree with others. I agree that > maven site isn't competitive with other site builders, but that was > never really its purpose. I think it's OK for generating a site for a > Maven project. I wouldn't expect it to be used for anything else. As a > maintainer of one such site <http://www.cafeconleche.org/jaxen/> it > would be very inconvenient for me if this plugin disappeared or > changed in a major way. > > The old site design just works. We don't need so-called modern, > responsive sites. For our purposes — documenting code — the 20 year > old classic HTML we use is just fine. In fact, I'd say it's superior > to modern designs as implemented in practice. > > I do wish Maven hadn't gone its own way with NIH components like > Plexus, APT, and Doxia that are all essentially used today by maven > and no one else. However in fairness this all happened twenty years > ago when alternatives that have become de facto standards was not > obviously better or simply did not exist. We should modernize our > dependencies where possible, but I don't think a rewrite is worth the > effort and I would oppose anything that broke existing sites, links, > and workflows. > > When counting "wasted engineering hours spent on it", these are at > least a couple of orders of magnitude lower than would be spent on a > radical replacement of the sort being proposed. It's like proposing we > build a new Lamborghini to save the money we spend on oil changes for > our 2002 Ford pickup. Of course this is open source, so if anyone has > the time and money to spend on an alternative site plugin that > scratches their itch, by all means they can do it. However this should > be a new plugin projects can adopt or not at a time that's convenient > for them. It should not replace the existing plugin so many projects > already use. > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák wrote: > > Howdy, > > > > This is really just a brainstorming thread I'd like to spin, regarding > > Maven Site stuff. > > > > Again, the message is in wiki > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > But I would like to make discussion happen here on dev ML. > > > > Thanks > > T - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Quo Vadis Maven Site
Hi, some my thoughts - site looks can be changed be skins - so can be more modern - long time on build site is caused by multiple executing the same Maven phase for many reports [1] - some reports, like tests result, static code analize is not usable for static documentation - such reports should be generated by CI nowadays [1] https://issues.apache.org/jira/browse/MSHARED-1044 śr., 16 lis 2022 o 11:19 Tamás Cservenák napisał(a): > Howdy, > > This is really just a brainstorming thread I'd like to spin, regarding > Maven Site stuff. > > Again, the message is in wiki > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > But I would like to make discussion happen here on dev ML. > > Thanks > T > -- Sławomir Jaranowski
Re: [DISCUSS] Quo Vadis Maven Site
perior to modern designs as implemented in practice. I do wish Maven hadn't gone its own way with NIH components like Plexus, APT, and Doxia that are all essentially used today by maven and no one else. However in fairness this all happened twenty years ago when alternatives that have become de facto standards was not obviously better or simply did not exist. We should modernize our dependencies where possible, but I don't think a rewrite is worth the effort and I would oppose anything that broke existing sites, links, and workflows. When counting "wasted engineering hours spent on it", these are at least a couple of orders of magnitude lower than would be spent on a radical replacement of the sort being proposed. It's like proposing we build a new Lamborghini to save the money we spend on oil changes for our 2002 Ford pickup. Of course this is open source, so if anyone has the time and money to spend on an alternative site plugin that scratches their itch, by all means they can do it. However this should be a new plugin projects can adopt or not at a time that's convenient for them. It should not replace the existing plugin so many projects already use. On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák < ta...@cservenak.net> wrote: Howdy, This is really just a brainstorming thread I'd like to spin, regarding Maven Site stuff. Again, the message is in wiki https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site But I would like to make discussion happen here on dev ML. Thanks T -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Quo Vadis Maven Site
On Thu, Nov 17, 2022 at 7:20 AM Tamás Cservenák wrote: > > Howdy, > > Yes, that's right, the "bootstrap" effort is not the same, true. > That's a good way of putting it. I care a lot more about the bootstrap effort (performed manually by people) than build time, where I can go get a cup of coffee and browse Reddit. It's not like I'm building the site on every hit to the docs or every time I run a test. It's a batch job that doesn't happen that often so I'm not willing to trade much to speed it up. -- 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: [DISCUSS] Quo Vadis Maven Site
> > > all. > > > > > > > > > > T > > > > > > > > > > On Wed, Nov 16, 2022 at 7:25 PM Benjamin Marwell < > > bmarw...@apache.org> > > > > > wrote: > > > > > > > > > >> Please do NOT consider jbake. > > > > >> We (shiro team) ported the page to jbake, and it is really a mess. > > > > >> Many things are not supported which can easily be done in other > > static > > > > >> site generators. > > > > >> There is absolutely no progress. No java.time support. JSON/YAML > > > > >> support is broken and needs a lot of workarounds. > > > > >> > > > > >> Look at the repo and build it yourself -- the amount of javadoc > will > > > > >> take very long to process. > > > > >> https://github.com/apache/shiro-site > > > > >> > > > > >> > > > > >> Am Mi., 16. Nov. 2022 um 13:21 Uhr schrieb Tamás Cservenák > > > > >> : > > > > >> > > > > > >> > Howdy, > > > > >> > > > > > >> > I am pretty much sure your site could be pretty much > "transported" > > > to > > > > >> use > > > > >> > jbake-maven-plugin instead of maven-site-plugin. > > > > >> > > > > > >> > I am aware of the long history of the Maven project, being here > > > since > > > > >> 2006, > > > > >> > but still... > > > > >> > I don't think what I propose is "build a lamborghini instead of > a > > > ford > > > > >> > pickup". > > > > >> > > > > > >> > I see it more like "let's replace the ford battery, but given > how > > > old > > > > it > > > > >> > is, we have > > > > >> > only aftermarket parts for it". > > > > >> > > > > > >> > Now that you have shown your site, let me try to de-site it, > just > > as > > > > an > > > > >> > experiment... > > > > >> > as I never tried this before > > > > >> > > > > > >> > Will do it here > > > > >> > https://github.com/cstamas/jaxen > > > > >> > > > > > >> > Thanks > > > > >> > T > > > > >> > > > > > >> > On Wed, Nov 16, 2022 at 1:08 PM Elliotte Rusty Harold < > > > > >> elh...@ibiblio.org> > > > > >> > wrote: > > > > >> > > > > > >> > > I like some parts of this. I don't agree with others. I agree > > that > > > > >> > > maven site isn't competitive with other site builders, but > that > > > was > > > > >> > > never really its purpose. I think it's OK for generating a > site > > > > for a > > > > >> > > Maven project. I wouldn't expect it to be used for anything > > else. > > > > As a > > > > >> > > maintainer of one such site < > http://www.cafeconleche.org/jaxen/ > > > > > > it > > > > >> > > would be very inconvenient for me if this plugin disappeared > or > > > > >> > > changed in a major way. > > > > >> > > > > > > >> > > The old site design just works. We don't need so-called > modern, > > > > >> > > responsive sites. For our purposes — documenting code — the 20 > > > year > > > > >> > > old classic HTML we use is just fine. In fact, I'd say it's > > > superior > > > > >> > > to modern designs as implemented in practice. > > > > >> > > > > > > >> > > I do wish Maven hadn't gone its own way with NIH components > like > > > > >> > > Plexus, APT, and Doxia that are all essentially used today by > > > maven > > > > >> > > and no one else. However in fairness this all happened twenty > > > years > > > > >> > > ago when alternatives that have become de facto standards was > > not > > > > >> > > obviously better or simply did not exist. We should modernize > > our > > > > >> > > dependencies where possible, but I don't think a rewrite is > > worth > > > > the > > > > >> > > effort and I would oppose anything that broke existing sites, > > > links, > > > > >> > > and workflows. > > > > >> > > > > > > >> > > When counting "wasted engineering hours spent on it", these > are > > at > > > > >> > > least a couple of orders of magnitude lower than would be > spent > > > on a > > > > >> > > radical replacement of the sort being proposed. It's like > > > proposing > > > > we > > > > >> > > build a new Lamborghini to save the money we spend on oil > > changes > > > > for > > > > >> > > our 2002 Ford pickup. Of course this is open source, so if > > anyone > > > > has > > > > >> > > the time and money to spend on an alternative site plugin > that > > > > >> > > scratches their itch, by all means they can do it. However > this > > > > should > > > > >> > > be a new plugin projects can adopt or not at a time that's > > > > convenient > > > > >> > > for them. It should not replace the existing plugin so many > > > projects > > > > >> > > already use. > > > > >> > > > > > > >> > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák < > > > > ta...@cservenak.net> > > > > >> > > wrote: > > > > >> > > > > > > > >> > > > Howdy, > > > > >> > > > > > > > >> > > > This is really just a brainstorming thread I'd like to spin, > > > > >> regarding > > > > >> > > > Maven Site stuff. > > > > >> > > > > > > > >> > > > Again, the message is in wiki > > > > >> > > > > > > > >> > > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > >> > > > > > > > >> > > > But I would like to make discussion happen here on dev ML. > > > > >> > > > > > > > >> > > > Thanks > > > > >> > > > T > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > -- > > > > >> > > Elliotte Rusty Harold > > > > >> > > elh...@ibiblio.org > > > > >> > > > > > > >> > > > > > > - > > > > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > >> > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >> > > > > > > >> > > > > > > >> > > > > >> > > - > > > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > >> > > > > >> > > > > > > > > > >
Re: [DISCUSS] Quo Vadis Maven Site
re your site could be pretty much "transported" > > to > > > >> use > > > >> > jbake-maven-plugin instead of maven-site-plugin. > > > >> > > > > >> > I am aware of the long history of the Maven project, being here > > since > > > >> 2006, > > > >> > but still... > > > >> > I don't think what I propose is "build a lamborghini instead of a > > ford > > > >> > pickup". > > > >> > > > > >> > I see it more like "let's replace the ford battery, but given how > > old > > > it > > > >> > is, we have > > > >> > only aftermarket parts for it". > > > >> > > > > >> > Now that you have shown your site, let me try to de-site it, just > as > > > an > > > >> > experiment... > > > >> > as I never tried this before > > > >> > > > > >> > Will do it here > > > >> > https://github.com/cstamas/jaxen > > > >> > > > > >> > Thanks > > > >> > T > > > >> > > > > >> > On Wed, Nov 16, 2022 at 1:08 PM Elliotte Rusty Harold < > > > >> elh...@ibiblio.org> > > > >> > wrote: > > > >> > > > > >> > > I like some parts of this. I don't agree with others. I agree > that > > > >> > > maven site isn't competitive with other site builders, but that > > was > > > >> > > never really its purpose. I think it's OK for generating a site > > > for a > > > >> > > Maven project. I wouldn't expect it to be used for anything > else. > > > As a > > > >> > > maintainer of one such site <http://www.cafeconleche.org/jaxen/ > > > > it > > > >> > > would be very inconvenient for me if this plugin disappeared or > > > >> > > changed in a major way. > > > >> > > > > > >> > > The old site design just works. We don't need so-called modern, > > > >> > > responsive sites. For our purposes — documenting code — the 20 > > year > > > >> > > old classic HTML we use is just fine. In fact, I'd say it's > > superior > > > >> > > to modern designs as implemented in practice. > > > >> > > > > > >> > > I do wish Maven hadn't gone its own way with NIH components like > > > >> > > Plexus, APT, and Doxia that are all essentially used today by > > maven > > > >> > > and no one else. However in fairness this all happened twenty > > years > > > >> > > ago when alternatives that have become de facto standards was > not > > > >> > > obviously better or simply did not exist. We should modernize > our > > > >> > > dependencies where possible, but I don't think a rewrite is > worth > > > the > > > >> > > effort and I would oppose anything that broke existing sites, > > links, > > > >> > > and workflows. > > > >> > > > > > >> > > When counting "wasted engineering hours spent on it", these are > at > > > >> > > least a couple of orders of magnitude lower than would be spent > > on a > > > >> > > radical replacement of the sort being proposed. It's like > > proposing > > > we > > > >> > > build a new Lamborghini to save the money we spend on oil > changes > > > for > > > >> > > our 2002 Ford pickup. Of course this is open source, so if > anyone > > > has > > > >> > > the time and money to spend on an alternative site plugin that > > > >> > > scratches their itch, by all means they can do it. However this > > > should > > > >> > > be a new plugin projects can adopt or not at a time that's > > > convenient > > > >> > > for them. It should not replace the existing plugin so many > > projects > > > >> > > already use. > > > >> > > > > > >> > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák < > > > ta...@cservenak.net> > > > >> > > wrote: > > > >> > > > > > > >> > > > Howdy, > > > >> > > > > > > >> > > > This is really just a brainstorming thread I'd like to spin, > > > >> regarding > > > >> > > > Maven Site stuff. > > > >> > > > > > > >> > > > Again, the message is in wiki > > > >> > > > > > > >> > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > >> > > > > > > >> > > > But I would like to make discussion happen here on dev ML. > > > >> > > > > > > >> > > > Thanks > > > >> > > > T > > > >> > > > > > >> > > > > > >> > > > > > >> > > -- > > > >> > > Elliotte Rusty Harold > > > >> > > elh...@ibiblio.org > > > >> > > > > > >> > > > > > - > > > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > >> > > For additional commands, e-mail: dev-h...@maven.apache.org > > > >> > > > > > >> > > > > > >> > > > >> > - > > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > >> > > > >> > > > > > >
Re: [DISCUSS] Quo Vadis Maven Site
iotte Rusty Harold < > > >> elh...@ibiblio.org> > > >> > wrote: > > >> > > > >> > > I like some parts of this. I don't agree with others. I agree that > > >> > > maven site isn't competitive with other site builders, but that > was > > >> > > never really its purpose. I think it's OK for generating a site > > for a > > >> > > Maven project. I wouldn't expect it to be used for anything else. > > As a > > >> > > maintainer of one such site <http://www.cafeconleche.org/jaxen/> > it > > >> > > would be very inconvenient for me if this plugin disappeared or > > >> > > changed in a major way. > > >> > > > > >> > > The old site design just works. We don't need so-called modern, > > >> > > responsive sites. For our purposes — documenting code — the 20 > year > > >> > > old classic HTML we use is just fine. In fact, I'd say it's > superior > > >> > > to modern designs as implemented in practice. > > >> > > > > >> > > I do wish Maven hadn't gone its own way with NIH components like > > >> > > Plexus, APT, and Doxia that are all essentially used today by > maven > > >> > > and no one else. However in fairness this all happened twenty > years > > >> > > ago when alternatives that have become de facto standards was not > > >> > > obviously better or simply did not exist. We should modernize our > > >> > > dependencies where possible, but I don't think a rewrite is worth > > the > > >> > > effort and I would oppose anything that broke existing sites, > links, > > >> > > and workflows. > > >> > > > > >> > > When counting "wasted engineering hours spent on it", these are at > > >> > > least a couple of orders of magnitude lower than would be spent > on a > > >> > > radical replacement of the sort being proposed. It's like > proposing > > we > > >> > > build a new Lamborghini to save the money we spend on oil changes > > for > > >> > > our 2002 Ford pickup. Of course this is open source, so if anyone > > has > > >> > > the time and money to spend on an alternative site plugin that > > >> > > scratches their itch, by all means they can do it. However this > > should > > >> > > be a new plugin projects can adopt or not at a time that's > > convenient > > >> > > for them. It should not replace the existing plugin so many > projects > > >> > > already use. > > >> > > > > >> > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák < > > ta...@cservenak.net> > > >> > > wrote: > > >> > > > > > >> > > > Howdy, > > >> > > > > > >> > > > This is really just a brainstorming thread I'd like to spin, > > >> regarding > > >> > > > Maven Site stuff. > > >> > > > > > >> > > > Again, the message is in wiki > > >> > > > > > >> > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > >> > > > > > >> > > > But I would like to make discussion happen here on dev ML. > > >> > > > > > >> > > > Thanks > > >> > > > T > > >> > > > > >> > > > > >> > > > > >> > > -- > > >> > > Elliotte Rusty Harold > > >> > > elh...@ibiblio.org > > >> > > > > >> > > > > - > > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >> > > For additional commands, e-mail: dev-h...@maven.apache.org > > >> > > > > >> > > > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > >> > > >> > > >
Re: [DISCUSS] Quo Vadis Maven Site
I wouldn't expect it to be used for anything else. > As a > > >> > > maintainer of one such site <http://www.cafeconleche.org/jaxen/> > it > > >> > > would be very inconvenient for me if this plugin disappeared or > > >> > > changed in a major way. > > >> > > > > >> > > The old site design just works. We don't need so-called modern, > > >> > > responsive sites. For our purposes — documenting code — the 20 > year > > >> > > old classic HTML we use is just fine. In fact, I'd say it's > superior > > >> > > to modern designs as implemented in practice. > > >> > > > > >> > > I do wish Maven hadn't gone its own way with NIH components like > > >> > > Plexus, APT, and Doxia that are all essentially used today by > maven > > >> > > and no one else. However in fairness this all happened twenty > years > > >> > > ago when alternatives that have become de facto standards was not > > >> > > obviously better or simply did not exist. We should modernize our > > >> > > dependencies where possible, but I don't think a rewrite is worth > the > > >> > > effort and I would oppose anything that broke existing sites, > links, > > >> > > and workflows. > > >> > > > > >> > > When counting "wasted engineering hours spent on it", these are at > > >> > > least a couple of orders of magnitude lower than would be spent > on a > > >> > > radical replacement of the sort being proposed. It's like > proposing we > > >> > > build a new Lamborghini to save the money we spend on oil changes > for > > >> > > our 2002 Ford pickup. Of course this is open source, so if anyone > has > > >> > > the time and money to spend on an alternative site plugin that > > >> > > scratches their itch, by all means they can do it. However this > should > > >> > > be a new plugin projects can adopt or not at a time that's > convenient > > >> > > for them. It should not replace the existing plugin so many > projects > > >> > > already use. > > >> > > > > >> > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák < > ta...@cservenak.net> > > >> > > wrote: > > >> > > > > > >> > > > Howdy, > > >> > > > > > >> > > > This is really just a brainstorming thread I'd like to spin, > > >> regarding > > >> > > > Maven Site stuff. > > >> > > > > > >> > > > Again, the message is in wiki > > >> > > > > > >> > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > >> > > > > > >> > > > But I would like to make discussion happen here on dev ML. > > >> > > > > > >> > > > Thanks > > >> > > > T > > >> > > > > >> > > > > >> > > > > >> > > -- > > >> > > Elliotte Rusty Harold > > >> > > elh...@ibiblio.org > > >> > > > > >> > > > - > > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >> > > For additional commands, e-mail: dev-h...@maven.apache.org > > >> > > > > >> > > > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > >> > > >> > > > > -- > 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: [DISCUSS] Quo Vadis Maven Site
do wish Maven hadn't gone its own way with NIH components like > >> > > Plexus, APT, and Doxia that are all essentially used today by maven > >> > > and no one else. However in fairness this all happened twenty years > >> > > ago when alternatives that have become de facto standards was not > >> > > obviously better or simply did not exist. We should modernize our > >> > > dependencies where possible, but I don't think a rewrite is worth > the > >> > > effort and I would oppose anything that broke existing sites, links, > >> > > and workflows. > >> > > > >> > > When counting "wasted engineering hours spent on it", these are at > >> > > least a couple of orders of magnitude lower than would be spent on a > >> > > radical replacement of the sort being proposed. It's like proposing > we > >> > > build a new Lamborghini to save the money we spend on oil changes > for > >> > > our 2002 Ford pickup. Of course this is open source, so if anyone > has > >> > > the time and money to spend on an alternative site plugin that > >> > > scratches their itch, by all means they can do it. However this > should > >> > > be a new plugin projects can adopt or not at a time that's > convenient > >> > > for them. It should not replace the existing plugin so many projects > >> > > already use. > >> > > > >> > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák < > ta...@cservenak.net> > >> > > wrote: > >> > > > > >> > > > Howdy, > >> > > > > >> > > > This is really just a brainstorming thread I'd like to spin, > >> regarding > >> > > > Maven Site stuff. > >> > > > > >> > > > Again, the message is in wiki > >> > > > > >> https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > >> > > > > >> > > > But I would like to make discussion happen here on dev ML. > >> > > > > >> > > > Thanks > >> > > > T > >> > > > >> > > > >> > > > >> > > -- > >> > > Elliotte Rusty Harold > >> > > elh...@ibiblio.org > >> > > > >> > > > - > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > >> > > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> >
Re: [DISCUSS] Quo Vadis Maven Site
> > ago when alternatives that have become de facto standards was not > >> > > obviously better or simply did not exist. We should modernize our > >> > > dependencies where possible, but I don't think a rewrite is worth the > >> > > effort and I would oppose anything that broke existing sites, links, > >> > > and workflows. > >> > > > >> > > When counting "wasted engineering hours spent on it", these are at > >> > > least a couple of orders of magnitude lower than would be spent on a > >> > > radical replacement of the sort being proposed. It's like proposing we > >> > > build a new Lamborghini to save the money we spend on oil changes for > >> > > our 2002 Ford pickup. Of course this is open source, so if anyone has > >> > > the time and money to spend on an alternative site plugin that > >> > > scratches their itch, by all means they can do it. However this should > >> > > be a new plugin projects can adopt or not at a time that's convenient > >> > > for them. It should not replace the existing plugin so many projects > >> > > already use. > >> > > > >> > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák > >> > > wrote: > >> > > > > >> > > > Howdy, > >> > > > > >> > > > This is really just a brainstorming thread I'd like to spin, > >> regarding > >> > > > Maven Site stuff. > >> > > > > >> > > > Again, the message is in wiki > >> > > > > >> https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > >> > > > > >> > > > But I would like to make discussion happen here on dev ML. > >> > > > > >> > > > Thanks > >> > > > T > >> > > > >> > > > >> > > > >> > > -- > >> > > Elliotte Rusty Harold > >> > > elh...@ibiblio.org > >> > > > >> > > - > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > >> > > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> -- 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: [DISCUSS] Quo Vadis Maven Site
Howdy, So, here is "stage No1" that pretty much already delivers what existing site had: https://github.com/jaxen-xpath/jaxen/pull/145 Point is: before, it was two runs to build and site (and took a total of 2 minutes), while now it is 10 seconds more than "build artifacts" (35 sec). To build it: mvn clean install -P site Just to clear up: I am NOT promoting JBake nor any other static site generator, this was just an exercise to see if we can do simple maven sites without site plugin. HTH T On Wed, Nov 16, 2022 at 7:28 PM Tamás Cservenák wrote: > Howdy, > > I am pretty much convinced it can do all that site is able to do. > Let's see the jaxen conversion result once done. > > Also, this would not push anything, I always wrote (at least intended to) > "static site tool is left at discretion of user", I just mentioned JBake as > something that can buy out functionality of the maven-site-plugin, that's > all. > > T > > On Wed, Nov 16, 2022 at 7:25 PM Benjamin Marwell > wrote: > >> Please do NOT consider jbake. >> We (shiro team) ported the page to jbake, and it is really a mess. >> Many things are not supported which can easily be done in other static >> site generators. >> There is absolutely no progress. No java.time support. JSON/YAML >> support is broken and needs a lot of workarounds. >> >> Look at the repo and build it yourself -- the amount of javadoc will >> take very long to process. >> https://github.com/apache/shiro-site >> >> >> Am Mi., 16. Nov. 2022 um 13:21 Uhr schrieb Tamás Cservenák >> : >> > >> > Howdy, >> > >> > I am pretty much sure your site could be pretty much "transported" to >> use >> > jbake-maven-plugin instead of maven-site-plugin. >> > >> > I am aware of the long history of the Maven project, being here since >> 2006, >> > but still... >> > I don't think what I propose is "build a lamborghini instead of a ford >> > pickup". >> > >> > I see it more like "let's replace the ford battery, but given how old it >> > is, we have >> > only aftermarket parts for it". >> > >> > Now that you have shown your site, let me try to de-site it, just as an >> > experiment... >> > as I never tried this before >> > >> > Will do it here >> > https://github.com/cstamas/jaxen >> > >> > Thanks >> > T >> > >> > On Wed, Nov 16, 2022 at 1:08 PM Elliotte Rusty Harold < >> elh...@ibiblio.org> >> > wrote: >> > >> > > I like some parts of this. I don't agree with others. I agree that >> > > maven site isn't competitive with other site builders, but that was >> > > never really its purpose. I think it's OK for generating a site for a >> > > Maven project. I wouldn't expect it to be used for anything else. As a >> > > maintainer of one such site <http://www.cafeconleche.org/jaxen/> it >> > > would be very inconvenient for me if this plugin disappeared or >> > > changed in a major way. >> > > >> > > The old site design just works. We don't need so-called modern, >> > > responsive sites. For our purposes — documenting code — the 20 year >> > > old classic HTML we use is just fine. In fact, I'd say it's superior >> > > to modern designs as implemented in practice. >> > > >> > > I do wish Maven hadn't gone its own way with NIH components like >> > > Plexus, APT, and Doxia that are all essentially used today by maven >> > > and no one else. However in fairness this all happened twenty years >> > > ago when alternatives that have become de facto standards was not >> > > obviously better or simply did not exist. We should modernize our >> > > dependencies where possible, but I don't think a rewrite is worth the >> > > effort and I would oppose anything that broke existing sites, links, >> > > and workflows. >> > > >> > > When counting "wasted engineering hours spent on it", these are at >> > > least a couple of orders of magnitude lower than would be spent on a >> > > radical replacement of the sort being proposed. It's like proposing we >> > > build a new Lamborghini to save the money we spend on oil changes for >> > > our 2002 Ford pickup. Of course this is open source, so if anyone h
Re: [DISCUSS] Quo Vadis Maven Site
Howdy, I am pretty much convinced it can do all that site is able to do. Let's see the jaxen conversion result once done. Also, this would not push anything, I always wrote (at least intended to) "static site tool is left at discretion of user", I just mentioned JBake as something that can buy out functionality of the maven-site-plugin, that's all. T On Wed, Nov 16, 2022 at 7:25 PM Benjamin Marwell wrote: > Please do NOT consider jbake. > We (shiro team) ported the page to jbake, and it is really a mess. > Many things are not supported which can easily be done in other static > site generators. > There is absolutely no progress. No java.time support. JSON/YAML > support is broken and needs a lot of workarounds. > > Look at the repo and build it yourself -- the amount of javadoc will > take very long to process. > https://github.com/apache/shiro-site > > > Am Mi., 16. Nov. 2022 um 13:21 Uhr schrieb Tamás Cservenák > : > > > > Howdy, > > > > I am pretty much sure your site could be pretty much "transported" to use > > jbake-maven-plugin instead of maven-site-plugin. > > > > I am aware of the long history of the Maven project, being here since > 2006, > > but still... > > I don't think what I propose is "build a lamborghini instead of a ford > > pickup". > > > > I see it more like "let's replace the ford battery, but given how old it > > is, we have > > only aftermarket parts for it". > > > > Now that you have shown your site, let me try to de-site it, just as an > > experiment... > > as I never tried this before > > > > Will do it here > > https://github.com/cstamas/jaxen > > > > Thanks > > T > > > > On Wed, Nov 16, 2022 at 1:08 PM Elliotte Rusty Harold < > elh...@ibiblio.org> > > wrote: > > > > > I like some parts of this. I don't agree with others. I agree that > > > maven site isn't competitive with other site builders, but that was > > > never really its purpose. I think it's OK for generating a site for a > > > Maven project. I wouldn't expect it to be used for anything else. As a > > > maintainer of one such site <http://www.cafeconleche.org/jaxen/> it > > > would be very inconvenient for me if this plugin disappeared or > > > changed in a major way. > > > > > > The old site design just works. We don't need so-called modern, > > > responsive sites. For our purposes — documenting code — the 20 year > > > old classic HTML we use is just fine. In fact, I'd say it's superior > > > to modern designs as implemented in practice. > > > > > > I do wish Maven hadn't gone its own way with NIH components like > > > Plexus, APT, and Doxia that are all essentially used today by maven > > > and no one else. However in fairness this all happened twenty years > > > ago when alternatives that have become de facto standards was not > > > obviously better or simply did not exist. We should modernize our > > > dependencies where possible, but I don't think a rewrite is worth the > > > effort and I would oppose anything that broke existing sites, links, > > > and workflows. > > > > > > When counting "wasted engineering hours spent on it", these are at > > > least a couple of orders of magnitude lower than would be spent on a > > > radical replacement of the sort being proposed. It's like proposing we > > > build a new Lamborghini to save the money we spend on oil changes for > > > our 2002 Ford pickup. Of course this is open source, so if anyone has > > > the time and money to spend on an alternative site plugin that > > > scratches their itch, by all means they can do it. However this should > > > be a new plugin projects can adopt or not at a time that's convenient > > > for them. It should not replace the existing plugin so many projects > > > already use. > > > > > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák > > > wrote: > > > > > > > > Howdy, > > > > > > > > This is really just a brainstorming thread I'd like to spin, > regarding > > > > Maven Site stuff. > > > > > > > > Again, the message is in wiki > > > > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > > > > > But I would like to make discussion happen here on dev ML. > > > > > > > > Thanks > > > > T > > > > > > > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Quo Vadis Maven Site
Please do NOT consider jbake. We (shiro team) ported the page to jbake, and it is really a mess. Many things are not supported which can easily be done in other static site generators. There is absolutely no progress. No java.time support. JSON/YAML support is broken and needs a lot of workarounds. Look at the repo and build it yourself -- the amount of javadoc will take very long to process. https://github.com/apache/shiro-site Am Mi., 16. Nov. 2022 um 13:21 Uhr schrieb Tamás Cservenák : > > Howdy, > > I am pretty much sure your site could be pretty much "transported" to use > jbake-maven-plugin instead of maven-site-plugin. > > I am aware of the long history of the Maven project, being here since 2006, > but still... > I don't think what I propose is "build a lamborghini instead of a ford > pickup". > > I see it more like "let's replace the ford battery, but given how old it > is, we have > only aftermarket parts for it". > > Now that you have shown your site, let me try to de-site it, just as an > experiment... > as I never tried this before > > Will do it here > https://github.com/cstamas/jaxen > > Thanks > T > > On Wed, Nov 16, 2022 at 1:08 PM Elliotte Rusty Harold > wrote: > > > I like some parts of this. I don't agree with others. I agree that > > maven site isn't competitive with other site builders, but that was > > never really its purpose. I think it's OK for generating a site for a > > Maven project. I wouldn't expect it to be used for anything else. As a > > maintainer of one such site <http://www.cafeconleche.org/jaxen/> it > > would be very inconvenient for me if this plugin disappeared or > > changed in a major way. > > > > The old site design just works. We don't need so-called modern, > > responsive sites. For our purposes — documenting code — the 20 year > > old classic HTML we use is just fine. In fact, I'd say it's superior > > to modern designs as implemented in practice. > > > > I do wish Maven hadn't gone its own way with NIH components like > > Plexus, APT, and Doxia that are all essentially used today by maven > > and no one else. However in fairness this all happened twenty years > > ago when alternatives that have become de facto standards was not > > obviously better or simply did not exist. We should modernize our > > dependencies where possible, but I don't think a rewrite is worth the > > effort and I would oppose anything that broke existing sites, links, > > and workflows. > > > > When counting "wasted engineering hours spent on it", these are at > > least a couple of orders of magnitude lower than would be spent on a > > radical replacement of the sort being proposed. It's like proposing we > > build a new Lamborghini to save the money we spend on oil changes for > > our 2002 Ford pickup. Of course this is open source, so if anyone has > > the time and money to spend on an alternative site plugin that > > scratches their itch, by all means they can do it. However this should > > be a new plugin projects can adopt or not at a time that's convenient > > for them. It should not replace the existing plugin so many projects > > already use. > > > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák > > wrote: > > > > > > Howdy, > > > > > > This is really just a brainstorming thread I'd like to spin, regarding > > > Maven Site stuff. > > > > > > Again, the message is in wiki > > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > > > But I would like to make discussion happen here on dev ML. > > > > > > Thanks > > > T > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Quo Vadis Maven Site
Howdy, I am pretty much sure your site could be pretty much "transported" to use jbake-maven-plugin instead of maven-site-plugin. I am aware of the long history of the Maven project, being here since 2006, but still... I don't think what I propose is "build a lamborghini instead of a ford pickup". I see it more like "let's replace the ford battery, but given how old it is, we have only aftermarket parts for it". Now that you have shown your site, let me try to de-site it, just as an experiment... as I never tried this before Will do it here https://github.com/cstamas/jaxen Thanks T On Wed, Nov 16, 2022 at 1:08 PM Elliotte Rusty Harold wrote: > I like some parts of this. I don't agree with others. I agree that > maven site isn't competitive with other site builders, but that was > never really its purpose. I think it's OK for generating a site for a > Maven project. I wouldn't expect it to be used for anything else. As a > maintainer of one such site <http://www.cafeconleche.org/jaxen/> it > would be very inconvenient for me if this plugin disappeared or > changed in a major way. > > The old site design just works. We don't need so-called modern, > responsive sites. For our purposes — documenting code — the 20 year > old classic HTML we use is just fine. In fact, I'd say it's superior > to modern designs as implemented in practice. > > I do wish Maven hadn't gone its own way with NIH components like > Plexus, APT, and Doxia that are all essentially used today by maven > and no one else. However in fairness this all happened twenty years > ago when alternatives that have become de facto standards was not > obviously better or simply did not exist. We should modernize our > dependencies where possible, but I don't think a rewrite is worth the > effort and I would oppose anything that broke existing sites, links, > and workflows. > > When counting "wasted engineering hours spent on it", these are at > least a couple of orders of magnitude lower than would be spent on a > radical replacement of the sort being proposed. It's like proposing we > build a new Lamborghini to save the money we spend on oil changes for > our 2002 Ford pickup. Of course this is open source, so if anyone has > the time and money to spend on an alternative site plugin that > scratches their itch, by all means they can do it. However this should > be a new plugin projects can adopt or not at a time that's convenient > for them. It should not replace the existing plugin so many projects > already use. > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák > wrote: > > > > Howdy, > > > > This is really just a brainstorming thread I'd like to spin, regarding > > Maven Site stuff. > > > > Again, the message is in wiki > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > But I would like to make discussion happen here on dev ML. > > > > Thanks > > T > > > > -- > 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: [DISCUSS] Quo Vadis Maven Site
I like some parts of this. I don't agree with others. I agree that maven site isn't competitive with other site builders, but that was never really its purpose. I think it's OK for generating a site for a Maven project. I wouldn't expect it to be used for anything else. As a maintainer of one such site <http://www.cafeconleche.org/jaxen/> it would be very inconvenient for me if this plugin disappeared or changed in a major way. The old site design just works. We don't need so-called modern, responsive sites. For our purposes — documenting code — the 20 year old classic HTML we use is just fine. In fact, I'd say it's superior to modern designs as implemented in practice. I do wish Maven hadn't gone its own way with NIH components like Plexus, APT, and Doxia that are all essentially used today by maven and no one else. However in fairness this all happened twenty years ago when alternatives that have become de facto standards was not obviously better or simply did not exist. We should modernize our dependencies where possible, but I don't think a rewrite is worth the effort and I would oppose anything that broke existing sites, links, and workflows. When counting "wasted engineering hours spent on it", these are at least a couple of orders of magnitude lower than would be spent on a radical replacement of the sort being proposed. It's like proposing we build a new Lamborghini to save the money we spend on oil changes for our 2002 Ford pickup. Of course this is open source, so if anyone has the time and money to spend on an alternative site plugin that scratches their itch, by all means they can do it. However this should be a new plugin projects can adopt or not at a time that's convenient for them. It should not replace the existing plugin so many projects already use. On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák wrote: > > Howdy, > > This is really just a brainstorming thread I'd like to spin, regarding > Maven Site stuff. > > Again, the message is in wiki > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > But I would like to make discussion happen here on dev ML. > > Thanks > T -- 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
[DISCUSS] Quo Vadis Maven Site
Howdy, This is really just a brainstorming thread I'd like to spin, regarding Maven Site stuff. Again, the message is in wiki https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site But I would like to make discussion happen here on dev ML. Thanks T
