On 26-Dec-08, at 2:55 AM, Ralph Goers wrote:
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.
I don't think you understand that Maven 2.x doesn't do this at all
correctly. So it's not just a matter of being more efficient, it's a
matter of actually having a system that works. SAT is at all strictly
for anything version specific. We need to replicate the behavior we
have but any attribute is represented as a variable in the system and
when you pile up all the variables in equations we are just solving
for a solution. What is happening in Mercury is absolutely critical.
What Oleg and Daniel are discussing is not limited to how a version is
solved for, but how to solve for anything akin to what you call an
attribute. The SAT solver doesn't care whether you stuff in versions,
platforms, quality markers. It's just how you represent the equations
and optimization functions. So any discussion of how this works is
useful. It buys us a lot understanding how this works, and we don't
have anything currently that would work properly.
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.
Yes, this all being predicated on people agreeing on features/
capabilities and how to encode them, and doing the same for non-
functional attributes. I see this taking as long as shifting people
over to a mindset of versioning things. And this is the work we're
signing up for, but I think we're looking at a couple years of work
here at the very least.
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 a complete feature/capability map concept no. For something
simple like "i want the servlet API and I don't care where it comes
from" yes. But also realize there is P2 at eclipse which is slated to
a be a full provisioning solution. So much the same as Mercury where
you'll be able to make queries and get what you require. As far as
runtime partitioning OSGi the best system we have today. That said if
you have a real problem start up another VM.
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.
It creates a graph of classloaders based on the bundles' specification
of imports and exports. It's in its 5th iteration as a specification
and while not a panacea, could use a lot better tooling, and has a
very lacking component model I don't think anything comes near it as
far as a runtime model. The classloader separation is useful.
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.
That may be but it's the general population of Java developers, our
users. That's the reality we deal with.
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 assume you mean how something could get constructed that would let
that happen, not why it happens.
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.
OSGi is a runtime model and it goes a long way to solve isolation
problems and reduce conflicts at runtime, the provisioning and
development model is not so strong IMO. There are good things like PDE
tools in the IDE that are great, and things that are generally abysmal
like PDE headless build. If you think anyone else is going to come
with a better runtime model then OSGi I think you're mistaken. Where
we can certainly help is the provisioning, development and build
tooling. As far as the system that you describe in terms of having a
completely attribute-based provisioning model, the runtime most suited
to accept that model is OSGi. How you build and provision things is
inextricably tied to how they run.
I hope to reach some level of interoperability with P2 as it aims to
be complete provisioning tool which is really the same space the Maven
and Mercury play in. We are grabbing a bunch of stuff, given and set
of constraints for an application and we want the application work at
runtime.
At any rate what you need I believe in there in Mercury. I also
believe it is necessary to get Mercury to work for the model we
currently have because what's present in Maven 2.x is not something we
can build on in the future.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
