gnupg-for-java

[Antony Prince]

On 09/09/2015 01:39 PM, Antony Prince wrote:
> On 09/09/2015 10:10 AM, Robert J. Hansen wrote:
>> Other stuff that needs to be done: verify it works on Java 1.8, clean up
>> the OS X build (which is really hackish), and consider distributing
>> pre-built jarfiles containing the binaries and the source code, so that
>> people don't have to rebuild from scratch on each platform they want to
>> work on.
>>
>> I'm certainly not saying you need to do these things, Antony.  I'm just
>> saying that if other people are looking for bite-sized chunks, there are
>> several of them waiting to be bitten.  :)
>>
> 
> I think the initial issue was that ant was unable to locate the junit
> jar file which is why it was complaining about the classes not existing.
> I'd certainly be willing to try and use the updated classes/methods and
> replacing the deprecated ones. I built it on Java 7, but I have the Java
> 8 JDK as well and wouldn't have any problem with building/testing it on
> Java 8. I can't help with the OS X builds as I don't have a Mac and am
> pretty much clueless on how they operate. Now, for the binaries, I could
> probably build and distribute them. I'm not 100% certain on how the
> build process for this project actually goes, but *I think* it is
> platform/architecture dependent (it appears that the build creates the
> necessary libraries and links to them at compile time). The 64 bit
> Windows and Linux binaries wouldn't be a problem. I don't have any
> 32-bit systems set up currently, but it wouldn't be much of a task to
> set up 32-bit VM's for building them. I need to make the changes I made
> to the code more... universal. As it is now, the path to the junit jar
> file in the eclipse project setup has an absolute path in my home
> directory. I need to see if variables can be used to get the relative
> path instead. I also need to check the junit licensing to see if it is
> permitted to distribute the jar files with the source code of the
> project (which may be why guardianproject does not distribute them with
> theirs). A few things to check up on, but I'll certainly look into it
> and then if the changes look good, I'll get in touch with the guys from
> guardianproject and see about submitting a pull request if they feel the
> changes are a benefit to the project.
> 

Alright. After playing around with it all day, there are a few things I
needed to clarify. First, Windows builds would require a DLL that I
don't have the coding knowledge to create, so that's scratched. Also,
when I initially tried to build the project, I strictly used ant which
failed until I downloaded JUnit and pointed ant to it. If you run it as
a maven build with the original code from Guardian Project, it works
since maven downloads the necessary dependencies and points ant to them
since maven is actually controlling the ant build. My objective
currently is to produce the binaries for Linux since the default maven
build creates the *.jar and *.so files needed to make this process
easier for those who prefer pre-compiled binaries without having to
figure this all out. My only concern is whether the compiled binary and
library file are architecture specific which will require more
investigation on my part. I should be able to get it going on Travis CI
with pretty much the exact source from Guardian Project other than the
additional files required by Travis CI. Once all that is going good, I
can turn my attention to possibly updating deprecated methods of JUnit
that are used.


--Antony

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150909/86975685/attachment.sig>