maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: [MNG-5761] Dependency management is not transitive.
Date Thu, 17 Nov 2016 16:12:45 GMT
On 17 November 2016 at 14:36, Jason van Zyl <jason@takari.io> wrote:

> Hyperbole easily made fact so let’s ask and then there will be no
> question. I have thousands of users in my organization, Igor likely has
> something similar. We don’t work together on a daily basis anymore but
> small changes have a dire impact and both of us care greatly about the
> preservation and consistency of behavior because it matters greatly in
> terms of usability, user trust in the systems we build, and real support
> costs. We also care about this on a large scale where these concerns are
> magnified intensely for all Maven users. It is a very well educated guess
> based on past experience that changes made like this reflect isolated
> development. Christian can clarify how many users he’s responsible for as
> I’m absolutely certain he’s not running a support organization. These
> concerns have always influenced my behavior, Igor is similar and I make
> zero apologies because it will impact my users, and will reflect poorly on
> the project globally and immediately. I will “trample” as much as necessary
> to preserve behavior for users. Igor and I have made fairly radical changes
> while preserving all existing behavior for existing users, we’ve outline
> how we did it: separate implementations, user opt-in, over time it may
> become default behavior if so desired by users.
>
> Stephen, have you looked at the history for the core and the integration
> tests? What do you see? Tell me how much consensus we had for all those
> changes.
>
> ITs are broken in a fundamental way, no release notes in SVN, no notes
> anywhere I can see that would explain how the changes would impact a user
> or what they do to understand. This is how you go pretty far to losing your
> community. Our users are normal everyday developers, they just want things
> to work, all systems have quirks and many have just lived with the scar
> tissue, software gets delivered, compromises get made, people go home at
> the end of the day. For the succession of minor releases everything needs
> to work, we live with our baggage. This, to me what we have right now is a
> potential flaming train wreck waiting to happen. I’m not really concerned
> with one person who seems not to understand this. My concern is about
> destroying the trust we’ve built up over the years in one fell swoop.
>

I am not happy with the current state of the integration tests

I am not happy that there have been changes that break backwards
compatibility in an unconsidered fashion.

But I do think we can make considered changes that break backwards
compatibility in known and defined concrete ways.

I will direct your attention to the change in the 3.3.x line where the in
memory model was made read-only.

This affects any multi-module Maven build where the shade plugin is used to
replace the primary artifact with one where it has shades some - but not
all - of the dependencies of an artifact and then that shaded artifact is
consumed by another module in the reactor (especially where that module is
not a jar file but rather something that aggregates jars, e.g. a war or an
ear)

In that case you will end up with a multi-module build where the .war
includes the shaded jar and *all* its *original* dependencies.

If you instead build the reactor one module at a time using `install` then
the .war will only include the non-shaded dependencies of the jar.

Now none of this happens with 2.0-3.2.x

It is a small regression in one sense... and you can fix it with some scope
(or <optional>true</optional>) changes (and those scope changes are
arguably the way shading in that use case should have been done
originally)... but this is still a regression and breaks existing builds in
a subtle way (one that took me quite some time to uncover)

That regression was driven by you IIRC, yet I do not see you clamouring to
revert the change and restore builds for your customers...

Now there are a number of questions/points that arise from the above
example:

1. Should we revert the change? If the principle is that we do not ship
breaking changes then we should revert the change and make the model
mutable... On the other hand I think that the impact is small (but deadly)
and the benefits of an immutable memory model are significant

2. The debate on making the memory model immutable did not expose this
regression. We can never ensure that we have a perfect debate on any
change. Making a new release always comes with the risk of breaking
something for somebody. If we could actually get into the habit of making
regular releases then this would not be as big a deal

While it is important that we maintain our community of users, doing that
requires that we maintain our community of developers. We should be
encouraging developers who do not have the weight of experience of having
many many customers to support to learn from us and to develop ways of
making changes that reduce risk.

FTR I am also concerned about some of the changes that seem to have gone in
for 3.4.0 (in fact I was the one who flagged the issue with the
modelVersion change) but I see that there is the potential that for some of
those changes the correct fix is to fix the integration tests... but they
need a case by case evaluation and I have not had the time to do that...
though on a release VOTE thread I will be reviewing the changes to the
integration tests as well as master

-Stephen


>
> > On Nov 17, 2016, at 12:10 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
> >
> > Jason, your hyperbole has slipped again. There is no need to make
> > assertions about how many or what kind of users other developers have
> > worked with, as that both does not foster the community and deflects from
> > the valid point you were otherwise making. Christian has done the right
> > thing in seeking consensus before attempting to make a change in this
> area
> > and what thanks does he get? Instead he gets trampled on because in the
> > past he made breaking changes that would have had grave consequences. Do
> > not trample on somebody for doing the wrong thing in the past when they
> are
> > in the middle of doing the right thing! Jason, as to breaking changes in
> a
> > minor version... does that mean we can revert the immutable model changes
> > that broke lots of shade users builds?
> >
> > Christian, this project has historically taken very seriously the goal of
> > allowing users to upgrade Maven without breaking their existing builds.
> > Whether we should continue to do so is a separate question, but certainly
> > we cannot change mid-major version.
> >
> > I am still working on my proposal for a version 5 of Maven. I am
> proposing
> > version 5 for two reasons:
> >
> > 1. It allows us to align the modelVersion with the Maven version
> > 2. It gives space for behavioural changes before the big pom format
> change
> >
> > Now having said that, my proposal for Maven 5 is just *my* proposal. From
> > the point of view of making a decision for the direction of this project
> my
> > voice is just one voice amongst all the *committers*. It is the
> > *committers* that decide the direction of this project - not the PMC. The
> > PMC is responsible for governance and ensuring that releases meet the
> > foundation's legal criteria established by the board.
> >
> > I am encouraged by the energy Christian is showing for this project, in
> > part it has inspired me to put effort into describing my plan for a way
> > forward.
> >
> > What we need to do right now is get 3.4.0 released. That means ensuring
> > that the integration tests pass. In a separate part of this thread Igor
> > reports that there are 24 tests not passing against master. Somebody
> needs
> > to diagnose why those tests are failing. Some failures may require
> changes
> > to the integration tests... some may require fixing the code. Let's
> figure
> > out what the story is for those 24 tests.
> >
> > The point we need to remember about the goal for 3.4.0 is to be a release
> > with the code formerly known as Aether moved to the Maven project and bug
> > fixes applied to that code. We should keep our focus on that and try not
> to
> > grow the scope... there are users clamouring for fixing that set of
> > problems.
> >
> > Once we have the 3.4.x line then we should sit down and plan the path
> > forward.
> >
> > -Stephen
> >
> >
> > On 16 November 2016 at 05:44, Christian Schulte <cs@schulte.it> wrote:
> >
> >> To sum it up. I've asked the very same question a few weeks ago. That
> >> has lead to creating that maven-3.x-next branch. A few weeks later I get
> >> a different answer and that branch becomes obsolete and all JIRA issues
> >> for version 3.5.0 need updating and the branch can be deleted, because
> >> it became meaningless.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message