Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make JARs (classes, javadoc, source) available on Maven Central #1

Closed
kriegaex opened this issue Nov 7, 2013 · 39 comments
Closed

Make JARs (classes, javadoc, source) available on Maven Central #1

kriegaex opened this issue Nov 7, 2013 · 39 comments

Comments

@kriegaex
Copy link

kriegaex commented Nov 7, 2013

Hi.

How about

  • building kryonet with Maven,
  • getting rid of dependencies (library JARs) in your SVN/Git repo,
  • making the artifacts available on Maven Central?

Maybe I can even give you a hand.

@NathanSweet
Copy link
Member

You are welcome to put in on Maven Central. I'll leave the JARs in git for now since it is convenient.

@kriegaex
Copy link
Author

kriegaex commented Nov 7, 2013

With all due respect: What is convenient about it?

Kryonet has two more dependencies which are not mavenised (Jsonbeans, Minlog), all the others are on Maven Central and I had a Maven build running locally within a few minutes. Putting binaries in an SCM system like Git or Subversion reduces SCM to absurdity. It is an anti-pattern. Dependency management should be automated. Don't you think it is rather odd to redundantly store binaries for ASM, Kryo and even JUnit (an outdated version BTW) in Git/SVN? It just bloats your project.

Furthermore, you do not even deliver a how-to for building the software, which with a Maven POM you would not need to do because everyone could just call mvn clean install and be done with. No more dependency on an Eclipse project configuration (I use IntelliJ IDEA, BTW).

Theoretically I could upload something to Maven Centra, but

  • I am not the maintainer of the software, so in which way am I authorised to speak for you and tell everyone it is the official build?
  • should I check on your project websites daily in order to keep Kryonet, Jsonbeans and Minlog up to date?

Sorry Nathan, but getting up to speed with Maven basics is quite easy and you would benefit from it forever because Maven would forever do dependency management and builds for you once you would have configured it. Your users would also benefit from it becauase they could just copy & paste a <dependency>... snippet from Maven Central into their POMs and be happy. No manual downloads, no unpacking, no search for sources and javadocs.

If I volunteer to migrate your three projects to Maven, would you then upload and maintain them? As I said, I can help you. I can fork your Git repos and issue pull requests after I am done.

@NathanSweet
Copy link
Member

I don't use Maven. It isn't a matter of "being up to speed". As great of a tool as it is for you and others, I am not interested.

If you would like to put the projects on Maven Central so those who would like to use Maven would benefit, great. If keeping them up to date is as easy as running a Maven command and uploading a file, I can probably keep them up to date. Otherwise you can get notification of new releases through the mailing list for each project so you can keep them up to date.

@kriegaex
Copy link
Author

kriegaex commented Nov 7, 2013

Nice attitude, just using a killer phrase like "I have never done it before and am not gonna change anything" instead of actually considering slightly moving from your comfort zone into the learning zone. And yes, if configured correctly, each build is just a mouse click (for you in Eclipse, for me in IDEA). Pretty much the same applies to performing a public release. The Maven release plugin can increment the version number for you, tag your repo and upload the artifacts. Anyway, I will stop here. It is like talking against a wall of ignorance. Thanks for the discussion anyway.

@NathanSweet
Copy link
Member

My choice to not use Maven has nothing to do with a "learning zone".

My OSS is provided to you for free. If you want to contribute something, then do so. Otherwise I would appreciate you not wasting my time any further.

@badlogic
Copy link
Contributor

badlogic commented Nov 7, 2013

The sense of entitlement in here is bewildering. Create a freaking pom and send a PR. The your build nightmares are over. Getting things in Maven Central requires considerably more effort (SonaType account, pgp keys, following the SonaType guide, ideally a CI server that pushes snapshots automatically, i'm sure you guys can come up with other things that should be done for you free of charge because YOU and not the author himself requires it).

Put your money where your mouth is and contribute if you know how to do it and need a specific feature.

@kriegaex
Copy link
Author

I have no sense of entitlement, I was just wondering how someone so smart can create such a nice piece of software and then not go the last mile to publish it in a state of the art way so as to make it available to all users for automatic builds. I have offered to help, though, and I mean it. I am critical, but in a constructive way.

Actually creating a "freaking POM" is not so strightforward because there are two dependencies which are also not mavenised: Jsonbeans and Minlog. The are also not hosted on GitHub, so I cannot just fork them and create pull requests for them. I worked around this temporarily by enabling Maven to download the official ZIP files from the respective Google Source pages, unpack them and install the JARs manually to the local Maven repo.

Before I issue a PR you might want to take a look at my quick shot at https://github.com/kriegaex/kryonet/commits/maven. Just check out the few changesets I have created in order to see step by step what I did.

As for uploading the artifacts myself to Maven Central, this would be easy, but I think it should not be my PGP signature on Nathan's artifacts, but his own. This is why I will not do that. I can help getting it done and automated though. There are nice how-to tutorials out there, and they look straightforward. Just a few more settings in pom.xml.

Nathan, if you decide to also migrate your repos for Jsonbeans and Minlog from Google Code to GitHub, give me a sign and I can mavenise those builds too. The advantage would be that the Kryonet POM would get much cleaner and shorter.

@NathanSweet
Copy link
Member

All my projects are on github as of a last week or so, just haven't had time to move over the wiki, issues, etc.
https://github.com/EsotericSoftware/

@kriegaex
Copy link
Author

Okay, I put quite some work into getting kryonet as well as its dependencide jsonbeans and minlog mavenised. The POMs are copied and adapted from one of my own ones with which I successfully deployed snapshots as well as releases to the Sonatype Nexus which is synchronised with Mavern Central. I can even do that from the IDE (IntelliJ IDEA in my case). But it also works from the console. Check out my forks (master branches everywhere, I also pulled and merged your latest changes just now since I had cloned the repos a few days earlier):

I can send you pull requests for all three or you can pull from them by yourself after adding them as remotes.

Basically jsonbeans and minlog were simple because they have no runtime dependencies. Kryonet was a bit more complex. I removed all binaries (libraries) from the repo and replaced them by clean Maven dependencies. If you follow the tutorials

it should be simple to

  • install GnuPG 2.x, put it on your path (also Maven 3.0.x, please),
  • create a key pair for signing artifacts,
  • signing up for a user name at Sonatype,
  • request a groupID for com.esotericsoftware (probably one exists already because Kryo can be found there, so you just need to request to be added as a deployer) and
  • deploy/release happily everafter.

I could do that for you too, but actually I went 95 of 100 miles for you on that way, reading all those tutorials and preparing your builds for Maven Central. I think it would be better when a signer with a Esoteric Software e-mail address would release the artifacts rather than me.

What has changed? No an awful lot, but

  • I have not added any debug library dependencies to the automated build because I don't know when and how this is needed.
  • I have not updated any path references for the Eclipse projects after I have adjusted the directory structure to Maven defaults. You can easily re-import the projects from the POM in Eclipse and start clean.
  • I have not committed my IDEA projects, by the way, because probably you do not use them anyway. Instead I have put all IDEA stuff into .gitignore so as not to accidentally commit stuff you do not like to see.
  • I have updated the snapshot versions for each project to a minor version number of your latest releases +1.

What needs to be done build-wise?

  • In all POMs you need to add your own GPG key ID instead of mine if you want to sign artifacts.
  • Please first get jsonbeans and minlog onto Maven Central as releases. Because they are not, currently the Kryonet build depends on Maven snapshots of them.
  • After the two are on Central, update the Kryonet POM to use those releases instead of snapshots. Then get Kryonet onto Central.

If you have any questions or need help, please let me know.

P.S.: I hope that you (Nathan and badlogic) do see that I am not just talking and demanding, but willing to help. I think I cleaned up quite a mess and hope I did not break anything important along the way.

P.P.S.: Even in the current master version there is a failing test on my machine:

junit.framework.AssertionFailedError: TCP data is not equal on client.
    at com.esotericsoftware.kryonet.JsonTest.testJson(JsonTest.java:79)

Update: I have just created the three pull requests.

@NathanSweet
Copy link
Member

Cool, thanks. A few issues though:

  1. I won't remove the JARs from git. Yes, I understand all the reasons not to put them in git. Still, you can just ignore them.
  2. I won't change the source folder structure. It's trivial to specify in the POM.

I went to do MinLog first, but found it is already there:
http://oss.sonatype.org/content/repositories/releases/com/esotericsoftware/minlog/minlog/1.2/
Martin from the Kryo mailing list has been managing the dependencies for Kryo. I don't mind taking it over if it can be made to work easily. I updated the POM.

I already have a sonatype account and I submitted this a long time ago:
https://issues.sonatype.org/browse/OSSRH-865
I don't see a place that shows where I have access to upload artifacts. Running mvn deploy:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project minlog: Failed to deploy artifacts: Could not transfer artifact com.esotericsoftware:minlog:jar:1.3-SNAPHOT from/to sonatype-nexus-staging (https://oss.sonatype.org/service/local/staging/deploy/maven2/): Access denied to: https://oss.sonatype.org/service/local/staging/deploy/maven2/com/esotericsoftware/minlog/1.3-SNAPHOT/minlog-1.3-SNAPHOT.jar, ReasonPhrase: Forbidden. -> [Help 1]

Sooo, should I create a new sonatype issue? Asking for what?

@NathanSweet NathanSweet reopened this Nov 14, 2013
@kriegaex
Copy link
Author

I can think of two reasons:

BTW, it is also trivial to change the directories in Eclipse to match Maven. The nice thing is that any Maven user independent of IDE knows the layout and any IDE can understand the Maven layout. But switch back if you like it so much better. Trivial either way.

As for the binaries, just re-add them if you prefer to have them redundantly in Eclipse as well as $HOME/.m2. It is not my harddrive. If you have 50 Eclipse projects, will you have them in 50 work directories instead of just one local Maven repo? Just go ahead and good luck, redundancy galore. I have done my share to let facts speak, you just do whatever you prefer to. I am giving up on trying to make an old horse learn new tricks.

@NathanSweet
Copy link
Member

@NathanSweet
Copy link
Member

They resolved it, deploy for minlog 1.3-SNAPHOT worked. Don't see the JARs though, guess we need to wait?

@kriegaex
Copy link
Author

Snapshots are not sync'ed to Central AFAIK, but available for download from the Sonatype OSS snapshot repo.

@NathanSweet
Copy link
Member

Got a response on the jira issue. Had to close and then release some repo somewhere. Still don't see it here:
http://oss.sonatype.org/content/repositories/releases/com/esotericsoftware/minlog/minlog/
Wait more, I guess.

@kriegaex
Copy link
Author

@NathanSweet
Copy link
Member

Ah, I guess Martin has used minlog/minlog and I didn't notice. No idea why he did? Now it looks like a mess!

@kriegaex
Copy link
Author

I think it is possible to delete artifacts from the repo. It might piss off people relying on it, but I guess they can adapt.

@magro
Copy link
Collaborator

magro commented Nov 15, 2013

Hi, just got pinged by Nate if I could comment.

The groupId was not chosen by me (I even looked this up, because I wasn't sure: EsotericSoftware/kryo#13 (comment)), and I didn't complain about it but just took this over later.

My preference is also to have just com.esotericsoftware as groupId and the project name as artifactId, but to me isn't that important that I would change it now. I'm speaking for kryo, I don't use other projects directly.

If the groupId should be changed for kryo, I'd suggest to do this for the next major release. I'm suggesting this especially, because there were just complaints about compatibility issues and I'd be very careful with anything related to compatibility now. I'd also suggest to switch to semantic versioning with the new major release (to have clearer versioning semantics obviously ;-)).
IMHO it makes sense to treat other esotericsoftware projects the same.

@NathanSweet
Copy link
Member

I also prefer using just com.esotericsoftware for the group ID. Do we really need to hold off on the change though? It doesn't affect compatibility, only POM configuration. Is it possible to move or redeploy the minlog/minlog, kryo/kryo, etc artifacts to minlog, kryo, etc? How are artifacts removed? I should remove minlog-1.3 and redploy as 1.2.1.

@magro
Copy link
Collaborator

magro commented Nov 15, 2013

Do we really need to hold off on the change though?

No, we don't have to, but this would be my (not so strong) preference. If for kryo we would have a bump of the major version in the near future anyways, why shouldn't we wait?
To be clear: I'm speaking for kryo here. Changing the groupId of minlog or reflectasm would not affect many users, so for the next minor kryo release we could leave the kryo groupId as it is but depend on minlog/reflectasm with their changed groupIds. Most users should just depend on kryo and pull in minlog/reflectasm transitively, so they wouldn't be bothered.

It doesn't affect compatibility, only POM configuration.

For users this breaks things, because they're used to just bumping the version number - that's what I've seen in other projects, where a changed groupId caused traffic on the mailing list.

How are artifacts removed?

AFAIK once artifacts are pushed to maven central there's no way back.

@kriegaex
Copy link
Author

How to delete in Nexus: Drill down to the version you want to deletem, select a single artifact (e.g. a JAR file), select "Artifact" tab on the right, click "delete" button. I tried this on a snapshot repo, I am unsure if it works on a released artifact. The button is active though.

@magro
Copy link
Collaborator

magro commented Nov 15, 2013

From a related SO question "Removing an artifact from Maven Central":

Can't be done. It's A Rule. But if you want to try, contact the Sonatype people who support oss.sonatype.org. So you generally push a new, higher, version with the fix, and tell everyone to use it.

@kriegaex
Copy link
Author

Good point. I even agree that it is usually a bad idea to remove an existing release. It should be no problem to issue a new one and after a short while people who like to have the latest version will migrate. For the few others who do not want to upgrade nothing will break. If they consciously decide to upgrade, they quickly change their group IDs and tadaa, they can use the latest version.

@ghost
Copy link

ghost commented Nov 19, 2013

Any updates? I'm really looking forward to this!

@magro
Copy link
Collaborator

magro commented Nov 21, 2013

IMHO kryonet, minlog and reflectasm can be released with groupId com.esotericsoftware (for kryo, we can decide this independently). I also suggest to switch to semantic versioning. When I can help with anything let me know.

@gjroelofs
Copy link

Hi, is there any update on this matter?

I've seen kryo, minlog and reflectasm appear in maven central; but have yet to see kryonet appear.
Is there anything that still needs to be done / anyone needs help with?

As a tip for those still waiting:
Up until now I've kept the repository in sync locally, and used the jars provided in the /libs/ along with "com.googlecode.addjars-maven-plugin" to deploy to a private repo. Which is obviously less than ideal, but it works.

On a unrelated sidenote, directed @kriegaex : Apart from in the end actually contributing the pom, I would like to say that I find your manner of communication appalling. From the manner and tone with which you have opened this issue, up unto the "wall of ignorance" remark; you showcase a general lack in sensitivity, gratitude and common decency towards those who provide you their work for free, all presented with a distinct odor of zealotry/superiority. You even go so far as to assume Nate's choice is made out of ignorance.

@NathanSweet
Copy link
Member

@magro Should we change the Kryo groupid with the next release? I went through the Kryo issues @romix brought up, I think we can release soon, if not now. Also, any chance you can push KryoNet to Maven Central? :D No worries if that is asking too much!

@romix
Copy link

romix commented Mar 22, 2014

@NathanSweet I still need a few days to fix some of the Kryo issues that you reviewed, e.g. update a PR based on your review and merge it. But, yes, I think we could release soon.
When it comes to pushing KryoNet to MavenCenral, it is Martin, who does it for Kryo now. I think he could push KryoNet rather easily as well, since he has an established release process in place already.

@magro Martin could you push KryoNet to Maven Central?

@magro
Copy link
Collaborator

magro commented Mar 22, 2014

@NathanSweet @romix I can push kryonet to central (I need to go through the registration process at sonatype, which will take some days), we can also change the groupId for kryo (for reflectasm and minlog as well, probably). Right now I'm ill, I can pick up things the next days.

@gjroelofs
Copy link

Any update so far? :)

@jonbonazza
Copy link

really looking forward to this. How close is it? Thanks!

@magro
Copy link
Collaborator

magro commented Apr 26, 2014

I just asked sonatype to give me permissions to deploy for groupId com.esotericsoftware: OSSRH-9626.

Is there already a pom.xml somewhere to build kryonet, or would I have to prepare this?

@cmorgner
Copy link

cmorgner commented May 4, 2014

+1 for Maven Central availability

@cmorgner
Copy link

cmorgner commented May 4, 2014

Just another hint for everyone who wants to use kryonet as a Maven dependency: it's in the clojars.org public repository, you can get it with the following repository and dependency entries:

<repository>
    <id>clojars</id>
    <url>http://clojars.org/repo/</url>
</repository>
<dependency>
    <groupId>kryonet</groupId>
    <artifactId>kryonet</artifactId>
    <version>2.21</version>
</dependency>

@Jyro117
Copy link

Jyro117 commented Jun 13, 2014

Not to repeat anything someone else said, but...

Any update so far? :)

@NathanSweet
Copy link
Member

@Jyro117 See the post about clojars above yours.

@magro I don't believe there is a POM. Could maybe model after the clojars POM.

@Jyro117
Copy link

Jyro117 commented Jun 13, 2014

@NathanSweet Yes that works and I currently use it, but it has no source code or docs and there isn't a debug version for actually getting kryonet logging information.

magro added a commit to magro/kryonet that referenced this issue Jun 14, 2014
…Software#1

This version is deployed to sonatype and synced to maven central:
http://repo1.maven.org/maven2/com/esotericsoftware/kryonet/

Currently tests failing when running `mvn install`:

    Tests in error:
      testRMI(com.esotericsoftware.kryonet.rmi.RmiSendObjectTest): Address already in use

The full output of `mvn install` is available here:
https://dl.dropboxusercontent.com/u/1439289/mvn-install.log.zip

To be able to build the jar `mvn install` was run with `-Dmaven.test.skip=true`.
@NathanSweet
Copy link
Member

Closed via #70

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

9 participants