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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org