| Re: [jakartaee-platform-dev] : Re: : Re: Pushing RCx or Mx to maven central |
> It has way more drawbacks than advantages, as explained, for end users and it is not officially validated artifacts for Jakarta/Eclipse so it must not hit central.Also note that it has *no* real drawback for vendors so all good for everyone.I disagree. Everyone understands (or should) that release candidate(RC)/milestone(M) artifacts in maven central are not final. That is, after all, the point of the RC/M version qualifier. You are arguing that no non-final artifacts should ever be in maven central but this is done all the time for valid reasons. The "end user" here is any party that needs to use the artifact. There is no meaningful distinction between an implementation of a Jakarta EE API or code otherwise using a Jakarta EE API.
> The right approach if open liberty wants to do a version of not existing spec (it is literally what is requested there) is to release their own spec jars to materialize a snapshot of it.This is overly burdensome since it require all parties to replicate the behavior when it is much better if Jakarta itself publishes the actual artifacts to a non-ephemeral repository. I also do not thing we want to encourage multiple parties to publish RC/M artifacts to non-ephemeral repositories when Jakarta itself should be the publishing authority.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx----- Original message -----
From: "Romain Manni-Bucau" <rmannibucau@xxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] : Re: : Re: Pushing RCx or Mx to maven central
Date: Fri, Jan 14, 2022 12:34
Hi Emily,tried to comment inline.Le ven. 14 janv. 2022 à 17:36, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :I am really confused with the conversation. Some comments indicate: we prefer to push the artifacts to staging, just use staging repo and it works. It was also mentioned that these artifacts could be deleted after a period of time. I have not grasped the reason why it is not possible/good to push to maven central.It has way more drawbacks than advantages, as explained, for end users and it is not officially validated artifacts for Jakarta/Eclipse so it must not hit central.Also note that it has *no* real drawback for vendors so all good for everyone.As explained by Nathan and Tom, this approach does create a risk and inconsistency by implementations picking up such artifacts. For instance, Open Liberty created an implementation for batch API 3.0-RC1 and then released this driver. Later on, in the Jakarta staging repo 3.0-RC1 was removed and there is no trace of it. This leaves Open Liberty beta in an awkward situation with such a 3.0-RC1 that does not exist anywhere. Worse case scenario: Batch 3.0-RC1 was deleted from the staging and then replaced by a different one still named as 3.0-RC1. This creates another confusing situation.The right approach if open liberty wants to do a version of not existing spec (it is literally what is requested there) is to release their own spec jars to materialize a snapshot of it.That said, as mentionned by multiple people, it will create an OL release of a not existing platform since spec jars are not in final version anyway so great careness must be taken if given to end users and it is used for more than just internal testing - where staging is more than sufficient and the staging drop is not an issue.I would add that it is even more accurate for OL to do that since it already patches all spec jars to add OSGi metadata so it must be done anyway by OL so a release on central is not sufficient by itself.Pusing RCx, Mx to maven central makes the adoption a lot easier! What stops us from pushing these artifacts to maven central?This is not really true, it makes the reject way easier as explained since you promote things which will never be and all the build toolings will start seeing not existing stuff.The issues are really:* correctly communicate the Jakarta API publicly and not expose working (as people are workin on) versions (snapshots in terms of design)* ensure the release work is the planned one* avoid some tooling to propose a dependency upgrade - or automatically upgrade - on an incompatible/(future) broken version (don't forget that central must be seen as immutable so once leaked you can just cry or call sonatype)Hope it helpsThoughts?EmilyOn Fri, Jan 14, 2022 at 2:07 PM Thomas Watson <tjwatson@xxxxxxxxxx> wrote:The alternative, as others have stated, is that implementations must pull in the API content into their own build. Projects wanting to maintain repeatable builds of stuff they publish to permanent locations will be responsible for keeping the jakarta APIs in a stable place so they can repeatedly build the released content for years down the road. This is how the Eclipse Equinox project has operated with respect to the OSGi APIs for years, although I would rather change that to using RC APIs from maven central in the future when we implement compliant implementations for the specification.Essentially we are going to have to do something like this for Open Liberty to be able to produce compliant implementations because we are unwilling to depend on a staging repository for our repeatable/stable builds of the project.
Tom
----- Original message -----
From: "BJ Hargrave" <hargrave@xxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: jakartaee-platform-dev@xxxxxxxxxxx
Cc:
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] : Re: : Re: Pushing RCx or Mx to maven central
Date: Thu, Jan 13, 2022 4:41 PM
Depending upon an ephemeral repository is not really sufficient for an implementation to themselves publish a candidate compatible implementation.The process as described by Tom Watson was how the OSGi Working Group worked with Apache and Eclipse to have candidate compatible implementations available for OSGi final specification approval. Apache Felix was not going to put RC builds in maven central based upon specification API jars in an ephemeral repository. I certainly would not support that for any open source project producing a spec implementation that I worked on.--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx----- Original message -----
From: "Ivar Grimstad" <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] : Re: : Re: Pushing RCx or Mx to maven central
Date: Thu, Jan 13, 2022 13:22
Hi,We have the Jakarta Staging Repository set up to address the chicken-and-egg situation. Here is how we have done it in the past:1) Spec projects publish final version of the API to Jakarta Staging Repository (this repo has extended timeout for artifacts of 2 months)
2) Implementations build based of the final versions APIs in Jakarta Staging Repository
3) Implementation publishes their RC impl to their location of choice
4) WG submits ballot that points to one or more compatible implementations that pass the final TCK
5) Spec projects releases final APIs from Jakarta Staging Repository to maven central from after ballot is approved
6) Implementation projects build off final APIs and release final implementations at their leisure.The only difference from the steps Thomas wrote is that it can be the final versions that are staged and used as basis for the implementations. The staging repository has extended the timeout to 2 months for this purpose.IvarOn Thu, Jan 13, 2022 at 1:04 PM Nathan Rauh <nathan.rauh@xxxxxxxxxx> wrote:Don't consider anything I have said to be a statement of what the Eclipse processes require or permit. When I said it didn't sound like a legitimate way to determine a compatible implementation, that's only my own opinion of what I think seems to be the right way to go about things independent of what the processes permit. I should have been clear on that, or better yet never have offered that opinion at all. What I said is not intended to be and is not a valid interpretation of the Eclipse process, as pointed out by Mike Milinkovich and others. The real focus here should be on the apparent disconnect in the process that Tom Watson brings up which we don't know how to get past in order to make a final release.
From: "Lukas Jungmann" <lukas.jungmann@xxxxxxxxxx>
To: jakartaee-platform-dev@xxxxxxxxxxx
Date: 01/13/2022 10:53 AM
Subject: Re: [jakartaee-platform-dev] [External] : Re: : Re: Pushing RCx or Mx to maven central
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On 1/13/22 4:35 PM, Nathan Rauh wrote:
> If the purpose of the Release Candidate or Milestone driver is to enable
> the certification of a compatible implementation of the spec so that you
> can release your spec, then the Release Candidate or Milestone driver
> really needs to be available from a permanent location like maven, not a
> temporary staging repo. It isn't acceptable to be telling potential
> compatible implementations to produce alpha or beta releases of their
> own product based upon an artifact from a temporary staging location
> that will disappear.
After reading https://www.eclipse.org/projects/dev_process/#6_4_Releases
what do you suggest so it adheres to it and complies with EFSP?
Given that we are asking these products to provide
> compatible implementations of our specification for our own benefit
> (verifying that our specs are ready for final release), we owe it to
> them to provide Release Candidate or Milestone artifacts that are
> product-ready and product-worthy to be picked up and consumed by their
> users. This includes the artifacts remaining available and not going away.
most projects do not change their RC/M/final builds once they are in
staging, even though it is not guaranteed, and publish them in central
as soon as they can (when their dependencies got necessary approvals and
are made available in central). One should talk to the particular
project if (s)he sees its RC/M/final builds being changed in staging;
usually there is a good reason behind it, such as found test/TCK
failures in final builds etc.
thanks,
--lukas
>
>
>
>
> From: "Tibor Digana" <tibordigana@xxxxxxxxxx>
> To: "jakartaee-platform developer discussions"
> <jakartaee-platform-dev@xxxxxxxxxxx>
> Date: 01/13/2022 06:02 AM
> Subject: Re: [jakartaee-platform-dev] [External] : Re: Pushing RCx or Mx
> to maven central
> Sent by: "jakartaee-platform-dev"
> <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
> ------------------------------------------------------------------------
>
>
>
> The main purpose of Nexus Staging Repo is internal within the
> Jakarta organization and it is mainly testing purposes in the Q/A team,
> and so the staging repo is temporal and has only a time limited life
> cycle. If we make a decision regarding
> The main purpose of Nexus Staging Repo is internal within the
> Jakarta organization and it is mainly testing purposes in the Q/A team,
> and so the staging repo is temporal and has only a time limited life cycle.
> If we make a decision regarding the staging repos, we would have
> problems with the arguments that these repos have been deleted at some time.
> Additionally, the names of staging repos are not general per Spec. They
> are not named like "BVAL". Their name has a postfix number been
> automatically generated by the staging server, e.g.
> BVAL-236289, BVAL-04832662 etc, and the list of staging repos in the
> server would be large and totally messy for the customer in order to
> understand which one should be picked up and which one is related to Git
> commit or Jira ticket.
>
> On Thu, Jan 13, 2022 at 12:31 PM Lukas Jungmann
> <_lukas.jungmann@oracle.com_ <mailto:lukas.jungmann@xxxxxxxxxx>> wrote:
>
> On 1/13/22 12:06 PM, Emily Jiang via jakartaee-platform-dev wrote:
>> Hi Mark,
>> Can you explain why you think the artifacts should not be pushed to
>> maven central? One of the reasons for pushing the artifacts to maven
>> central is to make it easier for others to access the artifacts and then
>> provide feedback. If all of the artifacts are in staging, only the
>> projects under EE4J can access them freely, which creates a barrier for
>> other projects to obtain these artifacts.
>
> Some of these RC/M spec project builds may depend on final builds of
> other spec projects. Final build of the spec project cannot be published
> to maven central (or basically anywhere from where it cannot be
> immediately deleted should the request for it come) with out prior
> approvals from EF (release review process) and spec committee (ballot).
> What is the point of pushing knwown-to-be broken for some undefined
> period of time broken RC/M builds to maven central?
>
>
> Should anyone have a need to use artifacts from the staging repo in his
> project, adding the staging repo to his pom is relatively easy to find
> and simple thing to do.
>
> thanks,
> --lukas
>
>>
>> Thanks
>> Emily
>>
>>
>> On Thu, Jan 13, 2022 at 8:12 AM Mark Thomas <_markt@apache.org_ <mailto:markt@xxxxxxxxxx>
>> <mailto:_markt@apache.org_<mailto:markt@xxxxxxxxxx>>> wrote:
>>
>> For Servlet, Pages, EL, WebSocket: No.
>>
>> Implementations should use the staging repository if they want
>> access to
>> non-final release artifacts.
>>
>> Mark
>>
>>
>> On 12/01/2022 23:12, Emily Jiang via jakartaee-platform-dev wrote:
>> > At the moment, some specs push RCx or Mx to maven central, which is
>> > great so that implementations can easily pick them up and provide
>> > feedback if anything is not working. However, not all specs
>> follow this
>> > approach. Can we get the following specs to push their latest Mx
>> or RCx
>> > to maven central so that implementations can easily consume them?
>> Open
>> > Liberty would like to consume the artifacts as soon as possible
>> so that
>> > we can provide timely feedback if we find any issues.
>> >
>> > * authentication 3.0
>> > * authorization 2.1
>> > * concurrency 3.0
>> > * connectors 2.1
>> > * _expression_ language 5.0
>> > * faces 4.0
>> > * jsonp 2.1
>> > * jsonb 3.0
>> > * jstl 3.0
>> > * messaging 3.1
>> > * pages 3.1
>> > * persistence 3.1
>> > * restfulWS 3.1
>> > * security 3.0
>> > * servlet 6.0
>> > * websocket 2.1
>> >
>> >
>> > Your help is greatly appreciated!
>> > --
>> > Thanks
>> > Emily
>> >
>> >
>> > _______________________________________________
>> > jakartaee-platform-dev mailing list
>> > _jakartaee-platform-dev@eclipse.org_
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
>> <mailto:_jakartaee-platform-dev@eclipse.org_
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
>> > To unsubscribe from this list, visit
>> _https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>> <_https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>>
>> >
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> _jakartaee-platform-dev@eclipse.org_
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
>> <mailto:_jakartaee-platform-dev@eclipse.org_
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
>> To unsubscribe from this list, visit
>> _https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>> <_https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>>
>>
>>
>>
>> --
>> Thanks
>> Emily
>>
>>
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> _jakartaee-platform-dev@eclipse.org_
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
>> To unsubscribe from this list, visit _https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
> _______________________________________________
> jakartaee-platform-dev mailing list_
> __jakartaee-platform-dev@eclipse.org_
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> _https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>_______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev--Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--_______________________________________________Thanks
Emily
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev