Giters

tim-group / test-driven-detectors4findbugs

Test-Driven Detectors For FindBugs. Utility project to ease the development of custom plugin detectors for FindBugs.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

findbugs 2.x

bokken opened this issue · comments

commented

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.

commented

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!

commented

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//issues/11#issuecomment-20464915
.

commented

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?

commented

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.

commented

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.

commented

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//issues/11#issuecomment-20491314
.

commented

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