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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/ > > >
