james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Knecht <fel...@apache.org>
Subject Re: Refactoring TLP pom (was Re: Mailbox doc)
Date Wed, 12 Oct 2011 10:18:47 GMT
Hi Eric

On 10/12/2011 11:36 AM, Eric Charles wrote:
> Hi Felix,
> Thx for launching the discussion and implementing in a sandbox :)
> I feel your focus is the maven-skin. Right?

Well it's not that I'm focussing on maven-skin (anyway the name might be 
confusing ...) but I remember when started in the James project. It was 
really hard to figure out the hierarchy parent poms. Some where 
referencing james-project, others james-parent. Having a quick look at 
the filesystem I could not find a short answer because I found it quite 
a mess. Having a project/project/'james-project'.pom.xml which was 
mainly used as modules parent pom but referencing to 
project/'james.parent'.pom.xml. In fact this is the real TLP pom.xml - 
it must be, because referencing as parent the apache.pom. But way are 
some modules referencing the one and other modules the other pom as 
'TLP' pom? And which is now the real source code which is work on?
The conclusion is that it's historical grown and longtime members are 
aware of what is actual and what isn't, but still there for ??

We can have A) or B). But if we choose B) the project/project tree must 
be cleaned and the project/pom.xml will have as only task to build the 2 
modules 'skin' and 'project' whereas project is the TLP pom to use as 
parent for all other James modules.

> I am also concerned with the way we handle the version dependencies.
> Example: For now, each of the project (imap, mailbox...) has freedom to
> define the derby version. This sometimes can give issues, as projects
> are implemented/tested against a specific version, and this can give
> issues. So, Should parent impose the version, or should we leave freedom
> to subprojects to do so?

I don't know which is better. Having the dependencyManagement in the TLP 
pom it will probably mean to release often also TLP pom. OTH we don't 
need to fight a dependency version hell among the modules.

> Also, the transitive dependencies are sometimes/often declared around
> (example, if a project uses mailbox-jpa, it still declares openjpa
> altough openjpa is a transitive dependency of mailbox-jpa). For example,
> I'm puzzled to need to exclude jruby in all projects. If we rely on the
> transitive resolution, we only have to exclude once. This point is not
> directly related to the parent structure, but more linked to a
> 'transitive dependency' discussion. But I feel it's also linked to the
> pom hierarchy in a way...

I feel the same (see above). You're talking about my latest excludes in 
the spring module for tests I suppose (of course others exists as well) 
- I'm not sure if trasitive exclusion also works for dependencies of 
scope test. Does anybody knows more about this?

When refactoring poms we should definitely make use of the 
dependency:tree dependency:analyze ... goals of maven to clean it up.

> I don't bring answers but questions here...

But they can help to clarify the problem :-)

Another point is to define what to use for logging tests and where to 
deploy a logging implementation. We use SLF4J as facade. IMO this 
implicates not to deploy any logging framewoks like log4j (including 
slf4j-log4j12) or similar exept when packaging a distribution. Therefore 
all such logging frameworks should be excluded. The only dependency 
should be slfj4-api. For logging tests we should agree on one like 
slf4j-simple or slf4j-nop scoped 'test'.


Still no answers ;-)

> Thx,
> Eric
> On 09/10/11 16:58, Felix Knecht wrote:
>> On 10/09/2011 11:28 AM, Felix Knecht wrote:
>> Hi all
>> 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?
>> 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.
>> When going the 2nd way B) we should IMO move the legacy server [6] tree
>> to somewhere else as it is no longer used.
>> 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]
>> [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: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message