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

Maven Central Request Created #31

Open
xsalefter opened this issue Jun 11, 2016 · 24 comments
Open

Maven Central Request Created #31

xsalefter opened this issue Jun 11, 2016 · 24 comments
Assignees

Comments

@xsalefter
Copy link
Contributor

Hi @pietercvdm ,

This is me again, after years, create new request (again) for work on maven central (sorry..). I will handle this, but I think sonatype need some clarification in a 2-3 business days, and I need your answers. For your information, issue for this work has been raised here:
https://issues.sonatype.org/browse/OSSRH-22999

If you have any concern or disagree with this work, please let me know.

Thanks.

@pietercvdm
Copy link
Collaborator

Hi @xsalefter.

I don't have any issues but @flotho is doing most of the development these days and need to confirm with him.

@flotho, any thoughts?

@gjvoosten
Copy link
Contributor

Would it be possible to revive this? I'm working on getting an up-to-date Odoo plugin in Pentaho Data Integration (a.k.a. Kettle) as the current OpenERP plugin is ancient and doesn't work with recent Odoo versions (the existing kettle-openerp-plugin uses v1.3.0 of openerp-java-api).

The odoo-java-api-2.0.1.jar built from the current master works with my experimental kettle-odoo-plugin and Odoo 10, so it would be nice if this (or at least: a recent enough) version were published on Maven Central etc.

@xsalefter
Copy link
Contributor Author

@gjvoosten The bottleneck is that neither you or me have an approval access to use com.debortoliwines in sonatype. One of developer from debortoliwines.com need to explicitly stated that they got approval to use that domain as maven's group id.

But there's another alternatives: You clone the project and use common public domain as group id, for example: com.github.gjvoosten or io.github.gjvoosten. But merging to the latest changes would be need extra work.

@gjvoosten
Copy link
Contributor

@xsalefter The question is less urgent, as per http://jira.pentaho.com/browse/PDI-16129 I am now building a Pentaho Marketplace plugin. For that I still need odoo-java-api-2.0.1.jar but to that end I have just cloned your repo, do a local build and install the artifact in our local Maven repo. So my plugin build can depend on it and find it through Maven.

[By the way, I see that the original kettle-openerp-plugin that is still part of PDI claims the copyright:
Copyright 2011 De Bortoli Wines Pty Limited (Australia)
and is licensed under LGPL v3. Since the new plugin is mainly an adaptation of that code, I will retain the copyright and the license.]

@flotho
Copy link
Collaborator

flotho commented Mar 23, 2017

Good morning everyone,
I really appreciate your follow up on this point. I'm not so experienced on Maven validation process so any help on this would be appreciated.
My thought would also be to rename all the classpath into something more generic as com.odoo-java.xxx as example.
Of course the orignal mention and the repo name don't need to change
@gjvoosten great news for your work, I also imagine some enhancement that could be helpful in PDI process : https://github.com/DeBortoliWines/openerp-java-api/issues?q=is%3Aissue+is%3Aopen+label%3Aenhancement

@xsalefter
Copy link
Contributor Author

Hi @flotho , thanks for your reply. The problem with group-id is, you can't use random/generic group-id name for public repositories. And best practice would recommend the same recommendation as well. (I applied years ago for personal open source project with group id com.xsalefter. They rejected my application because I don't own xsalefter.com domain). See the guide here . And here's general info docs to publishing artifact in maven repository.

Even if we own odoo-java.com, I'm not sure that sonatype will approve the application because, in my opinion, we need to change top packages name from com.debortoliwines to com.odoo-java.

So, because we don't want to change actual packages name com.debortoliwines for current and future releases, what we really need is approval from you (or your company that own debortoliwines.com domain name) that we could use com.debortoliwines as group-id for repository coordinates.

Personally, I don't think that the approval need to be in formal fashion. Just to make sure that you or your company agree to use it. github.com, for example, not explicitly saying the their sub-domain allowed to use as coordinates, but as once we create a project page using the name from github subdomain/project name, sonatype will be happy with that.

Once agreed with the coordinates naming, I will help with the process as far as I can. Hope that helps.

@gjvoosten
Copy link
Contributor

To be fair: since nothing later than openerp-java-api-1.3.0.jar has ever been published, you can get away with a package rename, provided you change the major version number (which you have already done: 1 => 2) and provide some simple upgrade instructions (basically: rename your imports).

@flotho
Copy link
Collaborator

flotho commented Mar 23, 2017

Hi @pietercvdm , as you are owning the domain could you here precise your approval?
From my side, all my contributions on this repository could be used to be pushed on Maven central.
Conditionnally to the approval of @pietercvdm for the use of his domain, you have my approval for starting the process.
Anyway, thanks for your buzz, actually I feel sometime a little alone in the middle of nowhere on this project as if nobody was using it.

@xsalefter
Copy link
Contributor Author

Anyway, thanks for your buzz, actually I feel sometime a little alone in the middle of nowhere on this project as if nobody was using it.

I was using this library for more than 2 years. And I believe that my previous client still using it. You're not alone.. :)

@pietercvdm
Copy link
Collaborator

Hi Guys.

De Bortoli Wines (DBW) developed this API with the hope that it will be useful and it seems like indeed it has! Unfortunately Odoo never took off at DBW and it isn't in use in any part of the company. DBW has no incentive to perform any development on the API or related components. I developed the initial software and I have moved on to another company in the mean time as well that also have no use for Odoo.

I have spoken to the IT Manager at De Bortoli Wines and he is happy if you want to rename the application to not use the debortoliwines.com domain while still adhering to the licencing requirements in the code (LGPL I think, did I ever move it to apache?).

As to what domain to move it to, I'm not sure. I approached @flotho to take over the repo since they were the most active users at the time when DBW stopped using / developing the API.

All the best.

Kind Regards,
Pieter

@gjvoosten
Copy link
Contributor

The license of openerp-java-api is Apache2; it was changed from LGPL in this commit:
`
commit 87fa7c9
Author: Pieter van der Merwe [email protected]
Date: Sun Dec 7 13:40:43 2014 +1100

Changed License to Apache V2

`

(Note: the license of the OpenERP plugin of Kettle/Pentaho (which uses openerp-java-api) is LGPLv3.)

@flotho
Copy link
Collaborator

flotho commented Jul 18, 2017

Hi @gjvoosten , @xsalefter

Couls you tell me if eerything is Ok, or do we still need some changes to propose this repo to maven central ?

@xsalefter
Copy link
Contributor Author

Hi @flotho See statement that

.... he is happy if you want to rename the application to not use the debortoliwines.com domain ....

What I got from that statement is that, we better to move on to other domain if we want to publish to maven central, since the name of @pietercvdm company will be publishing in maven central.

The problem with another domain is that, this would lead to incompatibility for current application. I'm not sure what the best approach for this, not who will affected by this changes, but eventually in the end, someone need to move this to other domain / change group-id strategy.

@gjvoosten
Copy link
Contributor

The problem with another domain is that, this would lead to incompatibility for current application. I'm not sure what the best approach for this, not who will affected by this changes, but eventually in the end, someone need to move this to other domain / change group-id strategy.

As I wrote above:

To be fair: since nothing later than openerp-java-api-1.3.0.jar has ever been published, you can get away with a package rename, provided you change the major version number (which you have already done: 1 => 2) and provide some simple upgrade instructions (basically: rename your imports).

@flotho
Copy link
Collaborator

flotho commented Aug 16, 2017

@gjvoosten , @xsalefter ,

Ok, so I'll gonna refactor all the code.
com.odoo-java. seems to be a good idea, does the domain need to exist on the web?
regards

@flotho
Copy link
Collaborator

flotho commented Aug 16, 2017

@gjvoosten
What is your recommendation regarding the licence?

@gjvoosten
Copy link
Contributor

@flotho I believe Sonatype requires that you actually control the domain: http://central.sonatype.org/pages/choosing-your-coordinates.html
Regarding licensing, I have no strong beliefs; Apache v2, LGPL v3, MIT, pick one… Some guidance is available at http://wiki.civiccommons.org/Choosing_a_License/

@flotho
Copy link
Collaborator

flotho commented Aug 19, 2017

Hi @pietercvdm ,
regading this Maven process, do you mind if I fork under an organisation odoo-java? I've bought the domain. Your repo will be kept as the original source and your licence as well. Yet I propose that no more job will be proposed on this repo
It will be easier for me to add some wiki, and all the stuff that could be done as a github repo admin.

@gjvoosten
Copy link
Contributor

@flotho (and possibly @xsalefter),
With the deprecation of the old OpenERP plugin in Pentaho 8.2 (and its eventual removal at some point in the future), we should probably pick this up. The way to go on GitHub would be to start a fork under a different GitHub account, archive this (the original) repository, and start moving/renaming things to the new domain in the (then) new master repo.
We should then try to publish a release on Sonatype, at which point I'll most likely update the PDI Odoo Plugin to start using this new library (and push the updated version to the Pentaho Marketplace).
What do you think?

@flotho
Copy link
Collaborator

flotho commented Jan 26, 2019

Hi @gjvoosten ,

I'm totally fan of your proposal. Moreover, we already have an initiative to upgrade the connector with a partner and are about to add more functions.
By the way, I'd already had a new repo here https://github.com/odoo-java already prepared for this.
I'm going to change all of this soon.

regards

@fhossfel
Copy link

fhossfel commented Apr 8, 2019

Hi!
I would like to see the Odoo PDI Plugin being opensourced. This depends omn the odoo-java-api being publicly available. So could you move the code to that repo? That would be great!

Thanks!

Felix

@flotho
Copy link
Collaborator

flotho commented May 1, 2019

hi folks,
I'd love to share and opensource everything.
My idea was to put everything on the repo https://github.com/odoo-java
is it a good way to work ?
additionnaly we need a refactor to change the xmlrpc library that was declared as insecure and maybe the integartion process of PDI won't accept anymore such tool.
BTW, we really love the PDI plugins too !

@fhossfel
Copy link

fhossfel commented May 1, 2019

Hi!
I would appreciate if you could publish this and I can contribute to it. IMHO it is most Important to get started and then get the whole stuff into an official Maven repo/Pentaho market place.

Best regards

Felix

@flotho
Copy link
Collaborator

flotho commented Jun 4, 2019

Hi @fhossfel ,

I forked the repo : https://github.com/odoo-java/odoo-java-api
Is it what you were expecting, did I do well ?

regards

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

No branches or pull requests

5 participants