Thanks to those of you who could join the discussion
about the project template that Jonathan Gallimore, put
together. I'm hopeful that we can roll this out to most,
if not all the Jakarta EE projects and repositories.
I'll let him provide coordinates of his work, but the
consensus seemed to be quite complimentary!
Jonathan is planning to provide some detailed
instructions shortly. As usual, we also brainstormed a bit
-- for one thing, the "index" page to all projects and
repositories will be quite challenging. If you look at the
current Java EE "index"
page, you'll note that there's nothing but project
names -- and the list is still pretty imposing. So, we
discussed various ways we could filter, or organize the
breadth of these projects.
In the meeting, I agreed to provide the web-site analysis
that we've done.
A couple of points to make first:
Web-sites have not been routinely staffed and have not
been consistently kept current. The analysis I provide
shows what is currently available from the Java EE github
organization projects (github.com/javaee).
In general most (but not all) web-sites are under: javaee.github.io/<repository>.
However some projects are exceptions: Jersey, JAX-RS, and
Mojarra (JavaServer Faces) for example. To complicate
things, we still have archives of sites which have not yet
been re-published after Java.net was shut down. These site
materials can be considered for contribution to Eclipse,
if there is interest.
In addition, some projects had pure boiler-plate
templates applied to them. We may be able to provide
additional data from our legacy archives, but we have been
focusing our efforts on migrating the code and getting the
artifacts built and published first.
Here is the Google Sheet that we have been using: Proposed Eclipse
Subprojects.
Some of you will have seen this Google Sheet before. I
have added two new columns: "Java EE GH Page?" (Col H) and
"GH Page Source From?" (Col I). The first indicates if
there is a GitHub page for this repository (if there is,
if there is useful data may also be noted). The second
indicates where the page source is located. In most cases,
this is in a GH Pages branch, but not always. I would
propose that we not bother trying to migrate any pages
that are simply the original boiler plate (I've noted: no
useful content). In some cases, it is debatable if the
content is worth moving. But in all cases, we can
contribute the content if it is of use.
No doubt, we will continue the discussion about
organization and affinity for projects and project
repositories for quite some time.
I would propose that the first set of Metadata include:
- Eclipse Project Name
- Repository Name
- Implementation (Y/N)
- API (Y/N)
- Tool/Utility (Y/N)
- Ancillary/Extra (Y/N)
- Documentation/Example (Y/N)
- Platform: [Enterprise|Web]
Perhaps much of the items I list here could be handled
with a more free-form "tags" field. Ideally, there'd be
some automation for collecting things like version data
and Jakarta version details but maybe that's for later.
The less manually entered data, the less likely it will
become stale.
I'm sure others will have better ideas about metadata so
please feel free to make recommendations.
I handed the recording of the meeting over to Tanja, to
post on YouTube. Either she, or I will provide the link,
once that's available.
Cheers,
-- Ed
Meeting details:
Organizer: Ed J Bratt
----------------------
Jakarta EE Project Template
Jonathan Gallimore will review progress with Jakarta EE
project template proposal. Operational characteristics and
take suggestions.
Discuss
1 - Operational status
2 - How to use
3 - Any work in progress
4 - Any further work
