|
Wayne,
Just curious (this is by no means urgent): Can you expand on the
weights you refer to for the Specifications? Other than Web and
Full profile specifications -- is this list going to be dynamic in
some way?
-- Ed
On 9/9/2019 2:26 PM, Wayne Beaton
wrote:
I've updated all of the ballot information. I've
also removed the .project file.
I decided to add weights to the entries for the Jakarta EE
Platform and Web Profiles so that they are positioned at the
top of the list.
All pending release reviews have been resolved.
The web dev team has a job scheduled to publish the website
with the specification content at 1am EDT.
From an Eclipse Foundation process point of view, I believe
that we're good-to-go.
I will be on standby if any issues come up.
Wayne
According to the webdev team, there was a file in the
./pages directory that was poorly formed that blew up the
preview for everybody (that seems like an unfortunate side
effect that we should ask the webdev team to investigate).
Specifically, specifications/faces/2.3/jsdoc/jsf.html#.ajax,
made the deployment script throw a fit.
I'm confident that the file is not actually used (I'm
pretty sure that a browser would interpret everything
after hash as an answer and would never actually ask for
the file) and so I removed the file. I've tested on the
staging site and it seems to work now.
Note that somebody included an Eclipse IDE ".project"
file in a commit. I'll remove it (and do some general
clean up) when we're done with everything else.
At this point, I have posted ballot results for all but
three specifications:
- Jakarta Enterprise Beans
- Jakarta Interceptors
- Jakarta Management
I'm standing by.
Wayne
I'm seeing
a few
automated PR checks that are "failing" with our
pre-deployment
steps... Maybe these are a known condition. You can
see some
of the check fails via this PR:
https://github.com/jakartaee/specifications/pull/19
I
discovered that
the _index.md file had an incorrect TCK link, so I
corrected it before
attempting to merge. I've done a similar change for the
platform,
web profile, and this managed beans PR. When I update
my pending
branch with these minor updates, I am getting the
messages as logged in
PR #19. I am waiting for Bill to approve his review
comments before
merging this one. The other PRs with these type of
messages, I just
went ahead and merged them.
I
trust these
are related to our staging processing and shouldn't be
too concerned with
the messages? That is, we should go ahead with our
merges? Thanks.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx
Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From:
Bill
Shannon <bill.shannon@xxxxxxxxxx>
To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>,
Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Date:
09/06/2019
09:53 PM
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Going backwards with the
content on https://jakarta.ee/specifications/?
Sent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Wayne Beaton wrote on
9/5/19 7:46
PM:
> Note that I noticed that the breadcrumbs are
rendered with absolute
URLs;
> clicking on an entry will take you to the
production site.
Ya, I was tripped up by that. Is that fixable?
> FWIW, the production site is operating as
designed and as I described.
That
> some of the specifications were rendering was due
to the value in
the date
> field being in the past. When I changed them to
September 10/2019,
they were
> removed on the next deployment. I believe that
there was some consensus
that
> we wanted to keep information about
specifications off the production
site
> until after they were released. Based on this
experience, we may want
to
> change this.
I don't see any problem with putting them on the
public web site after
they've
actually been approved, even if it's in advance of the
platform release
containing them.
> I envision that that the metadata at the top of
each of the specification
> files will be valuable (and possibly expanded at
one point); we might,
for
> example, generate some kind of data file out of
these files. So, having
a real
> date of release here feels like something we want
to have. Hugo actually
uses
> the "date" (and "publishDate") fields. We could
instead create our own
> "releaseDate" field and either put a different
value in
the date field, or
> just remove the date from the header and render
additions as they
come
> (regardless of release date).
>
> I'm thinking that this may be a topic for our
retrospective.
>
Agreed.
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
![]()
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
![]()
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
