-
Notifications
You must be signed in to change notification settings - Fork 26
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
Perform the first Maven release #6
Comments
I volunteer to take care for the step (2). |
👍 |
@paulvi nice to see your 👍 but I wonder how to interpret it? I suppose you are interested in the change, but you are not an owner of the |
👍 is imoji for code It also lets me follow the issue conversations. consuming Maven published artifacts is more stable way than gitmodules, see ncjones/editorconfig-eclipse#12 |
By the way you could release on bintray JCenter https://bintray.com/bintray/jcenter e.g. http://veithen.github.io/2013/05/26/github-bintray-maven-release-plugin.html It will sync will Sonatype OSS and Maven Central |
Having editorconfig-core-java published somewhere with Maven is important for Java-based tools that want to support editorconfig (such as the editorconfig-eclipse plugin). Is there any way to make it happen soon? |
@denofevil Can you look into this please? Thanks! |
@xuhdev I'm looking at it. Would it be ok if I publish that under JetBrains account to simplify things? |
Ping me if you need help with JFrog Bintray/JCenter or syncing to Maven Central from there. |
Gentlemen, thanks a lot that the things started to move :)
@denofevil account where? At Sonatype or Bintray? I prefer releasing directly to Sonatype. There is no point in depending on Bintray. Releasing to Sonatype is simpler and faster. BTW, does your question mean that mean that several JetBrains employees share one account? |
@ppalaga can you please elaborate why you think releasing to Bintray is not a good idea and how releasing to Sonatype is simpler? It's your project, you'll do what's right for it, but I am dying to hear the argument. Because for example, if you use Bintray, you don't need the "release engineer" (does that role sounds like 1990 for me only?). After all, you don't need a "source code engineer" to check in your code to GitHub, do you? Why the release should be different? Bintray supports organizations much like GitHub. |
@jbaruch when I released via Bintray last time, (1) I had to register at Sonatype anyway (2) I had to enter my Sonatype creds on Bintray UI and (3) releases via Bintray simply cannot appear faster on Central compared to releases via Bintray, because releases via Bintray go via Sontatype. To sum up, I see Bintray as a useless level of indirection. |
I am not sure you know what Bintray is. It is by all means not a gateway to Maven Central. If you only used it as such, there are two options – keep releasing to Sonatype directly, or give it another look to see what it gives except of the sync to legacy platforms like Maven Central. |
@jbaruch indeed, having |
In this case, absolutely, there is no need to drive a nail with a scientific microscope, if you get my analogy here. |
@jbaruch neither with galactic telescope :) |
True that. When you'll get to the need of a real universal distribution platform (either for editorconfig or anything else) let's talk :) |
Note that for editorconfig-eclipse, the artifact "only" needs on whatever Maven repo available publicly. However, as Maven central is available by default and has retention policies that have worked well so far, it would be my favorite too. But a 1st iteration on a dedicated Maven repo would already be great, and editorconfig-eclipse would most likely consume it as it. |
@denofevil No problem! |
Did this ever happen? In the README it seems like it should be published to Maven Central, but the search comes up empty. |
@stempler say it louder! |
Together with @angelozerr we created a new independent Java EditorConfig parser [1] https://github.com/ec4j/ec4j |
Not being sure at all how deep is the Maven knowledge here in editorconfig-core-java community, I am listing the steps necessary to perform the first Maven release.
(0) We should decide who will be the release engineer. Some of the project owners seems to be the most natural choice. I am ready to take the role too. Ideally, at least two community members should be able to release.
(1) Initial setup of our OSSRH Maven repository: http://central.sonatype.org/pages/ossrh-guide.html
(1.1) The release engineer needs to create a Jira account on Sonatype Jira: https://issues.sonatype.org/secure/Signup!default.jspa
(1.2) The release engineer needs to create a new project ticket that will be processed manually at Sonatype: https://issues.sonatype.org/secure/CreateIssue.jspa?issuetype=21&pid=10134
(2) Our project needs to comply with Maven Central Requirements http://central.sonatype.org/pages/requirements.html such as GPG/PGP signing, supplying Javadoc and Sources, etc.
(3) The release engineer needs to release.
The text was updated successfully, but these errors were encountered: