Details
Description
As part of the Mavenization updates of the project I'm proposing updating the libraries in both the POM and the lib directory while we keep supporting both build mechanisms.
I already tested by building and testing on Maven 2.2.1 and Maven 3.0.4 without issues but would like to know if someone else sees problems in upgrading. I detected two upgrades, fop and jep, that are not possible without modifying the code. Those are not available in Maven repositories and would need to stay as part of the source until code is migrated to newer and available versions of the dependencies.
I'll attach the proposed diff for review ASAP.
Activity
Is it worth it? Are we going to turn project into pure Maven project?
It looks good except that I couldn't find a 0.20.0 version of fop under the groupId of org.apache.xmlgraphics
Me neither, I'm using the one in the lib folder and installing it into local Maven repo. See changes in #CODE-1819
Should I also update the files in the lib folder?
Or should I get rid of it (except for two libraries I'm installing from there)
Until we can entirely remove the ant build we need to keep the lib folder up to date. This could be done using ivy though.
Oh and see http://mvnrepository.com/artifact/fop/fop for 0.20.5
Is the http://pcgen.sourceforge.net/mvnrepo down? I'm no longer able to get artifacts from it.
The repo is still there but it is a legacy format one, so will not work with maven 3 IIRC. I have enabled directory browsing so you can have a look around.
I'm aware of it, but yesterday I cleared my local repo and was failing to retrieve dependencies from it.
Patch for review. Tested boh on ant and Maven build without issues (some tests failed but I can't see relation with changes). Updating caused some more code to be marked as deprecated. I would address those if this patch is approved (if possible)
I'll run tests on Maven again to make sure before committing.
Removed initial patch since is superseded by the current one.
Detected an issue with spring upgrades. Reverting those (nothing committed)
The changes look good to me, but some libraries in the lib folder are not updated that were updated in the pom (e.g. js.jar). I assume you;ll get those?
For spring, maybe we need a separate issue for those so that we can fix the issues you noted.
Oh and the project.xml will need to be updated too (for now).
Thanks. I'll wait until I get back to work to get everything straight before committing. My old laptop at home makes it almost impossible to code. Also is hard to tell if I'm causing errors because there are failing tests even without my changes. I just happened to notice the spring ones.
I'm focusing on the Maven side first to propagate libraries to the lib folder. I'm having two test fails with this configuration:
Failed tests:
testInvalidInputBadHDRangePlus(plugin.lsttokens.template.HDTokenTest)
testInvalidInputBadHDRangePlus(plugin.lsttokens.template.LevelTokenTest)
The full patch was too big so I loaded this trimmed version which doesn't update the libraries (Maven will do during the build).
1) Maven updates the libraries so they are always in sync (still working on separating test and non-test dependencis if this is really needed)
2) Licences are downloaded (Still working on checking the license compatibility with PCGen because I'm not sure which is our license
)
3) Moved around lnf folder out of lib folder (also modified related files) so in the future I can have clean delete this folder to make sure is 100% up to date.
The new changes look good - I really like that this is all pulled into the pom. I generally prefer to have the versions in the jar name, but I assume you remove it so that ant does not need to be updated when we change the library in the pom.
Our license is LGPL.
If you send me the output from the two failed tests I'll have a look at them.
I'm glad you like it. About the versions in jar name, I can keep them but I'll then require the folder to be deleted as part of the clean goal. Maybe we can set up a properties file with the file names so ant script can feed from them. I was thinking on deleting it any way so it catches any jar that might be removed. Any issues with removing it?
Any comments?
I'll get those outputs ASAP.
Here's the first test output:
-------------------------------------------------------------------------------
Test set: plugin.lsttokens.template.HDTokenTest
-------------------------------------------------------------------------------
Tests run: 43, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.167 sec <<< FAILURE!
testInvalidInputBadHDRangePlus(plugin.lsttokens.template.HDTokenTest) Time elapsed: 0.119 sec <<< FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertFalse(Assert.java:39)
at junit.framework.Assert.assertFalse(Assert.java:47)
at junit.framework.TestCase.assertFalse(TestCase.java:219)
at plugin.lsttokens.template.HDTokenTest.testInvalidInputBadHDRangePlus(HDTokenTest.java:239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Second output:
-------------------------------------------------------------------------------
Test set: plugin.lsttokens.template.LevelTokenTest
-------------------------------------------------------------------------------
Tests run: 37, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec <<< FAILURE!
testInvalidInputBadHDRangePlus(plugin.lsttokens.template.LevelTokenTest) Time elapsed: 0.001 sec <<< FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertFalse(Assert.java:39)
at junit.framework.Assert.assertFalse(Assert.java:47)
at junit.framework.TestCase.assertFalse(TestCase.java:219)
at plugin.lsttokens.template.LevelTokenTest.testInvalidInputBadHDRangePlus(LevelTokenTest.java:231)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
These two were failing due to differences in Java versions (worked in Java 6 but failed in Java 7). Tom Parker traced that and fixed the code, see CODE-1934 for details.
That's great! I'll test again after updating my code and commit.
Having trouble committing. Looking at mail list threads to see what I did wrong...
Javier - you need to be set up to use svn+ssh, please see http://wiki.pcgen.org/Subversion_Setup and make sure that is all correct.
Cheers,
Proposed pom changes. Once approved I'll update libraries in lib folder.