This is
great. We should
wait a tiny bit and
unless there are
objections from
anyone else I
suggest the
following course of
action, roughly in
order.
* Could
you kindly change
all your potentially
donated code to EPL:
https://github.com/eclipse-ee4j/starter/blob/master/LICENSE?
I believe this
ensures basically no
legal trouble.
Please let us know
when that is done?
* Since
bringing in the
minimal Archetype
will involve some
work, I suggest the
most efficient way
to get it done is
for me to simply
work on a PR. It
will involve
addressing the gaps
I noted, adding
support for multiple
target runtimes as
well as introducing
Maven modules. I
think I can easily
do this by the end
of this weekend. You
and others can
review the PR.
* As you
are aware, Jeyvison
has already started
working on Jakarta
EE 9 support. I
think it's best to
wait a bit for him
to properly finish
that work. So I will
just stick to
Jakarta EE 8
runtimes for my
merge effort. Done
the right way,
adding Jakarta EE
9/10 support should
be quite trivial.
* I think
Ivo, it would be
great if you could
start the UI effort
in parallel. I won't
attempt to pull in
the UI that is there
now. I suggest
starting a fresh
thread on the UI
(this one I think is
already a bit
convoluted). The
first decision is
actually choosing
the backend
technology. Ivar and
the Eclipse
Foundation should
help guide us with
that. The basic
experience should be
allowing the user to
choose some high
level functional
parameters and
letting them
download a zip file
that is ready to go
I think. Whether we
like it or not,
Spring/Quarkus/MicroProfile
starters are
probably our
baseline target
experience to a
large extent. That
said, let's kindly
discuss on a
separate thread and
hopefully others
will also chime in
with regards to the
right direction.
P.S.: * I
think we all can
agree the
MicroProfile/Jakarta
EE situation is very
unfortunate. Unless
you have already
done so, I suggest
sharing your
viewpoints here: https://accounts.eclipse.org/mailing-list/cn4j-alliance.
I advise keeping
modest expectations.
Change in the "right
direction" has been
incredibly slow.
* If best
practices, clean
code and
architecture is your
passion, have you
considered Eclipse
Cargo Tracker: https://eclipse-ee4j.github.io/cargotracker/?
On
5/4/22 3:54 PM, Ivo
Woltring wrote:
Hi Reza, Edwin, et
all,
It is
a darn shame that
JakartaEE and
Microprofile are
still not together
(just my humble
opinion). The fact
is that both are
incomplete without
the other. In my
archetypes I have
put them together
because I think
they should be.
Having said that I
completely
understand that it
may not be
politically
advisable at this
time to combine
them. The trouble
is that Runtimes
like Payara just
give them to you
even if you do not
define them. As
long as they are
separate but open
source projects
they should be
usable right?
Spring uses every
kind of dependency
they need. Why
shouldn’t we? But
this discussion
should not keep us
from coming
together and make
something nice :-)
@Reza
I agree with
almost all your
points on my code.
It is clear that
you took a good
look at them :-)
I tent
to document my
work with actually
usable things.
That is the reason
behind the bash
scripts. If
something is a
command why not
make it
executable? It
brings its own
form of
documentation.
I have
indeed never
integrated my code
with github
actions. I have
never had the time
te really dive
into the actions
and it is till on
my todo list and
some of my
archetypes are
from before github actions
were launched :-).
I will bump it up
on my priority
list.
I most
certainly agree
that most of the
code should work
on its own without
docker. I am a
docker fan and I
made the
archetypes in
essence for
myself… so docker
is a logical
choice for me. I
hate installing
software if I do
not have to :-)
The
license issue is
IMHO solved easily
right? I’ll just
change them. I
have that right or
don’t I as the
sole committer on
my projects?
@Edwin
I like your
summary. And yes
the state of my
archetypes
represent the need
I had at the time.
They are actually
a very minor
effort on my part,
but as I have some
users I feel
obliged to update
the archetype(s)
now and again even
if I am not
actively working
on or with them at
this time. This is
my main drive to
start this
discussion and
hope to find a way
to work together.
@Reza
do you have an
idea on what I can
do to prepare for
a more easy merge?
I have no ego as
far as my
archetypes are
concerned, we can
do nothing,
anything or
everything to them
as far as I am
concerned. My ego
emerges only on
discussions
pertaining clean
code and best
practices and the
like 😄.
Is
there a clear idea
on what the UI
needs to do?
- will
we be working with
archetypes the
user needs to run
themselves or
generate a zip
like Spring does?
- do
we actually want
the same thing as
spring does?
Kind
regards,
Ivo.
Hi
Reza and all,
I
have caught up
with this
thread but
haven't found
time to look
at the code
myself - yet.
Though I would
like to
respond to
your comments.
I
think your
summary/analysis
is very sound
and feel that
I would make
the same
conclusions
when diving
into the
project. After
all, I know
where the
project came
from so I have
a bit of
background
knowledge.
What I would
like to say is
that you are
right that we
need to fix
some issues
regarding the
Jakarta
EE/MicroProfile
alignment,
Maven and
Docker
relation and
or
dependencies
in the
project. The
fact that the
project is in
a certain
state and does
or doesn't
contain some
features, is
because it
came from
Ivo's mind to
experiment
with the full
stack. It's
not impossible
to decouple
things if
effort is put
into this, and
Ivo agrees
with this of
course.
Please
correct me if
I'm wrong but
I hope this
project forms
a solid base
for starter
efforts to
come.
Kind
regards,
Edwin
One
additional
detail to add
- if we all
agree the UI
experience is
not centered
on surfacing
the use of
Archetypes
that the user
then needs to
manually
invoke
themselves but
should be more
like what the
Spring/Quarkus/MicroProfil/etc starter experience looks like, we still
need to sort
through what
the backend
technology for
the UI will
be. I suggest
going with
whatever is
most easily
provided by
the Eclipse
Foundation.
Invoking an
Archetype
behind the
scenes can be
done with
anything that
can make a
command line
invocation on
the
server-side
(could even be
node.js if we
want to stick
to JS on the
server-side
too).
As
promised, I
took some time
to carefully
take a look at
Ivo’s work. I
am sharing my
thoughts on
it. I hope
other folks
here also do a
bit of
analysis and
chime in with
their thoughts
so we can move
forward to
deliver value
for the
community.
- I
think the
clearest
alignment is
with regards
to bringing in
the UI. I
think the
current UI
code exposes
too much of
the underlying
Archetypes. I
think from a
UI
perspective,
the fact that
Archetypes are
used under the
hood at all
are an
implementation
detail. The
user should
mostly be
concerned with
higher level
functional
parameters
such as the
generation use
case (e.g.
minimal/REST
CRUD/JSF
CRUD/etc),
Jakarta EE
version,
target
runtime,
generated
artifact
metadata and
so on. This is
after all the
experience for
the Spring
initializer,
etc. However,
overall I
think these
are minor
deltas and UI
code looks
fairly sound.
- The
code is
definitely
focused on
minimal
generation,
just with a
simple POM,
Jakarta EE
deployment
descriptors
and a very
simple hello
world REST
endpoint. I
don’t think it
does any real
harm to add
this option to
the starter
here. Overall,
the amount of
additional
code would be
very small
(perhaps in
the order of a
few hundred
lines). I do
think the
nature of the
generated code
is different
enough to
warrant *one*
separate
Archetype with
a robust post
processing
script that
handles minor
variants like
target runtime
and Jakarta EE
version.
- The
examples mix
and match
MicroProfile
and Jakarta
EE. Given the
ongoing
Jakarta EE and
MicroProfile
alignment
conversations,
I think we
need to tread
carefully here
and maybe even
ask for advise
from the
Jakarta EE
steering
committee/platform
specification.
For one, it
makes the
situation odd
for runtimes
like
GlassFish. My
inclination is
to stick to
vanilla
Jakarta EE in
this starter
for now and
just stay out
of a
potentially
contentious
conversation.
- The
code makes no
effort in
trying to use
Maven plugins
to have a
self-contained
runtime
experience
right from
Maven (e.g.
mvn clean
package
tomee:run).
Honestly I
believe this
is a mistake.
With embedded
runtimes like
Spring Boot,
Quarkus, etc
developers
expect to
run/test
applications
right from
Maven. I think
even in a
minimal
starter
project,
having this is
important in
order to
position
Jakarta EE as
something
modern. This
is what we
have in the
starter
already for
reference.
- The
code really is
quite
dependent on
Docker, going
as far as
making an
assumption
that users
must have a
Docker Hub
account.
Honestly I
think this too
is a usability
mistake. Many
developers are
still very new
to containers
so needlessly
aligning too
much with
Docker is a
potential
usability
hazard that I
don’t think we
really need to
get into. It
should be
mostly
possible to
use the
starter
without Docker
at all and
still have
easily running
code.
- The
code has a
number of
scripts that
abstract over
relatively
simple Docker
commands. This
can actually
lead to the
impression
that using
Jakarta EE
with Docker is
so difficult
that you need
scripts to
deal with the
complexity. I
suggest we
simply
generate a
Dockerfile and
document the
few relatively
simple
commands to
build a Docker
image that
contains the
Jakarta EE
application
and run the
Docker image.
This is what
we have now
for reference.
- The
code does not
utilize GitHub
Actions or any
other kind of
automated
sanity
checks/tests.
I think we
absolutely
need that for
a distributed
project with
many potential
contributors.
- There
is no index
page and the
documentation
is quite
minimal. Since
we have quite
a bit more
visibility as
an official
Jakarta EE
umbrella
project, we
will obviously
need to
improve that.
If
this all seems
reasonable to
most folks
here, I am
happy to begin
working on a
PR to
basically
merge the
efforts (I may
need a tiny
bit of help
with the UI as
I am not that
proficient
with JS yet).
I think this
is small
enough to just
be a few
evenings’
effort. I
could get it
done by the
end of the
weekend so we
can keep
focusing on
forward
progress
delivering
more releases.
Unfortunately
with the
popularity of
the Spring
initializer, I
am afraid we
have no choice
but to have a
UI. I do
believe at
least
initially we
need to focus
on a simple
UI. Certainly
trying to
present a
“components”
view of
Jakarta EE is
something we
should
prioritize
lower at this
time. I think
it’s best to
just evolve
features
including the
UI over time.
Part of the
reason the
project was
stuck for so
long is a lot
of analysis
paralysis
around
requirements
and the UI. I
think we
should remain
in a different
gear now and
focus a bit
more on
delivering
working
releases, even
if
incremental.
I do
have to say
that
personally I
believe a
command line
is all you
need because
the array of
options indeed
could be quite
small. That’s
why I would
prefer we kept
a mindset of
being somewhat
agnostic of a
UI. Luckily as
a side effect
the IDE
experience
also remains
nice as most
IDEs have
pretty good
support for
Maven
Archetypes.
It’s fairy
easy to
support all
three pathways
equally
without too
much work.
With
regards to
Gradle, I
spoke with
Bazlur and we
feel we could
easily do this
without too
much hassle
using Maven to
Gradle
converters
behind the
scenes. The
plan was to
look at this
once we have
delivered a
few more solid
releases.
I
should add
that I am not
necessarily
totally
against having
a more minimal
project
generation
option. What I
am having
trouble
visualizing is
what exact
content is
worth putting
into a minimal
option. Just a
pom does not
feel like it’s
worth the
effort because
of the nature
of Jakarta EE.
Perhaps
looking at
what Ivo has
might help. I
will try to do