but it used to be ant, why abandon ant?

On Wed, May 16, 2012 at 7:15 AM, smith jack <[EMAIL PROTECTED]> wrote:
> but it used to be ant, why abandon ant?

I'd say the following 3 benefits were totally worth the switch:
   * standardization of build system
   * standardization of dependency management (for both upstream and
downstream projects)
   * standardization of IDE project imports

Of course, all of the above is theoretically possible with
Ant/Ivy, but it takes so much pain and discipline that
I haven't seen materialize in practical terms.

Thanks,
Roman.

I would also mention a benefit of testing and inter-component integration
standardization. This is, essentially, what BigTop has done by introducing and
supporting open-source solution for creating and validating Hadoop stacks.

Funnily enough, this simple concept was too hard to grok for some of the
commercial vendors. The management there were literally insisting on doing
_manual_ testing for their packages (at least at the time that when I was
working for one of them and observing it:) But I guess this is a different
story...

Cos

On Wed, May 16, 2012 at 7:15 AM, smith jack <[EMAIL PROTECTED]> wrote:
> > but it used to be ant, why abandon ant?
>
> I'd say the following 3 benefits were totally worth the switch:
>    * standardization of build system
>    * standardization of dependency management (for both upstream and
> downstream projects)
>    * standardization of IDE project imports
>
> Of course, all of the above is theoretically possible with
> Ant/Ivy, but it takes so much pain and discipline that
> I haven't seen materialize in practical terms.
>
> Thanks,
> Roman.

another reason: some people felt that the ant builds were excessively
deterministic. by including random downloads of -SNAPSHOT artifacts the
build has been made more enteratining

On 16 May 2012 21:40, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:

> I would also mention a benefit of testing and inter-component integration
> standardization. This is, essentially, what BigTop has done by introducing
> and
> supporting open-source solution for creating and validating Hadoop stacks.
>
>
> Funnily enough, this simple concept was too hard to grok for some of the
> commercial vendors. The management there were literally insisting on doing
> _manual_ testing for their packages (at least at the time that when I was
> working for one of them and observing it:) But I guess this is a different
> story...
>
>
I seem to recall showing someone (todd?) at an apachecon a few years back
how my ant build would scp the just-built RPMs to a test VM, install them,
walk them through their lifecycle and then verify that they uninstall.

Hallelujah.

I thought I was the only one who felt that maven's non-deterministic result was just plain batty.

In this mavenized world, is it guaranteed that if I build twice using maven on two different machines in two different locations, I will get the same exact bits?

If this guarantee exists, then I apologize for polluting the Internet with this posting.
If this is not true, then this is not a build system - it is a right royal cr** shoot system masquerading as a build system.

Jagane
-----Original Message-----
From: Steve Loughran [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2012 2:10 PM
To: [EMAIL PROTECTED]
Subject: Re: why hadoop choose maven as its build tool?

another reason: some people felt that the ant builds were excessively
deterministic. by including random downloads of -SNAPSHOT artifacts the
build has been made more enteratining

On 16 May 2012 21:40, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:

> I would also mention a benefit of testing and inter-component integration
> standardization. This is, essentially, what BigTop has done by introducing
> and
> supporting open-source solution for creating and validating Hadoop stacks.
>
>
> Funnily enough, this simple concept was too hard to grok for some of the
> commercial vendors. The management there were literally insisting on doing
> _manual_ testing for their packages (at least at the time that when I was
> working for one of them and observing it:) But I guess this is a different
> story...
>
>
I seem to recall showing someone (todd?) at an apachecon a few years back
how my ant build would scp the just-built RPMs to a test VM, install them,
walk them through their lifecycle and then verify that they uninstall.

If you depend on released artifacts that you havent overridden then maven is deterministic.

If you depend on snapshot artifacts then you get the latest snapshot which could change between builds.  But you asked for that.

Sent from my iPhone

On May 17, 2012, at 5:23 PM, Jagane Sundar <[EMAIL PROTECTED]> wrote:

> Hallelujah.
>
> I thought I was the only one who felt that maven's non-deterministic result was just plain batty.
>
> In this mavenized world, is it guaranteed that if I build twice using maven on two different machines in two different locations, I will get the same exact bits?
>
> If this guarantee exists, then I apologize for polluting the Internet with this posting.
> If this is not true, then this is not a build system - it is a right royal cr** shoot system masquerading as a build system.
>
> Jagane
>
>
> -----Original Message-----
> From: Steve Loughran [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 17, 2012 2:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: why hadoop choose maven as its build tool?
>
> another reason: some people felt that the ant builds were excessively
> deterministic. by including random downloads of -SNAPSHOT artifacts the
> build has been made more enteratining
>
> On 16 May 2012 21:40, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:
>
>> I would also mention a benefit of testing and inter-component integration
>> standardization. This is, essentially, what BigTop has done by introducing
>> and
>> supporting open-source solution for creating and validating Hadoop stacks.
>>
>
>
>
>
>>
>> Funnily enough, this simple concept was too hard to grok for some of the
>> commercial vendors. The management there were literally insisting on doing
>> _manual_ testing for their packages (at least at the time that when I was
>> working for one of them and observing it:) But I guess this is a different
>> story...
>>
>>
> I seem to recall showing someone (todd?) at an apachecon a few years back
> how my ant build would scp the just-built RPMs to a test VM, install them,
> walk them through their lifecycle and then verify that they uninstall.

Regardless of whether your complaint is valid (I claim no knowledge of the subject matter), that was a very very fun post to read.  Thank you.

On May 17, 2012, at 14:10 , Steve Loughran wrote:

> another reason: some people felt that the ant builds were excessively
> deterministic. by including random downloads of -SNAPSHOT artifacts the
> build has been made more enteratining
________________________________________________________________________________
Keith Wiley     [EMAIL PROTECTED]     keithwiley.com    music.keithwiley.com

"I used to be with it, but then they changed what it was.  Now, what I'm with
isn't it, and what's it seems weird and scary to me."
                                           --  Abe (Grandpa) Simpson
________________________________________________________________________________

+1 on that: let's not mix snapshot dependencies and release dependencies.
  Latter are 100% deterministic
  Former aren't by design.

Case is closed ;) You can apologize now, Sundar ;)
  Cos

On Thu, May 17, 2012 at 06:15PM, Ted Dunning wrote:
> If you depend on released artifacts that you havent overridden then maven is deterministic.
>
> If you depend on snapshot artifacts then you get the latest snapshot which
> could change between builds.  But you asked for that.
>
> Sent from my iPhone
>
> On May 17, 2012, at 5:23 PM, Jagane Sundar <[EMAIL PROTECTED]> wrote:
>
> > Hallelujah.
> >
> > I thought I was the only one who felt that maven's non-deterministic result was just plain batty.
> >
> > In this mavenized world, is it guaranteed that if I build twice using
> > maven on two different machines in two different locations, I will get the
> > same exact bits?
> >
> > If this guarantee exists, then I apologize for polluting the Internet with
> > this posting.
> > If this is not true, then this is not a build system - it is a right royal cr** shoot system masquerading as a build system.
> >
> > Jagane
> >
> >
> > -----Original Message-----
> > From: Steve Loughran [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, May 17, 2012 2:10 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: why hadoop choose maven as its build tool?
> >
> > another reason: some people felt that the ant builds were excessively
> > deterministic. by including random downloads of -SNAPSHOT artifacts the
> > build has been made more enteratining
> >
> > On 16 May 2012 21:40, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:
> >
> >> I would also mention a benefit of testing and inter-component integration
> >> standardization. This is, essentially, what BigTop has done by introducing
> >> and
> >> supporting open-source solution for creating and validating Hadoop stacks.
> >>
> >
> >
> >
> >
> >>
> >> Funnily enough, this simple concept was too hard to grok for some of the
> >> commercial vendors. The management there were literally insisting on doing
> >> _manual_ testing for their packages (at least at the time that when I was
> >> working for one of them and observing it:) But I guess this is a different
> >> story...
> >>
> >>
> > I seem to recall showing someone (todd?) at an apachecon a few years back
> > how my ant build would scp the just-built RPMs to a test VM, install them,
> > walk them through their lifecycle and then verify that they uninstall.

On 17 May 2012 15:15, Ted Dunning <[EMAIL PROTECTED]> wrote:
> If you depend on released artifacts that you havent overridden then maven is deterministic.
>
> If you depend on snapshot artifacts then you get the latest snapshot which could change between builds.  But you asked for that.
true, but as trunk generates it's own snapshots the only way to be
100% sure that mvn isn't downloading the nightly build versions and
not your locally built stuff is to build with the -o setting. This
ensures that your local artifacts are the ones that get used, but also
mean that the moment you reach some state in maven that needs to
download 300 JARs for some plugin then you are in trouble.

But I digress.

Speaking of test reporting -what do you do to get good reports, where
reports mean: "human readable information needed to track down bugs
fast". I know I can get good stuff with Jenkins, and in theory could
bring up Jenkins nearby sharing git repositories and doing CI builds
of my own code, but I'd like something simpler such as the output of
"mvn test" to go into HTML files -with stack traces.I haven't got mvn
site to pull in the whole stack traces, which is what the IDE needs.