I don't see a developer-specific board for jackcess or jackcess-encrypt, so figured I'd ask this here. Ive gone to the effort of updating the poms and the code in both projects to transition to commons-lang3 to avoid a scenario where I'd have to distrbute commons-lang and commons-lang3 in the same app, caused soley by jackcess. During that effort I also updated the jaxb plugin and a couple other small updates to plugin versions in the pom, get both projects using JUnit 4.11, and to use a supported version of the JDK/JRE. The checkout I did is off of the current production tags for each project. Is any of this of interest or useful to anyone? if it is, lemme know how to proceed with supllying patches etc. I will have done some testing of the new artifacts by reading large Microsoft Money files with it in the next couple days. But i have no need to do write access or other types of work with the libs other than reading Money files, so testing will be limited.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not too much, besides package names most of the changes were in the Pom. Sometime tomorrow I'll try to work up a change list. I found some stuff that would be nice to change though :-). In order to get jackcess and jackcess encrypt working in a production android build using ProGuard, I had to work around the reflection used to detect Bouncycastle versions older than 1.51 (I'm using 1.54) and deal with them. Is there still need for support of the old BouncyCastle stuff? Here's the Proguard config snippet it took to get it to run in production build. If the Reflection stuff could be removed (assuming its ok to drop support for older Bouncycastle), then only the enum class stuff would still be required.
#Jackcess related entries
# has enumeration classes, see http://proguard.sourceforge.net/manual/examples.html#enumerations
# prevents a warning about a static initializer that is trying to verify the correct version of bouncycastle
# dont use bouncycasle older than 1.51
-keep class org.bouncycastle.crypto.engines.RC4Engine { *; }
-keep class com.healthmarketscience.jackcess.util.RC4EngineCompat { *; }
-keep class com.healthmarketscience.jackcess.util.RC4EngineCompat$Factory { *; }
-dontwarn com.healthmarketscience.jackcess.util.RC4EngineLegacy
-keepclassmembers enum * {
public static **[] values();
public static ** valueOf(java.lang.String);
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure enough, outside of the pom tweaks there are only two sets of changes. One for the various lang (now lang3) imports. The other was restricted to the Encryption project. The Jackcess project evidently recently had refactored some stuff into a TestUtils class, and the JaccessEncrypt project wouldn't build without being caught up. So, pretty simple. I can easily produce a subversion patch if its useful. My checkout was based on the latest release tags though, not the trunk. Havent looked to see what is on the trunk already, possibly the TestUtils refactor is already done in encrypt on the trunk.
On the POM side; JRE 1.7 source/target, commons logging and Log4j current, lang3, different JAXB maven plugin (in Encrypt only of course, I couldn't get the original jaxb plugin to work in my environment), one additional apache repository (may not be necessary). Also seemed like the Maven bundle plugin has a newer version that requires
different config to use, I didn't try to battle that as it was working as-is.
Since my last writing the new jars have been tested on a couple of large encrypted Money databases with no problems. But I'm only doing reads (open read-only), no table/data changes. So nowhere near a thorough test. But did use 13 different tables, some with large numbers of columns, using the simple datatypes with no trouble. So looks promising.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't see a developer-specific board for jackcess or jackcess-encrypt, so figured I'd ask this here. Ive gone to the effort of updating the poms and the code in both projects to transition to commons-lang3 to avoid a scenario where I'd have to distrbute commons-lang and commons-lang3 in the same app, caused soley by jackcess. During that effort I also updated the jaxb plugin and a couple other small updates to plugin versions in the pom, get both projects using JUnit 4.11, and to use a supported version of the JDK/JRE. The checkout I did is off of the current production tags for each project. Is any of this of interest or useful to anyone? if it is, lemme know how to proceed with supllying patches etc. I will have done some testing of the new artifacts by reading large Microsoft Money files with it in the next couple days. But i have no need to do write access or other types of work with the libs other than reading Money files, so testing will be limited.
did you have to make any code changes outside of fixing package names?
Not too much, besides package names most of the changes were in the Pom. Sometime tomorrow I'll try to work up a change list. I found some stuff that would be nice to change though :-). In order to get jackcess and jackcess encrypt working in a production android build using ProGuard, I had to work around the reflection used to detect Bouncycastle versions older than 1.51 (I'm using 1.54) and deal with them. Is there still need for support of the old BouncyCastle stuff? Here's the Proguard config snippet it took to get it to run in production build. If the Reflection stuff could be removed (assuming its ok to drop support for older Bouncycastle), then only the enum class stuff would still be required.
#Jackcess related entries # has enumeration classes, see http://proguard.sourceforge.net/manual/examples.html#enumerations # prevents a warning about a static initializer that is trying to verify the correct version of bouncycastle # dont use bouncycasle older than 1.51 -keep class org.bouncycastle.crypto.engines.RC4Engine { *; } -keep class com.healthmarketscience.jackcess.util.RC4EngineCompat { *; } -keep class com.healthmarketscience.jackcess.util.RC4EngineCompat$Factory { *; } -dontwarn com.healthmarketscience.jackcess.util.RC4EngineLegacy -keepclassmembers enum * { public static **[] values(); public static ** valueOf(java.lang.String); }Sure enough, outside of the pom tweaks there are only two sets of changes. One for the various lang (now lang3) imports. The other was restricted to the Encryption project. The Jackcess project evidently recently had refactored some stuff into a TestUtils class, and the JaccessEncrypt project wouldn't build without being caught up. So, pretty simple. I can easily produce a subversion patch if its useful. My checkout was based on the latest release tags though, not the trunk. Havent looked to see what is on the trunk already, possibly the TestUtils refactor is already done in encrypt on the trunk.
On the POM side; JRE 1.7 source/target, commons logging and Log4j current, lang3, different JAXB maven plugin (in Encrypt only of course, I couldn't get the original jaxb plugin to work in my environment), one additional apache repository (may not be necessary). Also seemed like the Maven bundle plugin has a newer version that requires
different config to use, I didn't try to battle that as it was working as-is.
Since my last writing the new jars have been tested on a couple of large encrypted Money databases with no problems. But I'm only doing reads (open read-only), no table/data changes. So nowhere near a thorough test. But did use 13 different tables, some with large numbers of columns, using the simple datatypes with no trouble. So looks promising.