Well, I guess I have my answer, I am alone :-).
Many people are telling me that both the sonatype super pom and SNAPSHOTs are
optional. I obviously have been reading the wrong instructions. This is the
instructions I've followed:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
Are there better, clearer instructions somewhere else ? One of the "mvn
release:*" commands (dont rember which ) failed if I did not have a SNAPSHOT
version and told me the problem was that I did not have a SNAPSHOT version. So
is the above page completely wrong ? Are there other "mvn release:*" goals to
run ?
I also don't buy the argument that release complexity gives better quality.
Many of the responses to my mail have also indicated that the update of my
github repository is a totally obvious thing. I simply do not accept that. When
I update my repository and what I update it with is my and only my decision! I
went around this problem by making a copy repository before going through the
release steps, and then deleted the copy afterwards, keeping my original
intact. It was already in the state I wanted it before releasing to maven
central. The only thing I want to release to maven central is binaries! My
repository should not be touched. So if there is no way around that happening I
guess I have released my first and last code to maven central.
Anyhow, my question have been answered very clearly.
Tommy
5 jan 2014 kl. 16:18 skrev Markus Karg <[email protected]>:
> I uploaded lots of not-even-Mavenized prebuilt JARs to Maven Central and can
> tell you that you simply misunderstood these terms as "essential"
> requirements -- in fact most of them are only "best practices". You do
> neither need to have the Sonatype POM, it will just make things easier, nor
> do you have to use SNAPSHOTs. You can simply upload a prebuilt JAR file. The
> only "hard" requirements are a "good" POM, signing the JAR with GPG,
> uploading it to the OSS nexus instance, then closing and releasing it. This
> it at-most simple and done in minutes. If you need help, feel free to contact
> me at [email protected], I can guide you.
>
> -----Original Message-----
> From: Tommy Svensson [mailto:[email protected]]
> Sent: Sonntag, 5. Januar 2014 14:15
> To: Maven Users List
> Subject: Maven Central Opinion
>
> I was asked to submit one of my opensource tools at github to maven central.
> This turned out to be a rather complex procedure.
>
> Sonatype puts the following requirements on anyone wanting to submit to maven
> central:
>
> - You are forced to set a Sonatype pom as parent of your project and thus
> inherit things you have no control over.
> - You are forced to have a SNAPSHOT version even if you have no use for such.
> - You are forced at submission time to select a new version for your software
> even if you have no idea if it will be a minor, bugfix or new functionality
> at this point in time.
> - Your public repository (github, etc) which you are forced to point out in
> your pom are no longer yours to decide over. It will be updated during the
> submission process.
> - After running 3 different mvn commands you also need to login to Sonatypes
> nexus server and "release" the artifacts before the become available.
>
> The idea of the maven repository that has grown larger than maven itself is a
> completely brilliant idea. It takes open source to a new level where anyone
> can just depend on other open source code and automatically download it on
> build. This is really good for the open source world (well, at least the
> Java/JVM part of it) . The fact that the release process to this central
> repository is far too complex, I see as a really great problem, inhibiting
> the easy sharing of open source work. I have often found open source tools
> and frameworks that are not available in maven central, and that is because
> not everyone is willing to put up with this, which now also includes myself.
> As I see it, either this procedure needs to be changed to provide a trivial
> release of binary artifacts without affecting your poms, or there need to be
> an alternative open repository providing ease of release, where it is trivial
> for anyone to share their binaries for easy access by others. I'm wondering
> if I'm alone in this view or if there are others who agree with me ?
>
> Tommy Svensson
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
