NathanSweet
commented
10 years ago You are welcome to put in on Maven Central. I'll leave the JARs in git for now since it is convenient.
Closed kriegaex closed 10 years ago
NathanSweet
commented
10 years ago You are welcome to put in on Maven Central. I'll leave the JARs in git for now since it is convenient.
kriegaex
commented
10 years ago 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
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
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago 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
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
What needs to be done build-wise?
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
commented
10 years ago 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?
kriegaex
commented
10 years ago 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
commented
10 years ago NathanSweet
commented
10 years ago They resolved it, deploy for minlog 1.3-SNAPHOT worked. Don't see the JARs though, guess we need to wait?
kriegaex
commented
10 years ago Snapshots are not sync'ed to Central AFAIK, but available for download from the Sonatype OSS snapshot repo.
NathanSweet
commented
10 years ago 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
commented
10 years ago Hm, why minlog/minlog? Look here: http://oss.sonatype.org/content/repositories/releases/com/esotericsoftware/minlog/1.3-SNAPHOT/
NathanSweet
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago 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: https://github.com/EsotericSoftware/kryo/issues/13#issuecomment-28246577), 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
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago Any updates? I'm really looking forward to this!
magro
commented
10 years ago 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
commented
10 years ago 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
commented
10 years ago @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
commented
10 years ago @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
commented
10 years ago @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
commented
10 years ago Any update so far? :)
jonbonazza
commented
10 years ago really looking forward to this. How close is it? Thanks!
magro
commented
10 years ago 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
commented
10 years ago +1 for Maven Central availability
cmorgner
commented
10 years ago 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
commented
10 years ago Not to repeat anything someone else said, but...
Any update so far? :)
NathanSweet
commented
10 years ago @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
commented
10 years ago @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.
NathanSweet
commented
10 years ago Closed via #70
Hi.
How about
Maybe I can even give you a hand.