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 15:56:49 GMT
On 10/12/2011 03:07 PM, Eric Charles wrote:
> On 12/10/11 12:18, Felix Knecht wrote:
>> 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.
>
> I remember that also :)
>
> <snip>
>> 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 still need to take time to give feedback on option A) and B).
>
>>>
>>> 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.
>>
>
> mmh, releasing TLP pom to change a derby version for example is not nice
> either...
>
> maybe others can comment, I can see benefits and drawbacks in both
> scenarii.
>
>>>
>>> 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?
>>
>
> Don't know, but I will burn a candle before trying. I guess/home it
> should work.
>
>> When refactoring poms we should definitely make use of the
>> dependency:tree dependency:analyze ... goals of maven to clean it up.
>>
>
> dependency:analyze is great for post analysis, but we need some kind of
> general rules to know how to implement.
>
>>> I don't bring answers but questions here...
>>
>> But they can help to clarify the problem :-)

One more ...

Can or should we find a more consistent naming for the produced artifacts?
Look the prefixes at http://repo1.maven.org/maven2/org/apache/james/
- apache-james
- apache
- james
- maven
- none

>>
>> 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'.
>>
>
> slf4j-* is one more topic to list in our pom/dependency discussion. Very
> interesting!
>
> At the end, it will be good to have all those rules/practices documented
> on http://james.apache.org/guidelines.html (or anywhere else, but
> somewhere).
>
>> Regard
>> Felix
>>
>> PS:
>> Still no answers ;-)
>
> Asking is already giving the half of the answer.
>
>>
>>>
>>> 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
>>
>


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


Mime
View raw message