User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1
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.