To answer to David question about maven supporting >= :
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution (go to "Dependency Version Range")

Ok, it's not perfect though :
http://www.bearaway.org/wp/?p=509

Now, Ole has brought a very valid point on the table. Using >= seems attractive, but it's the very last thing we should do in a configuration management system. We should be able to build a version N of ADS which include _known_ versions of each used dependency, not allowing the build tool to download whatever last version available on a remote repos : the rationnal is that when you cut a verion, you unit-test it, integratuon-test it, and it should be reproductible. If at least a component change, and if you have a problem, then there is no easy way to help the guy who has the problem.

2cts.

On 12/2/06, Ole Ersoy <ole_ersoy@yahoo.com> wrote:
Hey Julius,

I think the automatic upgrades should be fine (I like
them too, so they better).

Let me explore with a little example.

Suppose ApacheDS sets all it's dependencies using

=

Then these are generated into the spec file using

=

If ApacheDS is to be installed, all the versions of
the dependencies in the repository have to be
available first, so that the Package manager can pull
them.

I believe the JPackage project is committed to doing
this.

So now ApacheDS is installed on your machine using
fixed dependencies.

Then we go ahead and upgrade one of the dependencies
and
the ApacheDS version number correspondingly.

JPackage now builds the package for the new dependency
and the ApacheDS server and deploys them to the
repository.

Your package manager now detects these updates and
installs them.

And you can be sure that what it installed is high
quality because the versions are fixed, thus the
process is as tight as possible.




Using version ranges is convenient, but it can easily
lead to "Glitches".

Suppose ApacheDS just let Maven upgrade versions of
dependencies to the latest and then we built the
server using those latest dependencies (We would never
ever do this of coarse).

It passes all the unit tests, integration tests, etc.
so we ship it.

Next day the support mailing list has all sorts of
%$#$%#.  (Or maybe we didn't actually ship, and there
#$#%@# are only on the developers mailing list).

What happened?

Well, some of the dependencies was upgraded
automatically, and the main server started using that
dependency.

OK - Which dependency was it?
Well, there are 20 dependencies that support ranges,
and when we look at the repository metadata we see
that 11 of them were upgraded automatically.  So which
of these 11 is it that caused the glitch.  We now
check the stack trace and find it.

thoughts?

Cheers,
- Ole




--- Julius Davies <juliusdavies@gmail.com> wrote:

> Hi, Ole,
>
> I don't know maven at all yet.  Looking forward to
> learning more about it!
>
> It would be a shame if Maven doesn't support ">=".
> I see ">=" occurs
> often in the competition ;-).  Automatic upgrades
> (security updates,
> for example) depend on most packages avoiding "="
> dependencies where
> possible.
>
> Here is a Debian dependency example:
> -------------------------
> Package: apache2.2-common
> Architecture: any
> Depends: ${misc:Depends}, apache2-utils, net-tools,
> libmagic1,
> mime-support, lsb-base
> Conflicts: apache2-common, libapache2-mod-php5 (<=
> 5.1.6-3),
> libapache2-mod-php4 (<= 4: 4.4.4-2),
> libapache2-mod-mime-xattr (<=
> 0.3-2), libapache2-mod-mono (<Replaces:
> apache2-common
>
>
> Here is RPM's httpd.spec file:
> -------------------------
> Name: httpd
> Version: 2.2.3
> Release: 1
> Requires: apr >= 1.2.0, apr-util >= 1.2.0, gawk,
> /usr/share/magic.mime, /usr/bin/find, openldap
> Provides: webserver
> Provides: httpd-mmn = %{mmn}
> Conflicts: thttpd
> Obsoletes: apache, secureweb, mod_dav
>
>
> Here is Gentoo's apache-2.2.3.ebuild file:
> -------------------------
> RDEPEND="dev-lang/perl
>
>         >=dev-libs/apr-1.2.7
>
>         >=dev-libs/apr-util-1.2.7
>
>         dev-libs/expat
>
>         dev-libs/libpcre
>
>         app-misc/mime-types
>
>         sys-libs/zlib
>
>         ssl? ( dev-libs/openssl )
>
>         selinux? ( sec-policy/selinux-apache )
>
>         !mips? ( ldap? ( =net-nds/openldap-2* ) )"
>
> DEPEND="${RDEPEND}
>
>         >=sys-devel/autoconf-2.59-r4"
>
>
> These three "depedency management systems" either
> don't mention a
> version at all (so allowing the dependency
> resolution engine to just
> do its best), or they use ">=".  The use of "=" is
> very rare!
>
> (Notice that Debian's use of "<=" less-than is only
> occuring in the
> "Conflicts" section).
>
> Regarding:
>
> > Requires:       jpackage-utils
>
> I was just showing an example where no specific
> version is mentioned.
> We just let RPM's database try its best.
>
> You're right that non-versioned dependencies cause
> of a lot of:
>
> $%#@$%^$#
>
> But always setting "=" has little value.  I want my
> automatic
> upgrades!  To me this is the whole point of entities
> like Redhat or
> Debian or Gentoo, and JPackage, too!  They use ">="
> or "unspecified"
> so that I can do automatic upgrades as an enduser.
> But they're also
> very careful about what they put in the "repository"
> so that my
> automatic upgrades don't cause me to say
> "$%#@$%^$#".
>
>
> yours,
>
> Julius
>
>
> On 12/1/06, Ole Ersoy < ole_ersoy@yahoo.com> wrote:
> > Hi Julius,
> >
> > (JPackage team - could you please comment on this
> if
> > you think any of my rationale is kooko...Just
> remember
> > my mailbox limit is 1 Gig)
> >
> > I have not investigated it personally, but
> > someone from JPackage said that it does.
> >
> > Yes - It does support non-versioned dependencies
> :-)
> >
> > Which I think is the cause of a lot of
> >
> > $%#@$%^$#
> >
> > showing up in some of the maven support mailing
> lists.
> >
> > Personally I'm concerned about using any
> dependency
> > other than one set by =.
> >
> > One could make the assumption that someone checked
> all
> > the dependencies outside of =.  But if they missed
> > one, and someone uses it...
> >
> > On the other hand = is the only thing used and the
> > application builds and runs, users can be fairly
> > certain that it's good to go.  They can also be
> > certain that the developers took care in
> specifying
> > versioned dependencies.
> >
> > This also encourages developers to be careful
> about
> > testing when changing depedencies (Since it takes
> a
> > warm body, at least for now).
> >
> > Sorry - I missed the point of:
> >
> > Requires:       jpackage-utils
> >
> > Could you please elaborate?
> >
> > Thanks,
> > - Ole
> >
> >
> >
> >
> >
> > --- Julius Davies <juliusdavies@gmail.com> wrote:
> >
> > > Hi, Ole,
> > >
> > > Probably the wrong venue for this question.
> > >
> > > Does maven2 support the "=, <, >, <=, >=" ranges
> > > possible in RPM?
> > >
> > >
> >
>
http://www.rpm.org/max-rpm/s1-rpm-specref-preamble.html#S3-RPM-SPECREF-REQUIRES
> > >
> > >
> > > # I think both can be in single SPEC file,
> pinning
> > > the depedency.
> > > Requires:       jpackage-utils >= 0:1.5;
> > > Requires:       jpackage-utils < 0: 2.0;
> > >
> > >
> > > Also, does mavn2 support non-versioned
> dependencies?
> > >
> > > # Just grab latest and greatest.
> > > Requires:       jpackage-utils
> > >
> > > yours,
> > >
> > > Julius
> > >
> > >
> > > On 12/1/06, Ole Ersoy <ole_ersoy@yahoo.com >
> wrote:
>
=== message truncated ===




____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com



--
Cordialement,
Emmanuel Lécharny