You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2007/11/14 22:01:07 UTC
Re: mvn site: a possible solution
http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn't%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20'mvn%20site'?
How does the above answer our problem of generating and deploying a site?
Martijn
On 9/10/07, Gerolf Seitz <ge...@gmail.com> wrote:
> martijn and i had a conversation in ##wicket about the site that could be
> generated via "mvn site" (if it actually worked).
> i attached the irc protocol to the end of this message.
>
> after doing some research i came to the following conclusions:
>
> 1) there is no way to flatten the module hierarchy, so that the modules
> jdk-1.x
> won't be included in the site generation. even when the jdk-1.x modules are
> omitted
> in a separate profile, the modules won't show up as child modules of the
> parent module.
>
> 2) when using the commands "mvn site" and "mvn deploy",
> the generated structure is kinda weird, e.g.:
> /wicket-extensions/wicket-jdk14/wicket-extensions/index.html
> and even after deploying the whole project the links to other modules
> somehow didn't really work.
>
> i was lucky to find a solution for both issues, although i'm not too happy
> about these either:
>
> 1) inspired by this article [0], which talks about in-memory POM
> modification,
> i wrote a small maven plugin (maven-flattire-plugin) that flattens the
> hierarchy on-the-fly so that all
> modules are direct children of the parent module (except the parent module
> itself).
> however, a concern with the maven-plugin might be, that it's not available
> on public maven repositories,
> so it takes an extra step to mvn install it first.
> i don't know how easy or how hard it is to get software published on maven
> repos, so that may not be a concern at all.
>
> 2) maven-site-plugin provides a goal (site:stage) for "testing the final
> result" (although site and site:stage
> didn't have any similarities structure wise during my tests).
> by executing "mvn site:stage -DstagingDirectory=/tmp/wicket" the site is
> created in that location.
> unfortunately the urls
>
> in order to use the flattire maven plugin, i created a profile "site" in the
> parent-pom which includes all modules except jdk-1.x
> and automatically binds flattire to a phase in the lifecycle. needless to
> say that only site:site provides the phases pre-/post-site.
> so i bound flattire to the clean phase, which leads to the final commandline
> for creating the site:
>
> mvn clean site:stage -Psite -DstagingDirectory=/targetDirectory
>
>
> any thoughts, comments, ... ?
>
> gerolf
>
>
>
> [0]
> http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html
>
> ##wicket protocol, Saturday 2007-09-08, started 22:03
> gerolf dashorst: do we want to use mvn site to generate the wicket
> website?
> dashorst not the main site
> dashorst but we do want to use the provided maven skin
> dashorst in wicket/common/wicket-site-skin
> gerolf yeah
> dashorst what I want it to do is
> dashorst generate the standard maven stuff, with just a small
> index.aptdescribing the project
> dashorst without the unit test reports
> dashorst but with the javadoc
> dashorst something like:
> dashorst index.html
> dashorst javadoc
> dashorst dependencies
> gerolf dpendencies probably too
> dashorst license
> dashorst svn repo
> dashorst jira
> dashorst but that is about it
> gerolf what about modules?
> dashorst the idea is to make it one big website
> dashorst with each module a sub directory of the parent
> dashorst or just all modules as children of the parent (flattened
> out)
> dashorst so we get:
> dashorst http://wicket.apache.org/wicket-1.3/wicket
> dashorst http://wicket.apache.org/wicket-1.3/wicket-extensions
> dashorst http://wicket.apache.org/wicket-1.3/wicket-ioc
> dashorst http://wicket.apache.org/wicket-1.3/wicket-spring
> dashorst http://wicket.apache.org/wicket-1.3/wicket-guice
> gerolf so i guess jdk-1.4 /5 should be omitted?
> dashorst and a http://wicket.apache.org/wicket-1.3/index.html
> dashorst yeah
> dashorst it would be nice to have that site included in the release
> zip
> dashorst in a directory docs/
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-rc1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: mvn site: a possible solution
Posted by Martijn Dashorst <ma...@gmail.com>.
BTW, when we move to JDK-1.5 only, we can drop the jdk-1.x directories and
flatten out the project again.
Martijn
On Nov 16, 2007 10:39 PM, Martijn Dashorst <ma...@gmail.com>
wrote:
> We can just create the submodules for the jdk-1.x projects if that helps
> with the site generation.
> We then just have to create a menu that links to the sub projects
> directly, but that should not be too big a problem IMO.
>
> Martijn
>
>
> On Nov 16, 2007 10:36 PM, Gerolf Seitz <ge...@gmail.com> wrote:
>
> > i tried the whole thing again with no success :(
> > we have the following problem:
> > we don't want to generate a site for the jdk-1.x submodules. that's why
> > i
> > came up with the maven plugin that flattens out the hierarchy.
> > when the site is generated via "mvn site site:deploy", the links to the
> > submodules on the wicket-parent's index.html do not work because of the
> > flattened hierarchy.
> > the generated links are "../wicket/wicket-jdk14/wicket/index.html" even
> > though the real location is "../wicket-jdk14/wicket/index.html". mvn
> > site
> > prepends the submodule-artifactId due to the hierarchy change.
> >
> > when the site is generated and deployed without flattening out the
> > hierarchy
> > (and no site.xml is available for the wicket-jdk1x modules), the
> > wicket-parent's index.html doesn't contain links to any submodules,
> > because
> > there's no site for it's direct submodules (wicket-jdk1x). otoh, the
> > generated sites for all other submodules contain links to their parent
> > module, which is one of the wicket-jdk1x modules. and because there is
> > no
> > site for these, the links are broken too.
> >
> > result: either we generate the site via "mvn site:stage" (as described
> > in
> > WICKET-952) and have the long names in the urls, or we postpone using
> > the
> > mvn site plugin after we have removed the structural wicket-jdk1x
> > modules
> > (which should make the whole process a little easier).
> >
> > Gerolf
> >
> > On Nov 15, 2007 8:59 AM, Gerolf Seitz < gerolf.seitz@gmail.com> wrote:
> >
> > > On Nov 14, 2007 10:01 PM, Martijn Dashorst <martijn.dashorst@gmail.com
> > >
> > > wrote:
> > >
> > > >
> > http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn't%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20'mvn%20site
> > > >
> > > > <http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn%27t%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20%27mvn%20site
> > >
> > > > '?
> > > >
> > > > How does the above answer our problem of generating and deploying a
> > > > site?
> > > >
> > >
> > > iirc, i deployed the site to a local directory, but the links were
> > still
> > > broken.
> > > i will give it another shot in the next few days...
> > >
> > > Gerolf
> > >
> > >
> > > >
> > > > Martijn
> > > >
> > > > On 9/10/07, Gerolf Seitz < gerolf.seitz@gmail.com> wrote:
> > > > > martijn and i had a conversation in ##wicket about the site that
> > could
> > > > be
> > > > > generated via "mvn site" (if it actually worked).
> > > > > i attached the irc protocol to the end of this message.
> > > > >
> > > > > after doing some research i came to the following conclusions:
> > > > >
> > > > > 1) there is no way to flatten the module hierarchy, so that the
> > > > modules
> > > > > jdk-1.x
> > > > > won't be included in the site generation. even when the
> > jdk-1.xmodules are
> > > > > omitted
> > > > > in a separate profile, the modules won't show up as child modules
> > of
> > > > the
> > > > > parent module.
> > > > >
> > > > > 2) when using the commands "mvn site" and "mvn deploy",
> > > > > the generated structure is kinda weird, e.g.:
> > > > > /wicket-extensions/wicket-jdk14/wicket-extensions/index.html
> > > > > and even after deploying the whole project the links to other
> > modules
> > > > > somehow didn't really work.
> > > > >
> > > > > i was lucky to find a solution for both issues, although i'm not
> > too
> > > > happy
> > > > > about these either:
> > > > >
> > > > > 1) inspired by this article [0], which talks about in-memory POM
> > > > > modification,
> > > > > i wrote a small maven plugin (maven-flattire-plugin) that flattens
> > the
> > > > > hierarchy on-the-fly so that all
> > > > > modules are direct children of the parent module (except the
> > parent
> > > > module
> > > > > itself).
> > > > > however, a concern with the maven-plugin might be, that it's not
> > > > available
> > > > > on public maven repositories,
> > > > > so it takes an extra step to mvn install it first.
> > > > > i don't know how easy or how hard it is to get software published
> > on
> > > > maven
> > > > > repos, so that may not be a concern at all.
> > > > >
> > > > > 2) maven-site-plugin provides a goal (site:stage) for "testing the
> > > > final
> > > > > result" (although site and site:stage
> > > > > didn't have any similarities structure wise during my tests).
> > > > > by executing "mvn site:stage -DstagingDirectory=/tmp/wicket" the
> > site
> > > > is
> > > > > created in that location.
> > > > > unfortunately the urls
> > > > >
> > > > > in order to use the flattire maven plugin, i created a profile
> > "site"
> > > > in the
> > > > > parent-pom which includes all modules except jdk-1.x
> > > > > and automatically binds flattire to a phase in the lifecycle.
> > needless
> > > > to
> > > > > say that only site:site provides the phases pre-/post-site.
> > > > > so i bound flattire to the clean phase, which leads to the final
> > > > commandline
> > > > > for creating the site:
> > > > >
> > > > > mvn clean site:stage -Psite -DstagingDirectory=/targetDirectory
> > > > >
> > > > >
> > > > > any thoughts, comments, ... ?
> > > > >
> > > > > gerolf
> > > > >
> > > > >
> > > > >
> > > > > [0]
> > > > >
> > > >
> > http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html
> > > > >
> > > > > ##wicket protocol, Saturday 2007-09-08, started 22:03
> > > > > gerolf dashorst: do we want to use mvn site to generate the
> >
> > > > wicket
> > > > > website?
> > > > > dashorst not the main site
> > > > > dashorst but we do want to use the provided maven skin
> > > > > dashorst in wicket/common/wicket-site-skin
> > > > > gerolf yeah
> > > > > dashorst what I want it to do is
> > > > > dashorst generate the standard maven stuff, with just a small
> > > > > index.aptdescribing the project
> > > > > dashorst without the unit test reports
> > > > > dashorst but with the javadoc
> > > > > dashorst something like:
> > > > > dashorst index.html
> > > > > dashorst javadoc
> > > > > dashorst dependencies
> > > > > gerolf dpendencies probably too
> > > > > dashorst license
> > > > > dashorst svn repo
> > > > > dashorst jira
> > > > > dashorst but that is about it
> > > > > gerolf what about modules?
> > > > > dashorst the idea is to make it one big website
> > > > > dashorst with each module a sub directory of the parent
> > > > > dashorst or just all modules as children of the parent
> > (flattened
> > > > > out)
> > > > > dashorst so we get:
> > > > > dashorst http://wicket.apache.org/wicket-1.3/wicket
> > > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-extensions
> > > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-ioc
> > > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-spring
> > > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-guice
> > > > > gerolf so i guess jdk-1.4 /5 should be omitted?
> > > > > dashorst and a http://wicket.apache.org/wicket-1.3/index.html
> > > > > dashorst yeah
> > > > > dashorst it would be nice to have that site included in the
> > release
> > > > > zip
> > > > > dashorst in a directory docs/
> > > > >
> > > >
> > > >
> > > > --
> > > > Buy Wicket in Action: http://manning.com/dashorst
> > > > Apache Wicket 1.3.0-rc1 is released
> > > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
> > > >
> > >
> > >
> >
>
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-rc1 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-rc1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: mvn site: a possible solution
Posted by Gerolf Seitz <ge...@gmail.com>.
On Nov 16, 2007 10:39 PM, Martijn Dashorst <ma...@gmail.com>
wrote:
> We can just create the submodules for the jdk-1.x projects if that helps
> with the site generation.
> We then just have to create a menu that links to the sub projects
> directly,
> but that should not be too big a problem IMO.
>
hm, are the long names really that much of a problem? because if we used
"mvn site:stage", nothing would have to be done manually (except invoking
the command).
what are the actual arguments against the long names with spaces (except
that it's kinda ugly, yet at the same time it just works)?
wasn't the main purpose of the generated site to be delivered to the user as
a zipped package? anyway, it should work locally and when invoked via
http://*
Gerolf
>
> Martijn
>
> On Nov 16, 2007 10:36 PM, Gerolf Seitz <ge...@gmail.com> wrote:
>
> > i tried the whole thing again with no success :(
> > we have the following problem:
> > we don't want to generate a site for the jdk-1.x submodules. that's why
> i
> > came up with the maven plugin that flattens out the hierarchy.
> > when the site is generated via "mvn site site:deploy", the links to the
> > submodules on the wicket-parent's index.html do not work because of the
> > flattened hierarchy.
> > the generated links are "../wicket/wicket-jdk14/wicket/index.html" even
> > though the real location is "../wicket-jdk14/wicket/index.html". mvn
> site
> > prepends the submodule-artifactId due to the hierarchy change.
> >
> > when the site is generated and deployed without flattening out the
> > hierarchy
> > (and no site.xml is available for the wicket-jdk1x modules), the
> > wicket-parent's index.html doesn't contain links to any submodules,
> > because
> > there's no site for it's direct submodules (wicket-jdk1x). otoh, the
> > generated sites for all other submodules contain links to their parent
> > module, which is one of the wicket-jdk1x modules. and because there is
> no
> > site for these, the links are broken too.
> >
> > result: either we generate the site via "mvn site:stage" (as described
> in
> > WICKET-952) and have the long names in the urls, or we postpone using
> the
> > mvn site plugin after we have removed the structural wicket-jdk1x
> modules
> > (which should make the whole process a little easier).
> >
> > Gerolf
> >
> > On Nov 15, 2007 8:59 AM, Gerolf Seitz <ge...@gmail.com> wrote:
> >
> > > On Nov 14, 2007 10:01 PM, Martijn Dashorst <martijn.dashorst@gmail.com
> >
> > > wrote:
> > >
> > > >
> >
> http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn't%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20'mvn%20site<http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn%27t%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20%27mvn%20site>
> > > >
> > > > <
> >
> http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn%27t%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20%27mvn%20site
> > >
> > > > '?
> > > >
> > > > How does the above answer our problem of generating and deploying a
> > > > site?
> > > >
> > >
> > > iirc, i deployed the site to a local directory, but the links were
> still
> > > broken.
> > > i will give it another shot in the next few days...
> > >
> > > Gerolf
> > >
> > >
> > > >
> > > > Martijn
> > > >
> > > > On 9/10/07, Gerolf Seitz < gerolf.seitz@gmail.com> wrote:
> > > > > martijn and i had a conversation in ##wicket about the site that
> > could
> > > > be
> > > > > generated via "mvn site" (if it actually worked).
> > > > > i attached the irc protocol to the end of this message.
> > > > >
> > > > > after doing some research i came to the following conclusions:
> > > > >
> > > > > 1) there is no way to flatten the module hierarchy, so that the
> > > > modules
> > > > > jdk-1.x
> > > > > won't be included in the site generation. even when the
> > jdk-1.xmodules are
> > > > > omitted
> > > > > in a separate profile, the modules won't show up as child modules
> of
> > > > the
> > > > > parent module.
> > > > >
> > > > > 2) when using the commands "mvn site" and "mvn deploy",
> > > > > the generated structure is kinda weird, e.g.:
> > > > > /wicket-extensions/wicket-jdk14/wicket-extensions/index.html
> > > > > and even after deploying the whole project the links to other
> > modules
> > > > > somehow didn't really work.
> > > > >
> > > > > i was lucky to find a solution for both issues, although i'm not
> too
> > > > happy
> > > > > about these either:
> > > > >
> > > > > 1) inspired by this article [0], which talks about in-memory POM
> > > > > modification,
> > > > > i wrote a small maven plugin (maven-flattire-plugin) that flattens
> > the
> > > > > hierarchy on-the-fly so that all
> > > > > modules are direct children of the parent module (except the
> parent
> > > > module
> > > > > itself).
> > > > > however, a concern with the maven-plugin might be, that it's not
> > > > available
> > > > > on public maven repositories,
> > > > > so it takes an extra step to mvn install it first.
> > > > > i don't know how easy or how hard it is to get software published
> on
> > > > maven
> > > > > repos, so that may not be a concern at all.
> > > > >
> > > > > 2) maven-site-plugin provides a goal (site:stage) for "testing the
> > > > final
> > > > > result" (although site and site:stage
> > > > > didn't have any similarities structure wise during my tests).
> > > > > by executing "mvn site:stage -DstagingDirectory=/tmp/wicket" the
> > site
> > > > is
> > > > > created in that location.
> > > > > unfortunately the urls
> > > > >
> > > > > in order to use the flattire maven plugin, i created a profile
> > "site"
> > > > in the
> > > > > parent-pom which includes all modules except jdk-1.x
> > > > > and automatically binds flattire to a phase in the lifecycle.
> > needless
> > > > to
> > > > > say that only site:site provides the phases pre-/post-site.
> > > > > so i bound flattire to the clean phase, which leads to the final
> > > > commandline
> > > > > for creating the site:
> > > > >
> > > > > mvn clean site:stage -Psite -DstagingDirectory=/targetDirectory
> > > > >
> > > > >
> > > > > any thoughts, comments, ... ?
> > > > >
> > > > > gerolf
> > > > >
> > > > >
> > > > >
> > > > > [0]
> > > > >
> > > >
> >
> http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html
> > > > >
> > > > > ##wicket protocol, Saturday 2007-09-08, started 22:03
> > > > > gerolf dashorst: do we want to use mvn site to generate the
> > > > wicket
> > > > > website?
> > > > > dashorst not the main site
> > > > > dashorst but we do want to use the provided maven skin
> > > > > dashorst in wicket/common/wicket-site-skin
> > > > > gerolf yeah
> > > > > dashorst what I want it to do is
> > > > > dashorst generate the standard maven stuff, with just a small
> > > > > index.aptdescribing the project
> > > > > dashorst without the unit test reports
> > > > > dashorst but with the javadoc
> > > > > dashorst something like:
> > > > > dashorst index.html
> > > > > dashorst javadoc
> > > > > dashorst dependencies
> > > > > gerolf dpendencies probably too
> > > > > dashorst license
> > > > > dashorst svn repo
> > > > > dashorst jira
> > > > > dashorst but that is about it
> > > > > gerolf what about modules?
> > > > > dashorst the idea is to make it one big website
> > > > > dashorst with each module a sub directory of the parent
> > > > > dashorst or just all modules as children of the parent
> (flattened
> > > > > out)
> > > > > dashorst so we get:
> > > > > dashorst http://wicket.apache.org/wicket-1.3/wicket
> > > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-extensions
> > > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-ioc
> > > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-spring
> > > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-guice
> > > > > gerolf so i guess jdk-1.4 /5 should be omitted?
> > > > > dashorst and a http://wicket.apache.org/wicket-1.3/index.html
> > > > > dashorst yeah
> > > > > dashorst it would be nice to have that site included in the
> > release
> > > > > zip
> > > > > dashorst in a directory docs/
> > > > >
> > > >
> > > >
> > > > --
> > > > Buy Wicket in Action: http://manning.com/dashorst
> > > > Apache Wicket 1.3.0-rc1 is released
> > > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
> > > >
> > >
> > >
> >
>
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-rc1 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
>
Re: mvn site: a possible solution
Posted by Martijn Dashorst <ma...@gmail.com>.
We can just create the submodules for the jdk-1.x projects if that helps
with the site generation.
We then just have to create a menu that links to the sub projects directly,
but that should not be too big a problem IMO.
Martijn
On Nov 16, 2007 10:36 PM, Gerolf Seitz <ge...@gmail.com> wrote:
> i tried the whole thing again with no success :(
> we have the following problem:
> we don't want to generate a site for the jdk-1.x submodules. that's why i
> came up with the maven plugin that flattens out the hierarchy.
> when the site is generated via "mvn site site:deploy", the links to the
> submodules on the wicket-parent's index.html do not work because of the
> flattened hierarchy.
> the generated links are "../wicket/wicket-jdk14/wicket/index.html" even
> though the real location is "../wicket-jdk14/wicket/index.html". mvn site
> prepends the submodule-artifactId due to the hierarchy change.
>
> when the site is generated and deployed without flattening out the
> hierarchy
> (and no site.xml is available for the wicket-jdk1x modules), the
> wicket-parent's index.html doesn't contain links to any submodules,
> because
> there's no site for it's direct submodules (wicket-jdk1x). otoh, the
> generated sites for all other submodules contain links to their parent
> module, which is one of the wicket-jdk1x modules. and because there is no
> site for these, the links are broken too.
>
> result: either we generate the site via "mvn site:stage" (as described in
> WICKET-952) and have the long names in the urls, or we postpone using the
> mvn site plugin after we have removed the structural wicket-jdk1x modules
> (which should make the whole process a little easier).
>
> Gerolf
>
> On Nov 15, 2007 8:59 AM, Gerolf Seitz <ge...@gmail.com> wrote:
>
> > On Nov 14, 2007 10:01 PM, Martijn Dashorst <ma...@gmail.com>
> > wrote:
> >
> > >
> http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn't%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20'mvn%20site
> > >
> > > <
> http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn%27t%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20%27mvn%20site
> >
> > > '?
> > >
> > > How does the above answer our problem of generating and deploying a
> > > site?
> > >
> >
> > iirc, i deployed the site to a local directory, but the links were still
> > broken.
> > i will give it another shot in the next few days...
> >
> > Gerolf
> >
> >
> > >
> > > Martijn
> > >
> > > On 9/10/07, Gerolf Seitz < gerolf.seitz@gmail.com> wrote:
> > > > martijn and i had a conversation in ##wicket about the site that
> could
> > > be
> > > > generated via "mvn site" (if it actually worked).
> > > > i attached the irc protocol to the end of this message.
> > > >
> > > > after doing some research i came to the following conclusions:
> > > >
> > > > 1) there is no way to flatten the module hierarchy, so that the
> > > modules
> > > > jdk-1.x
> > > > won't be included in the site generation. even when the
> jdk-1.xmodules are
> > > > omitted
> > > > in a separate profile, the modules won't show up as child modules of
> > > the
> > > > parent module.
> > > >
> > > > 2) when using the commands "mvn site" and "mvn deploy",
> > > > the generated structure is kinda weird, e.g.:
> > > > /wicket-extensions/wicket-jdk14/wicket-extensions/index.html
> > > > and even after deploying the whole project the links to other
> modules
> > > > somehow didn't really work.
> > > >
> > > > i was lucky to find a solution for both issues, although i'm not too
> > > happy
> > > > about these either:
> > > >
> > > > 1) inspired by this article [0], which talks about in-memory POM
> > > > modification,
> > > > i wrote a small maven plugin (maven-flattire-plugin) that flattens
> the
> > > > hierarchy on-the-fly so that all
> > > > modules are direct children of the parent module (except the parent
> > > module
> > > > itself).
> > > > however, a concern with the maven-plugin might be, that it's not
> > > available
> > > > on public maven repositories,
> > > > so it takes an extra step to mvn install it first.
> > > > i don't know how easy or how hard it is to get software published on
> > > maven
> > > > repos, so that may not be a concern at all.
> > > >
> > > > 2) maven-site-plugin provides a goal (site:stage) for "testing the
> > > final
> > > > result" (although site and site:stage
> > > > didn't have any similarities structure wise during my tests).
> > > > by executing "mvn site:stage -DstagingDirectory=/tmp/wicket" the
> site
> > > is
> > > > created in that location.
> > > > unfortunately the urls
> > > >
> > > > in order to use the flattire maven plugin, i created a profile
> "site"
> > > in the
> > > > parent-pom which includes all modules except jdk-1.x
> > > > and automatically binds flattire to a phase in the lifecycle.
> needless
> > > to
> > > > say that only site:site provides the phases pre-/post-site.
> > > > so i bound flattire to the clean phase, which leads to the final
> > > commandline
> > > > for creating the site:
> > > >
> > > > mvn clean site:stage -Psite -DstagingDirectory=/targetDirectory
> > > >
> > > >
> > > > any thoughts, comments, ... ?
> > > >
> > > > gerolf
> > > >
> > > >
> > > >
> > > > [0]
> > > >
> > >
> http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html
> > > >
> > > > ##wicket protocol, Saturday 2007-09-08, started 22:03
> > > > gerolf dashorst: do we want to use mvn site to generate the
> > > wicket
> > > > website?
> > > > dashorst not the main site
> > > > dashorst but we do want to use the provided maven skin
> > > > dashorst in wicket/common/wicket-site-skin
> > > > gerolf yeah
> > > > dashorst what I want it to do is
> > > > dashorst generate the standard maven stuff, with just a small
> > > > index.aptdescribing the project
> > > > dashorst without the unit test reports
> > > > dashorst but with the javadoc
> > > > dashorst something like:
> > > > dashorst index.html
> > > > dashorst javadoc
> > > > dashorst dependencies
> > > > gerolf dpendencies probably too
> > > > dashorst license
> > > > dashorst svn repo
> > > > dashorst jira
> > > > dashorst but that is about it
> > > > gerolf what about modules?
> > > > dashorst the idea is to make it one big website
> > > > dashorst with each module a sub directory of the parent
> > > > dashorst or just all modules as children of the parent (flattened
> > > > out)
> > > > dashorst so we get:
> > > > dashorst http://wicket.apache.org/wicket-1.3/wicket
> > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-extensions
> > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-ioc
> > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-spring
> > > > dashorst http://wicket.apache.org/wicket-1.3/wicket-guice
> > > > gerolf so i guess jdk-1.4 /5 should be omitted?
> > > > dashorst and a http://wicket.apache.org/wicket-1.3/index.html
> > > > dashorst yeah
> > > > dashorst it would be nice to have that site included in the
> release
> > > > zip
> > > > dashorst in a directory docs/
> > > >
> > >
> > >
> > > --
> > > Buy Wicket in Action: http://manning.com/dashorst
> > > Apache Wicket 1.3.0-rc1 is released
> > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
> > >
> >
> >
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-rc1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: mvn site: a possible solution
Posted by Gerolf Seitz <ge...@gmail.com>.
i tried the whole thing again with no success :(
we have the following problem:
we don't want to generate a site for the jdk-1.x submodules. that's why i
came up with the maven plugin that flattens out the hierarchy.
when the site is generated via "mvn site site:deploy", the links to the
submodules on the wicket-parent's index.html do not work because of the
flattened hierarchy.
the generated links are "../wicket/wicket-jdk14/wicket/index.html" even
though the real location is "../wicket-jdk14/wicket/index.html". mvn site
prepends the submodule-artifactId due to the hierarchy change.
when the site is generated and deployed without flattening out the hierarchy
(and no site.xml is available for the wicket-jdk1x modules), the
wicket-parent's index.html doesn't contain links to any submodules, because
there's no site for it's direct submodules (wicket-jdk1x). otoh, the
generated sites for all other submodules contain links to their parent
module, which is one of the wicket-jdk1x modules. and because there is no
site for these, the links are broken too.
result: either we generate the site via "mvn site:stage" (as described in
WICKET-952) and have the long names in the urls, or we postpone using the
mvn site plugin after we have removed the structural wicket-jdk1x modules
(which should make the whole process a little easier).
Gerolf
On Nov 15, 2007 8:59 AM, Gerolf Seitz <ge...@gmail.com> wrote:
> On Nov 14, 2007 10:01 PM, Martijn Dashorst <ma...@gmail.com>
> wrote:
>
> > http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn't%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20'mvn%20site
> >
> > <http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn%27t%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20%27mvn%20site>
> > '?
> >
> > How does the above answer our problem of generating and deploying a
> > site?
> >
>
> iirc, i deployed the site to a local directory, but the links were still
> broken.
> i will give it another shot in the next few days...
>
> Gerolf
>
>
> >
> > Martijn
> >
> > On 9/10/07, Gerolf Seitz < gerolf.seitz@gmail.com> wrote:
> > > martijn and i had a conversation in ##wicket about the site that could
> > be
> > > generated via "mvn site" (if it actually worked).
> > > i attached the irc protocol to the end of this message.
> > >
> > > after doing some research i came to the following conclusions:
> > >
> > > 1) there is no way to flatten the module hierarchy, so that the
> > modules
> > > jdk-1.x
> > > won't be included in the site generation. even when the jdk-1.xmodules are
> > > omitted
> > > in a separate profile, the modules won't show up as child modules of
> > the
> > > parent module.
> > >
> > > 2) when using the commands "mvn site" and "mvn deploy",
> > > the generated structure is kinda weird, e.g.:
> > > /wicket-extensions/wicket-jdk14/wicket-extensions/index.html
> > > and even after deploying the whole project the links to other modules
> > > somehow didn't really work.
> > >
> > > i was lucky to find a solution for both issues, although i'm not too
> > happy
> > > about these either:
> > >
> > > 1) inspired by this article [0], which talks about in-memory POM
> > > modification,
> > > i wrote a small maven plugin (maven-flattire-plugin) that flattens the
> > > hierarchy on-the-fly so that all
> > > modules are direct children of the parent module (except the parent
> > module
> > > itself).
> > > however, a concern with the maven-plugin might be, that it's not
> > available
> > > on public maven repositories,
> > > so it takes an extra step to mvn install it first.
> > > i don't know how easy or how hard it is to get software published on
> > maven
> > > repos, so that may not be a concern at all.
> > >
> > > 2) maven-site-plugin provides a goal (site:stage) for "testing the
> > final
> > > result" (although site and site:stage
> > > didn't have any similarities structure wise during my tests).
> > > by executing "mvn site:stage -DstagingDirectory=/tmp/wicket" the site
> > is
> > > created in that location.
> > > unfortunately the urls
> > >
> > > in order to use the flattire maven plugin, i created a profile "site"
> > in the
> > > parent-pom which includes all modules except jdk-1.x
> > > and automatically binds flattire to a phase in the lifecycle. needless
> > to
> > > say that only site:site provides the phases pre-/post-site.
> > > so i bound flattire to the clean phase, which leads to the final
> > commandline
> > > for creating the site:
> > >
> > > mvn clean site:stage -Psite -DstagingDirectory=/targetDirectory
> > >
> > >
> > > any thoughts, comments, ... ?
> > >
> > > gerolf
> > >
> > >
> > >
> > > [0]
> > >
> > http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html
> > >
> > > ##wicket protocol, Saturday 2007-09-08, started 22:03
> > > gerolf dashorst: do we want to use mvn site to generate the
> > wicket
> > > website?
> > > dashorst not the main site
> > > dashorst but we do want to use the provided maven skin
> > > dashorst in wicket/common/wicket-site-skin
> > > gerolf yeah
> > > dashorst what I want it to do is
> > > dashorst generate the standard maven stuff, with just a small
> > > index.aptdescribing the project
> > > dashorst without the unit test reports
> > > dashorst but with the javadoc
> > > dashorst something like:
> > > dashorst index.html
> > > dashorst javadoc
> > > dashorst dependencies
> > > gerolf dpendencies probably too
> > > dashorst license
> > > dashorst svn repo
> > > dashorst jira
> > > dashorst but that is about it
> > > gerolf what about modules?
> > > dashorst the idea is to make it one big website
> > > dashorst with each module a sub directory of the parent
> > > dashorst or just all modules as children of the parent (flattened
> > > out)
> > > dashorst so we get:
> > > dashorst http://wicket.apache.org/wicket-1.3/wicket
> > > dashorst http://wicket.apache.org/wicket-1.3/wicket-extensions
> > > dashorst http://wicket.apache.org/wicket-1.3/wicket-ioc
> > > dashorst http://wicket.apache.org/wicket-1.3/wicket-spring
> > > dashorst http://wicket.apache.org/wicket-1.3/wicket-guice
> > > gerolf so i guess jdk-1.4 /5 should be omitted?
> > > dashorst and a http://wicket.apache.org/wicket-1.3/index.html
> > > dashorst yeah
> > > dashorst it would be nice to have that site included in the release
> > > zip
> > > dashorst in a directory docs/
> > >
> >
> >
> > --
> > Buy Wicket in Action: http://manning.com/dashorst
> > Apache Wicket 1.3.0-rc1 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
> >
>
>
Re: mvn site: a possible solution
Posted by Gerolf Seitz <ge...@gmail.com>.
On Nov 14, 2007 10:01 PM, Martijn Dashorst <ma...@gmail.com>
wrote:
>
> http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn't%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20'mvn%20site<http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why%20doesn%27t%20the%20links%20between%20parent%20and%20child%20modules%20work%20when%20I%20run%20%27mvn%20site>
> '?
>
> How does the above answer our problem of generating and deploying a site?
>
iirc, i deployed the site to a local directory, but the links were still
broken.
i will give it another shot in the next few days...
Gerolf
>
> Martijn
>
> On 9/10/07, Gerolf Seitz <ge...@gmail.com> wrote:
> > martijn and i had a conversation in ##wicket about the site that could
> be
> > generated via "mvn site" (if it actually worked).
> > i attached the irc protocol to the end of this message.
> >
> > after doing some research i came to the following conclusions:
> >
> > 1) there is no way to flatten the module hierarchy, so that the modules
> > jdk-1.x
> > won't be included in the site generation. even when the jdk-1.x modules
> are
> > omitted
> > in a separate profile, the modules won't show up as child modules of the
> > parent module.
> >
> > 2) when using the commands "mvn site" and "mvn deploy",
> > the generated structure is kinda weird, e.g.:
> > /wicket-extensions/wicket-jdk14/wicket-extensions/index.html
> > and even after deploying the whole project the links to other modules
> > somehow didn't really work.
> >
> > i was lucky to find a solution for both issues, although i'm not too
> happy
> > about these either:
> >
> > 1) inspired by this article [0], which talks about in-memory POM
> > modification,
> > i wrote a small maven plugin (maven-flattire-plugin) that flattens the
> > hierarchy on-the-fly so that all
> > modules are direct children of the parent module (except the parent
> module
> > itself).
> > however, a concern with the maven-plugin might be, that it's not
> available
> > on public maven repositories,
> > so it takes an extra step to mvn install it first.
> > i don't know how easy or how hard it is to get software published on
> maven
> > repos, so that may not be a concern at all.
> >
> > 2) maven-site-plugin provides a goal (site:stage) for "testing the final
> > result" (although site and site:stage
> > didn't have any similarities structure wise during my tests).
> > by executing "mvn site:stage -DstagingDirectory=/tmp/wicket" the site is
> > created in that location.
> > unfortunately the urls
> >
> > in order to use the flattire maven plugin, i created a profile "site" in
> the
> > parent-pom which includes all modules except jdk-1.x
> > and automatically binds flattire to a phase in the lifecycle. needless
> to
> > say that only site:site provides the phases pre-/post-site.
> > so i bound flattire to the clean phase, which leads to the final
> commandline
> > for creating the site:
> >
> > mvn clean site:stage -Psite -DstagingDirectory=/targetDirectory
> >
> >
> > any thoughts, comments, ... ?
> >
> > gerolf
> >
> >
> >
> > [0]
> >
> http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html
> >
> > ##wicket protocol, Saturday 2007-09-08, started 22:03
> > gerolf dashorst: do we want to use mvn site to generate the
> wicket
> > website?
> > dashorst not the main site
> > dashorst but we do want to use the provided maven skin
> > dashorst in wicket/common/wicket-site-skin
> > gerolf yeah
> > dashorst what I want it to do is
> > dashorst generate the standard maven stuff, with just a small
> > index.aptdescribing the project
> > dashorst without the unit test reports
> > dashorst but with the javadoc
> > dashorst something like:
> > dashorst index.html
> > dashorst javadoc
> > dashorst dependencies
> > gerolf dpendencies probably too
> > dashorst license
> > dashorst svn repo
> > dashorst jira
> > dashorst but that is about it
> > gerolf what about modules?
> > dashorst the idea is to make it one big website
> > dashorst with each module a sub directory of the parent
> > dashorst or just all modules as children of the parent (flattened
> > out)
> > dashorst so we get:
> > dashorst http://wicket.apache.org/wicket-1.3/wicket
> > dashorst http://wicket.apache.org/wicket-1.3/wicket-extensions
> > dashorst http://wicket.apache.org/wicket-1.3/wicket-ioc
> > dashorst http://wicket.apache.org/wicket-1.3/wicket-spring
> > dashorst http://wicket.apache.org/wicket-1.3/wicket-guice
> > gerolf so i guess jdk-1.4 /5 should be omitted?
> > dashorst and a http://wicket.apache.org/wicket-1.3/index.html
> > dashorst yeah
> > dashorst it would be nice to have that site included in the release
> > zip
> > dashorst in a directory docs/
> >
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-rc1 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
>