#245 Blanket exception for test resource jar files
Closed: Fixed None Opened 11 years ago by sochotni.

Java packages sometimes contain binary jar files that are used during test phase to verify package doesn't contain any regressions.

Notable example:
http://tradej.fedorapeople.org/reviews/maven-repository-builder/0.1.alpha2/maven-repository-builder-1.0-0.1.alpha2.fc17.src.rpm

contains file src/test/resources/remote-repository/massembly/210/child/1.0-SNAPSHOT/child-1.0-SNAPSHOT.jar

Which has a binary class inside. I would consider this class as test data and not code. It is never included in binary rpms. However I believe according to current guidelines it's considered bundled library.

There are multiple possible solutions including:
1. blanket exception, treating tests jar files are data files (perhaps with careful wording to ensure they are not included in binary rpms)
2. we could just remove the tests in question/don't run them at all
3. there's a possibility to decompile jar files, include them as source and recompile during build. But I'd sooner just disable tests than go through this...

Reason why I believe solution 1 is acceptable is that bundled libraries guidelines are supposed to ensure we can always recompile package in case there's a security or licensing issue etc. These test data don't affect our ability to compile (worst case we can disable tests whenever we have to)

Can we get a clarification on this point?


I would consider this use acceptable. the .jar file(s) in question aren't used to build nor are they packaged (right?), so it would be a little bit of a stretch to consider them bundled libraries.

Indeed, never packaged and used during build only for unit tests (which are usually part of build process, but can be skipped). End result doesn't depend on these jars, they just serve as verification step. They should never be packaged and I haven't seen Java package which packages tests yet.

Those types of files are intentionally included in no bundled libraries. [http://cm.bell-labs.com/who/ken/trust.html Reflections on trusting trust] and all that.

The right way to fix this would be to have the source code for that jar and build it as a separate package. Then to use that package as a BuildRequire. But atm, is is fine to resort to your option #2 (skip the tests entirely) if the packages are not included in Fedora.

Replying to [comment:4 toshio]:

Those types of files are intentionally included in no bundled libraries. [http://cm.bell-labs.com/who/ken/trust.html Reflections on trusting trust] and all that.

Interesting essay. If I understand you correctly you are worried that test data with executable parts might modify binary that is to be installed on user's system on the fly during test phase. In all honesty, yes...that would be possible in some cases.

The right way to fix this would be to have the source code for that jar and build it as a separate package. Then to use that package as a BuildRequire.

That too would be an overkill of effort.

But atm, is is fine to resort to your option #2 (skip the tests entirely) if the packages are not included in Fedora.

I am not sure I understand "if the packages are not included in Fedora".

If the stuff in the jars (I assume it's executable code) is not packaged separately in Fedora, then it is okay to skip those tests that need them. If they are packaged, then effort should be expended to make the tests run with the system copies.

Also note that the general exception was discussed at the tail end of today's fpc meeting. The voting members were split in half. We should continue talking about it next week and the get the votes from the remaining members.

I think the issues here were all decided. Feel free to reopen and point out my failure if not.

Login to comment on this ticket.

Metadata