You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Chris Custine <ch...@gmail.com> on 2007/06/21 23:48:56 UTC
Maven pom fixes
While I was looking into the server-main logging issue (
https://issues.apache.org/jira/browse/DIRSERVER-979), I came to the
conclusion that our logging config in the poms needs some cleanup so I want
to make the following proposal.
1). Add slf4j default dependencies to parent pom.xml for each project such
as daemon, shared, apacheds). There is a lot of duplication of logging
setup in every subproject, so this would configure the default as slf4j-api
for compile scope and either slf4j-simple or slf4j-nlog4j for test scope
(requires concrete slf4j impl for JUnit tests). This would mean that normal
subprojects don't need additional dependencies in their pom and will use the
default which works for almost all 35-40 subprojects except those that
require actual runtime packaging. For the remaining projects that require
runtime dependencies such as server-installers, server-main, and the
plugins, we just add a concrete slf4j implementation like nlog4j to the
subproject pom and it will package up all the dependencies. This config
will also help fix https://issues.apache.org/jira/browse/DIRSERVER-979 and
it limits transitive dependencies in our maven artifacts so that users can
use their own impls.
2). Replace commons-logging with jcl104-over-slf4j which is a clone of
commons-logging that will just defer to slf4j. Commons-logging is required
at runtime by spring and possibly some other dependencies but it has some
peculiar problems that aren't obvious. If anyone wants more info on this I
can go on for days about it...
I was also thinking we could provide maven profiles for specifying the
inclusion of different log impls in server-main since this has come up a few
times. The installers will package nlog4j as a default, and the user can
change them out if required.
I would also like to go ahead and update the apacheds, shared, and daemon
parent poms to *-parent since it also requires modifying all of the poms in
each subproject (https://issues.apache.org/jira/browse/DIRSERVER-977) as
long as no one objects. I have all of these changes running locally and
have tested them out quite a bit today.
Sorry this is a little lengthy. Does anyone have any opinions or ideas?
Chris
Re: Maven pom fixes
Posted by Chris Custine <ch...@gmail.com>.
Ok, its not a big difference anyway so I'll use nlog4j then.
On 6/23/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Hmmm sometimes I do it. Sometimes tests pass in eclipse which makes me
> wonder what is going on when the same test fails with maven. Turning on
> tracing (DEBUG) in these cases has some value but it is not used all the
> time but under these not so rare circumstances.
>
> Alex
>
> On 6/23/07, Chris Custine <ch...@gmail.com> wrote:
> >
> > I forgot to mention that JUnit and slf4j are the only modules that EVERY
> > subproject have in common, so that drove me to thinking that we could
> > simplify the setup.
> >
> > One more thing, in my own projects I use slf4j-simple as a test scope
> > dependency to satisfy unit testing output. slf4j-simple outputs INFO, WARN,
> > and ERROR log levels to stdout and that is all it does. I was thinking we
> > could use that as a standard dependency (test scope) and use nlog4j where we
> > create packages. Does anyone ever want to output DEBUG while running unit
> > tests?
> >
> > Chris
> >
> > On 6/23/07, Alex Karasulu < akarasulu@apache.org> wrote:
> > >
> > > Go for it Chris! I trust you have a better grasp of this than I do.
> > >
> > > Thanks,
> > > Alex
> > >
> > > On 6/21/07, Chris Custine < chris.custine@gmail.com> wrote:
> > > >
> > > > While I was looking into the server-main logging issue ( https://issues.apache.org/jira/browse/DIRSERVER-979
> > > > ), I came to the conclusion that our logging config in the poms
> > > > needs some cleanup so I want to make the following proposal.
> > > >
> > > > 1). Add slf4j default dependencies to parent pom.xml for each
> > > > project such as daemon, shared, apacheds). There is a lot of duplication of
> > > > logging setup in every subproject, so this would configure the default as
> > > > slf4j-api for compile scope and either slf4j-simple or slf4j-nlog4j for test
> > > > scope (requires concrete slf4j impl for JUnit tests). This would mean that
> > > > normal subprojects don't need additional dependencies in their pom and will
> > > > use the default which works for almost all 35-40 subprojects except those
> > > > that require actual runtime packaging. For the remaining projects that
> > > > require runtime dependencies such as server-installers, server-main, and the
> > > > plugins, we just add a concrete slf4j implementation like nlog4j to the
> > > > subproject pom and it will package up all the dependencies. This config
> > > > will also help fix
> > > > https://issues.apache.org/jira/browse/DIRSERVER-979 and it limits
> > > > transitive dependencies in our maven artifacts so that users can use their
> > > > own impls.
> > > >
> > > > 2). Replace commons-logging with jcl104-over-slf4j which is a clone
> > > > of commons-logging that will just defer to slf4j. Commons-logging is
> > > > required at runtime by spring and possibly some other dependencies but it
> > > > has some peculiar problems that aren't obvious. If anyone wants more info
> > > > on this I can go on for days about it...
> > > >
> > > > I was also thinking we could provide maven profiles for specifying
> > > > the inclusion of different log impls in server-main since this has come up a
> > > > few times. The installers will package nlog4j as a default, and the user
> > > > can change them out if required.
> > > >
> > > > I would also like to go ahead and update the apacheds, shared, and
> > > > daemon parent poms to *-parent since it also requires modifying all of the
> > > > poms in each subproject (https://issues.apache.org/jira/browse/DIRSERVER-977)
> > > > as long as no one objects. I have all of these changes running locally and
> > > > have tested them out quite a bit today.
> > > >
> > > > Sorry this is a little lengthy. Does anyone have any opinions or
> > > > ideas?
> > > >
> > > > Chris
> > > >
> > >
> > >
> >
>
Re: Maven pom fixes
Posted by Alex Karasulu <ak...@apache.org>.
Hmmm sometimes I do it. Sometimes tests pass in eclipse which makes me
wonder what is going on when the same test fails with maven. Turning on
tracing (DEBUG) in these cases has some value but it is not used all the
time but under these not so rare circumstances.
Alex
On 6/23/07, Chris Custine <ch...@gmail.com> wrote:
>
> I forgot to mention that JUnit and slf4j are the only modules that EVERY
> subproject have in common, so that drove me to thinking that we could
> simplify the setup.
>
> One more thing, in my own projects I use slf4j-simple as a test scope
> dependency to satisfy unit testing output. slf4j-simple outputs INFO, WARN,
> and ERROR log levels to stdout and that is all it does. I was thinking we
> could use that as a standard dependency (test scope) and use nlog4j where we
> create packages. Does anyone ever want to output DEBUG while running unit
> tests?
>
> Chris
>
> On 6/23/07, Alex Karasulu <ak...@apache.org> wrote:
> >
> > Go for it Chris! I trust you have a better grasp of this than I do.
> >
> > Thanks,
> > Alex
> >
> > On 6/21/07, Chris Custine < chris.custine@gmail.com> wrote:
> > >
> > > While I was looking into the server-main logging issue ( https://issues.apache.org/jira/browse/DIRSERVER-979
> > > ), I came to the conclusion that our logging config in the poms needs
> > > some cleanup so I want to make the following proposal.
> > >
> > > 1). Add slf4j default dependencies to parent pom.xml for each project
> > > such as daemon, shared, apacheds). There is a lot of duplication of logging
> > > setup in every subproject, so this would configure the default as slf4j-api
> > > for compile scope and either slf4j-simple or slf4j-nlog4j for test scope
> > > (requires concrete slf4j impl for JUnit tests). This would mean that normal
> > > subprojects don't need additional dependencies in their pom and will use the
> > > default which works for almost all 35-40 subprojects except those that
> > > require actual runtime packaging. For the remaining projects that require
> > > runtime dependencies such as server-installers, server-main, and the
> > > plugins, we just add a concrete slf4j implementation like nlog4j to the
> > > subproject pom and it will package up all the dependencies. This config
> > > will also help fix https://issues.apache.org/jira/browse/DIRSERVER-979and it limits transitive dependencies in our maven artifacts so that users
> > > can use their own impls.
> > >
> > > 2). Replace commons-logging with jcl104-over-slf4j which is a clone of
> > > commons-logging that will just defer to slf4j. Commons-logging is required
> > > at runtime by spring and possibly some other dependencies but it has some
> > > peculiar problems that aren't obvious. If anyone wants more info on this I
> > > can go on for days about it...
> > >
> > > I was also thinking we could provide maven profiles for specifying the
> > > inclusion of different log impls in server-main since this has come up a few
> > > times. The installers will package nlog4j as a default, and the user can
> > > change them out if required.
> > >
> > > I would also like to go ahead and update the apacheds, shared, and
> > > daemon parent poms to *-parent since it also requires modifying all of the
> > > poms in each subproject (https://issues.apache.org/jira/browse/DIRSERVER-977)
> > > as long as no one objects. I have all of these changes running locally and
> > > have tested them out quite a bit today.
> > >
> > > Sorry this is a little lengthy. Does anyone have any opinions or
> > > ideas?
> > >
> > > Chris
> > >
> >
> >
>
Re: Maven pom fixes
Posted by Chris Custine <ch...@gmail.com>.
I forgot to mention that JUnit and slf4j are the only modules that EVERY
subproject have in common, so that drove me to thinking that we could
simplify the setup.
One more thing, in my own projects I use slf4j-simple as a test scope
dependency to satisfy unit testing output. slf4j-simple outputs INFO, WARN,
and ERROR log levels to stdout and that is all it does. I was thinking we
could use that as a standard dependency (test scope) and use nlog4j where we
create packages. Does anyone ever want to output DEBUG while running unit
tests?
Chris
On 6/23/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Go for it Chris! I trust you have a better grasp of this than I do.
>
> Thanks,
> Alex
>
> On 6/21/07, Chris Custine < chris.custine@gmail.com> wrote:
> >
> > While I was looking into the server-main logging issue ( https://issues.apache.org/jira/browse/DIRSERVER-979
> > ), I came to the conclusion that our logging config in the poms needs
> > some cleanup so I want to make the following proposal.
> >
> > 1). Add slf4j default dependencies to parent pom.xml for each project
> > such as daemon, shared, apacheds). There is a lot of duplication of logging
> > setup in every subproject, so this would configure the default as slf4j-api
> > for compile scope and either slf4j-simple or slf4j-nlog4j for test scope
> > (requires concrete slf4j impl for JUnit tests). This would mean that normal
> > subprojects don't need additional dependencies in their pom and will use the
> > default which works for almost all 35-40 subprojects except those that
> > require actual runtime packaging. For the remaining projects that require
> > runtime dependencies such as server-installers, server-main, and the
> > plugins, we just add a concrete slf4j implementation like nlog4j to the
> > subproject pom and it will package up all the dependencies. This config
> > will also help fix https://issues.apache.org/jira/browse/DIRSERVER-979and it limits transitive dependencies in our maven artifacts so that users
> > can use their own impls.
> >
> > 2). Replace commons-logging with jcl104-over-slf4j which is a clone of
> > commons-logging that will just defer to slf4j. Commons-logging is required
> > at runtime by spring and possibly some other dependencies but it has some
> > peculiar problems that aren't obvious. If anyone wants more info on this I
> > can go on for days about it...
> >
> > I was also thinking we could provide maven profiles for specifying the
> > inclusion of different log impls in server-main since this has come up a few
> > times. The installers will package nlog4j as a default, and the user can
> > change them out if required.
> >
> > I would also like to go ahead and update the apacheds, shared, and
> > daemon parent poms to *-parent since it also requires modifying all of the
> > poms in each subproject (https://issues.apache.org/jira/browse/DIRSERVER-977)
> > as long as no one objects. I have all of these changes running locally and
> > have tested them out quite a bit today.
> >
> > Sorry this is a little lengthy. Does anyone have any opinions or ideas?
> >
> >
> > Chris
> >
>
>
Re: Maven pom fixes
Posted by Alex Karasulu <ak...@apache.org>.
Go for it Chris! I trust you have a better grasp of this than I do.
Thanks,
Alex
On 6/21/07, Chris Custine <ch...@gmail.com> wrote:
>
> While I was looking into the server-main logging issue (https://issues.apache.org/jira/browse/DIRSERVER-979
> ), I came to the conclusion that our logging config in the poms needs some
> cleanup so I want to make the following proposal.
>
> 1). Add slf4j default dependencies to parent pom.xml for each project such
> as daemon, shared, apacheds). There is a lot of duplication of logging
> setup in every subproject, so this would configure the default as slf4j-api
> for compile scope and either slf4j-simple or slf4j-nlog4j for test scope
> (requires concrete slf4j impl for JUnit tests). This would mean that normal
> subprojects don't need additional dependencies in their pom and will use the
> default which works for almost all 35-40 subprojects except those that
> require actual runtime packaging. For the remaining projects that require
> runtime dependencies such as server-installers, server-main, and the
> plugins, we just add a concrete slf4j implementation like nlog4j to the
> subproject pom and it will package up all the dependencies. This config
> will also help fix https://issues.apache.org/jira/browse/DIRSERVER-979 and
> it limits transitive dependencies in our maven artifacts so that users can
> use their own impls.
>
> 2). Replace commons-logging with jcl104-over-slf4j which is a clone of
> commons-logging that will just defer to slf4j. Commons-logging is required
> at runtime by spring and possibly some other dependencies but it has some
> peculiar problems that aren't obvious. If anyone wants more info on this I
> can go on for days about it...
>
> I was also thinking we could provide maven profiles for specifying the
> inclusion of different log impls in server-main since this has come up a few
> times. The installers will package nlog4j as a default, and the user can
> change them out if required.
>
> I would also like to go ahead and update the apacheds, shared, and daemon
> parent poms to *-parent since it also requires modifying all of the poms in
> each subproject ( https://issues.apache.org/jira/browse/DIRSERVER-977) as
> long as no one objects. I have all of these changes running locally and
> have tested them out quite a bit today.
>
> Sorry this is a little lengthy. Does anyone have any opinions or ideas?
>
> Chris
>