On 25-Dec-08, at 2:02 AM, Ralph Goers wrote:
This whole thread makes my head hurt.
Frankly, and at the risk of being repetitious, I think all this work
into making this resolution based on versioning is pretty much a
waste of time.
I don't think anyone is OSGi land would agree with you. This is a
critical step along the way.
Now if your picture incorporated artifact metadata, such as
"provides" and "requires" attributes I'd sit up and take notice.
Until it does it really won't much matter how this works since
everything is going to continue to be locked down with managed
dependencies.
The whole point is to get down to a specified list of dependencies
that go into the runtime of your application. I don't disagree with
you here and Oleg certainly doesn't because we've discussed this at
length. What Mercury is provided is a way to arrive at that
possibility while along the way using the optimization functions to
get there. Otherwise it's a laborious manual process. We want to aid
this process during development with resolution and visualization
techniques. We don't want a system dynamically resolving everything at
runtime. The description of your application may say it can be
dynamic, but in practice you limit what is resolved. To manually
create your dependencyManagement, or lock down list, is a complete
pain in the ass.
I'm also not sure what you mean in your provides/requires model. What
you provide is something couched in terms your package. In OSGi you
generally export, or provide, packages in your library/application you
want to expose to others. What you import, or require, are the
dependencies your library/application needs. In our model currently
what a Maven project provides is itself as an artifact. What it
requires are its dependencies. This is how RPM works. If you look in a
spec file the list of what's provided is usually itself. I'm not sure
were on the same wavelength when talking about requires/provides. A
library can't provide anything then the content of what it contains
itself. In our course grained model (or requires bundle in OSGi speak)
it's the artifact you're making.
All I'm really looking for is a) dependency resolution based on
artifact attributes, b) notification when an unresolvable conflict
exists, and c) a way to generate managed dependencies based on a and
b so that the build can always be repeated.
a) is definitely coming and it essentially looks like an LDAP query
for lack of anything else to compare it against
b) most definitely required and this is handled internally by what we
have and is going to be far easier to see given what Oleg has
c) exactly
We are not talking about different things. To resolve all your
dependencies from scratch at runtime would be ill advised. The whole
point of the system is so that we can resolve on demand when changes
are necessary. Oleg and I have talked for a long time about the
dynamic nature of OSGi and balancing that with the fact that once your
QA team approves something you better not start throwing new bits into
the mix or you'll invalidate what was tested. Ultimately we want a
list of pieces for an application that we know don't change when we
are at the end of the cycle and are ready to ship. I'm pretty sure
what you need is something we have accounted for.
When building a standard web application there are really no
constraints or metadata establishing what your runtime versioning
looks like. So you can happily toss in some new JARs in your WEB-INF/
lib directory and if it all links at runtimes everything is good. When
you upgrade things maybe you add in a few JARs, or maybe you rebuild
the entire application and drop it into your container. In OSGi there
are constraints about what pieces can work together at runtime. You do
have the option of stating the exact version of your requirements, but
this is not generally how people setup their applications. They
specify ranges of versions that are acceptable. This is not to say
that you want the resolution to go hog wild at runtime. This doesn't
happen because people generally manage the bundle repository -- which
has no remote capabilities -- and they drop new things in. So the
runtime can dynamically accept new versions of dependencies if a range
allows it. What is resolved in practice is limited by what's in the
bundle repository.
So when Oleg is referencing all this resolution and the mechanics of
resolving it is toward the end of having a fixed list of something
that works and has been tested. We want the mechanics of this to work
in Mercury and be available in tooling like m2eclipse and we're also
working toward having a system where an application can say "I will
take anything you give me to resolve because I can dynamically update
myself" but it's going to be talking to Nexus who will say back "yes,
little application but I'm going to tell you what you are going to
use". To have to redeploy the metadata with the artifacts of an
application in order for it to resolve new versions of application on
N nodes of a large system is untenable. You need to be able to let the
application consume newer versions of artifacts while at the same time
limiting what it consumes. We are attempting to shift all this
management to Nexus where through a virtual URL an application will
resolve against a constrained set of artifacts that might be
available. In essence your fix Map of artifacts available from
dependencyManagement. So this is our end goal but I don't think
Mercury along way is incompatible with what you require.
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
----------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
