Hi,
I would do it but for some reason my Apache ID ("archie") is no longer
permitted to commit to the Ivy repository (it used to work).
If whoever is in charge of that can fix it, I'll commit it for you...
-Archie
On Wed, Feb 17, 2016 at 6:41 AM, Markus Schlegel <sch...@gmail.com> wrote:
> Are there any committers listening to this list?
> What do I have to do such that this issue gets fixed in the sourcecode?
>
> Kind regards,
>
> Markus Schlegel
>
> 2016-01-15 9:39 GMT+01:00 Markus Schlegel <sch...@gmail.com>:
>
> > Hi
> > There is a critical issue in Ivy "deliver":
> > https://issues.apache.org/jira/browse/IVY-1485
> > It has been filed in September 2014 together with a patch.
> > Unfortunately, it seems that it never has been applied to the code base.
> >
> > I would kindly ask if any of the current IVY commiters would be so kind
> to
> > apply the patch to the codebase for future IVY releases.
> >
> > There are at least three other people which have encountered this
> problem,
> > and I suspect all of them required HUGE work to find it out. As of this,
> it
> > can be expected that many if not all users of the deliver task inside a
> > reasonably large project suffer from this problem.
> >
> > Let me explain why this issue is so problematic:
> > In my case, our project worked with the retrieved artefacts during
> > development, which works perfectly well. Our delivery has been built
> > automatically on a CI-Server.
> > After some time, some dependent library change and also our dependency
> > requirements changed. During development and tests, everything seemed ok.
> > Unfortunately not in the delivery, since "somehow" one of the delivered
> > libraries was not in the expected version. The "ivy report" reported the
> > correct version (since it is built after the retrieve), but the delivery
> > simply had a different version.
> > We were expecting that by using IVY for the dependency management should
> > have protected us from such library version problems, but in fact, today
> > IVY is the source for such defects.
> >
> > So, many thanks in advance for the committer which takes care for this
> > problem.
> > With kind regards,
> > Markus Schlegel
> >
>
--
Archie L. Cobbs
