Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
On 2018-06-24, Gintautas Grigelionis wrote: > On Sun, 24 Jun 2018 at 14:38, Stefan Bodewig 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
On Sun, 24 Jun 2018 at 14:38, Stefan Bodewig 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
On 2018-06-24, Gintautas Grigelionis wrote: > On Sun, 24 Jun 2018 at 12:43, Stefan Bodewig 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
On Sun, 24 Jun 2018 at 12:43, Stefan Bodewig 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
On 2018-06-24, Gintautas Grigelionis wrote: > On Fri, 22 Jun 2018 at 09:45, Stefan Bodewig 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
On Fri, 22 Jun 2018 at 09:45, Stefan Bodewig 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
On 2018-06-22, Gintautas Grigelionis wrote: > On Fri, 22 Jun 2018 at 07:22, Stefan Bodewig 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
On Fri, 22 Jun 2018 at 07:22, Stefan Bodewig 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
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
On Thu, 21 Jun 2018 at 11:17, 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. > 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
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org