Re: Generating xdoc content to be included into site

2017-02-05 Thread Maxim Solodovnik 
Hello Hervé,

Thanks for the quick reply,

Few words about project structure:
project root: https://github.com/apache/openmeetings/tree/3.2.x

main site.xml
https://github.com/apache/openmeetings/blob/3.2.x/src/site/site.xml
contains skin definitions and links being displayed by all modules

"standard" site.xml
https://github.com/apache/openmeetings/blob/3.2.x/openmeetings-util/src/site/site.xml

one of the modules:
https://github.com/apache/openmeetings/tree/3.2.x/openmeetings-server
performing final assembly, and contains main site with all xdocs etc.:
https://github.com/apache/openmeetings/blob/3.2.x/openmeetings-server/src/site/site.xml

I'm not advanced maven user and still learning, so would appreciate any
suggestions :)

On Fri, Feb 3, 2017 at 6:41 PM, Hervé BOUTEMY  wrote:

> in all the cases I know of , since there is site.xml inheritance for shared
> parts, site.xml for modules are not necessary.
>
> Can you share the "standard" site.xml?
>
> Regards,
>
> Hervé
>
> Le vendredi 3 février 2017, 16:31:14 CET Maxim Solodovnik a écrit :
> > Actually I have multi-module project
> > I have "main site" with some how-tos, announces etc.
> > and "standard" sites for all sub-modules: info, rat-report, javadocs,
> > dependencies etc.
> > Currently I have exactly the same site.xml for all these "standard"
> sites,
> > and I don't really like to have 7 copies of the same file :(
> >
> > On Fri, Feb 3, 2017 at 4:20 PM, Hervé BOUTEMY 
> wrote:
> > > you're the first one I see who does that: I never imagined to support
> this
> > > scenario
> > >
> > > Then I'd say: it's by design :)
> > >
> > > I don't know if adding this feature would be hard or not
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le jeudi 2 février 2017, 01:02:33 CET Maxim Solodovnik a écrit :
> > > > One additional question,
> > > >
> > > > I'm generating site.xml during pre-site phase and storing it into
> > > > target/generated-site/site.xml
> > > > But it seems to be not used
> > > > Is it by design? Or maybe I'm doing something wrong?
> > > >
> > > > On Wed, Feb 1, 2017 at 8:16 PM, Maxim Solodovnik <
> solomax...@gmail.com>
> > >
> > > wrote:
> > > > > Thanks a lot!
> > > > > Works as expected!
> > > > >
> > > > > On Wed, Feb 1, 2017 at 7:03 PM, Lukas Theussl 
> > >
> > > wrote:
> > > > >> Heya,
> > > > >>
> > > > >> Try ${project.build.directory}/generated-site or change the
> > > > >> generatedSiteDirectory parameter, see
> > > > >>
> > > > >> https://maven.apache.org/plugins/maven-site-plugin/
> > >
> > > site-mojo.html#generat
> > >
> > > > >> edSiteDirectory
> > > > >>
> > > > >> HTH,
> > > > >> -Lukas
> > > > >>
> > > > >> Am 01.02.2017 um 11:49 schrieb Maxim Solodovnik:
> > > > >>> Hello Karl,
> > > > >>>
> > > > >>> Thanks a lot for the quick response
> > > > >>> pre-site phase is being called if I'm using "mvn site"
> > > > >>> but XML files from target/generated-sources/site/xdoc/ are not
> being
> > > > >>> used while site generation ...
> > > > >>> Should it be generated to the different folder?
> > > > >>>
> > > > >>> On Wed, Feb 1, 2017 at 3:52 PM, Karl Heinz Marbaise <
> > >
> > > khmarba...@gmx.de>
> > >
> > > > >>> wrote:
> > > >  Hi,
> > > > 
> > > >  On 01/02/17 06:52, Maxim Solodovnik wrote:
> > > > > Hello All,
> > > > >
> > > > > I wonder is it possible to generate content for maven site
> plugin?
> > > > > We are using xdoc for our site. I would like to generate source
> > >
> > > using
> > >
> > > > > xml-maven-plugin.
> > > > >
> > > > > Right now I do it in generate-sources phase and polluting
> > > > > src/site/xdoc/
> > > > > folder
> > > > > I tried to change the process as follows:
> > > > > 1) generate site source in pre-site phase
> > > > > 2) put generated content into
> > > > > ${project.build.directory}/generated-sources/site/xdoc/
> > > > >
> > > > > unfortunately it doesn't work this way :(
> > > > > It seems pre-site phase is not being called during mvn
> site:site
> > > > > :(
> > > > > What am I doing wrong?
> > > > 
> > > >  If you call site:site you call the goal of the plugin and NOT
> the
> > >
> > > life
> > >
> > > >  cycle. You need to call mvn site instead than pre-site and site
> > > >  life
> > > >  cycle
> > > >  phases will run...
> > > > 
> > > > 
> > > >  Kind regards
> > > >  Karl Heinz Marbaise
> > > > 
> > > >  
> > >
> > > -
> > >
> > > >  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > >  For additional commands, e-mail: users-h...@maven.apache.org
> > > > >>
> > > > >> 
> -
> > > > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > >> For additional commands, e-mail: users-h...@maven.apache.org
> > > > >
>

Deploying independently versioned modules

2017-02-05 Thread org . apache . maven . user 
Hello.

For years, I've been developing libraries as sets of modules sharing a
(semantic) version number. For each project, the project's root Maven
module defines the version number for all modules in the project. As a
result, intra-project dependencies can be efficiently declared like
this:

  
${project.groupId}
a-module
${project.version}
  

My release process for version x.y.z of any project looks like this:

  $ git flow release start x.y.z
  $ mvn versions:set -DnewVersion=x.y.z
  $ git add pom.xml */pom.xml
  $ git commit -m 'Mark x.y.z'
  (try a build, wait for CI results, etc, etc, etc)
  $ git flow release finish
  $ git push --all
  $ git push --tags
  $ mvn clean deploy site site:stage && mvn nexus-staging:rc-list
  $ mvn nexus-staging:rc-close -DstagingRepositoryId=...
  $ mvn nexus-staging:rc-release -DstagingRepositoryId=...

However, I've recently begun migrating to OSGi and in an OSGi context,
as soon as you have API bundles, it makes more sense to have
independently semantically-versioned modules. The version number of the
aggregating root Maven module therefore identifies a set of module
versions as opposed to dictating a fixed version number for all
submodules.

This is all fine, except for step 8 in my release process... If an API
module has not changed, the version number will not have changed.
Artifacts are immutable, and therefore I don't want to attempt to
deploy the same version of a module again. I can try to manually deploy
by specifying a list of projects with -pl, but this means that my
release process has to be different for each project. I have rather a
lot of projects (~70 and counting), so I'd prefer to avoid any
project-specific procedures in order to preserve my own sanity.

Is there some way I can get the deploy plugin (or possibly the nexus
staging plugin) to determine that it doesn't need to deploy a module
twice?

M


pgp8r9qa_kzBF.pgp
Description: OpenPGP digital signature