On 11/14/2022 6:13 PM, Emily Jiang via
starter-dev wrote:
The UI can support both and add an option on the UI to
specify which way the end user would like to use. I also
suggest adding some metrics to see which one has more usage
and invest more on that route over the time.
Definitely. While I did have the
Starter UI as the primary use case for the project,
a sensible set of easily discoverable and usable
Archetypes has many benefits. They provide the
simplest possible command line experience that does
not require installing a CLI, they are the most
Maven native way of generating projects and a very
easy way to allow project generation from IDEs
without a custom IDE plugin. I think we can document
all those scenarios in the wiki even with the
Starter UI.
To be honest another reason I had
suggested the Archetype route is that it provides a
very good, proven framework for dynamically
generating projects. We use it at Microsoft for
exactly that reason including fully leveraging
Velocity templates and Groovy scripts. I actually
consulted our engineering folks before embarking on
this path and they could not recommend it enough.
Our Archetype for Azure Functions is especially nice
and I borrowed quite a few ideas from it for this
project: https://github.com/microsoft/azure-maven-archetypes.
I think if the starter project does
pursue the ZIP solution, then the Maven archetype
solution that is currently in-place should remain as
well. I agree in the end that using archetypes to
generate the code provides lots of flexibility.
Whether the tool generates a project
ready to use, or a zip file I have to unzip and
then use is really a non-issue for me. I have no
opinion of this matter.
If generated on a server, I see a zip file as
the obvious delivery mechanism.
I agree with Ondro that using archetypes to
generate the code on the server and then zip to
deliver to the client makes sense.
The key point is using archetypes to generate
the code, which gives the user flexibility to
use them directly, or via a tool or UI.
The recently committed Starter UI code asks
users to select from various Maven
Archetypes and essentially outputs the exact
command to run a specific Archetype. The
user must then execute this command to
generate the actual code example.
The prior direction some of the committers
had been pursuing is to run Archetypes
behind the scenes based on higher level
functional inputs in the Starter UI such as
Jakarta EE version, Java SE version, Jakarta
EE profile, etc. The Starter UI would then
generate a zip file that the user downloads
containing the actual generated code
example. It can be noted that this is the
approach for the Spring, MicroProfile, etc
Starter. This allows for the possibility to
convert the example code from Maven to
Gradle behind the scenes using 'gradle
init', etc.
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.