(Adding Lukas)
Hi Markus,
Thanks for your feedback. See my answers inline.
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?
My first advice to the PMC would be to immediately step up from 1.0 to 1.1-SNAPSHOT, open a PR for 1.1, and let the project committers discuss the proposal on Github FIRST before publishing a parent POM to Maven Central. My second advice to the PMC would be to get rid of <developers>, <description>, <inceptionYear> and all other non-essential stuff. Start with the absolute minimal information that is really really really the same for all projects and then let the project committers propose additions in the form of POM profiles and / or optional plugins (aka dependencyManagement).
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
We will try to use it in some projects. When it works smoothly I’ll write a wiki page with instructions and PMC should oficially recommend it to use in all EE4J projects.
|
