RE: [RANT] This Maven thing is killing us....

[jmcconnell]

yep, totally...its just that 3.7 should never be 'fuzzy' from a
dependency standpoint unless it is 3.7-SNAPSHOT or this new idea of
incrementing pom versions for same jar.

in freebsd versioning this would be equivalent to something like
treating this 3.7-1 deal as 3.7-STABLE which could be treated just
like the -SNAPSHOT.  Difference being that 3.7-STABLE refers to the
evolution of metadata surrounding tne 3.7 release whereas -SNAPSHOT
refers to evolution of the underlying code.

jesse

On 7/5/06, Mark Hobson <markhobson@...> wrote:

> On 05/07/06, Jesse McConnell <jesse.mcconnell@...> wrote:
> > might be better off using the version ranges notation for this kind of
> > thing, I don't think you want to get into the habit of x.y being some
> > kinda fuzzy defintion, it should refer to a specific version.
> >
> > [3.7,) or something along those lines...
> >
> > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
> >
> > then when it comes to your release time, pin it down to a specific
> > version of the pom for release
>
> I did think of ranges, but even atm 3.7 is just a 'soft' version -
> merely a recommendation.  This notion could be extended to accommodate
> the above, with it becoming the 'hard' version [3.7-1] at release
> time.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[rahul.thakur.xdev]

Just wondering if rather than having an <exclusion> list stuffed in each
of <dependency> elements, if we could have some sort of  <compatible>
tag that can 'advise' Maven the choosing strategy for conflicting
artifacts (pretty much like version ranges).

For sake of an example:

  <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.2</version>
            <compatible> <=3.8.2 </compatible>
        </dependency>
    . . .
   </dependencies>

So, Maven can safely choose 3.8.2 for all varying versions JUnit less
than or equal to 3.8.2, but not 4.0.

The other thing is that when an artifact is published to a repo, the
publisher can add some compatibility meta-data as well to indicate that
the current version is incompatible with certain other versions or the
artifacts.

Just a thought...

Cheers
Rahul


<snip>

>       <dependency groupID="commons-lang"
>           artifactID="commons-lang"
>           version="${commons-lang.version}">
>         <exclusion
>             groupId="junit"
>             artifactId="junit"/>
>       </dependency>
>       <dependency groupID="commons-logging"
>           artifactID="commons-logging"
>           version="${commons-logging.version}">
>         <exclusion
>             groupId="junit"
>             artifactId="junit"/>
>         <exclusion
>             groupId="logkit"
>             artifactId="logkit"/>
>         <exclusion
>             groupId="avalon-framework"
>             artifactId="avalon-framework"/>
>       </dependency>
>

</snip>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Steve Loughran]

jerome lacoste wrote:

> On 7/5/06, Steve Loughran <stevel@...> wrote:
>> Ralph Goers wrote:
>> >
>> >
>> > Carlos Sanchez wrote:
>> >>
>> >> Yes you can, it's not the best way to do it but you can, by adding
>> >> explicitly the dependency with the versoin you want to your pom. In
>> >> the very worst case you have to add all transitive deendencies to your
>> >> pom, like in Maven 1.
>
>
> [..]
>
> I've been following this thread with interest.

Its an interesting discussion. Although the topic is how maven builds,
the underlying issue is how to do late binding to library versions
without things breaking...its one aspect of the whole
configuration-management problem.

> It makes me think of the various problems Linux distribution have to
> deal with when making their own repositories. It took 10 years for
> these solutions to be what they are today. I really think some ideas
> should be reused, even though the goals are slightly different.

I need to research these more. One issue I have with the linux world is
that they tend to require that a system only has a single version of a
package installed on a machine; they dont really support side-by-side
stuff. So if you install jdk-1.4.2 and lib-gtk-2.0.4 then you are
expected to uninstall jdk-1.4.0 and lib-gtk-2.0.3. In java, excluding
stuff in the JVM/JRE itself, and that endorsed directory mistake, you
can have any number of JARs around and each process gets to choose the
entire set of libraries to depend on.

Except of course if you use the sun manifest.mf way of specifying
dependencies, that just sucks, because you have to hard code in a
relative/absolute path to every JAR in the JAR file itself.

> Some features/ways of working that may or may not be applicable:
>
> - they typically use a versionning similar to x.y.z-n sometimes
> adding. -n can be used to fix packaging issues (POM in the case of
> maven). Vendor fixes are also accepted and version names reflect the
> vendor name.
>
> - the distributions with the best repositories typically require the
> package to be buildable from source. The build is tested in a separate
> environment where all the required build dependencies are listed, to
> make sure that the dependency list is accepted. Something similar
> should maybe be done before accepting a project on a POM, setting up a
> build environment based on the given pom.
>
> - number of versions of a particular package in a repo is reduced to a
> minimum. users are adviced to upgrade to the latest & greatest to make
> sure that fixes are always present in the last released versions

I could make some negative comments about linux backwards compatibility
here.

One person's bug fix is another person's "unexpected change in system
behaviour". This is why on qualified systems, you dont change
*anything*, if you can help it, even OS security patches are carefully
assessed before rollout.

>
> - responsibilities of preparing packages is spread around 10s of
> people. Packages are orphaned when no one is taking care of them.
> People can reuse tricks/scripts learned by former packagers to go on
> with the job.

yes, there is a good spread of participants. and the distros take on the
job of integrating everything.

-steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Alexandre Poitras]

Or can't Maven offer you to upgrade like it does with plugin (or use to)?

On 7/5/06, Jesse McConnell <jesse.mcconnell@...> wrote:

> yep, totally...its just that 3.7 should never be 'fuzzy' from a
> dependency standpoint unless it is 3.7-SNAPSHOT or this new idea of
> incrementing pom versions for same jar.
>
> in freebsd versioning this would be equivalent to something like
> treating this 3.7-1 deal as 3.7-STABLE which could be treated just
> like the -SNAPSHOT.  Difference being that 3.7-STABLE refers to the
> evolution of metadata surrounding tne 3.7 release whereas -SNAPSHOT
> refers to evolution of the underlying code.
>
> jesse
>
> On 7/5/06, Mark Hobson <markhobson@...> wrote:
> > On 05/07/06, Jesse McConnell <jesse.mcconnell@...> wrote:
> > > might be better off using the version ranges notation for this kind of
> > > thing, I don't think you want to get into the habit of x.y being some
> > > kinda fuzzy defintion, it should refer to a specific version.
> > >
> > > [3.7,) or something along those lines...
> > >
> > > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
> > >
> > > then when it comes to your release time, pin it down to a specific
> > > version of the pom for release
> >
> > I did think of ranges, but even atm 3.7 is just a 'soft' version -
> > merely a recommendation.  This notion could be extended to accommodate
> > the above, with it becoming the 'hard' version [3.7-1] at release
> > time.
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> --
> jesse mcconnell
> jesseDOTmcconnellATgmailDOTcom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

On 6/07/2006 3:40 AM, Rinku wrote:

> Just wondering if rather than having an <exclusion> list stuffed in each
> of <dependency> elements, if we could have some sort of  <compatible>
> tag that can 'advise' Maven the choosing strategy for conflicting
> artifacts (pretty much like version ranges).
>
> For sake of an example:
>
>  <dependencies>
>        <dependency>
>            <groupId>junit</groupId>
>            <artifactId>junit</artifactId>
>            <version>3.8.2</version>
>            <compatible> <=3.8.2 </compatible>
>        </dependency>
>    . . .
>   </dependencies>
>
> So, Maven can safely choose 3.8.2 for all varying versions JUnit less
> than or equal to 3.8.2, but not 4.0.

That's no different to (,3.8.2] now.

>
> The other thing is that when an artifact is published to a repo, the
> publisher can add some compatibility meta-data as well to indicate that
> the current version is incompatible with certain other versions or the
> artifacts.

Yes, this would be a good addition to 2.1 - I think it is already in the
wiki (but should be added if not).

This would only need to affect open-upper-ended ranges (including soft
versions). So for junit, if we assumed 4.0 was not compatible with <
4.0, ranges would change like this:

[3.8,) --> [3.8,4.0)
[3.8,4.1] --> unchanged (the range explicitly allows the
incompatibility, maybe a warning)
(,5.0] --> unchanged (the range explicitly allows the incompatibility,
maybe a warning)
3.8 --> (,4.0) (suggest 3.8)

Then the normal logic could kick in.

- Brett

--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jörg Schaible]

Hi Brett,

Brett Porter wrote on Friday, July 07, 2006 8:49 AM:

> On 6/07/2006 3:40 AM, Rinku wrote:
[snip]

>> The other thing is that when an artifact is published to a repo, the
>> publisher can add some compatibility meta-data as well to indicate
>> that the current version is incompatible with certain other versions
>> or the artifacts.
>
> Yes, this would be a good addition to 2.1 - I think it is
> already in the
> wiki (but should be added if not).
>
> This would only need to affect open-upper-ended ranges (including soft
> versions). So for junit, if we assumed 4.0 was not compatible with <
> 4.0, ranges would change like this:
>
> [3.8,) --> [3.8,4.0)
> [3.8,4.1] --> unchanged (the range explicitly allows the
> incompatibility, maybe a warning)
> (,5.0] --> unchanged (the range explicitly allows the incompatibility,
> maybe a warning)
> 3.8 --> (,4.0) (suggest 3.8)
>
> Then the normal logic could kick in.

You may also have the need to exclude a version in that range because of a critical bug. E.g. proxytoys run with CGLIB 2.0, 2.0.2 and 2.1.x ... but not with 2.0.1, that one had introduced a major bug, that broke proxytoys.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

On 6/07/2006 1:32 AM, jerome lacoste wrote:
> - they typically use a versionning similar to x.y.z-n sometimes
> adding. -n can be used to fix packaging issues (POM in the case of
> maven). Vendor fixes are also accepted and version names reflect the
> vendor name.

Yep, already have that for that very reason (calling it build number in
hindsight was not the greatest choice :)

>
> - the distributions with the best repositories typically require the
> package to be buildable from source. The build is tested in a separate
> environment where all the required build dependencies are listed, to
> make sure that the dependency list is accepted. Something similar
> should maybe be done before accepting a project on a POM, setting up a
> build environment based on the given pom.

This seems like a good idea in theory, but our situation is different
for the following reasons:
- we may not always have the source
- this assumes that the dependency list is used to build the project
(which assumes they build with m2). We could take a stab at anything
using ant by doing what gump does, though, so it's worth a shot.
- we are actually distributing the originally released artifact rather
than rebuilding and repackaging like most distros. They also go ahead to
test their repackaging, something we can't afford to do.

> - number of versions of a particular package in a repo is reduced to a
> minimum. users are adviced to upgrade to the latest & greatest to make
> sure that fixes are always present in the last released versions

And it is almost impossible to build stuff that targetted older releases
of the OS (look what happened with the various incompatible
autoconf/automake releases, gcc2 -> 3 -> 4, etc).

Makes sense for a stable OS, not so much a build system.

> - responsibilities of preparing packages is spread around 10s of
> people. Packages are orphaned when no one is taking care of them.
> People can reuse tricks/scripts learned by former packagers to go on
> with the job.

I think we are already on the way to this. Better docs and tooling needed.

>
> - use of provides and various other dependency markers (that's coming
> in m2 2.1 if I got it right)

Yup.

- Brett

--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

On 7/07/2006 4:58 PM, Jörg Schaible wrote:
> You may also have the need to exclude a version in that range because of a critical bug. E.g. proxytoys run with CGLIB 2.0, 2.0.2 and 2.1.x ... but not with 2.0.1, that one had introduced a major bug, that broke proxytoys.

you can already do that from the dependees end:
[2.0],[2.0.2,) or [2.0],[2.0.2],[2.1,) depending on if 2.0.3 <= x < 2.1
are any good.

 From a releasers end, I'm inclined to say they should pull the release,
but since some people may have already gotten it metadata that says
"this release is totally broken" that warns new users might be better.

- Brett

--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

I think we need the necessary auditing in the repository manager for
this first, but it's worth moving on. I'm trying to get that up and
running right now, and writing some internal docs so others can dig in
and do stuff like this.

The ideal is actually to have those segments of the repository managed
by the projects themselves, of course.

- Brett

On 6/07/2006 2:32 AM, Alexandre Poitras wrote:

> +1, really great idea.
>
> On 7/5/06, Mark Hobson <markhobson@...> wrote:
>> On 05/07/06, Arik Kfir <arikkfir@...> wrote:
>> > Hello all,
>> >
>> > A while back I suggested that the Maven team delegate some of the
>> > reponsibility of maintaining the ibiblio repo to volunteers (as in
>> the linux
>> > equivalent, as Jerome has noted earlier in the thread). Each such
>> voluteer
>> > can maintain a specific area in the repo; so, someone who uses
>> hibernate
>> > frequently can maintain its poms, until the hibernate team agrees to
>> do it
>> > for us.
>> >
>> > The idea was generally accepted by brett, with a slight modification
>> that
>> > volunteers go through a screening process, just like normal commit
>> access is
>> > provisioned (someone who submits enough pom patches will slowly be
>> given
>> > commit access to ibiblio).
>> >
>> > for more info, see
>> > http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495
>> >
>> > perhaps it is time to move this forward?
>>
>> Definitely +1 to seeing the ibiblio repostory devolving responsibility
>> to smaller, more managable, repositories - ideally maintained by
>> developers closer to the hosted projects.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

On 6/07/2006 2:19 AM, Mark Hobson wrote:
> Could we not use the syntax 3.7 to represent 'the latest revision of
> 3.7', whereas 3.7-1 would lock the version down to 3.7 rev 1?  So
> during development people could use 3.7 to allow updated revisions of
> the pom to be pushed to them, and then for reproducable builds they
> could use the 3.7-1 syntax.
>
> The release plugin could fully-qualify any version numbers of the form
> 3.7 to the currently-used revision, e.g. 3.7-1, at release time.

This is actually how I'd originally designed it to work (using newest
instead of nearest, with ranges much more common). Will have to come
back to that in 2.1 :)

Anyway, I think it's currently debatable whether a -1 release is enough
for this case. I'd really like to investigate a "vendor" element of the
version that allows people that aren't the original project to
modify/repackage their releases without screwing up the dependency model.

- Brett

--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...