Thanks Tom,
I'll bring this up with the commons developers and we'll see what
happens. Probably won't be in this release though.
Tom Huybrechts wrote:
This is the OSGi technical whitepaper:
http://www.osgi.org/documents/collateral/OSGiTechnicalWhitePaper.pdf .
Most relevant here is the
I would like to extend a big Thank you to the Maven community for
helping us out with this review.
--
Dennis Lundberg
on behalf of the Apache Commons Logging team
Dennis Lundberg wrote:
Hi all
The poms for commons logging has taken some beating on this list over
the years. The reason for
Wayne Fay wrote on Monday, August 27, 2007 8:55 PM:
A couple comments... take them or not, entirely your choice:
1. The properties at the bottom -- any reason you aren't just
configuring maven-compiler-plugin instead?
Although not done here, but you need the same values configuring the
Hi Michael,
Michael McCallum wrote on Tuesday, August 28, 2007 12:34 AM:
IMO the log4j, logkit, avalon dependencies all need to go... I as I
imagine most people do only use one logging implementation in the
deployed systems why introduce a dependency on several
implementations at the top
On 8/28/07, Jörg Schaible [EMAIL PROTECTED] wrote:
Michael McCallum wrote on Tuesday, August 28, 2007 12:34 AM:
I've generally stopped using dependencyManagement in favour of
dependency composition
Why? Only with dependencyManagement you're able to manage transitive versions.
Michael,
Hi Dennis,
I've got two remarks:
- You should really make sure that all plugins have a version declared. There
are definitely differences between versions, so the reproducibility of your
builds can only be guaranteed by using explicit versions.
- The artifacts commons-logging,
Michael McCallum wrote on Tuesday, August 28, 2007 1:15 PM:
Why? Only with dependencyManagement you're able to manage transitive
versions.
In order to keep clean dependency graphs I have used standard
OO principles to
encasulate functionality in this case I will use spring as an example.
Why? Only with dependencyManagement you're able to manage transitive
versions.
In order to keep clean dependency graphs I have used standard OO principles to
encasulate functionality in this case I will use spring as an example.
Spring provided many artifacts. I have many projects that use
Why? Only with dependencyManagement you're able to manage transitive
versions.
In order to keep clean dependency graphs I have used standard OO principles to
encasulate functionality in this case I will use spring as an example.
Spring provided many artifacts. I have many projects that use
http://en.wikipedia.org/wiki/Relation_composition
group.id.composition.spring 2.0.6
- spring-beans 2.0.6
- spring-context 2.0.6
group.id.composition.spring.persistence 2.0.6
-group.id.composition.spring 2.0.6
- hibernate 3.1.3
- spring-hibernate3
group.id.artifact.a X
-
Michael McCallum wrote on Tuesday, August 28, 2007 1:56 PM:
http://en.wikipedia.org/wiki/Relation_composition
group.id.composition.spring 2.0.6
- spring-beans 2.0.6
- spring-context 2.0.6
group.id.composition.spring.persistence 2.0.6
-group.id.composition.spring 2.0.6
- hibernate
http://en.wikipedia.org/wiki/Object_composition is really just the software
equivalent of the first link i sent
[snip]
You still did not explain, what composition means. It's no word used in
standard Maven terminology. Your description does not make it clear what
you *actually* have done.
OK. But this will not help you, if you include another artifact that
depends transitively on Spring or Hibernate in different versions. And
therefore we use a company or at least a master POM for a project with a
dependencyManagement section. This way you can overwrite the versions of
the
Michael McCallum wrote on Tuesday, August 28, 2007 2:39 PM:
OK. But this will not help you, if you include another artifact that
depends transitively on Spring or Hibernate in different versions.
And therefore we use a company or at least a master POM for a
project with a dependencyManagement
Yes, it is enough, but by adding optionaltrue/optional we wanted to
show that the dependency is also optional. You will only need it if you
use certain features of commons-logging. And scopeprovided/scope
says that it will be provided by the container, if you decide to use
those features.
Michael McCallum wrote:
IMO the log4j, logkit, avalon dependencies all need to go... I as I imagine
most people do only use one logging implementation in the deployed systems
why introduce a dependency on several implementations at the top level?
Commons-logging only has one level, the top
Marcel Schutte wrote:
Hi Dennis,
I've got two remarks:
- You should really make sure that all plugins have a version declared. There
are definitely differences between versions, so the reproducibility of your
builds can only be guaranteed by using explicit versions.
Yes we should, as
This is the OSGi technical whitepaper:
http://www.osgi.org/documents/collateral/OSGiTechnicalWhitePaper.pdf .
Most relevant here is the Modularity section of the Architecture
chapter.
To be usable in an OSGi setting, the jar manifest needs to have some
entries added. Most important are the name
but i want it managed across 75 artifacts in 11 groups with 9 aggregations...
using inheritance to manage a change in the version of spring for example is
way too time consuming and prone to error. Unless i specify all the deps in
the aggregation i can never be sure of what version of any
You can ping the people from Apache Felix, they create bundles of
apache projects for consumption in OSGi with the goal of contributing
it back to the projects.
They will tell you if it's ready or not for the projects.
On 8/27/07, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hi Tom
I've heard the
Is there any chance that OSGi headers could be added ?
On 8/27/07, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hi all
The poms for commons logging has taken some beating on this list over
the years. The reason for that has been the dependencies section.
Previous poms of commons-logging was
A couple comments... take them or not, entirely your choice:
1. The properties at the bottom -- any reason you aren't just
configuring maven-compiler-plugin instead?
2. Its a bit unfortunate the maven-jar-plugin doesn't support the
includes/excludes you require, and so you have to use antrun
Wayne Fay wrote:
A couple comments... take them or not, entirely your choice:
1. The properties at the bottom -- any reason you aren't just
configuring maven-compiler-plugin instead?
Actually we are, in the parent. I forgot to send the url to the parent
pom in my first mail, but here it
Hi Tom
I've heard the term OSGi from time to time, but have never took the time
to learn more about it. Do you know of a good place where I can find out
more about it?
A quick look at Google suggests that it has something to do with entries
in the manifest in the jar file, is that correct?
For the servlet-api dependency, provided scope is enough (provided is
not transitive).
Thanks,
Stéphane
On 8/27/07, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hi all
The poms for commons logging has taken some beating on this list over
the years. The reason for that has been the dependencies
IMO the log4j, logkit, avalon dependencies all need to go... I as I imagine
most people do only use one logging implementation in the deployed systems
why introduce a dependency on several implementations at the top level?
check out http://www.slf4j.com for an appropriate break up of the
agree with Michael here.
-D
On 8/27/07, Michael McCallum [EMAIL PROTECTED] wrote:
IMO the log4j, logkit, avalon dependencies all need to go... I as I imagine
most people do only use one logging implementation in the deployed systems
why introduce a dependency on several implementations at the
27 matches
Mail list logo
