[ANN] Apache Maven Doxia Sitetools 2.0.0 released
The Apache Maven team is pleased to announce the release of the Apache
Maven Doxia Sitetools, version 2.0.0
https://maven.apache.org/doxia/doxia-sitetools/
Release Notes - Maven Doxia Sitetools - Version 2.0.0
** Bug
* [DOXIASITETOOLS-251] - Plexus to Sisu migration misses Singleton
annotation
* [DOXIASITETOOLS-263] - Don't inject a default decoration model
when inheritance is at play
* [DOXIASITETOOLS-266] - Don't create anchors behind the user's back
* [DOXIASITETOOLS-299] - Site descriptor interpolation does not
properly escape reserved XML chars
* [DOXIASITETOOLS-305] - Removal of 0-byte site descriptors from
the local repo does not put remote repos into consideration
** New Feature
* [DOXIASITETOOLS-238] - Pass input file name as reference to parser
* [DOXIASITETOOLS-291] - Add timezone field to site descriptor
PublishDate object and pass onto Velocity tools context
* [DOXIASITETOOLS-324] - Allow configuration of parser per markup
** Improvement
* [DOXIASITETOOLS-253] - Clarify "border", "width" and "height" for
Banner and LinkItem
* [DOXIASITETOOLS-257] - Require a skin if a site descriptor
(site.xml) has been provided
* [DOXIASITETOOLS-268] - Don't open version resource file on every
call to render
* [DOXIASITETOOLS-271] - Overhaul locale support (make Locale#ROOT
instead of Locale#ENGLISH default and use full locale)
* [DOXIASITETOOLS-278] - Remove menu items link in the sidebar to
submodule that do not generate any site in the same build
* [DOXIASITETOOLS-293] - Remove menu items link in the sidebar to
submodule that are not present in the same build (reactor)
* [DOXIASITETOOLS-294] - Replace legacy artifact resolution with
Maven Resolver
* [DOXIASITETOOLS-300] - Don't populate Velocity context with XML
entities
* [DOXIASITETOOLS-301] - Automatically remove the 0-byte site
descriptors from the local repo
* [DOXIASITETOOLS-302] - Harmonize path separator in
DocumentRenderingContext
* [DOXIASITETOOLS-332] - Create anchors for indexable entries
automatically
* [DOXIASITETOOLS-334] - Pass project relative source path to
Parser.parse(...) as reference argument
* [DOXIASITETOOLS-336] - Make SiteRenderingContext#siteDirectories
editable aware
* [DOXIASITETOOLS-340] - Rearrange title order in Velocity context
* [DOXIASITETOOLS-344] - Improve performance of case-sensitive file
key checking
* [DOXIASITETOOLS-348] - Extend site descriptor to enforce a parent
* [DOXIASITETOOLS-349] - Remove plexus-component-metadata plugin
** Wish
* [DOXIASITETOOLS-174] - rename site.xml root tag from "project" to
"site"
** Task
* [DOXIASITETOOLS-156] - Fail if deprecated ${reports},
${parentProject} or ${modules} is found
* [DOXIASITETOOLS-167] - Replace deprecated Maven 2
MavenProjectBuilder with Maven 3 ProjectBuilder
* [DOXIASITETOOLS-239] - Remove Doxia Sitetools Doc Renderer
* [DOXIASITETOOLS-241] - Replace Plexus Container Default with Sisu
Plexus Shim
* [DOXIASITETOOLS-242] - Remove all deprecated code
* [DOXIASITETOOLS-244] - Clean up exceptions and log messages
* [DOXIASITETOOLS-245] - Upgrade to Java 8
* [DOXIASITETOOLS-247] - Replace Plexus Annotations with Java
Inject along with JUnit 5
* [DOXIASITETOOLS-254] - Clarify inconsistencies in Doxia site model
* [DOXIASITETOOLS-258] - Don't inject bannerLeft is none is set
* [DOXIASITETOOLS-259] - Deprecate Google-related site descriptor
properties
* [DOXIASITETOOLS-264] - Remove usage of default skin during testing
* [DOXIASITETOOLS-265] - Drop MiscVerifier
* [DOXIASITETOOLS-270] - Remove internal (pseudo) skin and use
Maven Fluido Skin by default
* [DOXIASITETOOLS-272] - Remove support for Maven 1.x style site
directory layout
* [DOXIASITETOOLS-281] - Deprecate SiteTool#getParentProject() in
favor of MavenProject#getParent()
* [DOXIASITETOOLS-282] - Deprecate support for Maven 1.x style site
directory layout
* [DOXIASITETOOLS-285] - Deprecate
SiteRenderingContext#defaultWindowTitle in favor of
SiteRenderingContext#defaultTitle
* [DOXIASITETOOLS-287] - Remove Google-related site descriptor
properties
* [DOXIASITETOOLS-289] - Remove SiteTool#getParentProject()
* [DOXIASITETOOLS-290] - Remove SiteRenderingContext#defaultWindowTitle
* [DOXIASITETOOLS-295] - Rename o.a.m.doxia.siterenderer.Renderer
to o.a.m.doxia.siterenderer.SiteRenderer
* [DOXIASITETOOLS-296] - Rename
o.a.m.doxia.siterenderer.RenderingContext to
o.a.m.doxia.siterenderer.DocumentRenderingContext
* [DOXIASITETOOLS-298] - Rename doxia-decoration-model to
doxia-site-model
* [DOXIASITETOOLS-303] - Implement workaround for
MNG-7758/MRESOLVER-335
* [DOXIASITETOOLS-306] - Clean up and simplify thrown exceptions
* [DOXIASITETOOLS-309] - Add resource bundle property "External
Links" to site-renderer.properties
* [DOXIASITETOOLS-310] - Add res
[RESULT] [VOTE] Release Apache Maven Doxia Sitetools version 2.0.0
Hi, The vote has passed with the following result: +1: Slawomir Jaranowski, Tamás Cservenák, Herve Boutemy, Sylwester Lachiewicz PMC quorum: reached I will promote the artifacts to the central repo, the source release ZIP file and add this release the board report. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Merge ITs in maven
Yes, that's definitely not a problem. I was simply stating that merging the branch is not sufficient and that the real integration needs to be done. Le mer. 9 oct. 2024 à 09:21, Xeno Amess a écrit : > RAT checks has a excluding rule, if we really wanna so we can just exclude > that folder anyway... > > Guillaume Nodet 于2024年10月9日周三 15:11写道： > > > I just pushed a branch with the results: > >https://github.com/gnodet/maven/tree/merge-its > > > > This is just the raw output of the recipe. The ITs are not integrated > into > > the build, which will even fail due to RAT checks and maybe other > reasons. > > > > Le mer. 9 oct. 2024 à 08:35, Herve Boutemy a > écrit : > > > > > I understand how it adds complexity > > > > > > AFAIK, the interest of having a separate project of core ITs is to > clear > > > state the Maven core version range for each test, to clearly document > > when > > > things were introduced / broken / fixed and even be able to run HEAD > ITs > > > against a past release > > > > > > is it the only reason? I don't know, it's the key aspect I understood > 15 > > > years ago when it was done and I was too noob to really grasp every > > detail > > > :) > > > > > > does this really deserve the complexity it creates? > > > I don't know > > > > > > I also need to check the Git merge recipe, to see how the result would > be > > > ok to me: do you have a personal fork somewhere so we can review > without > > > running the command ourselves? > > > > > > Regards, > > > > > > Hervé > > > > > > On 2024/10/08 06:36:19 Guillaume Nodet wrote: > > > > I'd like to discuss merging ITs into maven core repository. > > > > The ITs have already been splitted some time ago between the 3.x > branch > > > and > > > > master for testing Maven master. But I don't really see a good > reason > > to > > > > keep the repositories separated, this makes things more complicated > > when > > > > modifying maven code and adding ITs. > > > > > > > > The following script allow merging the two repositories while keeping > > > both > > > > histories: > > > > > > > > > > > > brew install git-filter-repo > > > > > > > > git clone https://github.com/apache/maven > > > > > > > > git clone https://github.com/apache/maven-integration-testing > > > > > > > > (cd maven-integration-testing && \ > > > > > > > > git filter-repo --to-subdirectory-filter its) > > > > > > > > (cd maven && \ > > > > > > > > git remote add its ../maven-integration-testing && \ > > > > > > > > git fetch its --no-tags && \ > > > > > > > > EDITOR=true git merge --allow-unrelated-histories its/master && \ > > > > > > > > git remote remove its) > > > > > > > > The next step would be to actually include them in a profile and > update > > > the > > > > github workflow. > > > > I think they could be refactored to: > > > > * first perform a full run on Ubuntu + latest LTS JDK: > > > > - restore cache > > > > - checkout > > > > - build with no tests > > > > - run IT bootstrap (to prime local repo) > > > > - save cache > > > > - build again with tests and ITs > > > > * if this first run succeeds, do the same on other platforms / jdks > > > > > > > > The cache is important to add imho. It seems lately, GH runners have > > > often > > > > problems downloading from maven central, so that would help a lot > > > > increasing the stability. So using > > > > https://github.com/marketplace/actions/maven-cache or a similar > action > > > > would be handy imho. > > > > > > > > We should also upload nightlies from GH. > > > > And automate the releases as much as possible > > > > > > > > -- > > > > > > > > Guillaume Nodet > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > -- > > > > Guillaume Nodet > > > -- Guillaume Nodet
Re: [DISCUSS] Merge ITs in maven
I just pushed a branch with the results: https://github.com/gnodet/maven/tree/merge-its This is just the raw output of the recipe. The ITs are not integrated into the build, which will even fail due to RAT checks and maybe other reasons. Le mer. 9 oct. 2024 à 08:35, Herve Boutemy a écrit : > I understand how it adds complexity > > AFAIK, the interest of having a separate project of core ITs is to clear > state the Maven core version range for each test, to clearly document when > things were introduced / broken / fixed and even be able to run HEAD ITs > against a past release > > is it the only reason? I don't know, it's the key aspect I understood 15 > years ago when it was done and I was too noob to really grasp every detail > :) > > does this really deserve the complexity it creates? > I don't know > > I also need to check the Git merge recipe, to see how the result would be > ok to me: do you have a personal fork somewhere so we can review without > running the command ourselves? > > Regards, > > Hervé > > On 2024/10/08 06:36:19 Guillaume Nodet wrote: > > I'd like to discuss merging ITs into maven core repository. > > The ITs have already been splitted some time ago between the 3.x branch > and > > master for testing Maven master. But I don't really see a good reason to > > keep the repositories separated, this makes things more complicated when > > modifying maven code and adding ITs. > > > > The following script allow merging the two repositories while keeping > both > > histories: > > > > > > brew install git-filter-repo > > > > git clone https://github.com/apache/maven > > > > git clone https://github.com/apache/maven-integration-testing > > > > (cd maven-integration-testing && \ > > > > git filter-repo --to-subdirectory-filter its) > > > > (cd maven && \ > > > > git remote add its ../maven-integration-testing && \ > > > > git fetch its --no-tags && \ > > > > EDITOR=true git merge --allow-unrelated-histories its/master && \ > > > > git remote remove its) > > > > The next step would be to actually include them in a profile and update > the > > github workflow. > > I think they could be refactored to: > > * first perform a full run on Ubuntu + latest LTS JDK: > > - restore cache > > - checkout > > - build with no tests > > - run IT bootstrap (to prime local repo) > > - save cache > > - build again with tests and ITs > > * if this first run succeeds, do the same on other platforms / jdks > > > > The cache is important to add imho. It seems lately, GH runners have > often > > problems downloading from maven central, so that would help a lot > > increasing the stability. So using > > https://github.com/marketplace/actions/maven-cache or a similar action > > would be handy imho. > > > > We should also upload nightlies from GH. > > And automate the releases as much as possible > > > > -- > > > > Guillaume Nodet > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Guillaume Nodet
Re: [DISCUSS] Merge ITs in maven
RAT checks has a excluding rule, if we really wanna so we can just exclude that folder anyway... Guillaume Nodet 于2024年10月9日周三 15:11写道： > I just pushed a branch with the results: >https://github.com/gnodet/maven/tree/merge-its > > This is just the raw output of the recipe. The ITs are not integrated into > the build, which will even fail due to RAT checks and maybe other reasons. > > Le mer. 9 oct. 2024 à 08:35, Herve Boutemy a écrit : > > > I understand how it adds complexity > > > > AFAIK, the interest of having a separate project of core ITs is to clear > > state the Maven core version range for each test, to clearly document > when > > things were introduced / broken / fixed and even be able to run HEAD ITs > > against a past release > > > > is it the only reason? I don't know, it's the key aspect I understood 15 > > years ago when it was done and I was too noob to really grasp every > detail > > :) > > > > does this really deserve the complexity it creates? > > I don't know > > > > I also need to check the Git merge recipe, to see how the result would be > > ok to me: do you have a personal fork somewhere so we can review without > > running the command ourselves? > > > > Regards, > > > > Hervé > > > > On 2024/10/08 06:36:19 Guillaume Nodet wrote: > > > I'd like to discuss merging ITs into maven core repository. > > > The ITs have already been splitted some time ago between the 3.x branch > > and > > > master for testing Maven master. But I don't really see a good reason > to > > > keep the repositories separated, this makes things more complicated > when > > > modifying maven code and adding ITs. > > > > > > The following script allow merging the two repositories while keeping > > both > > > histories: > > > > > > > > > brew install git-filter-repo > > > > > > git clone https://github.com/apache/maven > > > > > > git clone https://github.com/apache/maven-integration-testing > > > > > > (cd maven-integration-testing && \ > > > > > > git filter-repo --to-subdirectory-filter its) > > > > > > (cd maven && \ > > > > > > git remote add its ../maven-integration-testing && \ > > > > > > git fetch its --no-tags && \ > > > > > > EDITOR=true git merge --allow-unrelated-histories its/master && \ > > > > > > git remote remove its) > > > > > > The next step would be to actually include them in a profile and update > > the > > > github workflow. > > > I think they could be refactored to: > > > * first perform a full run on Ubuntu + latest LTS JDK: > > > - restore cache > > > - checkout > > > - build with no tests > > > - run IT bootstrap (to prime local repo) > > > - save cache > > > - build again with tests and ITs > > > * if this first run succeeds, do the same on other platforms / jdks > > > > > > The cache is important to add imho. It seems lately, GH runners have > > often > > > problems downloading from maven central, so that would help a lot > > > increasing the stability. So using > > > https://github.com/marketplace/actions/maven-cache or a similar action > > > would be handy imho. > > > > > > We should also upload nightlies from GH. > > > And automate the releases as much as possible > > > > > > -- > > > > > > Guillaume Nodet > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > -- > > Guillaume Nodet >
Re: [DISCUSS] Merge ITs in maven
> I always has seen this > more as some kind of compatibility-test-kit that can be used independent > of maven itself. yes, this rings a bell: compatibility-test-kit is the spirit that was promoted at that time, with "apache distribution" being just one distribution definitively a discontinued approach... On 2024/10/09 06:48:22 Christoph Läubrich wrote: > Maybe adding it as a git submodule would also help, then it could be > fetched/build together but still retain a separate git repo. > > I agree that having to specify version ranges for maven version in each > test looks odd if it is part of the repo itself, I always has seen this > more as some kind of compatibility-test-kit that can be used independent > of maven itself. > > > Am 09.10.24 um 08:33 schrieb Herve Boutemy: > > I understand how it adds complexity > > > > AFAIK, the interest of having a separate project of core ITs is to clear > > state the Maven core version range for each test, to clearly document when > > things were introduced / broken / fixed and even be able to run HEAD ITs > > against a past release > > > > is it the only reason? I don't know, it's the key aspect I understood 15 > > years ago when it was done and I was too noob to really grasp every detail > > :) > > > > does this really deserve the complexity it creates? > > I don't know > > > > I also need to check the Git merge recipe, to see how the result would be > > ok to me: do you have a personal fork somewhere so we can review without > > running the command ourselves? > > > > Regards, > > > > Hervé > > > > On 2024/10/08 06:36:19 Guillaume Nodet wrote: > >> I'd like to discuss merging ITs into maven core repository. > >> The ITs have already been splitted some time ago between the 3.x branch and > >> master for testing Maven master. But I don't really see a good reason to > >> keep the repositories separated, this makes things more complicated when > >> modifying maven code and adding ITs. > >> > >> The following script allow merging the two repositories while keeping both > >> histories: > >> > >> > >> brew install git-filter-repo > >> > >> git clone https://github.com/apache/maven > >> > >> git clone https://github.com/apache/maven-integration-testing > >> > >> (cd maven-integration-testing && \ > >> > >> git filter-repo --to-subdirectory-filter its) > >> > >> (cd maven && \ > >> > >> git remote add its ../maven-integration-testing && \ > >> > >> git fetch its --no-tags && \ > >> > >> EDITOR=true git merge --allow-unrelated-histories its/master && \ > >> > >> git remote remove its) > >> > >> The next step would be to actually include them in a profile and update the > >> github workflow. > >> I think they could be refactored to: > >>* first perform a full run on Ubuntu + latest LTS JDK: > >> - restore cache > >> - checkout > >> - build with no tests > >> - run IT bootstrap (to prime local repo) > >> - save cache > >> - build again with tests and ITs > >>* if this first run succeeds, do the same on other platforms / jdks > >> > >> The cache is important to add imho. It seems lately, GH runners have often > >> problems downloading from maven central, so that would help a lot > >> increasing the stability. So using > >> https://github.com/marketplace/actions/maven-cache or a similar action > >> would be handy imho. > >> > >> We should also upload nightlies from GH. > >> And automate the releases as much as possible > >> > >> -- > >> > >> Guillaume Nodet > >> > > > > - > > 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
