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