2011/10/9 Felix Knecht <[email protected]>: > On 10/09/2011 11:28 AM, Felix Knecht wrote: > Hi all
Hi Felix, I see you did a lot of thinking on this matter. I don't know the full extent of the changes you proposed, but I will state my mind. > > A) > I setup a small sample how this could look alike when splitting things off > and discard legacy things. > > Have a TLP pom.xml (james-parent / james-project or ...) being a merge of > the 2 former TLP/parent poms [1][2]. New the pluginManagement section will > contain all the plugins with their version and their configuration so far > this can be applied to each module. This is specially the case for the site > generation (not only javadoc). > > The skin module [3] is no longer part of the TLP pom module but has its own > module space lets name it james-skin which is less irritating than > maven-skin at first glance. > > What shall happen with the existing project tree [1], which will become > obsolete? Will it be replace by the proposed TLP module (when it gets named > 'james-project') or does it just stays as it is and a new module 'parent' > for TLP module is created? I didn't understand why there are parent and project so I'm for merging them if there are no reasons not to. > B) > Another approach than splitting up in different modules is to clean up the > current parent.pom [4] so it contains more or less only the definitions to > build the project maven-skin and the project module. This will mean [4] > will not have a <parent> definition (and all the other stuff like > <properties>, <developers>, ...) at all and the TLP pom will be the current > project.pom [5]. Definitions now in the parent.pom [4] will be merged into > the new TLP pom [5]. The new TLP pom [5] will have as parent > org.apache/apache. This looks good. Inheriting right from apache and simplify the inheritance schema. > When going the 2nd way B) we should IMO move the legacy server [6] tree to > somewhere else as it is no longer used. I'm also up for this. > wdyt? > > Regards > Felix > PS > @Eugen > I also setup mailbox in my sandbox project [7] to see if and how it works. > I'm neither able to generate the site (mvn site) nor to genrate the > technical reports (mvn site -Psite-reports). In both situations I get > following error which is hardly a problem of the new structure using the > demo poms but resulting of the javadoc-plugin configuration somehow. Do you > haven any ideas what could be wrong? > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-javadoc-plugin:2.8:aggregate (default) on > project apache-james-mailbox: An error has occurred in JavaDocs report > generation: > [ERROR] Exit code: 1 - javadoc: error - > /home/felix/svn/apache/james/trunk/sandbox/felixk/mailbox/target/classes > doesn't exist or is not readable. > [ERROR] > [ERROR] Command line was: /usr/lib/jvm/jdk1.7.0/jre/../bin/javadoc > -J-Xmx1024m -J-Xms256m @options @packages > [ERROR] This is APIviz not dealing ok with pom packaged projects that don't have java classes to compile. I came up with some solutions: 1. configure things in pluginManagement but leave the doclet definition out and declare it in all the pom's that need it. This means that we have to declare APIviz as the doclet for every project that is packaged as jar. APIviz needs classes to build the diagrams (it discovers relatios between classes that way). 2. I didn't get this working: same as above, except we declare the doclet as APIviz and redeclare the doclet as standard doclet in the pom's so they won't fail. > [1] https://svn.apache.org/repos/asf/james/project/trunk > [2] https://svn.apache.org/repos/asf/james/project/trunk/project > [3] https://svn.apache.org/repos/asf/james/project/trunk/maven-skin > [4] https://svn.apache.org/repos/asf/james/project/trunk/pom.xml > [5] https://svn.apache.org/repos/asf/james/project/trunk/project/pom.xml > [6] https://svn.apache.org/repos/asf/james/project/trunk/project/server > [7] https://svn.apache.org/repos/asf/james/trunk/sandbox/felixk/mailbox > >> Hi Eugen >> >> Your right :-) >> >> On 10/08/2011 09:18 PM, Ioan Eugen Stan wrote: >>> >>> Thanks, I am not familiar with the installation for the rest of the >>> implementations, including guice. Maybe you can put in some words >>> about them? >>> >>> For now, I am trying to make APIviz docs just for mailbox, and it >>> seems that the pom hierarchy is very complex. I have a solution for >>> standard javadoc:javadoc but that doesn't apply for site generation. I >>> will try to find a way to configure the site generation javadoc plugin >>> so all is ok. >>> >>> I did notice that the pom files need some clean-up and refactoring. >>> For example, for javadoc-plugin there is a lot of duplicate >>> configuration. I suggest we move a lot of the common configuration to >>> PluginManagement and dependencyManagement sections in the parent pom >>> and rely on inheritance to solve the rest of the issues. >> >> IMO we could do this for all kind of reporting plugins, not only for the >> javadoc one. Most of are used in the maven-site-plugin anyway. This >> would mean, that parent pom (org.apache.james/james-project.pom) will be >> released quite often, e.g. when updating to the latest reporting plugin >> versions. I'm not aware, that we can change the version but keep the >> configuration in a child pom, but maybe anybody knows more about this. >> Doing the configurations in the parent pom would make the child poms >> smaller. >> >> I wonder if we could not even merge the james-parent.pom and the >> james-project.pom into james-parent.pom? AFAICS james.project.pom would >> build legacy documentation for the server what is commented anyway. >> Doing so the project/project/src/site would need to be moved one level >> up as well (into james-parent.pom) >> >> We could even clean up the directory tree and move the legacy server 2.x >> stuff into a branch or to attic or where ever and have the james-parent >> renamed to the real name 'james-parent' from 'james-project', containg >> only the parent pom including pluginManagement section (including >> configurations for plugins used be site generation such as javadoc, >> findbugs and others) and the stuff for general site src stuff which is >> located atm @project/project/src/site. >> >> wdot? >> >> Regards >> Felix >> >>> >>> What do you think? >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Ioan Eugen Stan http://ieugen.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
