Thanks for responding Lukas. I think what you just provided is
essentially what I was looking for at the moment.
If possible, could you kindly advise when the time is right, how
people can best contribute to take this technology across the Jakarta
EE 9 threshold (if there is indeed something left to do beyond the
current PRs)? In the worst case I will check back around mid-December
to remind. Will also be delighted to spread word when you are ready
to get more people engaged in the project beyond the folks currently
present here already.
Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger
Please note views expressed here are my own as an individual
community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Lukas Jungmann <lukas.jungmann@xxxxxxxxxx>
Date: 11/26/19 6:17 AM (GMT-05:00)
To: jpa developer discussions <jpa-dev@xxxxxxxxxxx>, reza_rahman
<reza_rahman@xxxxxxxxx>, Ivar Grimstad <ivar.grimstad@xxxxxxxxx>
Cc: Tanja Obradovic <tanja.obradovic@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [jpa-dev] What's next for JPA?
On 11/26/19 11:38 AM, reza_rahman wrote:
> OK, thanks. I was aware of the difference now but was simply using
the
> wrong terminology. My apologies.
>
> To be more precise, may I request that some of the current committers
> ideally including the project lead share some thoughts on when
they see
> the Jakarta EE 9 work being started?
Has the Jakarta EE 9 plan been finalized? As far as I understand it, the
plan is supposed to be ready by Dec 9 and the only expected, required
and acceptable change for Jakarta EE 9 is the javax -> jakarta namespace
change. Everything else has to wait to post-EE9, unless it's done in
some branch/extra PRs.
The namespace change has been prepared By Scott M. already in
https://github.com/eclipse-ee4j/jpa-api/pull/231
What is not part of that PR is new version of XSDs which would use
non-JCP target namespace - not sure if that is or is not required but to
me it looks reasonable that Jakarta defines its own namespaces; in any
case this is something what should be done, if done, consistently
through the whole platform (ie will other specs provide new versions of
their schemas?).
Specification document has not been provided to the project by
EMO/Eclipse yet, so nothing can be done in this area at this point.
Is there anything else missing/not prepared for EE9?
thanks,
--lukas
Clearly a lot of folks are keen on
> seeing activity on this technology resume and are willing to help?
What
> do you think?
>
> Reza Rahman
> Jakarta EE Ambassador, Author, Speaker, Blogger
>
> Please note views expressed here are my own as an individual
community
> member and do not reflect the views of my employer.
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
> -------- Original message --------
> From: Ivar Grimstad <ivar.grimstad@xxxxxxxxx>
> Date: 11/26/19 5:01 AM (GMT-05:00)
> To: Reza Rahman <reza_rahman@xxxxxxxxx>
> Cc: jpa developer discussions <jpa-dev@xxxxxxxxxxx>, Roberto Cortez
> <radcortez@xxxxxxxxx>, Tanja Obradovic
> <tanja.obradovic@xxxxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [jpa-dev] What's next for JPA?
>
>
> On Sun, Nov 24, 2019 at 6:13 PM Reza Rahman <reza_rahman@xxxxxxxxx
> <mailto:reza_rahman@xxxxxxxxx>> wrote:
>
> Finally went through the issues. To be honest, I remain convinced
> big ticket changes to JPA is probably not necessary right now
though
> clearly some work could be triaged after Jakarta EE 9.
>
> I am wondering though, when will the javax*->jakarta* transition
> work start? I noticed Oracle remains the spec lead. Is that
correct?
>
>
> Not entirely since there is spec lead role in the Jakarta EE
> Specification Process. Lukas is the Project Lead for Jakarta
> Persistence, but decisions are made by the committers where all
have an
> equal vote.
>
>
> Reza Rahman
> Jakarta EE Ambassador, Author, Speaker, Blogger
>
> Please note views expressed here are my own as an individual
> community member and do not reflect the views of my employer.
>
> On 11/8/2019 1:36 PM, Roberto Cortez wrote:
>> Hi,
>>
>> The JPA Github repo already has a bunch of issues reported,
>> migrated from the old repo:
>> https://github.com/eclipse-ee4j/jpa-api/issues
>>
>> I think we should look into what is in there and figure out what
>> makes sense or not. I suggest that the requests being discussed
>> here to be reported over there.
>>
>> Cheers,
>> Roberto
>>
>> On Wednesday, November 6, 2019, 10:46:38 PM GMT, reza_rahman
>> <reza_rahman@xxxxxxxxx> <mailto:reza_rahman@xxxxxxxxx> wrote:
>>
>>
>> Let us see how others respond. If the response is good, I would
>> create a JIRA with some example code. In fact, you may want to
>> check if there is one already and add to that.
>>
>> Reza Rahman
>> Jakarta EE Ambassador, Author, Speaker, Blogger
>>
>> Please note views expressed here are my own as an individual
>> community member and do not reflect the views of my employer.
>>
>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>
>> -------- Original message --------
>> From: Behrang Saeedzadeh <behrangsa@xxxxxxxxx>
>> <mailto:behrangsa@xxxxxxxxx>
>> Date: 11/6/19 2:48 AM (GMT-05:00)
>> To: jpa developer discussions <jpa-dev@xxxxxxxxxxx>
>> <mailto:jpa-dev@xxxxxxxxxxx>
>> Cc: Bill Shannon <bill.shannon@xxxxxxxxxx>
>> <mailto:bill.shannon@xxxxxxxxxx>, Dmitry Kornilov
>> <dmitry.kornilov@xxxxxxxxxx>
<mailto:dmitry.kornilov@xxxxxxxxxx>,
>> Ivar Grimstad <ivar.grimstad@xxxxxxxxx>
>> <mailto:ivar.grimstad@xxxxxxxxx>, Tanja Obradovic
>> <tanja.obradovic@xxxxxxxxxxxxxxxxxxxxxx>
>> <mailto:tanja.obradovic@xxxxxxxxxxxxxxxxxxxxxx>
>> Subject: Re: [jpa-dev] What's next for JPA?
>>
>> Hi all
>>
>> I try to get more engaged here. Right now off the top of my
head,
>> I was thinking about discussing the possibility of adding
support
>> for UNION to JPQL/Criteria.
>>
>> It sometime can lead to significant performance improvement as
>> some planners struggle optimizing a query with many joins but do
>> fine when the query is split into two where results are combined
>> using UNION.
>>
>> Another feature was the possibility of declaring associations
with
>> Streams instead of Collections, with semantics that would allow
>> iterating over millions of rows without eating too much memory.
>>
>> Also now that some RDBMSes have first class support for JSON,
>> letting users inttospect JSON fields and use them in WHERE
>> clauses, adding support to JPQL/Ctiteria would be nice.
>>
>> On Mon, 4 Nov. 2019, 2:33 am Reza Rahman, <reza_rahman@xxxxxxxxx
>> <mailto:reza_rahman@xxxxxxxxx>> wrote:
>>
>> I am adding a few folks here that could help mentor and
>> kick-start this.
>> I myself frankly can only guess at this point. However, I
>> would say all
>> of this is new so starting just about anywhere is fine.
>>
>> Additional responses below. I have removed extra text for
brevity.
>>
>> Reza Rahman
>> Principal Program Manager
>> Java on Azure
>>
>> Please note views expressed here are my own as an individual
>> community
>> member and do not reflect the views of my employer.
>>
>> On 11/2/2019 9:04 AM, Christian Beikov wrote:
>> >
>> > I think there are lot's of issues in the issue tracker
that
>> could be
>> > tackled, but at this point I am not sure about how to
start.
>> >
>> I suggest starting by triaging the issues here together.
>>
>> > Are the discussions about the big bang namespace change
>> already over?
>> >
>> There is still some churn but looks like things are very,
very
>> slowly
>> gravitating towards big bang. I believe the community
stepping
>> up to
>> move things forward will accelerate these decisions.
>> >
>> > Is it even possible to add features in such a seemingly
>> > "namespace-change-only" release?
>> >
>> Likely not.
>> >
>> > What needs to be done to actually add a feature? Is a PR
>> containing
>> > the spec and API changes enough? I guess a TCK test would
>> have to be
>> > added as well? How is the decision made that a feature
is added?
>> >
>> Anything that can be done is progress. In order for
something
>> to be
>> considered complete, it likely needs an API change,
change in
>> one of the
>> implementations, a TCK change and a spec document change.
They
>> don't all
>> need to be done by the same people. The project
committers and
>> lead
>> decides if a change will be made - effectively that means
all
>> of us
>> together. Given the state of things, I would say most
>> reasonable changes
>> should make it in. It is contributing that actually matters.
>> >
>> > It would be great if we could illustrate the process
with a
>> more or
>> > less simple
>> issue(https://github.com/eclipse-ee4j/jpa-api/issues/163)
>> > so that people get a feeling for how the specification can
>> be shaped.
>> >
>> As long as you have the paperwork set up, I would say
there is
>> nothing
>> stopping you from doing exactly that.
>> _______________________________________________
>> jpa-dev mailing list
>> jpa-dev@xxxxxxxxxxx <mailto:jpa-dev@xxxxxxxxxxx>
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jpa-dev
>>
>> _______________________________________________
>> jpa-dev mailing list
>> jpa-dev@xxxxxxxxxxx <mailto:jpa-dev@xxxxxxxxxxx>
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jpa-dev
>>
>> _______________________________________________
>> jpa-dev mailing list
>> jpa-dev@xxxxxxxxxxx <mailto:jpa-dev@xxxxxxxxxxx>
>> To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jpa-dev
>
>
> --
> Reza Rahman
> Principal Program Manager
> Java on Azure
>
> Please note that views here are my own as an individual
community member and do not represent the views of my employer.
>
>
> _______________________________________________
> jpa-dev mailing list
> jpa-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jpa-dev
>