[
this project makes use of dependency scanning tools, the current dependency list is clear of vulnerabilities
on behalf of tranparency -- this is a demo project, the active code doesn't do very much and I wrote it along time ago -- on the other hand I do regular work on the project -- at some point I began using the allure test reporting library which executes in a build context only during the test, integration-test and site phases only, the dependencies of the allure mechanism do not execute at "normal runtime" -- adding dependencies on allure components added transitive dependencies on jackson-databind and tika-core -- if you pay a lot of attention to CVE's you may recognize these 2 components as ones that had demonstrated significant vulnerabilities
the versions of these 2 dependent components have been patched, the vulnerabilities have been remediated
jackson--data-bind 9.3.3.3 tika-core:2.22
and now for some whining
coveralls states that only 56% of the code has been tested. Well that's somewhat misleading. Because I'm not a big fan of compile time byte code manipulation, at least where a JPA provider is concerned, I use static weaving on the JPA entities. Unfortunately that exposes all of the generated and not tested code to be scored against me. Oh well.........
apparently waffle.io gave up the ghost while I wasn't looking, it may have been a good tool, but I don't remember using it, yet another "Oh well.........."
.... whining completed .....
recently added the coveralls coverage badge. Implemented the integration using the jacoco maven plugin to generate coverage information. When I attempted to use cobertura rather than jacoco the QueryDSL integration classes QAuthor.java and QBook.java could not be processed by the cobertura Java parser, so the build failed. I actually prefer cobertura but I switched to jacoco so that I could get a working coverage mechanism and generate a coveralls coverage badge.
In addition I added the pitest mutation coverage test plugin. It uncovered an issue with one of the tests which failed under mutation. The test was RepositoriesQueryTest::testFindByAuthorName, will want to take a closer look at that. Got around the issue in the short term by skipping the test.
this simple example project contains 2 Cucumber features, each one of which has 1 scenario. Cucumber is being used to drive Spring and Eclipselink which together write persistent data to an HSQL in memory database instance.
There are 2 JPA entity classes Book and Author. There is a bidirectional many to many relationship between them as a Book will have one or more Authors, and an Author may contribute to zero or more Books.
There is a relish project site at https://www.relishapp.com/zrgs-org/cucumber-spring-and-eclipselink/docs
The travis.ci site for this project is https://travis-ci.org/andyglick/cucumber-spring-eclipselink
The coveralls site for the project is https://coveralls.io/r/andyglick/cucumber-spring-eclipselink
Found the beginnings of this example in the book Cucumber Recipes, you can find the book example at page 92 in chapter 2 Java. The original is Recipe 18 Drive a Spring + Hibernate Project.
I changed out Hibernate for Eclipselink firstly because I prefer Eclipselink and secondly because the project that I am doing at work uses Eclipselink.
There are 2 libraries in use here that aren't being used by on my project at work, they are the AssertJ assertions library and the QueryDSL JPA querying library.
AssertJ allows for even more expressive fluent assertions than the fest assertions library, which I tried out but abandoned once I realized how much more powerful AssertJ is. (http://joel-costigliola.github.io/assertj/)
As example difference is the following:
using fest:
Assertions.assertThat(authorNameList.size()).isEqualTo(authorNamesToFind.size());
using AssertJ:
Assertions.assertThat(authorNameList).hasSameSizeAs(authorNamesToFind);
Cucumber Reporting and maven-cucumber-reporting plugin produce fairly good Cucumber reports
I have noticed that QueryDSL has some bugs and doesn't seem to be actively developed anymore. I have stumbled upon blaze-persistence and I may attempt to replace QueryDSL with it.
QueryDSL provides a good deal more flexibility in querying persistent data than does JQL, allowing us to derive even more benefits from the use of Spring Data JPA. (http://www.querydsl.com/)
An example query follows:
QAuthor author = QAuthor.author1;
BooleanExpression authorsToLookup = author.authorName.eq("Andy Glick")
.or(author.authorName.eq("Jim Laspada")).or(author.authorName.eq("Jeffrey Braxton"));
Iterable<Author> locatedAuthors = authorRepository.findAll(authorsToLookup);
The query returns only the entries specified in the BooleanExpression
An odd finding: attempted to configure and use AuthorDelegate and BookDelegate classes via Spring dependency injection. This worked successfully everywhere except in the Author and Book classes. It turns out that the JPA Entity classes are not Spring beans managed by the Spring DI container, they are instead managed by the JPA container itself. I had hoped that I could use the AspectJ weaving technique to do the injection, from what I read in the documentation there was a suggestion that AspectJ weaving could do injection into instances not managed by the Spring container but I couldn't get that to work, and I don't know why, so that is worth further investigation.
In addition I have attempted to configure CDI using a number of different CDI environments in particular the DeltaSpike environment. I couldn't actually get a fully working environment configured using DeltaSpike. What was interesting about running in the DeltaSpike environment is that the Spring Data JPA repository proxies seemed to be recognized and may actually work, so there appears to be some non-trivial interoperability between Spring Data JPA and CDI JPA and or Eclipselink JPA.
What seems to be the underlying issue is the interoperability between the JPA container, and one or more of the DI containers. I am not actually sure if the JPA managed Entities can be treated as beans managed by any of the DI containers, that may be the problem. That said, I would have expected the AspectJ weaving to do the injection. I'll have to do a better job of sorting out how AspectJ weaving is supposed to work for non-Spring managed beans and what can be expected from it.
Cucumber integration with default Spring Test rollback behavior fixed
Before the cucumber 1.2.0 release even when Cucumber tests loaded the spring-test jar, the cucumber-spring integration wasn't implementing the default contract for spring tests where the default behavior is to rollback database transactions that are created by the code under test.
To test that the capability has actually been added to cucumber as a demonstration I modified the default Eclipselink logging behavior from FINE to FINEST and modified the default Spring logging behavior from INFO to DEBUG. Under those conditions, which themselves have been rolled back, it was easy to see that the transactions executed by the code under test were being rolledback.
Verbose Logging -- Another thing that surprised me as I implemented this small example
I used slf4j (simple logging for java) to replace any logging to commons-logging, log4j or to the java 4 internal logging package.
I enabled test output logging to standard out (the console) by setting the surefire plugin's useFile property to false (see the properties block in the pom file. What surprised me was that If I configured logback classic in the project then it produced copious Spring debugging output, and if I unconfigured it the test code produced no debugging output, logging only informational log statements.
I took advantage of this by creating a verbose-logging profile, which when enabled produces the debugging output. Try running the test cases with and without enabling the verbose-logging profile. I think that you will be interested to see the difference.
Using HikariCP connection pool's DataSource class rather than the Spring DiverManagerDataSource class.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent