You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Felix Knecht <fe...@apache.org> on 2011/10/09 16:58:32 UTC
Refactoring TLP pom (was Re: Mailbox doc)
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
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Oct 12, 2011 at 9:30 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
<snip>
>> or wait some comment from Robert before taking any step.
>
> As I've recently learnt, trademarks are tricky and any interpretations
> ("apache is a trademark, james, mime4j, imap are not trademarks") are
> best avoided on public lists.
>
> Apache lists "Apache James" and "James" as marks[1]
Hopefully this is fact. Facts are fine.
(no criticism of Stefano intended)
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Oct 12, 2011 at 8:31 PM, Stefano Bagnara <ap...@bago.org> wrote:
> 2011/10/12 Ioan Eugen Stan <st...@gmail.com>:
>>> 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
>>
>> Very good point Felix, I agree that we should adopt a constant naming
>> convention.
>>
>> I think we can skip Apache from the artifact name, because they apear
>> in the group ID. We can keep the name in the parts intended for users
>> (site, documentation, etc.). I will probably have time for this and
>> pom in refactoring the weekend.
Please be aware that changing artifact names impacts downstream users.
Consider carefully before annoying them :-)
> I just want to point out that in past we added some "apache-" prefix
> around in order to have better trademark protection from ASF (apache
> is a trademark, james, mime4j, imap are not trademarks).
I'm not sure it's wise to put it quite like that. Historically, one of
the motivations behind prefixing all releases (with "apache-" say)
arose from the improved trademark protection gained.
Pragmatically, any jar not prefixed with one of our marks (whether
"apache-" or some other) ATM requires some extra manual verification
when verifying that we have rights to ship the jar.
> After years I still don't have a good understanding about this stuff,
> so maybe you want to read some documents from the asf website
http://www.apache.org/foundation/marks/
> or wait some comment from Robert before taking any step.
As I've recently learnt, trademarks are tricky and any interpretations
("apache is a trademark, james, mime4j, imap are not trademarks") are
best avoided on public lists.
Apache lists "Apache James" and "James" as marks[1]
Robert
[1] http://www.apache.org/foundation/marks/list/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Stefano Bagnara <ap...@bago.org>.
2011/10/12 Ioan Eugen Stan <st...@gmail.com>:
>> 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
>
> Very good point Felix, I agree that we should adopt a constant naming
> convention.
>
> I think we can skip Apache from the artifact name, because they apear
> in the group ID. We can keep the name in the parts intended for users
> (site, documentation, etc.). I will probably have time for this and
> pom in refactoring the weekend.
I just want to point out that in past we added some "apache-" prefix
around in order to have better trademark protection from ASF (apache
is a trademark, james, mime4j, imap are not trademarks).
After years I still don't have a good understanding about this stuff,
so maybe you want to read some documents from the asf website or wait
some comment from Robert before taking any step.
> If I get any bright ideas until then I will call.
>
> p.s. , offtopic : I just received my visa today so I'm going to ApacheCon :D.
>
> --
> Ioan Eugen Stan
> http://ieugen.blogspot.com/
>
> ---------------------------------------------------------------------
> 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
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Ioan Eugen Stan <st...@gmail.com>.
> 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
Very good point Felix, I agree that we should adopt a constant naming
convention.
I think we can skip Apache from the artifact name, because they apear
in the group ID. We can keep the name in the parts intended for users
(site, documentation, etc.). I will probably have time for this and
pom in refactoring the weekend.
If I get any bright ideas until then I will call.
p.s. , offtopic : I just received my visa today so I'm going to ApacheCon :D.
--
Ioan Eugen Stan
http://ieugen.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Felix Knecht <fe...@apache.org>.
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
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Eric Charles <er...@apache.org>.
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 :-)
>
> 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
>
--
Eric
http://about.echarles.net
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Felix Knecht <fe...@apache.org>.
On 10/12/2011 12:31 PM, Stefano Bagnara wrote:
> 2011/10/12 Felix Knecht<fe...@apache.org>
>> On 10/12/2011 11:36 AM, Eric Charles wrote:
>>> 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.
>
> I am the author of the mess :-)
> So, I try to explain why it worked that way, but it's been a while, so
> I'm not sure I remember the details.
>
> I did loose a lot of time with try and error to reach the current
> structure and I settled to that structure because it was the only one
> that worked fine with maven, maven site, the skin and the release
> process.
I remember that time being happy finally having something working :-)
> Now, since I did that we use a new maven version (3 vs 2) and a lot of
> new "site-plugin" versions have been released and maybe they fixed the
> issues that prevented me to use a simpler layout, so feel free to
> change it.
>
> Just remember to test also the release process as it easy to have
> circular dependencies between the skin and the parent using the skin
> (unless you want duplication of configuration between parent and the
> skin you will have skin to depend on parent).
I'll setup a sample in my sandbox. So we have something real to discuss
on it and see if it works.
Regards
Felix
>
> I'm sorry I have no time currently to give good answers to your other
> questions, feel free to go ahead if you find an easier working
> solution.
> Stefano
>
> ---------------------------------------------------------------------
> 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
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Stefano Bagnara <ap...@bago.org>.
2011/10/12 Felix Knecht <fe...@apache.org>
> On 10/12/2011 11:36 AM, Eric Charles wrote:
>> 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.
I am the author of the mess :-)
So, I try to explain why it worked that way, but it's been a while, so
I'm not sure I remember the details.
I did loose a lot of time with try and error to reach the current
structure and I settled to that structure because it was the only one
that worked fine with maven, maven site, the skin and the release
process.
Now, since I did that we use a new maven version (3 vs 2) and a lot of
new "site-plugin" versions have been released and maybe they fixed the
issues that prevented me to use a simpler layout, so feel free to
change it.
Just remember to test also the release process as it easy to have
circular dependencies between the skin and the parent using the skin
(unless you want duplication of configuration between parent and the
skin you will have skin to depend on parent).
I'm sorry I have no time currently to give good answers to your other
questions, feel free to go ahead if you find an easier working
solution.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Felix Knecht <fe...@apache.org>.
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'.
Regard
Felix
PS:
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
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Eric Charles <er...@apache.org>.
Hi Felix,
Thx for launching the discussion and implementing in a sandbox :)
I feel your focus is the maven-skin. Right?
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?
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 don't bring answers but questions here...
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
>
--
Eric
http://about.echarles.net
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Refactoring TLP pom (was Re: Mailbox doc)
Posted by Ioan Eugen Stan <st...@gmail.com>.
2011/10/9 Felix Knecht <fe...@apache.org>:
> 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: 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
>
>
--
Ioan Eugen Stan
http://ieugen.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org