Only two folks are in favor of this. Three are not in favor and
seven are identifying it as essentially a low priority or not a
priority. I believe the consensus is that this is a low
priority. Please discuss further here or on the GitHub issue if
required. Otherwise, it's probably best to move on to the next
decision point.
P.S.: I am thinking as well as discussing, it's best to
tabulate and summarize each decision in turn. If you would like
me to tabulate and summarize all input so far proactively, just
let me know and I will do it.
On 11/13/2022 5:26 PM, Reza Rahman
wrote:
In addition to the Jakarta EE use cases and technologies to
be covered, a consideration is whether to also include
MicroProfile use cases and technologies such as Open API,
Health, Configuration, JWT, etc.
The current project direction is to not include MicroProfile
but to first focus on Jakarta EE use cases and technologies.
MicroProfile use cases could be covered later once the
alignment with MicroProfile and Jakarta EE is better
understood. We should probably seek guidance from the Jakarta
EE steering committee whether the scope of the Jakarta EE
Starter should include MicroProfile. Some Jakarta EE runtimes
do not support MicroProfile.
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.