Hello.

Le mer. 13 nov. 2019 à 18:29, Alex Herbert <[email protected]> a écrit :
>
>
> On 13/11/2019 13:09, Gilles Sadowski wrote:
> > Hi.
> >
> > Do you think that it would be feasible to have all those fixes applied
> > to other modular components (that were based on the [RNG] layout)
> > through a common layer (another POM) between those components
> > and "commons-parent"?
>
> Most of the fixes have been in the module site descriptors or items that
> should be moved up to commons parent. It may be possible to put the site
> descriptors into a parent. IIUC the site descriptors are merged together
> before the maven site plugin creates the site. So the fix for the top
> right banner could be moved into a common parent. Each child module
> would also want to enumerate the past releases of the javadocs. Thus
> they would require a site descriptor anyway and the banner fix would
> only save 5 lines per site.xml for the banner.

Well, I was thinking of whether a multi-layered POM could be more
flexible and robust in handling the different type of components (e.g.
"multi-module" or not).

> I did a big change to the use of svn to checkout the current site. This
> was required as the archived javadocs are not in a top level directory.
> So each module has to be checked out, the archived javadocs set to be
> excluded and then the rest of the site can be checked out.

Sorry, I don't follow.
Didn't links to the Javadoc of previous versions exist prior to those
changes?

>
> Since this process is repeated for every module it can get very slow. I
> changed the site checkout to copy the directory from the parent if it
> was present. There was no solution I could find to fix this to run in a
> single maven command as profile activation for all modules is done by
> the reactor before any work is performed. Thus if the parent does the
> checkout there is no way for all the child modules to know the parent
> checkout exists in their profiles: when the profiles are initialised the
> parent checkout may not exist.
>
> There may be a better way to do this but it is all done in an antrun
> plugin. Ant has limited if-else capability in the antrun plugin as it
> only allows 1 <target> tag per execution. You require multiple <target>
> tags in the same ant build to have conditional dependencies between
> them, i.e. check for parent folder checkout and copy, otherwise do a svn
> checkout.
>
> I am going to try moving all this to a build.xml file and call that. It
> should allow more powerful use of ant. It also separates the ant config
> from the maven config.
>
> If this works the build.xml for ant to checkout the site recursively
> could be put into a parent.
>
> I am still unclear on why this site checkout is required for all the
> child modules. It is used in the maven-scm-publish-plugin but that
> should be used on the top level module during a release process. So a
> simpler fix is to not checkout the site in all the children.
>
> A simple test would be to set the poms to not copy the directory for all
> the child modules and do a dummy release.
>
> It's a work in progress...

I'm lost; what's the purpose?

Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to