waffle-1.7-SNAPSHOT available

[hazendaz]

Check out the snapshot and let me know if this looks ready for official release.

https://oss.sonatype.org/content/repositories/snapshots/com/github/dblock/waffle/

[hazendaz]

@dblock

Probably holding off for a couple of more weeks before 1.7 release. There are a few things I want to do before this goes out. In the meantime, anyone could pull the above waffle jars and try this release out.

1. I have some pending changes to upload with general code cleanup resulting as before out of various code checkers I'm running against library.

2. Introduction of the coverity scan. Initial run captured 19 issues of which I've resolved 11 of them. You can see this off my fork. Coverity runs as a special branch based off using travis-ci. So it runs at best once weekly as they limit the scans. It also has a slight downside of hard-coding what it runs so currently have it configured to run as hazendaz/waffle rather than dblock/waffle. Not sure this is that much of a big deal as the runs are limited and I envision initially only me running these since we will soon be clean and not have much need to run these often.

3. Introduction of the coverall test coverage. Due to using jacoco, it doesn't aggregate jacoco.exec information. At best, I've been able to work it so the jacoco merge feature will aggregate for me but there are some downsides there from what I've read and another jira related to fix those issues with something other than merge. Downstream though, I cannot get the merged jacoco.exec to find the class files as it appears I cannot override that in jacoco from what I can see. The way I got this working was to make the very last 'waffle-distro' actually merge those together. Now trying to get jacoco report to work there. After that, I need to figure out how to make coverall work only against the last one which might not work. Coverall group is working to figure out how to resolve this and as mentioned jacoco is too.

4. I've also added the maven central badge pointed to waffle jna. Maybe it makes sense to add a bunch of them to get to each individual item or possible something that would pull up all waffle pieces first. Haven't looked too deeply at this but it is nice that it shows waffle-jna-1.6 as the version in central and will change as new versions released. Plus it links out there which is great.

If you don't see any real need to wait on any of this, I can at least pull back on my commit of coverall and get everything else on a pull request tomorrow then start the process of release. Let me know!

[dblock]

I think you're doing all these great things and should be the one to decide what you want to do with it!

[hazendaz]

Thanks. I'm thinking will probably go ahead and move forward as some of the things I wanted to do here don't seem to have any good workaround so some partial items on the current pull request. Now the latest pull request with coverity_scan on it seemed to cause skip in processing so latest build is sort of funny. So I went ahead and added the branch on dblock/waffle. So next run should start to do what I see on mine and essentially that is oracle jdk8 will start failing due to invalid javadocs. That said, I'll start working on those and get building again properly on my end. Then preceding pull request should again do the correct thing and we should be back to green against what is expected. I plan to also fix the remaining coverity items. If all this goes well and looks good on the dblock/master aside from other underlying issues I'm aware of with these extra checkers, probably will promote. So maybe about another week to promote 1.7 after all this is figured out, then immediate start on 1.8.

1.8 onwards -> Then will seriously approach removing any no longer supported third parties (ie spring2, tomcat 5, and the items deprecated (base64). The later of which I decided to just leave deprecated in 1.7 because I've been known in the past to leverage such things if libraries have them available since the legacy sun way for base64 was not to be used and this worked. So I think some did probably use it and 1.7 with deprecation will show our intent to remove and 1.8 will have that removed. I have a lot of ideas for 1.8 which a major one being potential drop of java 6 and servlet 2.5 support. If that sounds good, after branch cleanup, it makes sense to make 1.7 as is a branch so that we can support that for some time due to removing larger scale items in case of any bugs users might find that need addressed. Possibly with the idea that 1.7.x will be last for jdk6 / servlet 2.5. and we will maintain that for a period of time. More and more third parties are starting to do the same here so that makes sense. Plus for deprecated / removed tomcat 5 and spring 2, it gives some additional support there if needed.

[dblock]

👍 on deprecating unsupported platforms.

[hazendaz]

jdk8 issue now resolved. 2 additional items on coverity scan cleared but one gained for same area of code. Basically the majority of what are left are potential but not likely null pointers. All but two are in unit tests. I'll try to clear out the main source code ones in the next day or so. Getting closer and exciting to see all the scans / ci builds occurring.

[hazendaz]

Snapshot link added to README, closing this as it is easier now for people to find the snapshots.