User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0
I believe the right thing to do here is begin merging in the hard
work I, Bazlur and Jeyvison have already committed to some of the
now firmly agreed upon features. I believe we should begin this
work in earnest once we have gone through all the major decisions
(and have a committer meeting if we need to) hopefully by next
week in a methodical fashion to avoid future abrupt surprises and
needless duplication of effort.
On 12/1/2022 12:13 PM, Ivo Woltring
wrote:
I would love to also have Docker support them in the “basic”
archetypes or create new ones with the support.
It is a bare necessity IMHO.
We could start
by adding Dockerfile.SUPPORTED_SERVER_TYPE files to the
archetype(s) with basic instructions in the README.md on how
to use them.
And/Or add third
party archetypes (like my own https://ivonet.github.io/archetype/)
to the list. In that case were are possible less restricted in
what we allow to live in there. Even less restrictive in the
licensing?
Eleven people expressed support for including Docker in
the code example, albeit the assertion of support varies
slightly (nine people expressed unequivocal support).
Only two considered it not a priority. Only two are not
in favor of including Docker support.
I believe the consensus is that we should implement
including Docker support as an option as a near term
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.
On 11/13/2022 4:25 PM, Reza
Rahman wrote:
The recently committed Archetypes do not
include Docker support in the generated code
examples. This is difficult to do since the code
examples do not reference a runtime in any way.
The prior direction some of the committers
had been pursuing is to include a working Dockerfile
in the generated code examples in addition to being
able to run the code right away from Maven via a
referenced runtime the user selects at the beginning
of the experience. An example can be seen here: https://github.com/eclipse-ee4j/starter/tree/master/minimal-starter.
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.