Publish the 1.2 on MavenRepositery

[AdrieanKhisbe]

Is it possible to publish the 1.2 artefact on maven repositery? :)

I was using this version from Maven Repositery, as graddle dependancy 'com.google.java.contract:cofoja:1.1-r150', but having updated the project to 1.8, I need the newest version to compile.

(java.lang.NoClassDefFoundError: com/sun/tools/javac/main/OptionName error)

thanks in advance :)

[nhatminhle]

I didn't publish the previous version; someone else did. Actually I'm not familiar with the process to do that; it seems like anyone can do it, so maybe you should submit a version?

[AdrieanKhisbe]

So far i'm not familiar neither ^^. Due to my tight univ project schedule, I choosed to use a work around. I might see how to publish them when I'll have some respite :)

[AdrieanKhisbe]

I did some research to see how to publish to maven central (and to automate this) and here is the leads l found to do it with an ant+ivybuild

• http://stackoverflow.com/questions/8505062/publish-snapshot-artifacts-to-maven-using-ivy-whats-the-magic
• http://stackoverflow.com/questions/5111831/how-to-publish-3rdparty-artifacts-with-ivy-and-nexus

[AdrieanKhisbe]

you might need to register an account on Sonatype to register the project

http://central.sonatype.org/pages/ossrh-guide.html

[marcusbb]

Are there any updates to this publication?
I'd rather not have to maintain the library on internal repository

[AdrieanKhisbe]

Nothing new as far as I know. :)

[ghost]

                                                                                  Same thing here. I have it on my local VC system for fear of it disappearing, and for the ease of having it in my own artifactory. Having it on maven central would be way better.                                                                                                                                                                                                                                                                                                                                        Sent from my BlackBerry 10 smartphone.                                                                                                                                                                                                                From: Marcus SimonsenSent: Tuesday, 1 December 2015 15:37To: nhatminhle/cofojaReply To: nhatminhle/cofojaSubject: Re: [cofoja] Publish the 1.2 on MavenRepositery (#44)Are there any updates to this publication?

I'd rather not have to maintain the library on internal repository

—Reply to this email directly or view it on GitHub.

[marcusbb]

Thanks for the updates. Do you maintain the 3 different build outputs as different modules in your local/internal repositories, or do you have an "uber" jar?

[nhatminhle]

Just to say I haven't done anything regarding this issue either. :)

(And I won't lie, I'm not doing much for Cofoja in general, these days; but I try to stick around for when the next major breakage due to language/JVM evolution comes around.)

Nhat

On Tue, Dec 1, 2015 at 3:59 PM, Marcus Simonsen notifications@github.com wrote:

Thanks for the updates. Do you maintain the 3 different build outputs as different modules in your local/internal repositories, or do you have an "uber" jar?

— Reply to this email directly or view it on GitHub https://github.com/nhatminhle/cofoja/issues/44#issuecomment-160991113.

[ghost]

I maintain 3 different modules in my local repo, in order to be able to reference them separately. Not all projects that use cofoja use them in the same way and combination.

[ghost]

@nhatminhle Neither am I. But I reserved the entire month of May 2016 to create a library letting a user compose algorithms with the help of pre-built lambdas, then serialize those as ( wrapped ) SerializedLambda to where the actual data are. I plan to use cofoja heavily in that project. By the time I'll be ready to show that stuff to customers, would be nice to have cofoja available in Maven Central :-)

[marcusbb]

So it appears that unless someone with authority to SonaType with group com.google.java.contract are we out of luck? @exercitussolus I'd like to know what your publication mechanism, with respect to ant/ivy build.

[ghost]

@marcusbb Not sure yet. I love Maven, but may not be able to impose a particular publication system to a customer. The best option may be to shadow all of cofoja - with the disadvantages coming along... Is this what you meant with your question ?

[marcusbb]

@exercitussolus - Yes I'm referring to maven repository publication. I know the ivy files describes the dependencies, but don't adequately describe the modules within - the 3 jars that comes out of the ant build.

[ghost]

@marcusbb Yep. Hence my last-lifesaver idea to simply shadow cofoja. Not the nicest way to do things, but hey - even elasticsearch shadow half of the internet in their build :-)

[AFulgens]

@marcusbb It would be a solution, if the group would be renamed, but that would mean a big refactoring for the project and all the current users...

The ideal solution would be to find the guy who did the 1.1-r150 release to Maven Central under the com.google.java.contract group during 2013 December. There are three developers listed in the pom.xml, if nobody wants to pick up this issue, I will just ping those e-mail addresses and report back what happens. No deadline promises though :)

@exercitussolus that sounds awfully like a bandwagon, still somehow it describes the current state of the IT industry somewhat perfectly

[demurgos]

Any news ?

[Shredder121]

I have looked a bit, since I have a Sonatype account.

I believe this should be open information so you don't need an account to view this: the artifact as published

You can open a tab on the bottom right, named Artifact, which lists the artifact metadata.

The point is, there is no metadata on who published it, which leads me to believe it either was synced to Maven Central before there was a tight structure on everything.

Besides that, the only other metadata is the pom.xml which I think was already found?

[demurgos]

What about simply mailing Sonatype to give the namespace com.google.java.contract:cofoja to @nhatminhle ? I know that they have the email community@sonatype.com, but maybe it's better to contact them with their support page ? (Problem with a Service I guess...)

@nhatminhle, even if you don't know exactly how to publish to Maven, the fact that there is an obsolete version published by a third party on the central repository is really confusing. Maybe @yildiz-online could help given its comment on #2.

[Shredder121]

What about simply mailing Sonatype to give the namespace com.google.java.contract:cofoja to @nhatminhle ?

I'm very sure you need to control the goole.com domain. But no harm in trying, I guess. (@nhatminhle sorry if I misunderstood, and you do control that domain)

[yildiz-online]

Hi all, as a temporary solution i ve deployed an artifact here on githhub for 1.3:

see https://github.com/nhatminhle/cofoja/issues/2

[ebourg]

Actually you don't have to control the domain, you can just explain that your project was hosted on googlecode and already has an artifact uploaded in the Maven Central Repository, and they'll grant you the upload rights.

[Shredder121]

I've done a quick search on one of the latest issues on OSSRH, to find a reclamation of a groupid. https://issues.sonatype.org/browse/OSSRH-25424

They do ask for proof.

But, you can always try, they will probably offer pointers on how to get a hold of (people who can get a hold of) the groupid.

[ebourg]

The proof is easy, https://code.google.com/p/cofoja/ redirects to https://github.com/nhatminhle/cofoja, and there is already an artifact published as com.google.java.contract:cofoja (http://search.maven.org/#artifactdetails%7Ccom.google.java.contract%7Ccofoja%7C1.1-r150%7Cjar)

[Shredder121]

That sounds solid enough. I'd say give it a go @nhatminhle!

[nhatminhle]

Hum, sorry I'm a bit out of touch with regard to this kind of things, nowadays. So, what do I need to do? Do you want me to write to Sonatype to get the artifact on Maven Central removed? I can certainly try. What am I supposed to do with http://maven-cofoja.github.io/maven ?

About the code.google.com URL, I used to have control of that, but nowadays, Google Code has completely shut down, and I'm unsure whether any modification is possible. If you're talking about the package URL, it's a side effect of having been started as a side project at Google years ago, but does it matter what package name we use?

Nhat

On Fri, Oct 7, 2016 at 4:11 PM, Ruben Dijkstra notifications@github.com wrote:

That sounds solid enough. I'd say give it a go @nhatminhle https://github.com/nhatminhle!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nhatminhle/cofoja/issues/44#issuecomment-252262796, or mute the thread https://github.com/notifications/unsubscribe-auth/ADtbnmcompNFgRNB5ZwheEv4FoXhR7hKks5qxlMpgaJpZM4DQwif .

[Shredder121]

Ah, well since the redirect is setup, I'm sure you can open an issue on their issue tracker: https://issues.sonatype.org/projects/OSSRH

You could try to get it removed, but I'm not sure that they do that. (maven central is actually mirrored on some places, and I am not sure how deletions work)

In any case, you can show them that the (google code) project url redirects to this repository now.

If all else fails, you can also ask for pointers on how to continue.

And if that also doesn't work out, a package change is also possible. But we'll see what they have to say.

P.S. I'd say, start the issue description with something that should catch their eyes, I'm not sure how mechanical they approach the process nowadays.

[nhatminhle]

Hum, sorry but I'm a bit lost: what is it that we are trying to achieve here? Is the problem that you cannot push a new artifact to their repo because there's already the old one?

If I understand correctly, you want me to create an account on whatever the Sonatype Maven repository and request that they give me the right to update the outdated artifact named "cofoja" with a new one you've created at http://maven-cofoja.github.io/maven ?

Nhat

On Fri, Oct 7, 2016 at 4:49 PM, Ruben Dijkstra notifications@github.com wrote:

Ah, well since the redirect is setup, I'm sure you can open an issue on their issue tracker: https://issues.sonatype.org/projects/OSSRH

You could try to get it removed, but I'm not sure that they do that. (maven central is actually mirrored on some places, and I am not sure how deletions work)

In any case, you can show them that the (google code) project url redirects to this repository now.

If all else fails, you can also ask for pointers on how to continue.

And if that also doesn't work out, a package change is also possible. But we'll see what they have to say.

P.S. I'd say, start the issue description with something that should catch their eyes, I'm not sure how mechanical they approach the process nowadays.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nhatminhle/cofoja/issues/44#issuecomment-252272900, or mute the thread https://github.com/notifications/unsubscribe-auth/ADtbnu50Bo6AXKmZD3WNBcQWB5mVnR_Jks5qxlwXgaJpZM4DQwif .

[Shredder121]

The problem isn't so much the old one being there, that's fine and can stay.

But you need write permission of that groupId. As soon as you own the groupId, you can push as many versions as you want.

This means you can upload versions yourself from then on, or use a build tool to publish and upload for you.

Sonatype will need an account name to link that to, and proof that you're entitled to write permission for that groupId. Just as an aside, you can also request additional people to have write permission, but I'm not sure if then they also need to present proof. Also, I think that this groupId is counted as a part of the com.google groupId? But I've had good experiences with the sonatype issue tracker.

As I said, if all else fails and they can't help, a different groupId is also possible.

[yildiz-online]

@nhatminhle Do not get the old one removed!!! maven central must be reliable, if projects still use the old one, they have to keep being buildable. About http://maven-cofoja.github.io/maven do not care about it, it will stay there in case someone build against it, but wont be updated as soon as maven central become the usable repo.

To deploy on maven central, you need to prove the domain associated with the group id you want to use. If you cannot have that domain available, you can use a different group id like com.github.nhatminhle and cofoja as artefact id. It is not mandatory to have the group id matching the packages used in the code(while it would be preferable)

If you need help during the process with sonatype, i ll help you gladly, i ve my own artefacts on maven central, the first time maybe a bit tricky.

[nhatminhle]

Yeah, I'm just not used to the modern Java ecosystem, really, though that might change in the coming months as my work brings me to use more Java again. So how was the artifact on maven-cofoja.github.io generated? Is it written by hand or does anyone have some kind of script? Last time I looked at it, the problem is mainly that we need to add Maven artifact generation to the Ant build script, which I'm not familiar with. Otherwise, I guess, given the low frequency of releases, I might just write them by hand, if that's easy to do.

Nhat

On Sun, Oct 9, 2016 at 5:41 PM, Grégory Van den Borre < notifications@github.com> wrote:

@nhatminhle https://github.com/nhatminhle Do not get the old one removed!!! maven central must be reliable, if projects still use the old one, they have to keep being buildable. About http://maven-cofoja.github.io/maven do not care about it, it will stay there in case someone build against it, but wont be updated as soon as maven central become the usable repo.

To deploy on maven central, you need to prove the domain associated with the group id you want to use. If you cannot have that domain available, you can use a different group id like com.github.nhatminhle and cofoja as artefact id. It is not mandatory to have the group id matching the packages used in the code(while it would be preferable)

If you need help during the process with sonatype, i ll help you gladly, i ve my own artefacts on maven central, the first time maybe a bit tricky.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nhatminhle/cofoja/issues/44#issuecomment-252493706, or mute the thread https://github.com/notifications/unsubscribe-auth/ADtbnrV8gTA7yABD2yBeSQYvvsLGgfhQks5qyQsogaJpZM4DQwif .

[yildiz-online]

About maven-cofoja.github.io, the artifact was not generated, i just downloaded your binary and created the appropriate pom.xml to deploy on maven central you can perfectly generate your binary nearly as before (you need to sign it, and also to generate the javadoc and sources) and use mvn deploy-file: https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html

[demurgos]

I agree with most of the above comments: the issue is that there is some confusion because we (and most of the people) would expect you (@nhatminhle) to have control over the Cofoja's artifacts on Maven Central. This leads to some reliability issues, that's why we would like you to be able to publish and manage this package (as a trusted maintainer). The old versions should be kept in order to maintain retro-compatibility and not break any build (I'm not even sure if Maven lets you delete published artifacts). Now, to achieve this I think that @yildiz-online is right: you could simply use com.github.nhatminhle as your groupId and cofoja as your artifactId since Github is now the official "home" of the project.

What is the place of Ivy in your build process ? I could try to convert this project to a Maven project if you want.

[Shredder121]

I could try to convert this project to a Maven project if you want.

Just an aside, you don't need a Maven build for publishing. You can also manually upload on the Sonatype Nexus. As long as the required files are present (jars + pgp signatures).

[demurgos]

Ok, I just thought that it would simplify the process. According to the guide posted above, it would just require mvn deploy:deploy-file. I have to admit that I did not try it yet, but it would greatly reduce the complexity for @nhatminhle.

[nhatminhle]

Yes I think if it's possible to publish a simple artifact packaged after the fact, it makes things a lot easier for me.

I've tried to convert the build process to Maven in the past, and it's not straightforward. I currently use Ivy to pull in some dependencies, but that's about it. The Ant script does multiple passes with various directory overrides to tell the tools to look at the right files while compiling itself, which is probably the main issue with the switch to Maven.

I think I understand the process better now; let's try to go for the simplest solution first. I'll try to tinker with generating a Maven artifact for a bit, then I can submit a ticket to Sonatype.

Nhat

On Thu, 13 Oct 2016 23:08:13 +0200, Charles Samborski wrote:

[1 <text/plain; UTF-8 (7bit)>] Ok, I just thought that it would simplify the process. According to the guide posted above, it would just require mvn deploy:deploy-file. I have to admit that I did not try it yet, but it would greatly reduce the complexity for @nhatminhle.

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nhatminhle/cofoja/issues/44#issuecomment-253639274 [2 <text/html; UTF-8 (quoted-printable)>]

[nhatminhle]

Cofoja is now on Maven Central under the org.huoc group ID. Note that the version published there does not bundle ASM, so you will need to include asm-all.jar in the classpath when running either the annotation processor or the agent. The version is 1.3.1, which is 1.3 with some minor changes to the build script in order to generate the POM file from the Ivy settings, as well as javadoc fixes.

[demurgos]

It's great! Here is the direct link.

Could you update the README.md to mention that it is available on Maven Central with your group ID (to disambiguate between the current third parties) ?

[nhatminhle]

I've updated the README :)