[VOTE] Release AntUnit 1.4 Based on RC2

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[VOTE] Release AntUnit 1.4 Based on RC2

Stefan Bodewig
Hi all

this is the second RC for AntUnit 1.4 with the problems Jaikiran
identified fixed.

tag:
     https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-antunit.git;a=tag;h=21c61e523c767bd1433544596478e9af7ce98858

tarballs:
     https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/
     svn revision 27611

Maven artifacts:
     https://repository.apache.org/content/repositories/orgapacheant-1032/org/apache/ant/ant-antunit/1.4/

vote will be open for 72 hours and not close before 2018-06-24 07:00 UTC.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release AntUnit 1.4 Based on RC2

Gintautas Grigelionis
POM template has inconsistent Ant versions, 1.7.1 in compile scope and
1.8.1 in provided scope.

Gintas

On Thu, 21 Jun 2018 at 08:57, Stefan Bodewig <[hidden email]> wrote:

> Hi all
>
> this is the second RC for AntUnit 1.4 with the problems Jaikiran
> identified fixed.
>
> tag:
>
> https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-antunit.git;a=tag;h=21c61e523c767bd1433544596478e9af7ce98858
>
> tarballs:
>      https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/
>      svn revision 27611
>
> Maven artifacts:
>
> https://repository.apache.org/content/repositories/orgapacheant-1032/org/apache/ant/ant-antunit/1.4/
>
> vote will be open for 72 hours and not close before 2018-06-24 07:00 UTC.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

[CANCELLED] Release AntUnit 1.4 Based on RC2

Stefan Bodewig
On 2018-06-21, Gintautas Grigelionis wrote:

> POM template has inconsistent Ant versions, 1.7.1 in compile scope and
> 1.8.1 in provided scope.

True.

This happened in c3f8655 which updated the dependencies to 1.8.1 because
one of the unit tests used a method of ant-testutil that hasn't been
present in Ant 1.7.

We could fix the test or explicitly document Ant 1.8.x as new
requirement - which really doesn't exist except for the tests.

The upgrade would be a breaking change but I don't expect it would break
anything in real life. Some of the other antlibs may require Ant 1.7 but
the only other one I'd expect to get new releases (Compress) is at 1.8
already, so upgrading the dependency probably doesn't do any harm to
them.

Any opinions?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Jaikiran Pai
I think moving to Ant 1.8.x would be a better option, given the
relatively low chances of it causing any issues.

-Jaikiran


On 21/06/18 2:47 PM, Stefan Bodewig wrote:

> On 2018-06-21, Gintautas Grigelionis wrote:
>
>> POM template has inconsistent Ant versions, 1.7.1 in compile scope and
>> 1.8.1 in provided scope.
> True.
>
> This happened in c3f8655 which updated the dependencies to 1.8.1 because
> one of the unit tests used a method of ant-testutil that hasn't been
> present in Ant 1.7.
>
> We could fix the test or explicitly document Ant 1.8.x as new
> requirement - which really doesn't exist except for the tests.
>
> The upgrade would be a breaking change but I don't expect it would break
> anything in real life. Some of the other antlibs may require Ant 1.7 but
> the only other one I'd expect to get new releases (Compress) is at 1.8
> already, so upgrading the dependency probably doesn't do any harm to
> them.
>
> Any opinions?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Gintautas Grigelionis
In reply to this post by Stefan Bodewig
On Thu, 21 Jun 2018 at 11:17, Stefan Bodewig <[hidden email]> wrote:

> On 2018-06-21, Gintautas Grigelionis wrote:
>
> > POM template has inconsistent Ant versions, 1.7.1 in compile scope and
> > 1.8.1 in provided scope.
>
> True.
>
> This happened in c3f8655 which updated the dependencies to 1.8.1 because
> one of the unit tests used a method of ant-testutil that hasn't been
> present in Ant 1.7.
>
> We could fix the test or explicitly document Ant 1.8.x as new
> requirement - which really doesn't exist except for the tests.
>
> The upgrade would be a breaking change but I don't expect it would break
> anything in real life. Some of the other antlibs may require Ant 1.7 but
> the only other one I'd expect to get new releases (Compress) is at 1.8
> already, so upgrading the dependency probably doesn't do any harm to
> them.
>

I decide to look at antlib builds, and I wonder why common/build.properties
contain

javac.-source=1.2
javac.-target=1.2

Shouldn't antlibs be baselined to something more recent? If I remember it
correctly,
Ant 1.8 was meant for Java 1.4, so I would suggest either that or the
oldest maintained
version of Ant, i.e. 1.9, corresponding to Java 5.

Gintas

P.S. I'm struggling to understand why "ant test" of antlibs bails because
"compile-tests" goes "setup-for-junit-tests, antlib, resolve" rather than
doing "resolve" first
and using the retrieved dependencies?
Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Stefan Bodewig
On 2018-06-21, Gintautas Grigelionis wrote:

> I decide to look at antlib builds,

Great.

> and I wonder why common/build.properties contain

> javac.-source=1.2
> javac.-target=1.2

Because this has been the baseline when we created the antlibs and
nobody has bothered to update them.

> Shouldn't antlibs be baselined to something more recent?

I'd say yes for any Antlib that was under active development - i.e. at
best AntUnit and Compress (which is my pet project but likely not used
by many people).

> P.S. I'm struggling to understand why "ant test" of antlibs bails
> because "compile-tests" goes "setup-for-junit-tests, antlib, resolve"
> rather than doing "resolve" first and using the retrieved
> dependencies?

antlib depends on compile which depends on resolve - so resolve is
supposed to be run long before any of the other targets,

Not sure what "bails" in your case (it doesn't for me) but maybe we are
missing a dependency somewhere in the graph.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Gintautas Grigelionis
On Fri, 22 Jun 2018 at 07:22, Stefan Bodewig <[hidden email]> wrote:

> On 2018-06-21, Gintautas Grigelionis wrote:
> > P.S. I'm struggling to understand why "ant test" of antlibs bails
> > because "compile-tests" goes "setup-for-junit-tests, antlib, resolve"
> > rather than doing "resolve" first and using the retrieved
> > dependencies?
>
> antlib depends on compile which depends on resolve - so resolve is
> supposed to be run long before any of the other targets,
>
> Not sure what "bails" in your case (it doesn't for me) but maybe we are
> missing a dependency somewhere in the graph.
>

Well, setup-for-junit-tests states that JUnit is not available and quits.
I'd like to
understand why setup targets are there at all.

Gintas
Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Stefan Bodewig
On 2018-06-22, Gintautas Grigelionis wrote:

> On Fri, 22 Jun 2018 at 07:22, Stefan Bodewig <[hidden email]> wrote:

>> On 2018-06-21, Gintautas Grigelionis wrote:
>>> P.S. I'm struggling to understand why "ant test" of antlibs bails
>>> because "compile-tests" goes "setup-for-junit-tests, antlib, resolve"
>>> rather than doing "resolve" first and using the retrieved
>>> dependencies?

>> antlib depends on compile which depends on resolve - so resolve is
>> supposed to be run long before any of the other targets,

>> Not sure what "bails" in your case (it doesn't for me) but maybe we are
>> missing a dependency somewhere in the graph.

> Well, setup-for-junit-tests states that JUnit is not available and
> quits.

So it lacks a dependency on resolve.

> I'd like to understand why setup targets are there at all.

They predate resolve by far. The initial build system for Antlibs didnt
use Ivy at all but expected manual configuration and the setup targets
ensured everything was there. When Ivy was added later (by Jan?) he
probably fmissed to adapt a few places - like setup-for-junit-tests.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Gintautas Grigelionis
On Fri, 22 Jun 2018 at 09:45, Stefan Bodewig <[hidden email]> wrote:

> On 2018-06-22, Gintautas Grigelionis wrote:
>
> > Well, setup-for-junit-tests states that JUnit is not available and
> > quits.
>
> So it lacks a dependency on resolve.
>
> > I'd like to understand why setup targets are there at all.
>
> They predate resolve by far. The initial build system for Antlibs didnt
> use Ivy at all but expected manual configuration and the setup targets
> ensured everything was there. When Ivy was added later (by Jan?) he
> probably missed to adapt a few places - like setup-for-junit-tests.
>

Actually, the targets are written in a way that checks explicitly for JUnit
3.
Should they be rewritten to check for JUnit 4, the baseline has to be moved
to
all the way Ant 1.9.5 because of BuildFileRule being first available in
that version.

Then, the order of compile-tests target dependencies must be changed so
that setup-for-junit-tests comes after antlib (which does resolve,
therefore explicit
resolve becomes redundant) and uses classpaths defined by resolve to
check for JUnit.

Gintas
Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Stefan Bodewig
On 2018-06-24, Gintautas Grigelionis wrote:

> On Fri, 22 Jun 2018 at 09:45, Stefan Bodewig <[hidden email]> wrote:

>> On 2018-06-22, Gintautas Grigelionis wrote:

>>> Well, setup-for-junit-tests states that JUnit is not available and
>>> quits.

>> So it lacks a dependency on resolve.

>>> I'd like to understand why setup targets are there at all.

>> They predate resolve by far. The initial build system for Antlibs didnt
>> use Ivy at all but expected manual configuration and the setup targets
>> ensured everything was there. When Ivy was added later (by Jan?) he
>> probably missed to adapt a few places - like setup-for-junit-tests.

> Actually, the targets are written in a way that checks explicitly for
> JUnit 3.  Should they be rewritten to check for JUnit 4, the baseline
> has to be moved to all the way Ant 1.9.5 because of BuildFileRule
> being first available in that version.

Would moving to JUnit 4 force us to use BuildFileRule? I'm pretty sure
we've used JUnit4 before 1.9.5 but may be wrong.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Gintautas Grigelionis
On Sun, 24 Jun 2018 at 12:43, Stefan Bodewig <[hidden email]> wrote:

> On 2018-06-24, Gintautas Grigelionis wrote:
> > Actually, the targets are written in a way that checks explicitly for
> > JUnit 3.  Should they be rewritten to check for JUnit 4, the baseline
> > has to be moved to all the way Ant 1.9.5 because of BuildFileRule
> > being first available in that version.
>
> Would moving to JUnit 4 force us to use BuildFileRule? I'm pretty sure
> we've used JUnit4 before 1.9.5 but may be wrong.
>

BuildFileRule is necessary when test case no longer extend BuildFileRule
which extends TestCase which is JUnit 3,

Gintas
Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Stefan Bodewig
On 2018-06-24, Gintautas Grigelionis wrote:

> On Sun, 24 Jun 2018 at 12:43, Stefan Bodewig <[hidden email]> wrote:

>> On 2018-06-24, Gintautas Grigelionis wrote:
>>> Actually, the targets are written in a way that checks explicitly for
>>> JUnit 3.  Should they be rewritten to check for JUnit 4, the baseline
>>> has to be moved to all the way Ant 1.9.5 because of BuildFileRule
>>> being first available in that version.

>> Would moving to JUnit 4 force us to use BuildFileRule? I'm pretty sure
>> we've used JUnit4 before 1.9.5 but may be wrong.

> BuildFileRule is necessary when test case no longer extend BuildFileRule
> which extends TestCase which is JUnit 3,

So if we went to a JUnit 4 only model in antlib-commons with what you
describe this would require the Antlib that updated to a new
antlibs-commons version to change all existing JUnit tests?

Most likely this would only affect AntUnit itself as the other antlibs
are either, errm, dormant or don't contain any JUnit tests at all
(Compress only uses AntUnit tests).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Gintautas Grigelionis
On Sun, 24 Jun 2018 at 14:38, Stefan Bodewig <[hidden email]> wrote:

> So if we went to a JUnit 4 only model in antlib-commons with what you
> describe this would require the Antlib that updated to a new
> antlibs-commons version to change all existing JUnit tests?
>

My point was that should some antlib start using JUnit 4-style (annotated)
tests,
then it should depend on ant-testutil 1.9.5 or newer, and, by extension, on
Ant 1.9.x

On top of that, antlib-commons would need adjustments to check for classes
relevant
to JUnit 4; regardless, there are issues with target dependencies like
redundant resolve
or ordering (antlib after setup-for-junit-tests rather than the other way
around).

Gintas
Reply | Threaded
Open this post in threaded view
|

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

Stefan Bodewig
On 2018-06-24, Gintautas Grigelionis wrote:

> On Sun, 24 Jun 2018 at 14:38, Stefan Bodewig <[hidden email]> wrote:

>> So if we went to a JUnit 4 only model in antlib-commons with what you
>> describe this would require the Antlib that updated to a new
>> antlibs-commons version to change all existing JUnit tests?

> My point was that should some antlib start using JUnit 4-style
> (annotated) tests, then it should depend on ant-testutil 1.9.5 or
> newer, and, by extension, on Ant 1.9.x

ACK.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]