search

stardog-union / pellet

Pellet is an OWL 2 reasoner in Java; open source (AGPL) and commercially licensed, commercial support available.
http://clarkparsia.com/pellet
Other
302 stars 153 forks source link

Convert Pellet to build using Maven #3

Closed ansell closed 10 years ago

ansell commented 10 years ago

This pull request converts the build to use Maven.

It includes the use of the findbugs plugin (using mvn -Pfindbugs clean install), but does not include support for cobertura at this point. The cobertura maven plugin isn't well suited to multi-module Maven builds at this point in time.

The majority of the file content changes are in tests to switch from direct file access (where possible) to using getClass().getResourceAsStream(...), to avoid copying the file out to the file system. There are a few cases where it is necessary to copy files out to the file system to satisfy some APIs. These are accommodated for in a new TestUtils helper function that copies the named resource from the classpath out to a JUnit TemporaryFolder. JUnit cleans up the file system after the test.

The file move changes, are to move to the standard Maven layout, to easily work with the standard maven plugins.

.classpath and .project were removed as they are not necessary anymore. They can be regenerated either using "mvn eclipse:eclipse" or by importing into Eclipse using M2E.

https://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html

ashish-nijhara commented 10 years ago

:+1:

evren commented 10 years ago

Peter, first of all thanks for doing this. I was very busy at the beginning of the week and couldn't investigate this in detail but now that I tried this conversion I'm having problems.

The most important issue is failing test cases. I have several tests failing like SWRLTestSuite, ParserTest, SparqlDawgTestSuite. These tests all require to list directory contents and read all the files in the directory which does not work well with test files inside the jar. The helper copy function in TestUtils does not help either since we can't list contents inside the jar. At least not easily and all the workarounds I have seen so far (opening source jar file as a zip input stream) seems not appropriate. Copying individual test files out of the jar into the file system seems to work fine though that's not great since we end up commonly used test files many times (this might not be a big deal since the test files are typically quite small).

I suppose we can modify the manifest file based tests so that they will read manifests inside the jar and we'll always have a root manifest pointing to nested manifest using relative paths. Any other test that depends on directory listing can be turned into manifest-based tests.

The other major issue is not being able to create distribution packages with the mavenized version. I suppose we could create an assembly descriptor that would create a zip file somewhat equivalent to what we currently have.

Maybe the way to go forward is to merge this pull request into a branch and work on these issues in the branch.

ansell commented 10 years ago

Pushing to a branch for now works for me, as it is an unfinished product so far.

Manifests are the cleanest way to migrate directory based testsuites. Opening source jar files as zips seems to be more trouble than it is worth in the long term, although I haven't tried it before. The way I have worked with manifests in the past for W3C testsuites, is to identify the base classpath in the test, and then join it with the filenames from the manifest to extract the resources for each test.

There is a widely used plugin (maven-assembly-plugin) for generating distributions, but as you say it isn't in the pull request yet. I will look into seeing what I can write up this morning and add it to the request.

tobias-hammerschmidt commented 10 years ago

An alternative approach to detect the test resources might be to use some library like https://code.google.com/p/reflections/ or guava (http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/reflect/ClassPath.html). At least the reflections lib supports regex so should be fine IMHO.

evren commented 10 years ago

I merged this pull request into a newly created 'maven' branch so I'm closing this request. I'll work on sorting out tests and if Peter has any updates I'll merge them to the new branch.

ansell commented 10 years ago

I will also work on getting the maven assembly plugin configurations generating the distribution files. They do something right now but it isn't what the ant version was creating yet.