User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2
I have written a free Maven Plugin with a
Autodeploy and Hotdeploy function that we use in our own projects.
It automatically deploys during the 'install' phase the artifact
to a running docker container providing the runtime. The advantage
of this solution is that no additional configuration in the IDE is
necessary and the solution is independent from the
runtime/application server. We automate also the docker container
build process in the pom.xml.
What we currently do is generate a Dockerfile
if we are able and skip if it is not possible. Similarly,
the thought is to skip the ability to start from Maven
directly if such automation is simply not possible (such
as with WebLogic as an example). The plan is to generate a
README (likely in TXT format) that briefly explains what
can be done with the generated project. By all means, this
means doing a bit more work on our end. However, in my
view this extra little bit of work can ultimately make all
the difference in a newcomer choosing Jakarta EE vis-a-vis
going elsewhere.
Input validation is another good discussion
but one that’s perhaps a bit premature right now? The
basic idea is to validate input and provide useful error
messages to the user via the Starter UI and/or Archetype
in case of invalid input (for example choosing a runtime
that is not Jakarta EE 10 compliant just yet). I believe
something very similar is done for the MicroProfile
Starter?
Also, not all runtimes might provide a Docker
image, like Glassfish. Also not all runtimes are available
at the same time, for example, currently only Payara and
WildFly have final products for Jakarta EE 10. All these
differences makes it complicated, especially when
including functionality for specific runtimes (like Docker
images)
And most runtimes have a dedicated start website or
project themselves with all the options. Are we going to
duplicate all this work and maybe not provide optimal
support, creating optimal projects?
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.