[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ee4j-pmc] EE4J parent pom
|
Hi,
short answer as given by google to at least half of questions:
http://central.sonatype.org/pages/requirements.html
longer answer is inline
On 5/11/18 8:51 PM, Dmitry Kornilov wrote:
(Adding Lukas)
Hi Markus,
Thanks for your feedback. See my answers inline.
On 11 May 2018, at 20:12, Markus KARG <markus@xxxxxxxxxxxxxxx
<mailto: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.
It is actually not a workaround but the requirement. Since OSSRH is used
for deployments to Maven Central by eclipse fnd, Sonatype's rules MUST
be followed:
developer section is mandatory. Alternative approach - setup own mirror
for deployment to Maven Central and use that, find someone else offering
deployments to Maven Central for free or ask Sonatype to remove this
enforcement.
I personally think that community and/or some list should be mentioned
here in case of the parent pom, not me.
Possibility of not having developers section in the pom for JAX-RS
project is a showstopper for using OSSRH for deployments to Maven Central.
I must admit that java.net <http://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 <http://Java.net> parent pom
we inspired with does have description section.
description section is mandatory. Alternative approach - setup own
mirror for deployment to Maven Central and use that, find someone else
offering deployments to Maven Central for free or ask Sonatype to remove
this enforcement.
so in short - if JAX-RS wants to use OSSRH for deployment to Maven
Central then it MUST have description section (= read as "some work may
be needed") else JAX-RS MUST find different way for deployments to Maven
Central.
- 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.
This one is not mandatory. On the other hand majority (if not all)
projects I've had a chance to work on/commit to (not only those APIs/RIs
under JavaEE/JakartaEE) in the past have had inception year in its pom
and I do consider having this as a good habit. I understand that it
takes time to add it and when it is missing it is really low-low-low
priority "bug", so it is probably not even worth to file an issue for
this but from my personal point of view this is exactly one of those
little things where creating and submitting a PR for adding this takes
much less time than arguing why (not) to add it with typical outcome of
few mins of work vs. hours of discussions
+ 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.
Keep in mind that from my point of view it can be possibly accepted if
and only if it follows http://central.sonatype.org/pages/requirements.html
thanks,
--lukas
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).
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
<https://github.com/eclipse-ee4j/ee4j/pulls?q=is:pr+is:closed>
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
*From:*ee4j-pmc-bounces@xxxxxxxxxxx
<mailto:ee4j-pmc-bounces@xxxxxxxxxxx>
[mailto:ee4j-pmc-bounces@xxxxxxxxxxx]*On Behalf Of*Dmitry Kornilov
*Sent:*Freitag, 11. Mai 2018 14:40
*To:*EE4J PMC Discussions
*Subject:*[ee4j-pmc] EE4J parent pom
Hi,
We managed to deploy the first version of EE4J parent pom. See here:
http://search.maven.org/#search%7Cga%7C1%7Corg.eclipse.ee4j
<http://search.maven.org/#search|ga|1|org.eclipse.ee4j>
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.
Thanks,
Dmitry
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx <mailto:ee4j-pmc@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-pmc
