You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Gerolf Seitz <ge...@gmail.com> on 2007/09/10 01:27:43 UTC
mvn site: a possible solution
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/
Re: mvn site: a possible solution
Posted by Igor Vaynberg <ig...@gmail.com>.
not all of us speak ruby or want to, so you will pretty much exclude those
people from the process.
-igor
On 9/10/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> What about using [1]Buildr for this? It would allow for easier
> customization.
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
> [1] http://buildr.rubyforge.org/
>
Re: mvn site: a possible solution
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
What about using [1]Buildr for this? It would allow for easier
customization.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
[1] http://buildr.rubyforge.org/
Re: mvn site: a possible solution
Posted by Tim O'Brien <to...@discursive.com>.
Thanks David, I added that the the version I'm using to generate and
ran the script.
For anyone else interested, here's the patch:
Index: pom.xml
===================================================================
--- pom.xml (revision 579721)
+++ pom.xml (working copy)
@@ -129,7 +129,7 @@
<distributionManagement>
<site>
<id>local</id>
- <url>file:target/site/</url>
+
<url>file:/home/tobrien/public_html/wicket/</url>
</site>
<repository>
<id>local</id>
@@ -709,6 +709,56 @@
<inherited>true</inherited>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
+ <configuration>
+ <aggregate>true</aggregate>
+<excludePackageNames>org.apache.wicket.quickstart.*:*.test:*.examples.*:*.spring.annot.web*:*.spring.common*:*.spring.direct*:*.spring.proxy*</excludePackageNames>
+ <groups>
+ <group>
+ <title>wicket</title>
+
<packages>org.apache.wicket*</packages>
+ </group>
+ <group>
+ <title>wicket-auth-roles</title>
+
<packages>org.apache.wicket.authentication*:org.apache.wicket.authorization*</packages>
+ </group>
+ <group>
+ <title>wicket-datetime</title>
+
<packages>org.apache.wicket.datetime*:org.apache.wicket.extensions.yui*</packages>
+ </group>
+ <group>
+ <title>wicket-extensions</title>
+
<packages>org.apache.wicket.extensions*</packages>
+ </group>
+ <group>
+ <title>wicket-guice</title>
+
<packages>org.apache.wicket.guice*</packages>
+ </group>
+ <group>
+ <title>wicket-ioc</title>
+
<packages>org.apache.wicket.injection*:org.apache.wicket.proxy*</packages>
+ </group>
+ <group>
+ <title>wicket-jmx</title>
+
<packages>org.apache.wicket.jmx*</packages>
+ </group>
+ <group>
+
<title>wicket-objectsizeof-agent</title>
+
<packages>org.apache.wicket.util.instrument*</packages>
+ </group>
+ <group>
+ <title>wicket-spring</title>
+
<packages>org.apache.wicket.spring*</packages>
+ </group>
+ <group>
+ <title>wicket-spring-annot</title>
+
<packages>org.apache.wicket.spring.injection.annot*</packages>
+ </group>
+ <group>
+ <title>wicket-velocity</title>
+
<packages>org.apache.wicket.velocity*</packages>
+ </group>
+ </groups>
+ </configuration>
</plugin>
</plugins>
</reporting>
On 9/26/07, David Bernard <dw...@free.fr> wrote:
> I've also create an agreate javadoc, this morning, but I added groups definition and excludes every samples (includes spring one that are not under org.apache.wicket.examples) and quickstart :
>
> <plugin>
> <inherited>true</inherited>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <configuration>
> <aggregate>true</aggregate>
> <excludePackageNames>org.apache.wicket.quickstart.*:*.test:*.examples.*:*.spring.annot.web*:*.spring.common*:*.spring.direct*:*.spring.proxy*</excludePackageNames>
> <groups>
> <group>
> <title>wicket</title>
> <packages>org.apache.wicket*</packages>
> </group>
> <group>
> <title>wicket-auth-roles</title>
> <packages>org.apache.wicket.authentication*:org.apache.wicket.authorization*</packages>
> </group>
> <group>
> <title>wicket-datetime</title>
> <packages>org.apache.wicket.datetime*:org.apache.wicket.extensions.yui*</packages>
> </group>
> <group>
> <title>wicket-extensions</title>
> <packages>org.apache.wicket.extensions*</packages>
> </group>
> <group>
> <title>wicket-guice</title>
> <packages>org.apache.wicket.guice*</packages>
> </group>
> <group>
> <title>wicket-ioc</title>
> <packages>org.apache.wicket.injection*:org.apache.wicket.proxy*</packages>
> </group>
> <group>
> <title>wicket-jmx</title>
> <packages>org.apache.wicket.jmx*</packages>
> </group>
> <group>
> <title>wicket-objectsizeof-agent</title>
> <packages>org.apache.wicket.util.instrument*</packages>
> </group>
> <group>
> <title>wicket-spring</title>
> <packages>org.apache.wicket.spring*</packages>
> </group>
> <group>
> <title>wicket-spring-annot</title>
> <packages>org.apache.wicket.spring.injection.annot*</packages>
> </group>
> <group>
> <title>wicket-velocity</title>
> <packages>org.apache.wicket.velocity*</packages>
> </group>
> </groups>
> </configuration>
> </plugin>
>
>
> Tim O'Brien wrote:
> > Gwyn, Martjin,
> >
> > Is there a better place to run this? Does Wicket have a zone where
> > we could run this as a cron job?
> >
> > The process is straightforward, I'm just changes the release
> > properties in the distributionManagement of the top-level pom.xml, I'm
> > also telling the javadoc-plugin to aggregate and exclude the examples.
> >
> > SCRIPT FOLLOWS:
> > #!/usr/local/bin/bash
> >
> > cd ~/svnw/wicket-trunk
> > svn update
> > mvn -P release site:deploy
> >
> > PATCH FOLLOWS:
> >
> > Index: pom.xml
> > ===================================================================
> > --- pom.xml (revision 579617)
> > +++ pom.xml (working copy)
> > @@ -129,7 +129,7 @@
> > <distributionManagement>
> > <site>
> > <id>local</id>
> > - <url>file:target/site/</url>
> > +
> > <url>file:/home/tobrien/public_html/wicket/</url>
> > </site>
> > <repository>
> > <id>local</id>
> > @@ -709,6 +709,10 @@
> > <inherited>true</inherited>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-javadoc-plugin</artifactId>
> > + <configuration>
> > + <aggregate>true</aggregate>
> > +
> > <excludePackageNames>org.apache.wicket.examples.*:org.apache.wicket.examples</excludePackageNames>
> > + </configuration>
> > </plugin>
> > </plugins>
> > </reporting>
> >
> >
> > On 9/20/07, Gwyn Evans <gw...@gmail.com> wrote:
> >> On Thursday, September 20, 2007, 11:13:23 PM, Tim <to...@discursive.com> wrote:
> >>
> >>> BTW, I'm continuing to run the full javadoc build in ~tobrien as an interim
> >>> solution. It certainly isn't ideal, but it's one way to solve the
> >>> problem. I'll keep an eye on the discussion.
> >> Please flag it (to myself or Martijn, if no-one else) if/when that
> >> changes, as that's where the JavaDoc link on the front page goes! :-)
> >>
> >> /Gwyn
> >>
> >>
> >
> >
>
--
------
Tim O'Brien: (847) 863-7045
Re: mvn site: a possible solution
Posted by David Bernard <dw...@free.fr>.
I've also create an agreate javadoc, this morning, but I added groups definition and excludes every samples (includes spring one that are not under org.apache.wicket.examples) and quickstart :
<plugin>
<inherited>true</inherited>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<aggregate>true</aggregate>
<excludePackageNames>org.apache.wicket.quickstart.*:*.test:*.examples.*:*.spring.annot.web*:*.spring.common*:*.spring.direct*:*.spring.proxy*</excludePackageNames>
<groups>
<group>
<title>wicket</title>
<packages>org.apache.wicket*</packages>
</group>
<group>
<title>wicket-auth-roles</title>
<packages>org.apache.wicket.authentication*:org.apache.wicket.authorization*</packages>
</group>
<group>
<title>wicket-datetime</title>
<packages>org.apache.wicket.datetime*:org.apache.wicket.extensions.yui*</packages>
</group>
<group>
<title>wicket-extensions</title>
<packages>org.apache.wicket.extensions*</packages>
</group>
<group>
<title>wicket-guice</title>
<packages>org.apache.wicket.guice*</packages>
</group>
<group>
<title>wicket-ioc</title>
<packages>org.apache.wicket.injection*:org.apache.wicket.proxy*</packages>
</group>
<group>
<title>wicket-jmx</title>
<packages>org.apache.wicket.jmx*</packages>
</group>
<group>
<title>wicket-objectsizeof-agent</title>
<packages>org.apache.wicket.util.instrument*</packages>
</group>
<group>
<title>wicket-spring</title>
<packages>org.apache.wicket.spring*</packages>
</group>
<group>
<title>wicket-spring-annot</title>
<packages>org.apache.wicket.spring.injection.annot*</packages>
</group>
<group>
<title>wicket-velocity</title>
<packages>org.apache.wicket.velocity*</packages>
</group>
</groups>
</configuration>
</plugin>
Tim O'Brien wrote:
> Gwyn, Martjin,
>
> Is there a better place to run this? Does Wicket have a zone where
> we could run this as a cron job?
>
> The process is straightforward, I'm just changes the release
> properties in the distributionManagement of the top-level pom.xml, I'm
> also telling the javadoc-plugin to aggregate and exclude the examples.
>
> SCRIPT FOLLOWS:
> #!/usr/local/bin/bash
>
> cd ~/svnw/wicket-trunk
> svn update
> mvn -P release site:deploy
>
> PATCH FOLLOWS:
>
> Index: pom.xml
> ===================================================================
> --- pom.xml (revision 579617)
> +++ pom.xml (working copy)
> @@ -129,7 +129,7 @@
> <distributionManagement>
> <site>
> <id>local</id>
> - <url>file:target/site/</url>
> +
> <url>file:/home/tobrien/public_html/wicket/</url>
> </site>
> <repository>
> <id>local</id>
> @@ -709,6 +709,10 @@
> <inherited>true</inherited>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> + <configuration>
> + <aggregate>true</aggregate>
> +
> <excludePackageNames>org.apache.wicket.examples.*:org.apache.wicket.examples</excludePackageNames>
> + </configuration>
> </plugin>
> </plugins>
> </reporting>
>
>
> On 9/20/07, Gwyn Evans <gw...@gmail.com> wrote:
>> On Thursday, September 20, 2007, 11:13:23 PM, Tim <to...@discursive.com> wrote:
>>
>>> BTW, I'm continuing to run the full javadoc build in ~tobrien as an interim
>>> solution. It certainly isn't ideal, but it's one way to solve the
>>> problem. I'll keep an eye on the discussion.
>> Please flag it (to myself or Martijn, if no-one else) if/when that
>> changes, as that's where the JavaDoc link on the front page goes! :-)
>>
>> /Gwyn
>>
>>
>
>
Re: mvn site: a possible solution
Posted by Tim O'Brien <to...@discursive.com>.
Gwyn, Martjin,
Is there a better place to run this? Does Wicket have a zone where
we could run this as a cron job?
The process is straightforward, I'm just changes the release
properties in the distributionManagement of the top-level pom.xml, I'm
also telling the javadoc-plugin to aggregate and exclude the examples.
SCRIPT FOLLOWS:
#!/usr/local/bin/bash
cd ~/svnw/wicket-trunk
svn update
mvn -P release site:deploy
PATCH FOLLOWS:
Index: pom.xml
===================================================================
--- pom.xml (revision 579617)
+++ pom.xml (working copy)
@@ -129,7 +129,7 @@
<distributionManagement>
<site>
<id>local</id>
- <url>file:target/site/</url>
+
<url>file:/home/tobrien/public_html/wicket/</url>
</site>
<repository>
<id>local</id>
@@ -709,6 +709,10 @@
<inherited>true</inherited>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
+ <configuration>
+ <aggregate>true</aggregate>
+
<excludePackageNames>org.apache.wicket.examples.*:org.apache.wicket.examples</excludePackageNames>
+ </configuration>
</plugin>
</plugins>
</reporting>
On 9/20/07, Gwyn Evans <gw...@gmail.com> wrote:
> On Thursday, September 20, 2007, 11:13:23 PM, Tim <to...@discursive.com> wrote:
>
> > BTW, I'm continuing to run the full javadoc build in ~tobrien as an interim
> > solution. It certainly isn't ideal, but it's one way to solve the
> > problem. I'll keep an eye on the discussion.
>
> Please flag it (to myself or Martijn, if no-one else) if/when that
> changes, as that's where the JavaDoc link on the front page goes! :-)
>
> /Gwyn
>
>
--
------
Tim O'Brien: (847) 863-7045
Re: mvn site: a possible solution
Posted by Gwyn Evans <gw...@gmail.com>.
On Thursday, September 20, 2007, 11:13:23 PM, Tim <to...@discursive.com> wrote:
> BTW, I'm continuing to run the full javadoc build in ~tobrien as an interim
> solution. It certainly isn't ideal, but it's one way to solve the
> problem. I'll keep an eye on the discussion.
Please flag it (to myself or Martijn, if no-one else) if/when that
changes, as that's where the JavaDoc link on the front page goes! :-)
/Gwyn
Re: mvn site: a possible solution
Posted by Tim O'Brien <to...@discursive.com>.
BTW, I'm continuing to run the full javadoc build in ~tobrien as an interim
solution. It certainly isn't ideal, but it's one way to solve the
problem. :-) I'll keep an eye on the discussion.
On 9/10/07, Gerolf Seitz <ge...@gmail.com> wrote:
>
> issue filed: https://issues.apache.org/jira/browse/WICKET-952
>
> gerolf
>
> On 9/10/07, Gerolf Seitz <ge...@gmail.com> wrote:
> >
> > right, i somehow missed that one can add repositories, dependencies and
> > all that stuff on a per profile basis.
> >
> > i just noticed that i had an unfinished sentence in the solution for 2):
> > unfortunately the urls are created using the name of the module (eg.
> > Wicket Extensions)
> > instead of the artifact ids (eg. wicket-extensions), which makes it a
> > little less web friendly
> > due to the blanks, but i think this shouldn't be a show stopper.
> >
> > for now i will put maven-flattire-plugin in the wicketstuff svn
> repository
> > (as igor suggested) and
> > provide a patch for the parent pom.xml with the modifications for the
> > site-creation,
> > so that it's easier to try it out and review the actual changes.
> >
> > gerolf
> >
> > On 9/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > >
> > > i dont think plugin availability will be a problem. it can live in our
> > > wicketstuff repo for our build so it should be automatic, just include
> > > that
> > > repo in the profile for sitegen. if it becomes more popular submit it
> to
> > > the
> > > main repo, its not a big deal to get stuff into it afaik.
> > >
> > >
> > > -igor
> > >
> > >
> > > On 9/9/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.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/
> > > >
> > >
> >
> >
>
--
------
Tim O'Brien: (847) 863-7045
Re: mvn site: a possible solution
Posted by Gerolf Seitz <ge...@gmail.com>.
issue filed: https://issues.apache.org/jira/browse/WICKET-952
gerolf
On 9/10/07, Gerolf Seitz <ge...@gmail.com> wrote:
>
> right, i somehow missed that one can add repositories, dependencies and
> all that stuff on a per profile basis.
>
> i just noticed that i had an unfinished sentence in the solution for 2):
> unfortunately the urls are created using the name of the module (eg.
> Wicket Extensions)
> instead of the artifact ids (eg. wicket-extensions), which makes it a
> little less web friendly
> due to the blanks, but i think this shouldn't be a show stopper.
>
> for now i will put maven-flattire-plugin in the wicketstuff svn repository
> (as igor suggested) and
> provide a patch for the parent pom.xml with the modifications for the
> site-creation,
> so that it's easier to try it out and review the actual changes.
>
> gerolf
>
> On 9/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > i dont think plugin availability will be a problem. it can live in our
> > wicketstuff repo for our build so it should be automatic, just include
> > that
> > repo in the profile for sitegen. if it becomes more popular submit it to
> > the
> > main repo, its not a big deal to get stuff into it afaik.
> >
> >
> > -igor
> >
> >
> > On 9/9/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.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/
> > >
> >
>
>
Re: mvn site: a possible solution
Posted by Gerolf Seitz <ge...@gmail.com>.
right, i somehow missed that one can add repositories, dependencies and all
that stuff on a per profile basis.
i just noticed that i had an unfinished sentence in the solution for 2):
unfortunately the urls are created using the name of the module (eg. Wicket
Extensions)
instead of the artifact ids (eg. wicket-extensions), which makes it a little
less web friendly
due to the blanks, but i think this shouldn't be a show stopper.
for now i will put maven-flattire-plugin in the wicketstuff svn repository
(as igor suggested) and
provide a patch for the parent pom.xml with the modifications for the
site-creation,
so that it's easier to try it out and review the actual changes.
gerolf
On 9/10/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> i dont think plugin availability will be a problem. it can live in our
> wicketstuff repo for our build so it should be automatic, just include
> that
> repo in the profile for sitegen. if it becomes more popular submit it to
> the
> main repo, its not a big deal to get stuff into it afaik.
>
>
> -igor
>
>
> On 9/9/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/
> >
>
Re: mvn site: a possible solution
Posted by Igor Vaynberg <ig...@gmail.com>.
i dont think plugin availability will be a problem. it can live in our
wicketstuff repo for our build so it should be automatic, just include that
repo in the profile for sitegen. if it becomes more popular submit it to the
main repo, its not a big deal to get stuff into it afaik.
-igor
On 9/9/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/
>
Re: mvn site: a possible solution
Posted by David Bernard <dw...@free.fr>.
Hi,
I've done a similar job for a previous project (an eclipse application with lot of module (one per eclipse's plugin)) 8 months ago.
If you want I could help you.
FYI, the javadoc plugin have a usefull feature : create a "flatten" javadoc for multi-module project, that avoid to bookmark every module's javadoc.
I also thinks that generate htmlized java files is usefull and easier (color, links) than SVN to browse the source and the test to understand how it works without the need to download the source,
create a project in our IDE,...
/david
Gerolf Seitz 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/
>
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/
>
Re: mvn site: a possible solution
Posted by Martijn Dashorst <ma...@gmail.com>.
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/