FYI if required I can provide some
lightweight mentoring on Arquillian, CI/CD or website development
if needed (not just for Nishant but any other Jakarta EE
contributor if needed).
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.
Not that those things are small, in fact they
each require some specialized skill (not so deep that it
couldn't be learned somewhat quickly, but still).
If any of those interest you or overlap you
skills, they could be a nice thing to start on, because they
are basically independent of the core goal of moving the batch
API and specification forwards.
If not, I'll just have to get moving on the
project so we can generate some more tasks for volunteers like
you !
Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience skurz@xxxxxxxxxx
--------------------------------------------------------
Nishant Raut ---03/14/2020 06:30:19 AM---Hi
Scott, I am new to this project can you give me small issues
to begin with?
I am new to this project can you give me small issues to begin
with?
Thanks and Regards,
Nishant
On Sun, Mar 8, 2020, 4:47 AM Scott Kurz <skurz@xxxxxxxxxx> wrote:
Hi all,
As we've gotten some offers to help with the project, let me
write this kickoff email saying where I see us starting from.
At the moment, of course, nothing much is happening so this is
just my opinion, and by no means the final word.
What is the short term goal?
To release Batch 2.0 as part of Jakarta EE 9. As the package
rename ("big bang") from javax.* => jakarta.* will be the
only (or almost the only?) change, this is not the most
exciting work. https://github.com/eclipse-ee4j/batch-api/issues/7
I'd like to leverage the work we're going to do to release
Jakarta EE 9 and the buzz to build enough momentum to carry us
to releasing some new enhancements, maybe later in the year,
maybe as part of a new EE platform release (or maybe on its
own even).
The exact directions and priorities are up to whatever
community we generate here. But I can start by tackling some
obstacles I know lie ahead, and also help keep alive some of
the collective knowledge we've built in the earlier project.
What about the old issues from the former project?
My take, (and I'm just throwing this out there, you can
disagree and propose a different approach), is that we start
with a clean slate and do NOT just automatically move over the
old issues.
Now, I recognize we've had some discussions worth coming back
to, but from a variety of sources. I did make an attempt at
collecting one set of issues, including the old JSR 352 issues
here: https://github.com/eclipse-ee4j/batch-api/wiki/Legacy-Issues
If someone cares enough to go and open new issues for each of
these, I'm not going to stop them. I plan to review to some
degree and (re)open issues myself.
But I don't want to take the stance that, until we've gone
through and filtered and prioritized this large issue set, we
cannot do anything new. Maybe before we put in a release plan
we well, maybe we won't, I don't think we have to decide just
yet. Let's wait until we are making some progress first.
What do we need to clarify before working on new function?
I'm going to elaborate in separate emails, but I at least
captured the two big issues I see us needing to clarify to
really move forward:
1) The future of Batch in the Glassfish runtime
2) How to add TCK tests that potentially break existing impls
passing the 1.0.x TCK:
What can I do to contribute in the meantime?