Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
From: =?ISO-8859-1?Q?Herv=E9?= BOUTEMY <herve.boutemy@free.fr>
To: Maven Developers List <dev@maven.apache.org>
Subject: Re: Pain with MNG-5181 (_maven.repositories)
Date: Sun, 03 Feb 2013 10:12:35 +0100
Message-ID: <27755383.35kiOfxmSB@bigmax>
User-Agent: KMail/4.8.5 (Linux/3.2.0-37-generic; KDE/4.8.5; x86_64; ; )
In-Reply-To: <96D75A8B-F489-4BF1-A9ED-903FA355365F@tesla.io>
References: 
 <701203540.142078.1357922601074.JavaMail.open-xchange@webmail.strato.com>
 <CAFNCU-_QomQEftbKWL2vqZF44VNAQsLUhV78JE_VWyoPA6kRFg@mail.gmail.com>
 <96D75A8B-F489-4BF1-A9ED-903FA355365F@tesla.io>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

Le samedi 2 f=E9vrier 2013 22:39:55 Jason van Zyl a =E9crit :
> On Feb 1, 2013, at 3:47 AM, Arnaud H=E9ritier <aheritier@gmail.com> w=
rote:
> > My position was to propose the low cost possible solution to have a=
 quick
> > fix and not to wait for months.
>=20
> You realize that disabling this feature allows the potential for a de=
veloper
> to go home, download something in a build with a GAV and go to work w=
here
> that GAV doesn't correspond to the same thing for whatever reason -- =
and he
> will never know or be warned with it disabled. Maybe the JAR is patch=
ed and
> not renamed but does something important for the organization like fi=
x a
> security problem. This might cause a disparity in how the build behav=
es in
> a mild case where he sees something different than the other develope=
rs.
> Worst case is that artifact finds its way into something it's not sup=
posed
> to and cause a real problem.
is it really a part of the feature? I didn't understand that this featu=
re=20
calculated something like a checksum of an artifact and could store the=
=20
artifact multiple times

I thought it was only to avoid for example downloading a dependency fro=
m a=20
plugin then use it in component dependency (ie the use case I was expec=
ting):=20
that's what I understanding when reading aether-impl's=20
EnhancedLocalRepositoryManager javadoc and source (in source, since thi=
s class=20
is package private, then not published in javadoc)

Am I wrong? Do I miss something?


>=20
> Maven currently does not consider the same GAV from two different sou=
rces to
> be the same and for good reason. If we added the logic which asserted=
 they
> were, in fact, the same JAR like checking the SHA1 I think that would=
 be
> perfectly reasonable. Turning it off is just not wise.
Turning it off is just a workaround to get the same behaviour than Mave=
n 2,=20
which is not perfect but that everybody understand, to help people whil=
e we're=20
working to understand the feature ourselves (yes, ourselves...) and doc=
ument=20
it sufficiently for end-users

>=20
> If you move around between work and home a lot use a repository manag=
er
> locally. I've done that forever and I don't have any issues aside fro=
m
> having to add the odd proxy repository when there is a repository lis=
ted in
> a POM. I don't consider it a problem and it prevents the problem of
> mismatched identity. This logic should be improved not neutered.
+1 but if we can't improve it before the next release, disabling it can=
 be a=20
temporary solution since this feature is really hard for users

> And I'm
> frankly tired of slapdash changes like this being made in the core wi=
thout
> any discussion or review.
which change are you talking about? enhanced local repository without r=
eally=20
understanding or documentation, or the addition of -slrm option as a=20=

reasonable fix for MNG-5181, ie add an option to disable the enhanced l=
ocal=20
repository manager?


> The last two major changes I've made I've asked
> other to review my work which I think now with some other incidents o=
f late
> that would be wise for all changes to the core.
>=20
> I'm -1 on disabling this feature by default.
nice, it isn't disabled by default, Olivier did a nice job to not break=
=20
anything


> Fix it properly, using a
> property to turn it off is half measure which potentially causes user=
s even
> more severe problems.
+1
I'm trying to find a better way for a long time now, that's why I tried=
 to=20
write maven-aether-provider unit tests as a first step
but for the moment, I couldn't find a solution: thank you Olivier for f=
inding=20
some workaround, even if not ideal
if anydoby has a clue on how to solve the problem, please explain (and =
"just=20
do it" is not an explanation)


> > If it could be fixed/configurable in aether it may be the solution =
to
> > follow but I'm not sure about the status of this 3rd party project
> > (eclipse
> > migration ...) on which we don't have the hand.
> > Seriously I helped and lost MANY hours with this problem because it=
 is
> > hard
> > to diagnose.
> > I'm sure that many people abandoned to try to understand and just d=
ropped
> > their local repo or decided to downgraded to m2 (or to switch to an=
other
> > tool).
> > I think we can have a lot of similar feedbacks.
> > The worst thing is to have another thing that users don't understan=
d (lake
> > of documentation ? communication ?)
> > The side effect is that changing a repository id (or mirror id) mak=
es
> > maven
> > to re-download all the earth (while we are claiming from the beginn=
ing
> > that
> > Maven won't never download twice a release).
> > And when the remote artifact just disappeared it is just a nightmar=
e due
> > to
> > the lake of correct logs and this case is easy to have.
> > For example in my company I have a profile to let people DL artifac=
ts from
> > staging repositories (thus these are releases). It happened that th=
ey
> > activated it once to test a build and then they rebuild the project=

> > without
> > the profile (thinking the artifact is in the local repo) and it fai=
ls ...
> >=20
> > Sincerely I think I had my worst headaches with maven due to this b=
ug
> >=20
> > On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl <jason@tesla.io> wrot=
e:
> >> On Jan 31, 2013, at 7:13 PM, Arnaud H=E9ritier <aheritier@gmail.co=
m> wrote:
> >>> Hi Olivier,
> >>>=20
> >>> Thx a lot for the fix. It will help a lot the community.
> >>> But from my point of view it's perhaps not yet enough.
> >>> We should :
> >>> 1/ change the default behavior to deactivate this control which i=
s
> >>> difficult to understand
> >>=20
> >> I disagree. We may want to change it slightly but it's only a prob=
lem for
> >> people who flip between Maven a repository manager and without but=
 it's
> >> to
> >> ensure the identity of a component. I haven't seen a huge number o=
f
> >> complaints. I do not want to turn this off. Improve it, sure, but =
turning
> >> it off by default I believe is not the right thing to do.
> >>=20
> >>> 2/ change the error message when this control is activated to cle=
arly
> >>> explain that the problem comes from the unavailability of the art=
ifact
> >>> on
> >>> its original remote repo.
> >>>=20
> >>> For me 1/ is mandatory and 2/ a nice to have
> >>>=20
> >>> WDYT ?
> >>>=20
> >>> On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy <olamy@apache.org> =
wrote:
> >>>> I have pushed a fix for that.
> >>>> Now you can desactivate the enhanced local repository using:
> >>>> * new cli option: -slrm,--simple-local-repository-manager
> >>>> * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=3Dtrue
> >>>>=20
> >>>> will be available for testing here
> >>>> https://builds.apache.org/job/maven-3.x/ with build #368
> >>>>=20
> >>>> 2013/1/31 J=F6rg Hohwiller <joerg@j-hohwiller.de>:
> >>>>> Hi Arnaud,
> >>>>>=20
> >>>>>> +1 to consider the current behavior as a bug.
> >>>>>> We should be able to deactivate it easily (and perhaps to have=
 it off
> >>=20
> >> by
> >>=20
> >>>>>> default to activate it only on CI servers)
> >>>>>>=20
> >>>>> :)
> >>>>> :
> >>>>>> and we should take care to have
> >>>>>> a real error message explaining the issue and not a classical
> >>=20
> >> dependency
> >>=20
> >>>>>> not found while the artifact is in the local repo.
> >>>>>=20
> >>>>> This is exactly filed here:
> >>>>> http://jira.codehaus.org/browse/MNG-5185
> >>>>>=20
> >>>>>> Arnaud
> >>>>>=20
> >>>>> Cheers
> >>>>> J=F6rg
> >>>>>=20
> >>>>> --
> >>>>> If know-how becomes know-where, then knowledge gets nowhere.
> >>>>> [J=F6rg Hohwiller]
> >>>>=20
> >>>> --
> >>>> Olivier Lamy
> >>>> Talend: http://coders.talend.com
> >>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>>=20
> >>>> ----------------------------------------------------------------=
-----
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>=20
> >>> --
> >>> -----
> >>> Arnaud H=E9ritier
> >>> http://aheritier.net
> >>> Mail/GTalk: aheritier AT gmail DOT com
> >>> Twitter/Skype : aheritier
> >>=20
> >> Thanks,
> >>=20
> >> Jason
> >>=20
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder & CTO, Sonatype
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>=20
> >> Our achievements speak for themselves. What we have to keep track
> >> of are our failures, discouragements and doubts. We tend to forget=

> >> the past difficulties, the many false starts, and the painful
> >> groping. We see our past achievements as the end result of a
> >> clean forward thrust, and our present difficulties as
> >> signs of decline and decay.
> >>=20
> >> -- Eric Hoffer, Reflections on the Human Condition
>=20
> Thanks,
>=20
> Jason
>=20
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>=20
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
>=20
>   -- Jakob Burckhardt

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