findbugs 2.x

[bokken]

It appears that the detector does not work with findbugs 2.x. There are actually a couple of non-passive changes in the abstract detectors, making it difficult to develop/test with findbugs 1.3.9 but actually run with findbugs 2.x.

[Grundlefleck]

Hmmm. This will be an interesting one.

While this project must support 2.x to be useful, I don't think I want to drop support for 1.3.x. Being able to do this in the same codebase would be very tough, and and likely result in some monumental hackery.

I will need to have a look around for examples of working projects that maintain two active branches, specifically how that works with Maven. For example, would there be two different artifacts, or a single artifact with two classifiers, or perhaps two artifacts versioned to match FindBugs, e.g. tdd4fb-1.3.9.1 and tdd4fb-2.0.1.1?

Do you have any suggestions/preferences?

Thanks for the bug report!

[bokken]

I think perhaps an artifact per major findbugs release. So perhaps a new tdd4b2 to support findbugs 2.x. Most new minor or bug fix versions of findbugs will not require changes to the testing framework. On Jul 4, 2013 3:25 AM, "Graham Allan" notifications@github.com wrote:

Hmmm. This will be an interesting one.

While this project must support 2.x to be useful, I don't think I want to drop support for 1.3.x. Being able to do this in the same codebase would be very tough, and and likely result in some monumental hackery.

I will need to have a look around for examples of working projects that maintain two active branches, specifically how that works with Maven. For example, would there be two different artifacts, or a single artifact with two classifiers, or perhaps two artifacts versioned to match FindBugs, e.g. tdd4fb-1.3.9.1 and tdd4fb-2.0.1.1?

Do you have any suggestions/preferences?

Thanks for the bug report!

— Reply to this email directly or view it on GitHubhttps://github.com/youdevise/test-driven-detectors4findbugs/issues/11#issuecomment-20464915 .

[Grundlefleck]

Hi @bokken,

I have tried something a little more... inventive (shall we say ...)

That is, to use a Java proxy interface to simulate an interface that will work from 1.3.7 to 2.0.1 (I also just discovered that 2.0.1 removed as well as added methods). If this works, it means that we don't need to worry about multiple artifacts. I still need to be reactive to interface changes in later versions, but they need a source level change anyway.

Would you be able to try it and let me know if it works?

[Grundlefleck]

Sorry, I know it's a pain, but could you clone the repo to test? There's a lot of hurdles for both of us to jump if we want it available from Maven snapshot repositories. Let me know if that's a problem.

[Grundlefleck]

Hi @bokken,

I plan to do perform another release to Maven Central once this issue is confirmed. If you think you will be unable to find the time to test (which is fine) then please let me know and I'll take the risk, and go by my own personal testing.

Thanks.

[bokken]

I am out of the office right now. I should be able to take a look at your changes next week sometime. On Jul 4, 2013 2:40 PM, "Graham Allan" notifications@github.com wrote:

Hi,

I plan to do perform another release to Maven Central once this issue is confirmed. If you think you will be unable to find the time to test (which is fine) then please let me know and I'll take the risk, and go by my own personal testing.

Thanks.

— Reply to this email directly or view it on GitHubhttps://github.com/youdevise/test-driven-detectors4findbugs/issues/11#issuecomment-20491314 .

[Grundlefleck]

I'm going to assume this change fixes the problem, and begin preparing for a new release to nexus.