On Dec 7, 2022, at 11:31 AM, reza_rahman@xxxxxxxxx wrote:
OK. Let me invest some time in formulating an efficient way we can discuss the details asynchronously. I may not have time to do that until the weekend unfortunately. I do think it’s best to do this to a reasonable extent to avoid needless churn later and allow us to focus on efficient delivery.
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Kito D. Mann <kito.mann@xxxxxxxxxxx> Sent: Wednesday, December 7, 2022 12:01 PM To: starter developer discussions <starter-dev@xxxxxxxxxxx> Subject: Re: [starter-dev] Decision - use cases
Indeed the idea either way is to “build up” to a cehesive example (basically CRUD being the ceiling). The essential difference between A and B is basically one of granularity (and hence slightly more choices for B). Minimal/without Persistence just means a “hello world” REST endpoint that doesn’t really do anything.
By the choices, I literally mean the choices we want in the UI. Perhaps that’s an easier way to think about the requirements? If easier, I can try to create a quick screen mock-up with an outline of what would be produced for each option?
That could help. I imagine we could still do both without a lot of overhead. For any given starter, we supply the technologies + the use case. That way the user can access the starter either way... So if you pick "Minimal" you can choose which technologies you want to see a Minimal starter for. And vice versa.
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Kito D. Mann <kito.mann@xxxxxxxxxxx> Sent: Tuesday, December 6, 2022 9:06 PM To: starter developer discussions <starter-dev@xxxxxxxxxxx> Subject: Re: [starter-dev] Decision - use cases
I can meet if necessary, but I agree that we should be able to do this asynchronously. That being said, I don't see A and B as mutually exclusive. For example, if someone chooses REST as a technology, couldn't the example be minimal or a CRUD app?
I think let's wait a couple of days and look to see how we can
schedule?
I also think asynchronous is not too hard. If my analysis seems
correct enough, it's mostly about choosing one path or the other
with any additional commentary needed:
* A: Choices based on mostly use case (and add lesser used use
cases/technologies later): REST (minimal), REST CRUD , Web app
CRUD
* B: Choices based purely on technology (and add lesser used
technologies later): REST/Faces (choose one), JSON/XML (choose one
for REST), Persistence, Validation, Test
On 12/6/2022 7:57 AM, Jeyvison
Nascimento wrote:
That's fine for me. I think Ivar already sent some
schedule options a few weeks ago
I think this requires a bit more careful thought,
input and discussion before it should be considered
resolved. Is a face-to-face meeting with very
committed folks the best way to properly resolve this
topic so that the code can move forward with sound,
documented consensus?
On 12/4/2022 4:05 PM, Reza Rahman wrote:
The votes are close enough such that I would
certainly be OK with this approach (so the choices
for now would be just minimal, REST CRUD or web app
CRUD). It does allow us to leverage the existing
work faster while still allowing for future
evolution. This may actually also fit the underlying
Jakarta EE ethos behind profiles better. What do
others think?
The alternative is to try to introduce more
granular per-technology choices on top of the
existing CRUD/minimal code examples. Taking very
basic things like CDI/JSON/transaction handling for
granted (that is adding it whenever it makes sense)
the choices could be something along these lines:
* REST (make choosing either this or Faces
required?)
* Persistence
* Validation
* XML (make it an option instead of JSON?)
* Test
* Faces
For reference that will basically leave out things
like the following (personally I think a lot if not
all of this is out of scope for something geared
towards smoothing out the beginner experience):
* Security
* Messaging
* Mail
* Batch
* WebSocket
* Concurrency
On 12/4/2022 2:55 PM, Kito D. Mann wrote:
FYI there are already plans to work
on Jakarta EE guides and revamp the tutorial,
and as Reza mentioned, these are separate
efforts from the Starter.
I hadn't seen the Helidon starter,
but I took a look at it and I like it a lot,
too. I'm tempted to play with it with my son
while he's still into Pokemon 🙂.
With respect to the use cases, I think we
should should do this:
* Finalize the REST CRUD and Minimal use
cases
* Build scaffolding to easily allow
stakeholders for individual specs to create
per-technology use cases
And then the first per-technology use-case
can be Faces CRUD (assuming there are resources
available)/
I think there is
definitely a separate problem space
for guides, the tutorial and
examples (as does more of an
end-to-end application like Cargo
Tracker or Spring’s Pet Clinic)
There is a tiny bit of overlap, but
really not that much.
I too like the
MicroProfile and Helidon starter
approach better than the Spring
starter approach. I think it’s
relatively easily doable here too.
Having examples per
technology is a good idea, but
Jeyvision mentioned that it would
require much effort. That's true,
but we now have a lot of
contributors, and we can invite more
people to join this project.
I like the Helidion starter better
than the spring starter. Spring only
adds dependencies—no code at all.
However, spring has guides, which
are also great.
I'm working on creating some guides,
but the Helidion approach is way
better.
On
Sat, Dec 3, 2022 at 9:57 AM
Jeyvison Nascimento <jeynoronha@xxxxxxxxx>
wrote:
I still think we
should have examples per
technology but I understand that
maybe it's better if it's a
long-term goal since it will
require a lot of effort.
I don't know how much
cargo track uses the Jakarta
technologies but if it has a
good coverage of examples it
may be a good first step.
Of course, things can run
in parallel but if we're going
for the per technology option
we have to discuss if the
examples will be independent ,
for example, or if the
technology is just another
layer in one single general
example.
A possible reasonable
summary is that we should
implement a minimal option
as a "floor", and add
options per technology
(most likely including
things like tests as an
option too) with REST CRUD
and/or web app CRUD
(Faces) being the
"ceiling" for now. Do
folks think that's a
reasonable way to proceed
for now?
For full context here is
a complete breakdown of
collated input:
* Per technology - 9
* REST CRUD - 9
* Minimal - 8
* Web app CRUD (Faces) -
3
* JUnit tests - 2
* Integration tests - 2
* Allow addition of
Archetypes external to
project - 1
* Cargo Tracker - 1
* _javascript_ interface -
1
On 11/13/2022 4:13 PM,
Reza Rahman wrote:
The recently committed
Archetypes include a
minimal "hello world"
rest endpoint code
example.
The prior direction
some of the committers
had been pursuing is to
include two use cases
the user can choose from
- a minimal "hello
world" rest endpoint as
well as a REST CRUD code
example. The REST CRUD
code example makes use
of an embedded database
as well as a working
JUnit test. The
corresponding minimal
Archetype is here: https://github.com/eclipse-ee4j/starter/tree/master/minimal-starter.
The REST CRUD Archetype
is here: https://github.com/eclipse-ee4j/starter/tree/master/rest-starter.
A web app CRUD example
using Faces had been in
planning as a low
priority. It can be
noted that this is
somewhat in line with
the approach for the
MicroProfile Starter.
Another possibility
discussed early on but
not pursued currently by
any current committers
is dynamically including
examples in the
generated code such as
for security, batch,
mail, WebSocket, etc.
Yet another possibility
is including Cargo
Tracker in the Starter.
It is worth noting that
Cargo Tracker currently
supports Payara with no
short term committed
plan or resources to
support other runtimes.
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.
_______________________________________________ starter-dev mailing list starter-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev