You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2005/10/09 11:38:25 UTC
[logging] dependencies [WAS Re: [logging] new release?]
On Fri, 2005-10-07 at 22:16 +1300, Simon Kitching wrote:
> Hi All,
>
> A week or so ago I was prompted by new activity on the logging topic to
> review what is currently sitting in SVN. I think it's actually quite
> good, and perhaps we could try to push for a release.
>
> The issues I'm aware of are:
> * Do we include the ServletContextListener stuff or not? And if we do,
> do we put it in an "optional" jar or in the main jar?
>
> Personally, I would like to include it, and put it in the main jar.
> It does no harm being there, as no logging classes reference it. It
> only gets used if someone explicitly references it from a web.xml
> file.
>
> There have been objections about adding "dependencies", but JCL is
> a project that already has heaps of compile-time dependencies that
> aren't actually runtime dependencies, eg LogKit is a compile-time
> dependency too, but isn't needed to run.
i think that there are a lot of different issues here which could do
with being untangled. i'll make a stab at outlined the different ones i
see (possibly with a few to documenting later). please feel free to kick
off discussion (i've refrained from presenting solutions) and add any
i've missed.
downstream maintainers
----------------------
my major concern was about the impact of JCL dependencies on downstream
maintainers (rather than users). this include the gump infrastructure
and packagers such as debian. JCL is now a really basic component right
at the bottom of the java package tree.
in the best case scenario, more dependencies mean that maintainers have
more work to do. in the worst case scenario, maintainers will be forced
to remove JCL and all packages that depend upon it from their
distribution. for example, debian will only ship java libraries that
will run on a free JVM. so, the impact of adding an innocuous dependency
may be that downstream maintainers are forced to remove scores or
hundreds or packages from their distributions.
perceived dependencies
----------------------
a different concern is that users are given the wrong impression of the
libraries which are required to run JCL. this includes users who feel
they need to find and download sources for all dependencies and those
who need to distribution and run a minimal stripped down version. what
classes and dependencies are required is a FAQ.
solution specific jars
----------------------
we ship a number of jars to help users configure JCL effectively in
containers with complex classloaders. this will allow better
documentation to be created describing how to configure JCL effectively.
however, the complexity (and possible confusion) of shipping additional
optional jars is increased by the fact there are already multiple
versions of the core shipped.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
robert burrell donkin <ro...@blueyonder.co.uk> writes:
>> There have been objections about adding "dependencies", but JCL is
>> a project that already has heaps of compile-time dependencies that
>> aren't actually runtime dependencies, eg LogKit is a compile-time
>> dependency too, but isn't needed to run.
>i think that there are a lot of different issues here which could do
>with being untangled. i'll make a stab at outlined the different ones i
>see (possibly with a few to documenting later). please feel free to kick
>off discussion (i've refrained from presenting solutions) and add any
>i've missed.
>downstream maintainers
>----------------------
>my major concern was about the impact of JCL dependencies on downstream
>maintainers (rather than users). this include the gump infrastructure
>and packagers such as debian. JCL is now a really basic component right
>at the bottom of the java package tree.
I think the problem is the perception of "compile time dependencies"
and "run time dependencies" here.
Our current build tool (maven) is not able to distinguish between
compile-time and run-time dependencies. And some packagers don't
understand this and start to require all of the compile time
dependencies also at runtime.
>in the best case scenario, more dependencies mean that maintainers have
>more work to do. in the worst case scenario, maintainers will be forced
>to remove JCL and all packages that depend upon it from their
>distribution. for example, debian will only ship java libraries that
>will run on a free JVM. so, the impact of adding an innocuous dependency
That is a political decision of debian (and e.g. Fedora) to do
so. They won't be able to ship a large number of packages anyway
(e.g. everything that requires Sun libs until either GlassFish or
Geronimo come along far enough to allow the usage of things like mail
or activation).
The question for this scenario is: Do we want to cater to the needs of
"truly free software" (as in GNU) or do we want to continue down the
road of "truly free software" (as in ASF). :-)
>may be that downstream maintainers are forced to remove scores or
>hundreds or packages from their distributions.
No matter what decision we make, there is someone is bound to stand up
and whine. So IMHO we should just continue as it is comfortable to the
JCL community and let the rest sort out the political details.
>perceived dependencies
>----------------------
>a different concern is that users are given the wrong impression of the
>libraries which are required to run JCL. this includes users who feel
>they need to find and download sources for all dependencies and those
>who need to distribution and run a minimal stripped down version. what
>classes and dependencies are required is a FAQ.
+1 I hope that m2 will help us along here in being able to clearly
specify build and runtime dependencies.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
Niall Pemberton wrote:
> You need verson 1.9.2 of the maven-xdoc-plugin to get it to generate the
> comments (it was introduced in version 1.9.0, but doesn't work in 1.9.1).
>
> Validator uses this feature and it works well:
>
> http://jakarta.apache.org/commons/validator/dependencies.html
>
> Hopefully maven 2 will be better though - it has "scopes" for depenencies
> which hopefully it uses to create a better dependency report (I haven't
> tried it yet)
You can classify your dependencies (test, compile-time, run-time).
A very important feature that is missing in maven1.
Most (all?) things that where bad in maven1 have changed in m2.
I tried m2 and it is really cool. But the site-generation stuff etc. is not
far enough to make it worth to migrate yet. But it will rock!
>
> http://maven.apache.org/maven2/dependency-mechanism.html#dependency_scope
>
> Niall
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDTC3ZmPuec2Dcv/8RAm7CAJwOzDDiCg+DamA7V9sTCbkFV7AoxgCfX5Ls
ybOQKb4BbjIJwj5dnL5/a8U=
=efRo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
You need verson 1.9.2 of the maven-xdoc-plugin to get it to generate the
comments (it was introduced in version 1.9.0, but doesn't work in 1.9.1).
Validator uses this feature and it works well:
http://jakarta.apache.org/commons/validator/dependencies.html
Hopefully maven 2 will be better though - it has "scopes" for depenencies
which hopefully it uses to create a better dependency report (I haven't
tried it yet)
http://maven.apache.org/maven2/dependency-mechanism.html#dependency_scope
Niall
----- Original Message -----
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> > > (logging uses ant for builds but) i agree that this is a major issue
for
> > > all projects that use maven. JCL uses maven to generate the
> > > documentation which is misleading.
> > >
> > > does anyone know how to add comments for dependencies?
> >
> > For Maven 1 it could be solved by setting properties [1] on the
> > dependency. This would be something local to commons-logging that would
> > not work automatically in other places.
> >
> > [1]
> >
http://maven.apache.org/reference/project-descriptor.html#class_Dependency
>
> thanks :)
>
> helped me to track down what i was looking for:
>
> <properties>
> <comment>XXX</comment>
> </properties>
>
> can be used to add comments which appear in the dependency report.
>
> - robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-10-09 at 18:27 +0200, Dennis Lundberg wrote:
> robert burrell donkin wrote:
> > On Sun, 2005-10-09 at 09:39 +0000, Henning P. Schmiedehausen wrote:
> >
> >>Our current build tool (maven) is not able to distinguish between
> >>compile-time and run-time dependencies. And some packagers don't
> >>understand this and start to require all of the compile time
> >>dependencies also at runtime.
> >
> >
> > (logging uses ant for builds but) i agree that this is a major issue for
> > all projects that use maven. JCL uses maven to generate the
> > documentation which is misleading.
> >
> > does anyone know how to add comments for dependencies?
>
> For Maven 1 it could be solved by setting properties [1] on the
> dependency. This would be something local to commons-logging that would
> not work automatically in other places.
>
> [1]
> http://maven.apache.org/reference/project-descriptor.html#class_Dependency
thanks :)
helped me to track down what i was looking for:
<properties>
<comment>XXX</comment>
</properties>
can be used to add comments which appear in the dependency report.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by Dennis Lundberg <de...@mdh.se>.
robert burrell donkin wrote:
> On Sun, 2005-10-09 at 09:39 +0000, Henning P. Schmiedehausen wrote:
>
>>Our current build tool (maven) is not able to distinguish between
>>compile-time and run-time dependencies. And some packagers don't
>>understand this and start to require all of the compile time
>>dependencies also at runtime.
>
>
> (logging uses ant for builds but) i agree that this is a major issue for
> all projects that use maven. JCL uses maven to generate the
> documentation which is misleading.
>
> does anyone know how to add comments for dependencies?
For Maven 1 it could be solved by setting properties [1] on the
dependency. This would be something local to commons-logging that would
not work automatically in other places.
[1]
http://maven.apache.org/reference/project-descriptor.html#class_Dependency
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-10-09 at 09:39 +0000, Henning P. Schmiedehausen wrote:
> robert burrell donkin <ro...@blueyonder.co.uk> writes:
<snip>
> >downstream maintainers
> >----------------------
> >my major concern was about the impact of JCL dependencies on downstream
> >maintainers (rather than users). this include the gump infrastructure
> >and packagers such as debian. JCL is now a really basic component right
> >at the bottom of the java package tree.
>
> I think the problem is the perception of "compile time dependencies"
> and "run time dependencies" here.
IMHO for downstream maintainers, it's more a question of official core
dependencies (which is something a little different from either runtime
or compile time dependencies). the current build detects when optional
dependencies are missing and does not build anything relying on them.
required core dependencies are much smaller than those that we compile
into the standard distribution.
for gump, JCL is split into api and full. projects declare themselves
dependent upon the api and then don't have to worry about all the other
dependencies.
one of the biggest mistakes we made was creating an official
distribution which works only for compilation: to run an application,
you need something a little bigger. this means that the tactic which
works well for gump can't be easily applied by downstream maintainers
elsewhere.
> Our current build tool (maven) is not able to distinguish between
> compile-time and run-time dependencies. And some packagers don't
> understand this and start to require all of the compile time
> dependencies also at runtime.
(logging uses ant for builds but) i agree that this is a major issue for
all projects that use maven. JCL uses maven to generate the
documentation which is misleading.
does anyone know how to add comments for dependencies?
> >in the best case scenario, more dependencies mean that maintainers have
> >more work to do. in the worst case scenario, maintainers will be forced
> >to remove JCL and all packages that depend upon it from their
> >distribution. for example, debian will only ship java libraries that
> >will run on a free JVM. so, the impact of adding an innocuous dependency
>
> That is a political decision of debian (and e.g. Fedora) to do
> so. They won't be able to ship a large number of packages anyway
> (e.g. everything that requires Sun libs until either GlassFish or
> Geronimo come along far enough to allow the usage of things like mail
> or activation).
though some are more agnostic about JVM's than debian, all packagers
have similar problems with any dependencies they cannot package and
distribute. the whole point of package maintenance is to ensure that the
end user ends up with a working system.
the more official required dependencies a library declares, the more
likely it is that it cannot be packaged. so this is a real issue (as
well as one of perception).
> The question for this scenario is: Do we want to cater to the needs of
> "truly free software" (as in GNU) or do we want to continue down the
> road of "truly free software" (as in ASF). :-)
JCL is a library whose downstream users are often libraries and
applications. IMO the right attitude is to allow downstream libraries
and application a choice. this means having some appreciation of the
problems of downstream maintainers of packages.
> >may be that downstream maintainers are forced to remove scores or
> >hundreds or packages from their distributions.
>
> No matter what decision we make, there is someone is bound to stand up
> and whine. So IMHO we should just continue as it is comfortable to the
> JCL community and let the rest sort out the political details.
this isn't politics: it's about being sympathetic to the needs of our
downstream users. downstream users for a library include many
maintainers as well as developers of libraries and applications. IMO
it's important that allow them to choose whether they want to be able to
support packaged distributions or not. we should not be making this
choice for them.
many (most?) downstream maintainers roll their own from the source
possibly this could be addressed by analysing the ant build and creating
documentation aimed specifically at them.
> >perceived dependencies
> >----------------------
> >a different concern is that users are given the wrong impression of the
> >libraries which are required to run JCL. this includes users who feel
> >they need to find and download sources for all dependencies and those
> >who need to distribution and run a minimal stripped down version. what
> >classes and dependencies are required is a FAQ.
>
> +1 I hope that m2 will help us along here in being able to clearly
> specify build and runtime dependencies.
+1
the documentation we created for the break in compatibility between
collections 2 and 3 seemed to work out ok so maybe this one can be
addressed by documentation.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org