User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1
Yes, once we mature the conversation a bit more, that's
absolutely my intent - creating issues per logical work item. I
believe it's best to have a bit more flexibility for more
tentative discussions via the mailing list right now.
Is that alright or is tracking discussions on GitHub
significantly easier? I can try to transfer the discussion to
GitHub issues on Sunday if not sooner if needed.
On 11/18/2022 1:28 PM, Ryan Cuprak via
starter-dev wrote:
For some of the suggestions, can/should they be
filed at issues on GitHub? The discussions can then be easier
tracked on a per-suggestion/issue basis?
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.