No one doubted that. :-) -Markus From: Ivar Grimstad [mailto:ivar.grimstad@xxxxxxxxx]
Sent: Sonntag, 13. Mai 2018 18:27
To: EE4J PMC Discussions
Cc: Markus KARG
Subject: Re: [ee4j-pmc] EE4J parent pom Hi all, As Lukas points out, the parent pom has been created in cooperation with the PMC. - It is not mandatory for any EE4J project to use this parent pom. - We welcome any suggestions to improvements! On 5/13/18 3:05 PM, Markus KARG wrote:
> Lukas,
>
> [..]
> No, I do not want to be the one that checks all POMs of all subprojects.
> And no, I do not want to "delegate" that to anybody. What I want is a
> bottom-up process:
first mention about possible need of parent I've noticed was on April 9
on the ee4j-community@xxxxxxxxxxx list
The parent POM is empty mostly
+ it must follow existing requirements enforced by ossrh which is
recommended to be used (otherwise it cannot be deployed to maven central
using existing infra)
and all subproject
> committers can open PRs to propose additions.
everyone can fork https://github.com/eclipse-ee4j/ee4j repo and propose
whatever (s)he wants/needs, or file an issue, or ...
Then the PMC will review
> and vote +1 or -1.
PMC reviewed and approved https://github.com/eclipse-ee4j/ee4j/pull/13
which I believe is publicly available and visible to everyone
in the end, after >4 weeks, there is initial version which is as minimal
as possible given "restrictions" in place. No other proposals nor
changes were submitted by anyone during last ~4 weeks.
By the time, this fills the parent POM and reduces
> the clutter in the subproject POMs. I do not see a different way as in
> the EF all subprojects are sovereign and the committers are in charge. I
> also do not see why this shall slow down things. We could be done in
> two weeks if we ask all committers now and have a voting period of few
> days. Compared to Java EE's past this would be really fast. Nobody
> expects us to be done on Monday.
cycle for the next version had started already...
-anyone can propose PR, file an issue etc
-anyone can work on adding/removing stuff once changes on the infra
sides of things are done
-PMC can review and accept/reject PRs
-once everyone is satisfied, new version can be released (someone may
suggest the version to be changed to 2 as "no one would want to buy
version 1"[1])
meanwhile existing initial version can be used to replace existing jvnet
parent and make preparing initial release easier.
>
> Yes, I want to work on that, and yes, I want to speed up things, (and
> yes, just like you, I do work on Sunday in my sparetime exactly on that
> issue right now)
should I really be pedantic then I'd say that for you it's Sunday, for
me it's the middle of vacation and it's sad to hear it's Sunday already.
Anyway, for both of us it's time we invest to (hopefully) improve things ;-)
thanks,
--lukas
[1]:
http://www.businessinsider.com/the-cia-made-larry-ellison-a-billionaire-2014-9?international=true&r=US&IR=T
but that does not imply that I want to hastily rush
> into publishing something that is "EE4J official" what was not discussed
> upfront with the active commiters of the affected subprojects. I am fine
> if I shall be the one that talks to these people. No problem. So I will
> do that. I just wondered if the PMC will do that, as it is the PMC's job
> to keep contact with all subprojects, and I wanted to wait for the PMC
> lead's comments before I chime in.
>
> -Markus
>
> *From:*LUKAS.JUNGMANN@xxxxxxxxxx [mailto:LUKAS.JUNGMANN@xxxxxxxxxx]
> *Sent:* Sonntag, 13. Mai 2018 14:45
> *To:* Markus KARG; 'EE4J PMC Discussions'
> *Cc:* 'Dmitry Kornilov'
> *Subject:* RE: [ee4j-pmc] EE4J parent pom
>
> Markus, the sense is in that those "affected" projects may have
> something in common and it may be perhaps possible to fix while we're at
> it. I understand you don't want to identify that and prefer to delegate
> this task to someone else, like all project committers. Who do you think
> should represent those most active committers in projects being donated
> in the next round where the pom usage should be "tested" as Dmitry wrote
> earlier? I remember who was eager to start working on donated code and
> wanted to speed up donation process at all cost. Isn't that against what
> you're suggesting now?
>
> Thanks,
>
> --lukas
>
> Odesláno z mého chytrého telefonu Samsung Galaxy.
>
> -------- Původní zpráva --------
>
> Od: Markus KARG <markus@xxxxxxxxxxxxxxx <mailto:markus@xxxxxxxxxxxxxxx>>
>
> Datum: 13.05.18 14:06 (GMT+01:00)
>
> Komu: LUKAS.JUNGMANN@xxxxxxxxxx <mailto:LUKAS.JUNGMANN@xxxxxxxxxx>,
> 'EE4J PMC Discussions' <ee4j-pmc@xxxxxxxxxxx <mailto:ee4j-pmc@xxxxxxxxxxx>>
>
> Cc: 'Dmitry Kornilov' <dmitry.kornilov@xxxxxxxxxx
> <mailto:dmitry.kornilov@xxxxxxxxxx>>
>
> Předmět: RE: [ee4j-pmc] EE4J parent pom
>
> Lukas,
>
> I do not see a sense in this argue at all, as the final answer can only
> be to ask the most active committers of all projects, which is just what
> I proposed right from the start. For your projects it does work, for
> JAX-RS it does not. Let's see what other projects do.
>
> -Markus
>
> *From:*LUKAS.JUNGMANN@xxxxxxxxxx <mailto:LUKAS.JUNGMANN@xxxxxxxxxx>
> [mailto:LUKAS.JUNGMANN@xxxxxxxxxx]
> *Sent:* Sonntag, 13. Mai 2018 12:45
> *To:* Markus KARG; 'EE4J PMC Discussions'
> *Cc:* 'Dmitry Kornilov'
> *Subject:* RE: [ee4j-pmc] EE4J parent pom
>
> Markus, can you define "most projects" you are refering to? I have
> roughly 15-20 projects in hands which can benefit from moving from jvnet
> parent to the proposed one. I see no problem of giving credits to the
> developer of the parent in the downstream projects. Majority of these
> projects do have all mandatory elements present.
>
> It's also worth to mention that using parent is proposed to be
> recommended, not required.
>
> Thanks,
>
> --lukas
>
> Odesláno z mého chytrého telefonu Samsung Galaxy.
>
> -------- Původní zpráva --------
>
> Od: Markus KARG <markus@xxxxxxxxxxxxxxx <mailto:markus@xxxxxxxxxxxxxxx>>
>
> Datum: 12.05.18 18:21 (GMT+01:00)
>
> Komu: LUKAS.JUNGMANN@xxxxxxxxxx <mailto:LUKAS.JUNGMANN@xxxxxxxxxx>,
> 'EE4J PMC Discussions' <ee4j-pmc@xxxxxxxxxxx <mailto:ee4j-pmc@xxxxxxxxxxx>>
>
> Cc: 'Dmitry Kornilov' <dmitry.kornilov@xxxxxxxxxx
> <mailto:dmitry.kornilov@xxxxxxxxxx>>
>
> Předmět: RE: [ee4j-pmc] EE4J parent pom
>
> Lukas,
>
> I don't know why you think you need to tell me that. You know that I am
> an active committer of JAX-RS API, and I think it is clear to all
> reading this that I am willing to help in developing a working solution.
> In fact, I will ask Sonatype and talk to the EF admins regarding this
> topic. Yes, I will go ahead, and yes, I will propose a solution. But I
> want us to slow down a bit and find the best solution first instead of
> rushing into a solution not working for most projects. Believe me, I am
> an open source guy since decades, so I know that nothing comes from
> nothing and I am really not asking anybody to do my own work. I just am
> asking for working together publicly instead of acting behind the scenes
> before asking.
>
> -Markus
>
> *From:*LUKAS.JUNGMANN@xxxxxxxxxx <mailto:LUKAS.JUNGMANN@xxxxxxxxxx>
> [mailto:LUKAS.JUNGMANN@xxxxxxxxxx]
> *Sent:* Samstag, 12. Mai 2018 12:59
> *To:* Markus KARG; 'EE4J PMC Discussions'
> *Cc:* 'Dmitry Kornilov'
> *Subject:* RE: [ee4j-pmc] EE4J parent pom
>
> Markus,
>
> If something needs to be done, then just go ahead, do it and present
> the solution. If some question needs to be answered, then ask and
> present the answer. Speculating that someone may do something is not a
> solution nor answer to the problem nor is, in some cases, asking others
> to ask on someone's behalf. It's just waste of time in most cases, IMHO.
> All I wanted to say was that there are rules in place which has to be
> followed and if jakartaee project wants to _currently_ deploy to maven
> central through ossrh then it _must_ follow those rules. Or as an
> alternative to find the way to relax and/or get around current
> constraints. And that implies some real work for someone. It is just the
> matter of finding the one getting the old maid. Who will that be ? EF?
> Sonatype? Non-conforming ee project committer? The last is the place
> where the change usually takes less time and is under our direct
> control. Everything else requires involvement of other people/companies
> and usually takes more time. I'm saying nothing about what should or
> should not be done.
>
> BTW: No, I'm not willing to propose anything to JAX-RS API project
> anytime soon nor discuss anything there. There exist only 2 persons who
> can change that, one of them being myself
>
> Thanks,
>
> --lukas
>
> Odesláno z mého chytrého telefonu Samsung Galaxy.
>
> -------- Původní zpráva --------
>
> Od: Markus KARG <markus@xxxxxxxxxxxxxxx <mailto:markus@xxxxxxxxxxxxxxx>>
>
> Datum: 12.05.18 11:47 (GMT+01:00)
>
> Komu: 'EE4J PMC Discussions' <ee4j-pmc@xxxxxxxxxxx
> <mailto:ee4j-pmc@xxxxxxxxxxx>>
>
> Cc: 'Lukas Jungmann' <lukas.jungmann@xxxxxxxxxx
> <mailto:lukas.jungmann@xxxxxxxxxx>>, 'Dmitry Kornilov'
> <dmitry.kornilov@xxxxxxxxxx <mailto:dmitry.kornilov@xxxxxxxxxx>>
>
> Předmět: RE: [ee4j-pmc] EE4J parent pom
>
> Lukas,
>
> remember that we are the Eclipse Foundation:
>
> * Possibly Sonatype is willing to reduce some restrictions for the EF.
> At least asking them is free.
>
> * At EF have our own infrastructure running, so we could set up a
> service to push into Maven Central with less restrictions. The EF
> webmaster could answer this.
>
> * Whether or not a service utilized by the EF has to be FREE is up to
> the EF to decide. We should not assume that EE4J has a budget of zero
> Dollars.
>
> These options have to be discussed by the EF, not by the PMC, not Oracle
> internally. The decision whether we (the EF) do that, is up to the EF.
>
> BTW, what JAX-RS MUST do or not will be decided solely by the JAX-RS
> committers. So THIS mailing list is the wrong place to discuss what
> JAX-RS MUST or COULD or SHOULD do. I understand your answers as
> proposals, but they are better addressed in the JAX-RS developers
> mailing list. Maybe you like to open a PR for that so ALL JAX-RS
> committers and contributors can comment (least of them are subscribed to
> THIS mailing list)?
>
> Besides that, I think the solution is to use a BOM instead of a parent
> POM, but this certainly needs more checks. If I were part of that parent
> POM project I would work on that. Unfortunately I was not invited upfront.
>
> -Markus
>
>
> -----Original Message-----
> From: ee4j-pmc-bounces@xxxxxxxxxxx <mailto:ee4j-pmc-bounces@xxxxxxxxxxx>
> [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Lukas Jungmann
> Sent: Freitag, 11. Mai 2018 22:14
> To: Dmitry Kornilov; EE4J PMC Discussions
> Subject: 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%20%0b>>> <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>
> <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
> >
> _______________________________________________
> 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
>
_______________________________________________
ee4j-pmc mailing list
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
-- Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader |
