On Dec 25, 2008, at 7:02 PM, Jason van Zyl wrote:
On 25-Dec-08, at 4:27 PM, Ralph Goers wrote:
Jason,
I'm surprised you don't remember this discussion since we've had it
so many times.
The only thing I wanted to make sure you weren't doing was passing
on requirements as provisions transitively. If you know RPMs then
we're on the same wavelength. It was one of your previous emails
that made me wonder.
Transitivity would have to come into play in some fashion. If A
depends on B and C and B depends on an incompatible version of C this
is a problem. The use of attributes would allow the system to be able
to determine that. RPMs do the same thing, just differently. One of
the primary differences is that sometimes it is OK for two versions of
a component to be installed simultaneously in a Linux system, so in
some cases this kind of transitivity is not a problem on a Linux
system - although I'm not sure how the RPM system allows it.. In other
cases it will be detected and the install will fail. With typical
class loading this would be a problem in a Maven build and would
hopefully be detected.
Again I don't think we're off to far from what you want Suse and
most of the other distributions employ a SAT solver to calculate a
set of suitable artifacts. The library that we are using, SAT4J, is
capable of doing this and is moreso used like this in P2 which is
the update manager technology used in Eclipse. It takes into account
attributes like platform and that's taken into account when doing
resolution for a particular target platform. But the first thing we
need to do with Mercury is make it work for what we do currently.
This is all good to hear and I'm fine with that. I guess I'm just
trying to emphasize that doing what Maven 2.0.x already does but more
efficiently really isn't much of a win. I realize that there are a few
other benefits that go with it, but I'm more interested in how this
will take us where we want to go, not in the math or logic behind
version range checking.
What I envision for Maven would be that the xerces pom might look
like:
<project>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.9.1</version>
<provides>
<feature name="jaxp">1.2,1.3</feature>
<feature name="xml">1.0,1,1</feature>
<feature name="xml-schema>1.0</feature>
<feature name="sax">2.0.2</feature>
<feature name="xinclude">1.0</feature>
</provides>
</project>
A component might only be interested in JAXP 1.3 and not really
care which version of Xerces provides it. It should be able to
specify something like
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<requires>
<feature name="jaxp">1.2</feature>
</requires>
</dependency>
This would allow any version of xerces that provides jaxp 1.2 to be
selected.
This is one thing we could certainly do, but honestly something I
don't think is useful most of the time. I haven't had many instances
myself where I didn't care about the implementation of a particular
specification. If you really could guarantee not only API but non-
functional requirements like performance then possibly. It won't be
hard to do things like this with SAT4J. But I haven't deployed in
any sort of standard application server in a long time. So if you're
thinking to take everything that a platform might provide in order
to mesh that with what requirements your application needs then
sure. And something like this is totally possible with Mercury and
our use of SAT4J.
I didn't say you didn't care about the implementation. In fact, that
is why I xercesImpl is named as the artifact. What I don't care about
is what version gets picked. As long as it meets all the features
required throughout the build, then Mercury should choose the
appropriate version - and allow me to create a managed dependency file
so I can reproduce it. Or, as you had discussed, create some sort of
label that the repo can use to insure the same artifacts are always
chosen again.
On the other hand, a different component might want both JAXP 1.3
and xinclude support. This would limit the number of versions that
could be selected but would still be resolvable since the latest
version supports all of the requirements.
Yah, I think we're a long way from this being practical and I
imagine we would be forging the way here again. OSGi can provide
something like the servlet api but I don't think they provide
capability maps, or feature sets as you've depicted them above. But
OSGi is certainly closer here if you can make the mental jump of
mapping a capability to a package like javax.servlet.
No, from what I've seen from OSGi it doesn't solve this problem. From
what I understand is what it does do is play games with the class
loader so that multiple versions of a component can exist within a JVM
within different bundles. I also read a blog somewhere that indicated
that this solution has some sort of fatal flaw in it.
While this example for Xerces might seem out of the ordinary, it
really isn't. If you look at commons-collections history page http://commons.apache.org/collections/history.html
it should be obvious that features could have easily been used to
describe the various changes made to the project as well as to
identify the binary incompatibilities that occurred.
Ralph, I honestly think again on larger scale it is not going to be
a technical problem. It's deciding on a global capability map that
everyone would use accurate. I mean we still argue with people about
versioning their dependencies and "why can't I just use a lib
directory of JARs" kind of mentality so while I think this is the
direction we should go it's use is going to limited for a while and
Mercury is just beginning its life.
From my experience the people you have those conversations with have
very little understanding of how class loaders work in Java. I have
conversations with experienced developers who wonder why they are
getting class loader exceptions trying to pass data between servlets
in two different war files. I haven't seen a proposal yet - including
OSGi - that really fixes this problem. And until it is fixed in Java
itself we will need our build tools to do as much as they can to help
out.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
