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
On 12 Nov 2022, at 07:21, Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:
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.
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.
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
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".
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
Am 11.11.22 um 08:22 schrieb Ivar
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
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,
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.
Jakarta EE Developer Advocate | Eclipse Foundation
Foundation - Community. Code. Collaboration.