See in-line.
Dmity, Yep, it depends on how we approach this
"technical direction"... Based on our discussion at the
last PMC, we thought we would solicit input from each (or many) of the
components. This would require some type of "template"
asking for input. Thus, I went down that path thinking of using the
Eclipse Release request for each component to identify their "next
release" plan... But, as you say, maybe that's more of a project
release plan -- which is different from a technical vision document.
I have concerns about suggested bottom-up approach which I already expresed earlier. There are 39 projects in EE4J. Unfortunately now there are not many active projects (yes, we should work on it). Some project leads are placeholders. I am sure that some projects will provide needed feedback, but not all of them. I doubt that it will be even a half of them. Waiting for feedback in this situation could take forever. We (PMC) should take initiative, get as much feedback from committers as possible and make the document. Relying on projects in this situation can dramatically delay the result. I read through your blog... This
is a good start, as well. A few comments...- I like the division of the TCKs to their
respective API projects. As you say, major piece of work. Requiring
the same test framework may be difficult. Hate to speak for Red Hat,
but I doubt that they will be moving CDI and Bean Validation away from
Arquillian -- unless Arguillian is chosen as the common test framework.
But, in that case, then all of the rest of the TCK buckets have major
work... :-)
You are right. It won’t be easy. I still think that it should have some level of standard. If we allow projects to do whatever they want we will end up with a mess bigger than CTS today. ;) - Have to be careful on how far we embrace
Java 9 modules... Some of us (Red Hat, Payara, and IBM) use alternate
module systems. We can't alienate these implementations.
It’s more about long-term strategy. We may like it or not, but this is a Java feature and we will need to support it at some point to be up to date. It’s better to start thinking about it now to make the process smooth. - Standardizing on Maven is good. And,
standardizing the artifacts.
- Marking old and unused technologies
as optional or deprecated is good. We probably need to define a deprecation
policy. Is that us? Or, the Spec committee?
I think it’s us, but I am not sure. Sometimes I still have problems understanding who is responsible for what, but it’s getting better. - Specific
to your comment about JPA-RS... Wouldn't that just be considered
an implementation detail that EclipseLink has and it could be deprecated
based on EclipseLink project rules. It's not required for the JPA
spec implementation, so we (PMC) shouldn't care.
Possibly I was not clear enough. I listed EclipseLink features/APIs which would be nice to separate as modules. It users want to use it they will need to add extra dependency. It’s not done in EclipseLink yet, but we are thinking of doing it. Other projects can do the same with deprecated features/APIs they have. I agree that PMC should not care about approving this kind of changes. - Your comment about integration with
CDI and Config... We should also consider the eventual integration
with the MicroProfile features. Some will have a natural evolution
like merging Rest Client with JAX-RS (already being discussed). But,
others like Config would need to be a new component project under EE4J.
I think we need to put the MicroProfile integration into our Technical
Vision.
I was talking about base APIs which most of the projects should use. All projects require configuration. Injection is also a nice feature which we should embrace. MicroProfile APIs are not base APIs. It doesn’t mean that I think that MP APIs should not be adopted by other projects. I fully support the idea of using (moving) MicroProfile APIs to Jakarta EE and make it a base of Jakarta EE Micro Profile. I agree to add MicroProfile integrating to our technical vision. It can be another topic for discussion.
— Dmitry
Thanks! --------------------------------------------------- Kevin Sutter STSM, MicroProfile and Java EE architect e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter phone: tl-553-3620 (office), 507-253-3620 (office) LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>To:
EE4J PMC Discussions
<ee4j-pmc@xxxxxxxxxxx>Date:
05/18/2018 02:24 PMSubject:
Re: [ee4j-pmc]
Jakarta EE / EE4J Technical Vision documentSent by:
ee4j-pmc-bounces@xxxxxxxxxxx Hi,It looks good and I like your idea, but my understanding
of technical directions PMC should provide is different. It doesn’t mean
that what you’ve done is wrong. Possibly it’s just my misunderstanding.You are talking about a project release plan describing
what project is planning to achieve in the next release. This is not technical
directions for all EE4J projects, it’s one particular project plan. It
will be required by the spec committee for the initial spec review.My understanding of technical directions is that it’s
a set of recommendations for all EE4J projects. It contain general issues
projects should address. I also spent some time with Prague folks and we
came out with a document published here: https://dmitrykornilov.net/2018/05/18/jakarta-ee-technical-directions/.
This is our vision of technical directions. Consider it as a draft. It
should be discussed by the community. At the end PMC should review all
community comments and create a final technical directions statement.Thanks,DmitryOn 18 May 2018, at 20:14, Kevin Sutter <sutter@xxxxxxxxxx>
wrote:Hi, I know some of this discussion was started under the "PMC Minutes"
subject line, but I thought it would be better to start a new thread to
make it easier to organize...
I've been talking with our Java Batch lead (Scott Kurz) and we came up
with some good input, but not necessarily a draft template... I'll
explain. Scott is not a fan of the current JCP template. For
Java EE 8, he was considering an MR for Java Batch. The JCP template
basically requires you to start from scratch with every new revision. In
many cases, you are just copying-and-pasting from the original to the new
template, with only a few sections actually being updated. He would
like to see "common" metadata for a project to be consistent
and only require updates to the specific items that are affected by a new
release.
I pointed out the Eclipse Release mechanism. Some of you are familiar
with the MicroProfile project. Here's an example of a Release definition
for MicroProfile 1.3: https://projects.eclipse.org/projects/technology.microprofile/releases/microprofile-1.3
You can enter as much (or as little) detail required to defined the release
content, the release plan, issues being tracked, etc. Scott liked
this type of approach much better. The overall project information
is long-lived (https://projects.eclipse.org/projects/technology.microprofile)
and consistent across releases. But, each release can be further
defined as required by the project.
Let's use JAX-RS as a Jakarta example: https://projects.eclipse.org/projects/ee4j.jaxrs
Currently, there are no additional releases defined for JAX-RS (other than
the creation review, https://projects.eclipse.org/projects/ee4j.jaxrs/governance).
But, the JAX-RS project could create a JAX-RS 2.2 Release definition
(for example) by specifying a proposed release date: https://projects.eclipse.org/node/12849/create-release(All of this information can easily be changed after the fact.) Once
the proposed Release is created, then all of the detail specific to that
release could be filled out (deliverables, compatibility, milestones, issues,
standards, etc). This is all defined in more detail in the handbook:
https://www.eclipse.org/projects/handbook/#release
If this is an agreeable process, we could require the non-Eclipse based
projects (ie. CDI, Bean Validation, Batch) to still have a "holding
project" in Eclipse to capture this type of release information. The
main project page could point off to their real location (Red Hat, Apache,
IBM, etc) for the project artifacts. I'm just trying to point out
that we would not require all Jakarta projects to be an Eclipse project
-- just the release tracking information. This is very similar to the JCP
requirements, except lighter weight.
For the Platform, we could aggregate all of the component release information
into a single interface that is easy to navigate.
Just an idea to discuss. We could re-use existing capabilities within
the Eclipse foundation without having to invent something new. I'm
sure this Eclipse Release process isn't perfect, but with Wayne on the
PMC, I'm sure we could get some tweaks done to satisfy the requirements.
:-)
Some additional ideas for either the static or dynamic content...- package prefix (io.jakarta)
- maven coordinates/URL of artifacts
- project dependencies (especially other
ee4j projects -- Wayne's graphing experiment may help here)
- project "health" -- something
along the lines of Apache project status (committers, community growth,
blockers, etc)
--------------------------------------------------- Kevin Sutter STSM, MicroProfile and Java EE architect e-mail:
sutter@xxxxxxxxxx
Twitter: @kwsutter phone: tl-553-3620 (office), 507-253-3620 (office) LinkedIn: https://www.linkedin.com/in/kevinwsutter _______________________________________________ ee4j-pmc mailing list ee4j-pmc@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-pmc_______________________________________________ ee4j-pmc mailing list ee4j-pmc@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________ ee4j-pmc mailing list ee4j-pmc@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-pmc
|