Spring will allow you to integrate with tons of other open source projects. It is one of their absolute selling points. I agree that we should focus on Jakarta EE tech for now but later….??!
I would love Example projects with Jakarta EE integrating with MicroProfile / OpenApi / Graph-QL or any other cool tech out there, with the possible plumbing code included.
We can also stimulate community donations there. I e.g. already have some with Payara and docker and MicroProfile in maven central… That should not be a problem right?
I agree, When we have a Jakarta EE starter, it should be focussed on Jakarta EE specs. If you want to have a starter that generates projects for any kind of enterprise project, with Jakarta EE, MicroProfile and all common libraries and frameworks, it becomes in my opinion, a huge and unmaintainable project.
There is already a starter for MicroProfile (start.microprofile.io) that already does this. We should NOT duplicate this effort as it is not within the scope of this project.
We can link to the MicroProfile starter from our page and contribute to that project if required.
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.
_______________________________________________ starter-dev mailing list starter-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
