Publish to Maven Central

masterav10 commented 8 years ago

Hey Kustaa,

I've done some of the legwork to support #82.

Application code is cross compiling against JDK 1.5 (you will need to download and install 1.5 from oracle for correctness). Testsuite code is compiled using the default JDK, and not included in the deployed jar. I would recommend that it be built and deployed separately, if at all.

I've tested up gradlew assemble: it produces the .class jar, sources jar, and javadoc jar, all signed.

The following guide(s) provides instructions on how to deploy: http://central.sonatype.org/pages/ossrh-guide.html

Overview of steps:

Download JDK 1.5 and extract the rt.jar file into lib-rt.
Create keys as described in http://central.sonatype.org/pages/working-with-pgp-signatures.html
Added the gradle.properties file to your home as described in http://central.sonatype.org/pages/gradle.html#credentials
Upload using gradlew uploadArchives

Disclaimer: I've never uploaded artifacts to maven central.

The javadoc compiler was angry at a couple of files, so I modified them to be compliant. No code changes were made in this branch.

Update Validated gradlew uploadArchives using a local artifactory server. You shouldn't need to deviate from the guides provided above.

nyholku commented 8 years ago

Thanks, I will have a look.

Is Java 1.5 mandatory and if so why?

I'm not sure where I could find Java 1.5 for Mac which is my main development system.

masterav10 commented 8 years ago

Cross-compiling to target an older JDK requires two things:

java -source -target to be set to the VM version you want.
bootclasspath to point to the runtime you want (ex. jdk1.5.0_22\jre\lib\rt.jar)

The first one is obvious. If the code is not binary compatible with the VM you are targeting, it won't work. The second option is to ensure that you do not use a class/method that does not exist in the older runtime. So for instance, when I tried to compile purejavacomm using the JDK 1.4 rt.jar I get a bunch of errors like this:

purejavacomm\src\jtermios\JTermios.java:555: error: cannot find symbol
                        StackTraceElement e = Thread.currentThread().getStackTrace()[2 + n];
                                                                    ^
  symbol:   method getStackTrace()
  location: class Thread
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
100 errors
2 warnings

Thread.getStackTrace() was introduced in version 1.5 of the API. So suppose we remove generics and you could compile the code with javac -source 1.4 -target 1.4 on your JDK 1.8. It would compile and you'd have a nice jar. Your JDK 1.4 users, however, would find that it would fail at runtime because it could not find that method.

The only reason I bring up JDK 1.4 is because RXTX claims to support JDK 1.4. Systems that run RXTX on JDK 1.4 could not use this API as a drop-in for the aforementioned reason. Now, I doubt you have any users on JDK 1.4, but it is something to think about.

The code is currently compliant and compilable against the 1.5 API, which is probably sufficient.

More info about the Cross Compiling business can be found in the javac docs.

As for getting your hands on the 1.5 rt.jar, go to the legacy Java SE website and download the linux .bin file. I was able extract it as an archive using 7Zip. You can then reference the rt.jar in the jdk/jre/lib folder. I don't know what the MAC equivalent to 7Zip is, unfortunately. You'll need an oracle account to download the older JDKs (it's free).

nyholku commented 8 years ago

Thanks for the detailed explanation. So the takeaway from that is I should be able to do this on my Java 1.8 but I would need the 1.5.rt.jar. Hmm, so good but a bit of a nuisance.

JDK 1.4 is a fair point, but at this point in time because now one has ever spotted this I don't think I will support that. For the unfortunate one who needs it they can hack the code themself.

I think I will just document this.

derikd commented 8 years ago

On OS X, the JRE (and I believe also the JDK) were distributed by Apple up until Java6. Java 7, from non-Apple sources will only run on OS X Lion (10.7.3) and later. Java 6 (from Apple) will work on computers as recent as El Capitan (10.11.x). You can get that here. https://support.apple.com/kb/dl1572?locale=en_US

I don’t think Java 5 is supported past 10.7.3 and I doubt that Java 6 will ever be ported to Sierra (10.12.x). I have a legacy Java6 program, and I will loose my ability to test and develop on the same platform once I upgrade to Sierra. :(

— derik

On Oct 30, 2016, at 10:30 PM, Dan Avila notifications@github.com<mailto:notifications@github.com> wrote:

As for getting your hands on the 1.5 rt.jar, go to the legacy Java SE websitehttp://www.oracle.com/technetwork/java/javase/archive-139210.html and download the linux .bin file. I was able extract it an archive using 7Zip. You can then reference the rt.jar in the jdk/jre/lib folder. I don't know what the MAC equivalent to 7Zip is, unfortunately. You'll need an oracle account to download the older JDKs (it's free).

masterav10 commented 8 years ago

Java 5 compliant jars will run on any JRE/JDK >= 1.5. This pull request guarantees that when compiled, the .class files are binary compliant with Java 5 JVM and are compiled with access to the public API available to Java 5 implementations.

In other words, you should have no problem.

nyholku commented 7 years ago

I may have succeeded in publishing to a sonatype manven central.

Please test if you can access it.

FWIW, this is what the Nexus Repository Manager shows for 'maven':

com.github.purejavacomm purejavacomm 1.0.1.RELEASE

Thanks for the legwork, this would not have happened without it and even then it took some four hours of work and about a week of calendar time to get all the ducks in a row.

derikd commented 7 years ago

I may have succeeded in publishing to a sonatype manven central.

Sorry if this is a bit off topic, but I have a question about Maven repsositories.

I presume that Maven can download files from GitHub repositories just as easily as a Maven repository. If that’s so, and your project is already setup to use Maven, what benefit do you gain?

I have a few have projects that use external libraries. None of those projects use Maven (that I know of - maybe NetBeans uses Maven under the cover). None of the libraries have Maven repositories (that I know of). Now that the new Maven repository for PJC was created, would my projects gain some immediate benefit by taking advantage of this effort?

Again, I apologize for being slightly off topic for this forum.

— derik

On Dec 26, 2016, at 9:12 AM, nyholku notifications@github.com<mailto:notifications@github.com> wrote:

I may have succeeded in publishing to a sonatype manven central.

Please test if you can access it.

FWIW, this is what the Nexus Repository Manager shows for 'maven':

com.github.purejavacomm purejavacomm 1.0.1.RELEASE

Thanks for the legwork, this would not have happened without it and even then it took some four hours of work and about a week of calendar time to get all the ducks in a row.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/nyholku/purejavacomm/pull/91#issuecomment-269227891, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AOMXDythpvyKV5Lu3MB_pVSasSF6lgBjks5rL_V2gaJpZM4KklPn.

nyholku commented 7 years ago

Hi derikd,

I honestly don't know! Some people think it is the cat's whisker and seem to mind a lot to have it in Maven Central so now there they have it. I don't think it will affect your usage in one way or the other unless you want to move over to maven. And that is a totally different can of worms (or cherries) if you want to do that. I will keep releasing the jars in the github so (but I will stop the sparetimelabs/maven repository I guess because as far as I understand it is now redundant).

johnstosh commented 7 years ago

What I'm getting out of maven is a change from (a) manually finding and moving around jars to (b) maven automatically handling stuff for me. So this means updating a jar to a new version means I just type the version number into a maven project file. And it means that I don't have to locate, download, copy, and move around the jar. It sounds like a small thing, but it turns out to mean a lot of convenience.

In the long term, I expect even more support in the IDE for automatically manipulating information about jar files. Today I can "just click" to download javadoc and sources for a jar or set of jars. In the future, I expect better support for analyzing my maven project and getting automatic recommendations about compatible jar versions and updated jar versions and such.

If you're into copyrights and licenses, then there are some tools out there that'll tell you when you add a non-compatible jar into your project.

To to summarize, its about tooling and automation. But that summary is rather vague and unhelpful.

nyholku commented 7 years ago

Hi, thanks, I think that is a very helpful comment actually.

To get to hear from a real experience of what the benefits are.

My beef with Maven is the Maven's core concept "convention over configuration" which as far as I understand is that you should (re)organise your project according to Maven convention or else!

My way or highway..

I'm all for conventions, it so often life more, well convenient ;) but re-organizing old projects can be a lot of work and upset a lot things and people. Also I'm not at all happy with the many of the Maven conventions.

More importantly when (and not if) Maven is replaced with something else (i.e. something else becomes the fad) then do I/we want to re-organise everything again to a new convention?

So I'm all for using Maven Central as a distribution mechanism for publishing stuff, but I'm not going to organise my existing projects to please Maven conventions.

For new projects I may consider using Maven as a build tool, then again my brief exposure to gradle (the new fad) looked more promising.

masterav10 commented 7 years ago

@derikd I don't know of a way to download GitHub releases using modern build tools. Closest thing I could find was jitpack, but that would have required @nyholku to do a the same things I already did in this pull request.

My background: I work in a mostly offline environment, and use gradle + artifactory to maintain the ever growing list of dependencies in this offline environment for 5+ projects; in the range of 20k-70k lines of code. To give you an idea, the latest drop I pulled had over 400 MB's of jars and roughly 1k+ artifacts. To get that drop, I simply changed the version numbers (20 or so) in my gradle script and do a refresh dependencies. 1 hour later, my local artifactory is populated with all my stuff. Export the repo to CD, import the repo on the LAN, all projects are happy. I don't have to worry having multiple versions of the same jar on my classpath; gradle takes care of that for me.

Additional benefits of publishing to maven central, to supplement comments by @johnstosh :

The artifacts are signed by the developer.
Javadoc + Sources (this was my primary reason for performing this work). Debugging is so much easier with source code in the IDE.
Longevity and Support (Central is going to be around for a while).

@nyholku Gradle is pretty forgiving about deviations from the "conventions", as you can see from the gradle scripts in this project (took me roughly 2 hours after work to do). It should be fairly straightforward to reuse most of the work done here in other projects should you desire, and I doubt it will take 4 hours every time. As for conventions posting to central, that's a different ball game. I'd say half a day effort is par for the course.

nyholku / purejavacomm

Publish to Maven Central #91