User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0
Hi,
I think the Idea from the spreadsheet was to organize all the
different upcoming opinions and new ideas. Now, with the help of
the spreadsheet it is possible to order them by priority.
None of the ideas should be discarded but maybe become a feature
later for the future. The ongoing discussion can be done in the
corresponding issue on Github.
===
Ralph
Am 18.11.22 um 08:24 schrieb Ivar
Grimstad:
Hi Reza,
I think the spreadsheet was excellent to get an overview of
various inputs at a certain point in time. But it is a
snapshot of opinions and does not contain the nuances, or
background. And people change their minds, so it is volatile.
I think I would just leave it as it is. It has sort of served
its purpose by sparking off the various discussion threads.
Having healthy, constructive dialogue focusing around each
topic in the threads is what I would suggest.
Ivar, how important is it that people
need to explicitly “sign off” before we begin an
intermediate analysis of outcomes? My view is that
people providing input here are responsible enough
such that this is unnecessarily. If you truly feel
this is necessary, I will add a “sign off” row and
ensure everyone fills it out. It will take
additional time and effort on my/others part to do
so, but I am happy to do it for us to achieve
committed agreement we can confidently move forward
together on.
Understood. Let me put some
thought into what either the most critical or
easiest decision point is and also what a
reasonable sequence of decisions are. We can
then discuss each decision with a view towards
committing to reaching agreement, taking into
account the input patterns as they stand on
Sunday. I haven’t looked closely yet, but it
does look like there are clear patterns on
most items already. We should be able to
reconcile the diverging code streams without
significant loss of contributions.
The desire is indeed to ultimately
result in detailed GitHub issues with links to
discussion/input including hopefully milestones,
priorities and initial committer/contributor
assignments.
I think the number of points discussed has
been overwhelming, at least for me. It's
difficult to track all emails and reply to all
threads. I would wind down the discussion
after Sunday, record what we have, decide on
priorities. And then I would continue
discussing each point again, from the highest
priority ones, a single point at a time, and
iterate. When we have a clear view about the
highest priority point, implement it, and only
then continue discussing the next point.
Otherwise I'm afraid many of us will get lost
in too many parallel discussions.
As an alternative, we can create a github
issue for each point and discuss each topic in
its github issue, but that doesn't solve the
problem with tracking all the parallel
discussions. So, even then, I suggest focusing
on one topic at a time.
I have to say I am a
bit worried that the conversation
has slowed down so soon. I do see a
lot more of the sheet is full, which
is awesome. However, I still see
that there are a lot of empty spots.
I also think there is a lot of room
for good discussion on topics such
as use cases (at least a good solid
initial take).
It’s of course possible
some folks are still absorbing the
discussion and rethinking their
initial viewpoints (I certainly am)
Your thoughtful input is very
appreciated. I worry without
sufficient input, discussion and
agreement we will have unproductive
decision drift that’s painful to
deal with for people volunteering on
their free time.
Is it reasonable to aim
to begin to wind down discussion by
the end of Sunday but not too much
earlier? I think we can then begin
tabulation, building agreement and
moving forward in a committed
direction together.
I definitely agree
we should wait a bit more to do
a final tabulation (my guess
would be at least a week or
more). Folks should definitely
review, update and change to
reflect their current viewpoints
as we progress the conversation.
I am planning to do
a final review prompt before we
start a tally and determine
outcomes. I think the outcomes
are best determined in an
in-person meeting and then
communicated here.
I have updated my
column so it reflects my
viewpoints more accurately. I
encourage everybody to do so, and
I would refrain from using this
table in any way until everybody
mentioned there have "signed off"
on their viewpoints. The ones that
were recorded for me were
seriously skewed.
It is a good idea to set up a
regular call. When we have found
a timeslot for it, I'll help set
it up with the EE4J Zoom
account.
I am out of time today but
should be able to share my
own viewpoints by some time
tomorrow late evening.
Hopefully the emails this
afternoon will help generate
thoughts, discussions and
ultimately committed
decisions together. I would
like to get back to hacking
on this project during
nights and weekends once
overall direction is once
again a bit better
understood. It took me a
while to secure permanent
Azure hosting for this
project on our managed
Jakarta EE PaaS (App
Service). Thankfully that's
all done now and can be used
if a server-side portion for
the Starter UI is something
we ultimately still pursue.
Another thing I think we
need to schedule soon once
we get a chance to have some
more async online
conversation is a regular
sync meeting (maybe once a
month?). I think not having
that is one of the factors
that has caused some
mismatched
expectations/assumptions,
misalignment, and
unnecessary surprises we
should be able to avoid
going forward hopefully?
I will now try to start
separate threads on the
distinct decision points
so we can hopefully better
structure the discussion,
capture input for more
traceable archival and
achieve reasonable
decision outcomes easier.
I'll also outline the
rationale for my own
viewpoints separately.
I am
very grateful
responsible folks
from the community
as well as current
committers have
taken the time to
help us agree on
directions. I
believe more views
from more folks
will be
forthcoming soon.
I
think it will help
to see where
consensus is if I
broke out each key
question/decision
into a separate
thread. For each
decision point, I
will read each
message carefully
and include a
tentative vote per
decision/person
that I will record
and keep updated
in a Google Sheet.
Please do help me
make sure I get it
right.
I
will also include
my own views at
this point. I
think that may
also help set
additional context
for folks that
have not been very
intimately
involved in all
the project
activities so far.
Wow, being
here from the
beginning i can
say that is
really awesome
to see so many
people involved
on this =D
I think the
approach based on
maven archetypes
was a good way to
get things going
but I feel like
this is something
too much related
to the Jakarta EE
community. If we
wanna reach other
developers we
should try to make
things easier(or
more build-tool
agnostic).
While it's good to
have a minimum
archetype so we have
a project
bootstrapped and
ready to be used, if
wanna new developers
to learn and
understand how
things are used, one
of our goals has to
be provide project
with usage
examples(for
transactions, JPA,
etc...) or else it
will become a
generator for people
that already knows
Jakarta EE and i
think that's not the
original proposition
for this project.
The CLI could
be a good addition
but I don't see it
as a MUST for now.
I agree with Ondro
that we should
have a GUI to
download the ZIP
file and I
submitted a
proposal for that
some time ago.
I'll attach it
here.
In summary: I
agree we should
have more examples
with different
apis, not just the
minimum, and we
should decouple
the project
generation from
the maven
archetype, hiding
it behind a GUI.
In the future
we can have Gradle
as an option too,
but I think these
both above items
will already
require a lot of
us.
Em
sáb., 12 de nov de
2022 às 07:02, Ivo
Woltring <ivo@xxxxxxxxx>
escreveu:
Like
Bazlur I am very
happy to be part
of the community
now. Forgot to
mention that in
the heat of the
discussion :-)
I also work
a lot with
junior
developers.
One of the
first things
they learn is
how to work
with maven as
it is the most
important
build
framework out
there.
Generating a
project from
the
commandline
with maven
should not be
a big problem
for most. I do
not see the
added benefit
if generating
a zip first
and making
that the
download. The
only thing I
can think of
is that the
user does not
yet have maven
installed. Hmm
maybe it is a
good idea
:lol:
Ondro I am
interested in
looking at
that code of
yours too :-)
Complete
example
projects are
very useful.
They teach a
wow and the
correct way.
But
Maven
archetypes ar
not meant to
generate
complete
example
projects but
working
skeletons so
you can add
your own
functionally
easily. Copy
and pasting a
project to
strip it down
defeats the
whole purpose
I think.
I think
that heaving
complete
examples is a
great idea and
they should be
made, but in
tutorial
fashion like
the spring
guides. Not as
part of an
archetype. I
don’t know if
generating a
zip in this
case is
necessary as
it can just be
a git project
or many git
projects.
I like the
idea of a Cli.
Kinda like ng
does.
Not only to
generate a
base but maybe
even add e.g.
a controller
or somesuch.
I really
like the basic
starter as we
have it now
and I think a
barebones
starters
should always
be available
because that
is how I
mostly start
and that is a
very good
reason hehe
It's
great to see
so much
activity on
the Starter
project.
I like
the approach
the Starter
project did
initially, to
get things
started and
simple - just
generate a
maven command
line to
execute. It
was at the
time when the
Started
project didn't
have many
contributors.
And using
maven
archetypes is
a good
starting
point.
But my
vision for
Starter
resonates with
other ideas
mentioned in
this thread:
It would
be good to
provide an
option to
download a ZIP
file generated
from the
archetype
Provide
example
projects, or
even make it
possible to
generate an
example
project by
selecting the
components
that users are
interested in
(e.g. they
select REST
and CDI, and
the generated
project would
create a REST
service with a
bean injected
to it
beans.xml
file, and a
corresponding
README that
describes how
to build it
and how the
components are
wired)
On top of
that, I'd like
to see a REST
endpoint in
Starter, so
that ZIP file
or Maven
command line
can be
generated with
a script or
REST client
that connects
to the
endpoint. This
would allow
writing a
Starter CLI or
IDE plugins,
which would
use the
Starter webapp
as the
backend.
A few
years ago, I
started
writing a Java
app, that
generates a
ZIP file from
any Maven
archetype and
I think it
would nicely
fit what is
already in the
Starter
webapp. I'll
check what's
the state of
this app and
will try to
contribute it
to the
Starter, so
that we can
generate ZIP
files for
download based
on the
archetypes.
Ondro
On Sat, Nov 12, 2022 at 3:11 AM A N M Bazlur Rahman
<bazlur@xxxxxxxxx>
wrote:
Hello
everyone,
I am thrilled
to be a part
of this
initiative and
grateful to
everyone who
nominated/voted
for me to be a
committer.
I love what
you have all
said so far. I
don’t
necessarily
disagree with
any of Ivar’s
points, but
let me share
my thoughts
about it.
I work with
junior
developers so
that I can see
things from
their
perspective.
We're all
experienced
developers
here, so we
don't have any
trouble
understanding
and working
through a low
level of
complexity.
Everyone here
knows the
maven
archetype like
the back of
their hand.
But if we want
to get new or
less
experienced
developers to
try out the
Jakarta EE
spec, I think
it's a good
way to stop
them. There
are already a
lot of good
alternatives
that are
pretty easy to
use. One
example is the
spring boot
starter. I can
go to the
website,
download the
project, and
try it out
even though I
don't know
anything about
it.
If you already
know about
Maven and the
Maven
archetype, I
don't think
you need this
starter
project. You
can use GitHub
to find a
sample project
and start
working on it.
From this
point of view,
I think the
second option
Ivar mentioned
in the email
is the best
one.
So,
essentially
what I'm
saying is:–
Let's make a
website where
we hide all
the archetype
stuff and let
the user
download a
fully working
sample along
with a
convenient
runtime. The
idea is that
the user will
download and
run the
sample, then
hit the
browser.
Since this is
one of the
major
open-source
projects I’m
contributing
to, I can
assure my
commitment.
Hi all,
I followed
this project
and the
discussion in
the last view
weeks. I also
agree that
this idea of a
starter page
is really
great. And
it's important
to give new
developers
(who haven't
been using
Java EE for
the last 10
years) a
starting
point.
For us here,
everything
that is on the
starter page
is completely
clear and the
"The Jakarta®
EE Tutorial"
explains the
rest. But what
I observe is
that many new
developers
have
absolutely no
patience
anymore. So I
think it would
be good to
offer not only
a selection of
platforms, but
also a small
selection of
minimalist
project
templates. For
example, a
simple RestAPI
example with a
Swagger UI or
a minimal JPA
example. Some
time ago I had
assembled
something like
this for a
customer in a
draft version
including a
Dockerfile to
provide a
simple start
with a default
runtime:
The goal was
to show that
Jakarta EE
brings a lot
of additional
functionality
if you combine
it for example
with Eclipse
Microprofile.
I don't know
what you think
about a
Dockerfiles
with a Wildfly
or Payara
Runtime? Or
whether you
consider
Eclipse
Microprofiles
to be
overloaded
here?
But I think
that at least
we should
somehow give
the
profile/template
selection a
dynamically
reloaded
README.md file
that explains
a bit what the
template
consists of.
It may be
enough to
point the
developer to
the
corresponding
sections in
the "The
Jakarta® EE
Tutorial".
For example:
This
example
contains a
Rest Service
called
'/hello' which
is defined in
the class
RestResource.
You can add
additional
GET, POST and
DELETE
resources.
Find out more
about the
Jakarta EE
Rest API here. If you
want to load
or store your
data from a
Database you
can use the Jakarat EE Persistence API.
I know you
think this is
idiotic, but
for many new
developers
these very
simple hints
are important
to survive the
first half
hour ;-)
===
Ralph
Am
11.11.22 um
08:22 schrieb
Ivar Grimstad:
Greetings
Committers and
Contributors,
I am
super excited
to see the
starter project
moving forward
after a little
standstill.
There has been
some great
progress made
lately! New
contributors
and committers
are on board.
We now have a
simple UI
available at https://start.jakarta.ee that
generates a
simple project
for Jakarta EE
8, Jakarta EE
9.1, and
Jakarta EE 10.
The feedback I
have received
from the
community when
demoing it has
been 100%
positive.
The UI
uses
bare-minimum
archetypes to
generate the
code. The next
steps would be
to add support
for runtimes
and possibly
explore
creating a CLI
as an
alternative to
the Web UI.
In
addition to
the UI, there
are also
several
archetypes
that generate
more extensive
examples being
worked on.
Since
everything is
based on
archetypes,
adding these
and
potentially
other
archetypes
created by the
community
should be
fairly
straightforward.
The
archetypes for
EE 8, 9.1, and
10 could
be mashed
together as
one with the
conditional
logic inside
the archetype.
I am not sure
if this is the
right thing to
do, though.
Keep in
mind that as
we go forward
with EE 11,
12, 13, ...
the older
versions won't
need much
attention.
Sometimes, a
little
duplication is
favorable over
adding another
branch in the
logic (even if
it is just
another
if-statement...).
The
option of
creating a
server-based
solution to
generate the
starter
projects is
still an
option if
someone wants
to pursue
this. It is
always good to
have options.
Personally,
I think the
approach to
base the
starter on
archetypes is
a better and
more flexible
way to go. The
only server
needed is
Maven Central,
and that is
already there
and not our
problem to
maintain. And
it provides
the option for
developers to
consume the
archetypes
directly, via
our UI,
potentially a
CLI, or
directly in
IDEs.
Ivar
--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation
Eclipse Foundation - Community. Code. Collaboration.