[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] : Re: Pushing RCx or Mx to maven central
|
I hope you are not
suggesting that compatible implementations certify on a forked copy of
the API rather than the official Release Candidate or Milestone artifact.
That does not sound like a legitimate certification.From:
"Romain
Manni-Bucau" <rmannibucau@xxxxxxxxx>To:
"jakartaee-platform
developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>Date:
01/13/2022
10:30 AMSubject:
[EXTERNAL]
Re: [jakartaee-platform-dev] : Re: Pushing RCx or Mx to maven centralSent
by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
@Nathan don't think it is a very strong
point since all vendors are used to fork API (for several reasons, one
historical being to handle their own SPI or default provider) and handle
that. Wouldn't it be worrying if a vendor can't release a jar after all?
That said, on user side it is way more impacting to see higher versions
on central which must not be used and there is no such metadata on central
so, IMHO, it is really bad to release alpha/beta/RC on central for the
product.
Romain Manni-Bucau
@rmannibucau| Blog |
Old
Blog | Github |
LinkedIn |
BookLe jeu. 13 janv. 2022 à 16:35,
Nathan Rauh <nathan.rauh@xxxxxxxxxx>
a écrit :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. 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.
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 ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender This message came from
outside your organization.
ZjQcmQRYFpfptBannerEnd
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@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@xxxxxxxxxx
> <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@xxxxxxxxxxx
> <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
> <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>
>
>
>
> --
> 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
_______________________________________________
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