| Re: [starter-dev] Decision - CLI |
The decision on this particular topic seems relatively straightforward. I have tentatively summarized and tabulated it (cell 8Q): https://docs.google.com/spreadsheets/d/1bthiYVjX_UK7Xp2qQmq93awPwVhVCDnprGdzeMtv_ow/edit?usp=sharing. I have also updated the preexisting GitHub issue here: https://github.com/eclipse-ee4j/starter/issues/138.
Eight people have identified this as a lower priority issue to be addressed later, though there appears to be variance as to how much later. Four people expressed unequivocal support for this issue.The recently committed work includes a CLI facade over a handful of static Maven Archetypes.
The prior direction some of the committers had been pursuing is to first build out support for the smallest set of mostly self-documenting dynamic Maven Archetypes and a Starter UI (that supports both Maven and Gradle). A CLI would be considered later mostly to better support Gradle in the command line (e.g. invoking 'gradle init' behind the scenes on a generated Maven project).
On 11/13/2022 2:58 PM, Reza Rahman wrote:
As promised, I read through all the messages carefully and attempted to tabulate the decision record so far: https://docs.google.com/spreadsheets/d/1bthiYVjX_UK7Xp2qQmq93awPwVhVCDnprGdzeMtv_ow/edit?usp=sharing. Could everyone here kindly take a look and make sure I got it right? It would also be very helpful to fill in any gaps with your viewpoints (the entire sheet is editable).
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.
On 11/12/2022 9:16 AM, reza_rahman@xxxxxxxxx wrote:
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.
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Jeyvison Nascimento <jeynoronha@xxxxxxxxx>
Sent: Saturday, November 12, 2022 7:39 AM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Some updates on the progress made latelyWhile 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.Wow, being here from the beginning i can say that is really awesome to see so many people involved on this =DI 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).
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. ButMaven 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
Ivo.
On 12 Nov 2022, at 07:21, Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:
Hi, all,
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.
Thank you,
-Bazlur
![]()
On Fri, Nov 11, 2022 at 11:49 AM Ralph Soika <ralph.soika@xxxxxxxxx> wrote:
_______________________________________________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:
https://github.com/rsoika/ralphs-microservices
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 ;-)
===
RalphAm 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--
Imixs Software Solutions GmbH
Web: www.imixs.com Phone: +49 (0)89-452136 16
Timezone: Europe/Berlin - CET/CEST
Office: Agnes-Pockels-Bogen 1, 80992 München
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsführer: Gaby Heinle u. Ralph SoikaImixs is an open source company, read more: www.imixs.org
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
--
Jeyvison Nascimento
_______________________________________________ starter-dev mailing list starter-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev