You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2018/06/21 09:17:35 UTC
[CANCELLED] Release AntUnit 1.4 Based on RC2
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-06-24, Gintautas Grigelionis wrote:
> On Sun, 24 Jun 2018 at 14:38, Stefan Bodewig <bo...@apache.org> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Gintautas Grigelionis <g....@gmail.com>.
On Sun, 24 Jun 2018 at 14:38, Stefan Bodewig <bo...@apache.org> 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
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-06-24, Gintautas Grigelionis wrote:
> On Sun, 24 Jun 2018 at 12:43, Stefan Bodewig <bo...@apache.org> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Gintautas Grigelionis <g....@gmail.com>.
On Sun, 24 Jun 2018 at 12:43, Stefan Bodewig <bo...@apache.org> 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
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-06-24, Gintautas Grigelionis wrote:
> On Fri, 22 Jun 2018 at 09:45, Stefan Bodewig <bo...@apache.org> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Gintautas Grigelionis <g....@gmail.com>.
On Fri, 22 Jun 2018 at 09:45, Stefan Bodewig <bo...@apache.org> 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
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-06-22, Gintautas Grigelionis wrote:
> On Fri, 22 Jun 2018 at 07:22, Stefan Bodewig <bo...@apache.org> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Gintautas Grigelionis <g....@gmail.com>.
On Fri, 22 Jun 2018 at 07:22, Stefan Bodewig <bo...@apache.org> 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
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Stefan Bodewig <bo...@apache.org>.
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Gintautas Grigelionis <g....@gmail.com>.
On Thu, 21 Jun 2018 at 11:17, Stefan Bodewig <bo...@apache.org> 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?
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
Posted by Jaikiran Pai <ja...@gmail.com>.
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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org