| Re: [ee4j-pmc] EE4J parent pom |
Adding a developers section in the subproject pom is not the solution, as it would still merge Lukus into the subproject developers then! So maybe an empty developer section in the parent POM could work? If java.net did not have that, the solution cannot be to add Lukus, but the solution has to be to ask Sonatype how to publish a "real" parent POM. I am pretty sure they will be glad to help the Eclipse Foundation with this issue. Regarding the description, the best practice certainly applies to all subprojects, not to a generic parent POM. I think it is a misunderstanding to apply the best practice to a generic parent POM, as <description> is an inherited element. EE4J's inception was 2017, not 2018. Anyways, the issue is that JAX-RS's inception was 2008 IIRC, it is invalid to inherit the inception of EE4J by default -- no project was incepted AFTER EE4J, all of them existed before. I do not see any benefit of POM coherence among all projects. The EF sees the projects as standalone items. Only some vendors, and possible the PMC, sees the subprojects as bricks of one big product. Most coders I talked to are only interested in one or two projects (like only JAXB, only EclipseLink, only JAX-RS, etc.). I assume that least of the future committers will be working on ALL or at last SOME of these projects. So speaking for non-vendor-committers I do not see any benefit at all of such coherence. This might be hard to believe for "Oracle-grown-ups", but I am currently working on lots of Open Source projects, and never had a problem with the fact that not even two of them share the same set up. To sum up: I see coherence as negative, and it won't outweigh the benefits. I do not see that it makes any sense to release a "1.0" before at least a minority of subprojects actuyll implemented this parent POM (this is what I told you weeks ago with "to bubble up"). Releaseing something just for the sake of getting feedback is a very strange concept I have never seen before in real open source projects. There is a good reason why Sonatype runs a SNAPSHOT repository. It exists exacty for that sole reason. I would be happy if the PMC would accept Maven lifecycle a bit stricter: A project under development goes into SNAPSHOT repo, a thing that is proven to work goes into RELEASE repo. The PMC overhastily pushed something into RELEASE that still is a SNAPSHOT without asking the subproject committers. Please withdraw the 1.0, replace it by 1.1-SNAPSHOT, put it into Sonatype SNAPSHOT and collect reviews from subproject committers BEFORE publishing something that affects us all. Also I would be more happy if the parent POM would accept all subproject committers as committers, too, so *we* develop and agree upon *our* common stuff *ourself*; we do not want some kind of "government" that comes up with a project where only PMC members have write access. This is "top down" government, which is not EF style. While writing it came into my mind that it might simply be the wrong idea to have a parent POM for unrelated projects. Maybe it might be better to publish an importable BOM instead? I assume that this would fix the above problems (but I haven't tried it yet), as IMHO imported BOMs are not inherited. -Markus From: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Dmitry Kornilov (Adding Lukas) Hi Markus, Thanks for your feedback. See my answers inline. On 11 May 2018, at 20:12, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote: Dmitry, first of all, thanks for publishing the parent pom! I think this can become a valueable tool! :-) Second, I have some negative feedback, too. I tried to apply the parent pom to JAX-RS API and it makes more work to integrate it than it provides value. The reason is that this is not a pure parent pom, but it more looks like the head of a multi-module project where it is expected that all modules look and work the same. This is not the case of EE4J. All projects are independent, and so the following issues are: - Lukas is mentioned as a programmer in all projects now and it cannot be overridden by subprojects. This is a no-go as for example at JAX-RS we do not mention ANY developers in the POM, so the result now is that in JAX-RS he is listed as the SOLE programmer. That is a showstopper for using the parent POM at least in JAX-RS. The original version didn’t have developers section. We added it there because we couldn’t close the staging repository. This error was reported: Invalid POM: /org/eclipse/ee4j/project/1.0/project-1.0.pom: Developer information missing I suppose it will happen when you try to deploy your pom as well. The workaround is to add developers section. I must admit that java.net parent pom didn’t have it. If you know a way how to deploy a project to Maven Central bypassing this check, let me know. - The description given in the parent pom is used in all subprojects unless these explicitly overide the <description> that. At JAX-RS we do not have a description, so we either need to add one or at least add an empty <description/> element. That's not nice as it implies work. Nobody wants to have the EE4J description as the default for the subproject. I understand what you mean, but think that it’s a good practice to have description section in your pom. Java.net parent pom we inspired with does have description section. - The inception year is defaulted by 2018 now. This is problematic as this element is used by some maven plugins, e. g. to set the copyright year. JAX-RS does not have this element in its POM, so Maven did not know our inception. Now it is overriden by 2018, which simply is wrong. Hence, this is a source of failure, even with a legal aspect. If JAX-RS adopts the parent pom, we MUST override the inception year now. BTW, I assume ALL existing projects MUST do that, so what is this default good for at all? EE4J project inception year is 2018, isn’t it? I don’t have an opinion about it. Passing it to Lukas. We can remove it if it’s not needed. I would like to hear other committers opinion. + The sole benefit JAX-RS actually found is that we get rid of our own <licences> and <organization> elements (just a few lines actually), and the preconfigured Sonatype repos. To sum up: I do not see that the benefit outweighs the drawbacks from the view of the JAX-RS API project. Nevertheless, it is not my decision, so I will open a PR tomorrow and let the contributors vote. Sorry to hear that. Just wondering, if you add consistency between all EE4J projects to the positive side, will it overweight your drawbacks?
There were PRs and even some discussions (not much really) around it. See here: https://github.com/eclipse-ee4j/ee4j/pulls?q=is%3Apr+is%3Aclosed I am not pretending that this is a final-final version. We released it to get feedback from EE4J projects like JAX-RS. We will collect improvement requests and deploy a new version if needed. Cheers, Dmitry
|