eclipse-ee4j / ee4j Goto Github PK

The EE4J projects will sooner or later have the need to publish SNAPSHOT version.
We need to first figure out what is legally possible
Then get the correct permissions from Sonatype to push.
We will have to wait for Oracle agreement to be in place.
Probably best to do this as a bulk operation rather than every project having to do this on their own.

Ivar will create an action item on GitHub for creating a list of all the group id’s that will be affected. Typically, org.glassfish, javax, net.java etc.

Most of the Wiki pages under https://github.com/eclipse-ee4j/ee4j/wiki say "Moved to Eclipse Wiki", so does a "ghost" Wiki still make sense in this repository, or could it not be disabled?

The PMC has been tasked by the Jakarte EE Steering Committee to propose technical direction for the EE4J projects. We will do this bottom-up by reaching out to the EE4J project leads to get their input. Before doing so, we will create a template and guide to structure the input. This should include information such as top-three priorities, schedule, release plan etc. We will look at the JSR template for inspiration. There must also be set a deadline to respond

While doing some contributions to eclipse-ee4j/krazo, I found that the project doesn't build on Maven 4. This is because its parent, maintained in this repo, declares a few repositories with an URL that is an expression. This is no longer supported in Maven 4:

Apache Maven 4.0.0-alpha-4-SNAPSHOT (fbdf109b34947c5cc64b8d584d0c3010351e613b)
Maven home: /opt/homebrew/Cellar/maven-snapshot/4.0.0-alpha-4-20221231.163631-23/libexec
Java version: 11.0.17, vendor: Eclipse Adoptium, runtime: /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
Default locale: en_NL, platform encoding: UTF-8
OS name: "mac os x", version: "13.1", arch: "aarch64", family: "mac"
[INFO] Scanning for projects...
[ERROR] Some problems were encountered while processing the POMs
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project org.eclipse.krazo:krazo-parent:3.1.0-SNAPSHOT (/Users/maarten/Code/open-source/krazo/pom.xml) has 4 errors
[ERROR]     'profiles.profile[snapshots].repositories.repository.[sonatype-nexus-snapshots].url' contains an expression but should be a constant. @ org.eclipse.ee4j:project:1.0.6, /Users/maarten/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom, line 252, column 26
[ERROR]     'profiles.profile[snapshots].pluginRepositories.pluginRepository.[sonatype-nexus-snapshots].url' contains an expression but should be a constant. @ org.eclipse.ee4j:project:1.0.6, /Users/maarten/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom, line 265, column 26
[ERROR]     'profiles.profile[staging].repositories.repository.[sonatype-nexus-staging].url' contains an expression but should be a constant. @ org.eclipse.ee4j:project:1.0.6, /Users/maarten/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom, line 289, column 26
[ERROR]     'profiles.profile[staging].pluginRepositories.pluginRepository.[sonatype-nexus-staging].url' contains an expression but should be a constant. @ org.eclipse.ee4j:project:1.0.6, /Users/maarten/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom, line 302, column 26
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the '-e' switch
[ERROR] Re-run Maven using the '-X' switch to enable verbose output
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException

Also, the project doesn't declare which version of the Maven Install Plugin it uses - thus making it dependent on the Maven version that the user has. In Maven 4, this will trigger a warning:

[WARNING] Version not locked for default bindings plugins [maven-install-plugin], you should define versions in pluginManagement section of your pom.xml or parent

If desired, I can contribute a PR that resolves these issues.

According to the Eclipse Development Process, in order for a committer election to be considered valid, a demonstration of merit is required. Generally, merit is demonstrated with publicly accessible links to tangible contributions by the nominee to the project in the nomination statement.

Any minimum measure of quantity and quality of those contributions is left to the discretion of the PMC. Having said that, there has to be some minimum that's greater than zero. Basically, we need at least some visible proof that the nominee understands the Eclipse Development Process and is a good fit with the project team. This is part of operating in an open and transparent manner; the demonstration of merit is open for all to see.

We need to setup requirements and decide what sort of minimum bar that we'd like to set for a merit statement.

This should be documented.

Having a separate license file is more convenient for packaging purposes.

Eclipse killed the Sun, today, turns to Oracle.

The community response to the first Phase of this process (#1) was awesome. The process of whittling those names down to a list of names that we could actually use was challenging and time consuming, but we're finally done and ready to get the community to help us with the selection.

The EE4J PMC considered numerous factors, but in the end the selection process effectively boiled down to identifying those names from the suggestions that The Eclipse Foundation can register and hold as a trademark on behalf of the community.

The choices are: "Jakarta EE" and "Enterprise Profile".

To answer the most obvious question... yes, we have consulted with our friends over at Apache, and they're cool with us using Jakarta.

Since we ended up with only two names, the use of a weighted poll is unnecessary, and so we're taking this forward with a simple "pick your favourite of the two" poll.

https://goo.gl/forms/EPJUi6A6Dms5oiXl1

Note that this poll requires that you log in with a Google Account. We have configured the corresponding form to not capture your identity.

If you have any questions regarding the poll, feel free to ask them here or in the ee4j-community mailing list.

It's been a while since 1.0.7 and the updated versions in 1.0.8 are important for projects that wish to compile using JDK 17.

Some further information is in here: https://www.eclipse.org/lists/ee4j-pmc/msg02306.html

While attempting to release the RC1 for the Platform and Web Profile APIs, I have the following warning in the output (this is repeated for everyone of our modules in the jakartaee-api repo):

[WARNING] Some problems were encountered while building the effective model for jakarta.platform:jakarta.jakartaee-bom:pom:9.0.0-RC1
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-enforcer-plugin is missing. @ org.eclipse.ee4j:project:1.0.6, /home/jenkins/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom, line 164, column 29

Looking at the 1.0.6 version of the parent pom, I see that we don't specify a version for the maven-enforcer-plugin:

                     <groupId>org.apache.maven.plugins</groupId>
                     <artifactId>maven-enforcer-plugin</artifactId>

Are users of the the parent pom supposed to specify a version for this plugin? It looks like most everybody follows this practice with the maven-source-plugin and specifies a version in their own pom files. But, I thought one of the reasons of having a parent pom was to define which version is defined for the whole EE4J project -- and if a component needs override the version for some reason, then they can do that.

This isn't stop ship right now. But, we should get this cleaned up to avoid these Warnings in our builds.

Something seems out of whack... We have released version 1.0.6 of the parent pom, but the actual file still has 1.0.6-SNAPSHOT. The code should be at 1.0.7-SNAPSHOT, correct? And, how did we get into this situation in the first place?

Since they kindly donated the name for the vote I think it seems like a reasonable thing to suggest.

http://jakarta.apache.org/

There needs to be a channel for distributing builds of the Jakarta EE TCK. Everyone is forced to build from source at the moment. Eclipse GlassFish is currently building it from source. Apache TomEE community is currently building it from source.

Note this is not a discussion of how the official final TCK build under the TCK license will be distributed. This is simply establishing a distribution mechanism for projects to consume the TCK binaries in daily runs of the TCK to support what will be a several-month process of chasing compliance.

Ideally, it would be something that can be fetched in an automated fashion from a build job.

Eclipse provide a Code of Conduct here: https://www.eclipse.org/org/documents/Community_Code_of_Conduct.php

From my point of view it would make sense to add a CODE_OF_CONDUCT to all repos that contains the Eclipse CoC.

If this is a good idea I can provide the PRs ;)

The EE4J Project Bootstrapping page/chart is no longer particularly useful or interesting. Let's shut it down.

https://www.eclipse.org/ee4j/status.php

The jakarta namespace must not be used for implementation projects. Eclipse standard practices must be followed.

The PMC suggests org.eclipse.* as module names for the EE4J projects.

Please add comments and/or suggestions to this issue.

We should define a fixed structure for the PMC meetings. E.g.

• Use issue tracker for action items
• How to use labels
• Follow up action items in meetings
• Update action items between meetings
• Fixed meeting agenda

The EE4J Top-Level Project Charter states:

Content produced by projects under the Eclipse EE4J Top Level Project is licensed under the Eclipse Public License v2.0, with the Secondary License GPL 2.0 with Classpath Exception.

We should capture why.

Question, why not set the java source and target level in the pom.xml ?

Hello!
I would like to know if all specs (JPA, JTA, JAX-RS, ...) have a plan to include module-info to be Jakarta EE 9 compatible or if it's planned only for Jakarta EE 10+.

I've been looking to build up the CI/CD pipeline for concurrency api and ri and the goal install fails due to the lack of a signing key. What should projects use as a signing key to sign jars?

While the integration of all specs to https://jakarta.ee/specifications/ is already very good and in the general the generated HTML & PDF specs are quite familiar there are some differences that should be refactored for the next version:

One point is how java classes and keywords are formatted in the text. The following image shows how classes are formatted in the Java Bean Validation Spec and in the JPA Spec:

Next to this some specs contain images (normally JPG or PNG). Whenever you need to change something is such image the complete image needs to be recreated. Next to this some of the images are not available in a high quality while the complete content of the images (mostly diagrams) could easily be defined as a vector based graphic (like SVG). I assume the HTML / PDF generator support SVG without any problem. https://www.diagrams.net allows to create (technical) diagrams and graphics in a modern web tool. Next to exporting such images as PNG or SVG the basic source file can be saved as an XML and easily committed to the spec repos. By doing so the file can easily be modified (see jakartaee/servlet#348 as an example).

I assume that that we can find more differences between the specs and can improve them in some other points. Maybe it would make sense to collect all this points and do a general review of all the specs once we have a list. @ivargrimstad who would be a good contact to discuss such topics?

It would be great if someone would find the time to donate some formatting ruleset files for IDEs, matching the recommed formatting rules. This makes it easier for hacking the code with the IDE of choice.

Thanks to @arjantijms for donating his Eclipse IDE configuration in 20c7b20. It would be great to receive such contributions for more IDEs! :-)

EL with unnecessary parentheses fail. For instance:

<c:set var = "i" scope = "session" value = "1"/>
<c:if test="${(i) == '1'}">
<p>i is:  <c:out value = "${i}"/><p>
</c:if>

Stack trace:

15:16:51,904 INFO  [stdout] (http_8080 task-1) com.sun.el.parser.ParseException.<init>(ParseException.java:179)
--
15:16:51,904 INFO  [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.generateParseException(ELParser.java:2963)
15:16:51,904 INFO  [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.jj_consume_token(ELParser.java:2845)
15:16:51,904 INFO  [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.LambdaExpression(ELParser.java:295)
15:16:51,904 INFO  [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.Assignment(ELParser.java:226)
15:16:51,904 INFO  [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.SemiColon(ELParser.java:181)
15:16:51,904 INFO  [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.Expression(ELParser.java:174)

Similar issue in Tomcat https://bz.apache.org/bugzilla/show_bug.cgi?id=56179

This should in its initial version help projects in migration from current jvnet-parent to something similar provided by ee4j as the jvnet-parent (and similar parents provided by sonatype through https://github.com/sonatype/oss-parents) is already deprecated.

We need a new brand name for the set of specifications that will be created by the new community process. This brand name will also become a certification mark in the industry for compatible, independent implementations. The open source projects that fall under the Eclipse EE4J top level project will be one such implementation. In short, we need a new name to replace “Java EE”. Much like the OpenJDK project implements the Java SE Platform specification, the EE4J projects will provide implementations of a set of specifications that we today call Java EE: we need a brand name for this set of specifications.

With this in mind, we are initiating a community process to select the brand name. This process will be managed by the EE4J Project Management Committee (“PMC”) with assistance from the Eclipse Management Organization (“EMO”). The name that is selected by this process must pass legal and other trademark searches to ensure that the names are available for use. As a result, it is possible that the favoured selection will not be the ultimate choice. The final decision will be made by the EMO Executive Director (“EMO(ED)”) in consultation with the PMC.

The process is described in greater detail below.

Nominations

Names can be nominated by anyone in the community via this GitHub Issue record.

Nominations will be open from November 15 until November 30, 2017 (UPDATED; note that the date had been incorrectly specified as November, 2018)

Naming Guidelines

All suggested names must conform to the following:

• They must conform to Oracle’s trademark usage guidelines. Amongst other things this means that the name cannot start with the word “Java”.
• They must conform to the Eclipse Foundation trademark guidelines.
• They must not be obscene, sexist, racist, controversial, etc., and they must not be frivolous (e.g. we’re not going to choose Boaty McBoatface or the like.)

Any suggested names which fail to meet the above criteria will be rejected.

Name Selection Process

The process will be executed as follows:

1. Members of the community will be invited to enter their nominations into the specified channel;
2. At the end of the nomination period, the names suggested by the community will be reviewed by the PMC to identify those which meet the criteria specified in the by the naming guidelines (depending on response, the PMC may decide to further reduce the list to a manageable size);
3. The PMC will then initiate a community vote using the CIVS system (which will produce an overall ranking of the choices); and
4. The results of the vote will be delivered to the EMO(ED) who will engage in the required legal and other trademark searches to ensure that the names are available for use, and consult with the PMC to make the final decision.

Since we have no idea what sort of community response to expect, it is difficult to time box anything other than the initial nomination process. But this will be an open and transparent process, and we invite the community to engage in all aspects of it. There is a great deal of legal, marketing, and community thought that goes into selecting an industry brand, so it’s important that we get this right. This may take a little time.

Consider this an informal poll to help with the logo selection process. This is not a vote.

Add thumbs up to any logos you like. Feel free to use other emoticons.

UPDATE March 29th, 2018

Poll is now closed and the official voting is now open! Cast your vote! Vote will be closed April 6th.

• https://t.co/cfxT47xTyQ

Here's mine Wayne, it's from the female name Marnie:

"Marnee" or "MarnEE" or "Eclipse Marnee" if you need EF in the the name.
It is an acronym for:
Multi-tiered, applications reliable. networked. enterprise enabling.

Inspiration from the old JEE blurb which had:
large-scale, multi-tiered, scalable, reliable, and secure network applications.
in it.

Cheerio,

Matt

We have agreed to start with a flat ee4j project structure, where all projects - including API and impl projects - are simply independent technology projects and any relationship or navigation between will rely on an overarching EE4J project web page.
As all the technologies for EE are moved to EE4J, including their APIs, RIs and TCKs, understanding the relationship between (for example) the JAX-RS API project and Jersey implementation project may become challenging without some form of project hierarchy. EE has always welcomed multiple implementations and it is certainly conceivable in the future that independent implementations of a single API may be managed under EE4J. That would not require project hierarchies but may benefit from them. Precedent for project hierarchies exists (e.g. https://projects.eclipse.org/projects/modeling.m2t) although it has not necessarily been shown to be useful in the past.

This issue is a placeholder for future discussion as we get more experience in EE4J - for now we are agreed on a non-hierarchical project structure.

Do we want to set those explicitly? It's considered good practice to do so in a parent POM for repeatable builds.

The PMC recommends using jakarta.* as module names for the Jakarta EE specification projects.

Please add comments and/or suggestions to this issue.

Right now, there are 2 EE4J GH Org: 'eclipse-ee4j' and 'ee4j'
The ee4j Org header should be updated to reflect the fact that it's a parked Org without any activity; people should go to https://github.com/eclipse-ee4j/ instead.

per http://central.sonatype.org/pages/choosing-your-coordinates.html domain owner is the right person to request creation of groupId repo at sonatype's nexus. Request can be filed at https://issues.sonatype.org. Once this is done, I can ask sonatype to give me write access to this repo...

The Eclipse Project Handbook has a checklist, but it's heavily rooted in the Eclipse Foundation's history of most projects building Eclipse Platform Plug-ins. If you ignore the bits about bundles and plug-ins, though, it's a pretty good start.

The EMO does a lot of the actual checking, but leans on the PMC to assess that the project is working within their scope, is following the rules of the EDP (the open source rules of engagement in particular), and is just generally doing the right sorts of things to develop community.

It's up to the PMC to determine how to assess this before giving approval for a Release Review. Having a checklist that we can point to would be a valuable asset.

Seek approval from Specification Committee about the intent.
Use Servlet as an example -> pick text from JSR

Create issue in the projects and follow up that it is being done.

enforcer plugin execution currently emits "noise" for every module in multi-module build - this is usually not needed during regular dev-build cycle but this check should be there for making sure that during "release", correct maven version is used.

The MX (mail.eclipse.org, 198.41.30.200) that hosts the mailinglist [email protected] does not support TLS.

Currently published as a news item:

https://www.eclipse.org/ee4j/news/?date=2018-06-08

It is a little confusing where we document rules, suggestions etc. related to EE4J projects.
We currently have it spread out a little between:

• https://www.eclipse.org/ee4j/
• https://wiki.eclipse.org/Category:Jakarta_EE
• https://github.com/eclipse-ee4j/ee4j/wiki
• https://github.com/eclipse-ee4j/ee4j

I think it would be a good idea to replace the particular name "Lukas Jungmann" by the more general name "Eclipse Foundation" in the developers section.

The reason is that developers found in a parent POM are always inherited into the subproject POM -- without any chance to exclude them. But the developers section is not a hall of fame. Its purpose solely is to tell explicitly these few people that are contact persons of that particular project. This is explicitly told in the official POM reference (https://maven.apache.org/pom.html#Developers):

...Note that, although an organization may have many developers (programmers) as members, it is not good form to list them all as developers, but only those who are immediately responsible for the code. A good rule of thumb is, if the person should not be contacted about the project, they need not be listed here.

Without any doubt Lukas earned his merits in EE4J, but it is clear that he is by definition the one to be contacted for all projects (in particular not for projects where is not an active committer).

As of today OSSRH and Maven Central both enforce the existence of this section of the POM, we should replace it simply with something like:

<name>The Eclipse Foundation</name>

or

<name>EE4J PMC</name>