new build output directory 'target'

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

new build output directory 'target'

Holger
Hey guys,

I've changed the build file to use the new common base output directory 'target'.

So everything is generated into this directory, for example:

target/classes
target/test-classes
target/reports
target/docs
target/demojar
target/java14_glazedlists
target/glazedlists*.jar
target/glazedlists*.zip


Before you do a CVS update you probably want to run an 'ant clean' to remove the old
output directories.

In addition, you should configure your IDE to
- place compiled java classes in target/classes
and
- place compiled java test classes in target/test-classes

Please check it out and let me know any problems.

Thanks,
Holger

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

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

Reply | Threaded
Open this post in threaded view
|

Re: new build output directory 'target'

James Lemieux
Holger,

   I tested out all of the targets. They work great on my machine. I made two small changes:

1) I added a target for the new treetable extension

2) I added a couple of excludes to the source.zip that we generate:

            <exclude name="*.iml"/> <!-- Intellij IDEA Module File -->
            <exclude name="*.ipr"/> <!-- Intellij IDEA Project File -->
            <exclude name="*.iws"/> <!-- Intellij IDEA Workspace File -->
            <exclude name="*.tfpt"/> <!-- Performance Test Data (mozillabugs.tfpt, mp3collection.tfpt) -->

since it was creating a 9 MB source zip on my system. We have some large data files, that aren't in source control, that we used for performance testing (one of them is 25 MBs unzipped). I like keeping them in my root folder, though obviously I don't want to put them in the source zip unwittingly...

If you don't mind including Intellij's IDE files, then we can get rid of the first 3 lines. Those files are slightly larger than 100K combined.

Jesse, we should go through and clean up our broken test cases. I also think we should remove those perpetually broken tests in EventListTest. They aren't totally valid test cases, and I doubt we either CAN or WILL fix them. They are the ones that try to remove a collection from itself, etc. Remember, even the stock Collections implementations don't handle these cases.

Good Job Holger,

James

On 7/23/06, Holger Brands <[hidden email]> wrote:
Hey guys,

I've changed the build file to use the new common base output directory 'target'.

So everything is generated into this directory, for example:

target/classes
target/test-classes
target/reports
target/docs
target/demojar
target/java14_glazedlists
target/glazedlists*.jar
target/glazedlists*.zip


Before you do a CVS update you probably want to run an 'ant clean' to remove the old
output directories.

In addition, you should configure your IDE to
- place compiled java classes in target/classes
and
- place compiled java test classes in target/test-classes

Please check it out and let me know any problems.

Thanks,
Holger

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

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


Reply | Threaded
Open this post in threaded view
|

Re: new build output directory 'target'

Holger
In reply to this post by Holger
Hi James,

> Holger,
>
>    I tested out all of the targets. They work great on my machine. I made two small changes:
>
> 1) I added a target for the new treetable extension
>
> 2) I added a couple of excludes to the source.zip
>  that we generate:
>
>             <exclude name="*.iml"/> <!-- Intellij IDEA Module File -->
>             <exclude name="*.ipr"/> <!-- Intellij IDEA Project File -->
>             <exclude name="*.iws"/> <!-- Intellij IDEA Workspace File -->
>
>             <exclude name="*.tfpt"/> <!-- Performance Test Data (mozillabugs.tfpt, mp3collection.tfpt) -->
>
> since it was creating a 9 MB source zip on my system. We have some large data files, that aren't in source control, that we used for performance testing (one of them is 25 MBs unzipped). I like keeping them in my root folder, though obviously I don't want to put them in the source zip unwittingly...
>

It's ok for me. I'll probably add some excludes for the two eclipse specific project files, too.

>
> Jesse, we should go through and clean up our broken test cases. I also think we should remove those perpetually broken tests in EventListTest. They aren't totally valid test cases, and I doubt we either CAN or WILL fix them. They are the ones that try to remove a collection from itself, etc. Remember, even the stock Collections implementations don't handle these cases.
>

+1

At least there should be a clear note in source code and test output that the existing broken tests are expected to fail.

Holger

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: new build output directory 'target'

Jesse Wilson
On 7/23/06, Holger Brands <[hidden email]> wrote:
> > Jesse, we should go through and clean up our broken test cases.

Good idea. But broken test cases are a good thing, since
they remind us that there are still unresolved problems in
the code!

I've seen annotations used for this purpose:

    @Suppress("Bug134");
   public void testSomethingThatsNotYetFixed() { ... }

It's nice, but it requires a lot more support from the test
mechanism, and stock JUnit doesn't do it out of the box.
I've been meaning to try out TestNG. You think anyone
would mind if we went down that road?

Cheers,
Jesse

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: new build output directory 'target'

Holger
In reply to this post by Holger
Hey Jesse,

> On 7/23/06, Holger Brands <[hidden email]> wrote:
> > > Jesse, we should go through and clean up our broken test cases.
>
> Good idea. But broken test cases are a good thing, since
> they remind us that there are still unresolved problems in
> the code!

That's true. But the issue tracker could serve this purpose, too.

I like the idea that running the tests is part of the release-making
process and all tests should pass. Failing test cases should abort
the release build.
Changing code with failing test cases is a tedious task because
you have to recheck every time if a new test case is broken
in additon to the already failing ones.

>
> I've seen annotations used for this purpose:
>
>     @Suppress("Bug134");
>    public void testSomethingThatsNotYetFixed() { ... }
>
> It's nice, but it requires a lot more support from the test
> mechanism, and stock JUnit doesn't do it out of the box.

I think JUnit 4 has an @Ignore annotation for this purpose.
But it requires JDK 1.5 ...

> I've been meaning to try out TestNG. You think anyone
> would mind if we went down that road?

I'm not sure, because I'm not very familiar with TestNG.
With TestNG you can enable/disable tests and/or exclude
test groups from the test run, I think.
It also supports JDK 1.4 by using javadoc tags instead of annotations.
Last but not least it provides a JUnitConverter to support
the migration from JUnit to TestNG.

So, it would be doable, the question is, if it's worth the effort.

My preference would be to fix the broken test cases if possible and
file issues for the remaining ones, commenting them in the code
until they are fixed ...

But that's just my opinion, other suggestions are welcome.

Thanks,
Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: new build output directory 'target'

James Lemieux
My opinions are:

1) I don't mind broken test cases that point out known issues we WILL fix. Broken test cases that sort of hang around in the ether don't excite me. I consider the ones in EventListTest of this variety.

2) I have no problems if the test cases are JDK 1.5 only. IMO, we're only trying to support JDK 1.4 builds of our \source folder for people who like to debug\build from scratch with the source. Test cases are optional in this regard.

3) As such, the JUnit 4 @ignore solution sounds great to me. I'd embrace it for the few permanently broken test cases that we choose to keep around. (like ConflictingThreadsTest)

4) As far as I'm concerned, JUnit does everything we need it to, and the built-in support for JUnit within Intellij is ridiculously good, so why switch to TestNG? I know there is an Intellij plugin for TestNG, but why even embrace the change when it seems largely unnecessary.

James

On 7/24/06, Holger Brands <[hidden email]> wrote:
Hey Jesse,

> On 7/23/06, Holger Brands <[hidden email]> wrote:
> > > Jesse, we should go through and clean up our broken test cases.
>
> Good idea. But broken test cases are a good thing, since
> they remind us that there are still unresolved problems in
> the code!

That's true. But the issue tracker could serve this purpose, too.

I like the idea that running the tests is part of the release-making
process and all tests should pass. Failing test cases should abort
the release build.
Changing code with failing test cases is a tedious task because
you have to recheck every time if a new test case is broken
in additon to the already failing ones.

>
> I've seen annotations used for this purpose:
>
>     @Suppress("Bug134");
>    public void testSomethingThatsNotYetFixed() { ... }
>
> It's nice, but it requires a lot more support from the test
> mechanism, and stock JUnit doesn't do it out of the box.

I think JUnit 4 has an @Ignore annotation for this purpose.
But it requires JDK 1.5 ...

> I've been meaning to try out TestNG. You think anyone
> would mind if we went down that road?

I'm not sure, because I'm not very familiar with TestNG.
With TestNG you can enable/disable tests and/or exclude
test groups from the test run, I think.
It also supports JDK 1.4 by using javadoc tags instead of annotations.
Last but not least it provides a JUnitConverter to support
the migration from JUnit to TestNG.

So, it would be doable, the question is, if it's worth the effort.

My preference would be to fix the broken test cases if possible and
file issues for the remaining ones, commenting them in the code
until they are fixed ...

But that's just my opinion, other suggestions are welcome.

Thanks,
Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

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


Reply | Threaded
Open this post in threaded view
|

Re: Re: new build output directory 'target'

Jesse Wilson
On 7/24/06, James Lemieux <[hidden email]> wrote:
> 1) I don't mind broken test cases that point out known issues we WILL fix.
> Broken test cases that sort of hang around in the ether don't excite me. I
> consider the ones in EventListTest of this variety.

Good call. We'll remove 'em, and close the related
bug as WONT FIX


> 2) I have no problems if the test cases are JDK 1.5 only. IMO, we're only
> trying to support JDK 1.4 builds of our \source folder for people who like
> to debug\build from scratch with the source. Test cases are optional in this
> regard.

I'd like to keep around the tests 'just so we can verify
that Declawer isn't doing anything dumb that might
change behaviour. It hasn't so far, but who knows if we'll
try to add features to it.


> 3) As such, the JUnit 4 @ignore solution sounds great to me. I'd embrace it
> for the few permanently broken test cases that we choose to keep around.
> (like ConflictingThreadsTest)

Sounds good to me.


> 4) As far as I'm concerned, JUnit does everything we need it to, and the
> built-in support for JUnit within Intellij is ridiculously good, so why
> switch to TestNG? I know there is an Intellij plugin for TestNG, but why
> even embrace the change when it seems largely unnecessary.

There's a few things that TestNG does that JUnit doesn't,
that we don't realize that we miss because we haven't seen
them. In particular:
 - data providers. Test the same logic over multiple different
   sets of data. Useful to test multiple implementations of the
   same interface, such as both publishers or both assemblers.
 - @expectedExceptions annotation, makes certain code more
   readable.
 - test groups. Useful for tests expected to fail, or tests expected
   to fail only for a certain implementation of an interface, such as
   some tests that only support the newer ListEventPublisher

None of this is urgent, of course, except perhaps testing all
implementations all the time. Currently this is something our
tests fail to do. We could hack around this by tweaing our test
task in our build file to keep things simple.

Cheers,
Jesse

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: new build output directory 'target'

Holger
In reply to this post by Holger
> > 2) I have no problems if the test cases are JDK 1.5 only. IMO, we're only
> > trying to support JDK 1.4 builds of our \source folder for people who like
> > to debug\build from scratch with the source. Test cases are optional in this
> > regard.
>
> I'd like to keep around the tests 'just so we can verify
> that Declawer isn't doing anything dumb that might
> change behaviour. It hasn't so far, but who knows if we'll
> try to add features to it.
>
>
> > 3) As such, the JUnit 4 @ignore solution sounds great to me. I'd embrace it
> > for the few permanently broken test cases that we choose to keep around.
> > (like ConflictingThreadsTest)
>
> Sounds good to me.
>
>

How does the Declawer handle annotations?
I assume it ignores them, but I could be wrong.
If that's true, the annotated @ignored test cases won't compile in
the Java 1.4 build.

How to deal with that?
Modify Declawer to remove or comment out the annotations?

Holger






_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: new build output directory 'target'

Jesse Wilson
I haven't tested it, but I think declawer won't
be able to handle exceptions at all.

Extending Declawer isn't trivial - it's probably not
worthwhile. The tool currently uses some undocumented
APIs in the sun Javac compiler, and if those APIs don't
support annotations it would be an enormous job to add
them.

Is there any support in JUnit 4 for Javadoc-style annotations
for Java 1.4 compatibility? I know TestNG has this feature.

Cheers,
Jesse

On 7/25/06, Holger Brands <[hidden email]> wrote:

> > > 2) I have no problems if the test cases are JDK 1.5 only. IMO, we're only
> > > trying to support JDK 1.4 builds of our \source folder for people who like
> > > to debug\build from scratch with the source. Test cases are optional in this
> > > regard.
> >
> > I'd like to keep around the tests 'just so we can verify
> > that Declawer isn't doing anything dumb that might
> > change behaviour. It hasn't so far, but who knows if we'll
> > try to add features to it.
> >
> >
> > > 3) As such, the JUnit 4 @ignore solution sounds great to me. I'd embrace it
> > > for the few permanently broken test cases that we choose to keep around.
> > > (like ConflictingThreadsTest)
> >
> > Sounds good to me.
> >
> >
>
> How does the Declawer handle annotations?
> I assume it ignores them, but I could be wrong.
> If that's true, the annotated @ignored test cases won't compile in
> the Java 1.4 build.
>
> How to deal with that?
> Modify Declawer to remove or comment out the annotations?
>
> Holger
>
>
>
>
>
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000071
>
> ---------------------------------------------------------------------
> 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: Re: new build output directory 'target'

James Lemieux
Well, I suppose we can't be certain until we test it. I'll try it tonight if no one else does. It IS possible that the Lower class that ships with javac really will strip out annotations. It's not that far fetched...

But I do agree with Jesse that Declawer is not too easy to hack around in. It would take about a day of testing and hacking to get back into the code, get some samples, adjust Declawer, test, and deploy. We would probably just handle it by placing comments in front of the annotations.

James

On 7/25/06, Jesse Wilson <[hidden email]> wrote:
I haven't tested it, but I think declawer won't
be able to handle exceptions at all.

Extending Declawer isn't trivial - it's probably not
worthwhile. The tool currently uses some undocumented
APIs in the sun Javac compiler, and if those APIs don't
support annotations it would be an enormous job to add
them.

Is there any support in JUnit 4 for Javadoc-style annotations
for Java 1.4 compatibility? I know TestNG has this feature.

Cheers,
Jesse

On 7/25/06, Holger Brands <[hidden email]> wrote:

> > > 2) I have no problems if the test cases are JDK 1.5 only. IMO, we're only
> > > trying to support JDK 1.4 builds of our \source folder for people who like
> > > to debug\build from scratch with the source. Test cases are optional in this
> > > regard.
> >
> > I'd like to keep around the tests 'just so we can verify
> > that Declawer isn't doing anything dumb that might
> > change behaviour. It hasn't so far, but who knows if we'll
> > try to add features to it.
> >
> >
> > > 3) As such, the JUnit 4 @ignore solution sounds great to me. I'd embrace it
> > > for the few permanently broken test cases that we choose to keep around.
> > > (like ConflictingThreadsTest)
> >
> > Sounds good to me.
> >
> >
>
> How does the Declawer handle annotations?

> I assume it ignores them, but I could be wrong.
> If that's true, the annotated @ignored test cases won't compile in
> the Java 1.4 build.
>
> How to deal with that?
> Modify Declawer to remove or comment out the annotations?
>
> Holger
>
>
>
>
>
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000071
>
> ---------------------------------------------------------------------
> 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: Re: new build output directory 'target'

Holger
In reply to this post by Holger
Ok, I made a quick test: I placed a @Deprecated annotation on a test class:

@Deprecated
public class BasicEventListTest ...

The result of Declawer was:

@Deprecated()
public class BasicEventListTest ...

Hm, that's not what we need.

As far as I know JUnit 4 doesn't support Javadoc-style annotations.

But what about the following suggestion:

We comment out the remaining failing test cases and put some kind
of TODO tag there, e.g.

// @todo Fix testcase for Bug4711
// testBug4711() {
//...

Eclipse supports the notion of configurable task tags.
It computes a list of all task tags in source code, so you always have
an update-to-date todo list.
Perhaps IDEA has a similiar capability?

Holger


> Well, I suppose we can't be certain until we test it. I'll try it tonight if no one else does. It IS possible that the Lower class that ships with javac really will strip out annotations. It's not that far fetched...
>
> But I do agree with Jesse that Declawer is not too easy to hack around in. It would take about a day of testing and hacking to get back into the code, get some samples, adjust Declawer, test, and deploy. We would probably just handle it by placing comments in front of the annotations.
>
>
> James
>
>
> On 7/25/06, Jesse Wilson <[hidden email]> wrote:
> I haven't tested it, but I think declawer won't
> be able to handle exceptions at all.
>
> Extending Declawer isn't trivial - it's probably not
> worthwhile. The tool currently uses some undocumented
> APIs in the sun Javac compiler, and if those APIs don't
>
> support annotations it would be an enormous job to add
> them.
>
> Is there any support in JUnit 4 for Javadoc-style annotations
> for Java 1.4 compatibility? I know TestNG has this feature.
>
> Cheers,
> Jesse
>
>
> On 7/25/06, Holger Brands <[hidden email]> wrote:
> > > > 2) I have no problems if the test cases are JDK 1.5 only. IMO, we're only
> > > > trying to support JDK 1.4 builds of our \source folder for people who like
> > > > to debug\build from scratch with the source. Test cases are optional in this
> > > > regard.
> > >
> > > I'd like to keep around the tests 'just so we can verify
>
> > > that Declawer isn't doing anything dumb that might
> > > change behaviour. It hasn't so far, but who knows if we'll
> > > try to add features to it.
> > >
> > >
> > > > 3) As such, the JUnit 4 @ignore solution sounds great to me. I'd embrace it
>
> > > > for the few permanently broken test cases that we choose to keep around.
> > > > (like ConflictingThreadsTest)
> > >
> > > Sounds good to me.
> > >
> > >
> >
> > How does the Declawer handle annotations?
> > I assume it ignores them, but I could be wrong.
> > If that's true, the annotated @ignored test cases won't compile in
> > the Java 1.4 build.
> >
> > How to deal with that?
>
> > Modify Declawer to remove or comment out the annotations?
> >
> > Holger
> >
> >
> >
> >
> >
> >
> > _____________________________________________________________________
> > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > http://smartsurfer.web.de/?mc=100071&distributionid=000000000071
>
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
>
>


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: new build output directory 'target'

James Lemieux
Intellij also supports todo tags in much the same way that eclipse does.

Maybe I'll drag out declawer this weekend and see if I can get it to comment out annotations.

Even if I did, we'd get different behaviour from our test suite in 1.4 vs. 1.5 (since 1.4 test cases would ALL execute and thus some would fail). Does that offend anyone?

BTW, the handling of the @Deprecated tag you saw is what javac does by default. We aren't changing that behaviour at all. We'll have to add another TreeTranslator to the mix which will alter the parse tree to remove annotations.

On second thought... removing annotations altogether will probably prove easier... though perhaps not quite as nice. We'll see...

James

On 7/25/06, Holger Brands <[hidden email]> wrote:
Ok, I made a quick test: I placed a @Deprecated annotation on a test class:

@Deprecated
public class BasicEventListTest ...

The result of Declawer was:

@Deprecated()
public class BasicEventListTest ...

Hm, that's not what we need.

As far as I know JUnit 4 doesn't support Javadoc-style annotations.

But what about the following suggestion:

We comment out the remaining failing test cases and put some kind
of TODO tag there, e.g.

// @todo Fix testcase for Bug4711
// testBug4711() {
//...

Eclipse supports the notion of configurable task tags.
It computes a list of all task tags in source code, so you always have
an update-to-date todo list.
Perhaps IDEA has a similiar capability?

Holger


> Well, I suppose we can't be certain until we test it. I'll try it tonight if no one else does. It IS possible that the Lower class that ships with javac really will strip out annotations. It's not that far fetched...
>
> But I do agree with Jesse that Declawer is not too easy to hack around in. It would take about a day of testing and hacking to get back into the code, get some samples, adjust Declawer, test, and deploy. We would probably just handle it by placing comments in front of the annotations.
>
>
> James
>
>
> On 7/25/06, Jesse Wilson <[hidden email]> wrote:
> I haven't tested it, but I think declawer won't
> be able to handle exceptions at all.
>
> Extending Declawer isn't trivial - it's probably not
> worthwhile. The tool currently uses some undocumented
> APIs in the sun Javac compiler, and if those APIs don't
>
> support annotations it would be an enormous job to add
> them.
>
> Is there any support in JUnit 4 for Javadoc-style annotations
> for Java 1.4 compatibility? I know TestNG has this feature.
>
> Cheers,
> Jesse
>
>
> On 7/25/06, Holger Brands < [hidden email]> wrote:
> > > > 2) I have no problems if the test cases are JDK 1.5 only. IMO, we're only
> > > > trying to support JDK 1.4 builds of our \source folder for people who like
> > > > to debug\build from scratch with the source. Test cases are optional in this
> > > > regard.
> > >
> > > I'd like to keep around the tests 'just so we can verify
>
> > > that Declawer isn't doing anything dumb that might
> > > change behaviour. It hasn't so far, but who knows if we'll
> > > try to add features to it.
> > >
> > >
> > > > 3) As such, the JUnit 4 @ignore solution sounds great to me. I'd embrace it
>
> > > > for the few permanently broken test cases that we choose to keep around.
> > > > (like ConflictingThreadsTest)

> > >
> > > Sounds good to me.
> > >
> > >
> >
> > How does the Declawer handle annotations?
> > I assume it ignores them, but I could be wrong.
> > If that's true, the annotated @ignored test cases won't compile in
> > the Java 1.4 build.
> >
> > How to deal with that?
>
> > Modify Declawer to remove or comment out the annotations?
> >
> > Holger
> >
> >
> >
> >
> >
> >
> > _____________________________________________________________________
> > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > http://smartsurfer.web.de/?mc=100071&distributionid=000000000071
>
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
>
>


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

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