Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [starter-dev] Project structure change proposal voting
Currently it is a simple web application. I would like to use different templates for different purposes.
 
Introduce a *Applicatoin Type*(your purpose) to simplify the deps management and package archive and use a BOM as possible.

* Regular Web Application(Faces) -- (Web profile)
* Regular Web Application(MVC) -- (Web profile)
* Event-Driven Application(WebSocket, JMS/AMQP) -- (Full profile)
* Enterprise Application(EAR archive) -- (Full profile)
* RESTful API Application(JAXRS) -- (Core profile)
* Microservice(Microprofile) -- (Microprofile)
* Client Application(Jaxrs Client,  MicroProfile RestClient, etc) -- (standalone deps)

Then just need to choose the Java version and Jakarta EE version.

---

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

GitHub: https://github.com/hantsy

Twitter: https://twitter.com/@hantsy

Medium: https://medium.com/@hantsy


On Wed, Jan 11, 2023 at 2:16 PM Ryan Cuprak via starter-dev <starter-dev@xxxxxxxxxxx> wrote:
I vote +1

I agree with Bazlur, it can be split later if it becomes a problem. 

On Jan 10, 2023, at 8:43 AM, A N M Bazlur Rahman <bazlur@xxxxxxxxx> wrote:

My vote is: +1

I believe the complexity of the project is manageable. Keeping the code in a monolithic format helps avoid duplication and ensures consistent functionality across all runtimes. The 2–3K lines of code should not pose a significant maintenance problem in the future. If it does become an issue, we can always split it later. The "wait and see" approach seems appropriate in this case.

On Tue, Jan 10, 2023 at 3:57 AM Jeyvison Nascimento <jeynoronha@xxxxxxxxx> wrote:
+1

Em ter., 10 de jan. de 2023 07:54, Ivo Woltring <ivo@xxxxxxxxx> escreveu:
My vote is: 0

I agree with all of Ivar’s reasons, but I may feel a bit more strongly about them.

I have been maintaining multiple archetypes for a couple of years now (https://ivonet.github.io/archetype/) and have had no maintenance problems at all.
Note that we are talking about an archetype and not duplication of a code base even though it may seem that way. 
Every time we create a new archetype we are actually creating a new template to be maintained. from that point onwards there is no connection to other archetypes anymore as they have their own lifecycle due to reasons like runtime / Jakarta version etc.
Jakarta EE version(s) that are deprecated are still there but do not need maintenance anymore and one can just stop maintaining them without any code change or if statement.
Testing a single purpose archetype is trivial.

I fear that having all versions in one archetype is just asking for trouble and not even on the long run. Soo many dependencies to take into account and so many extra flows to test. 
I have worked for years on these kinds of projects and I have even taken the time to create my own archetypes because they are so useful.

IMHO it is a shame to discard senior developers and we should not make thqt distinction.
Starter projects should be for everybody equally and should serve all purposes.

The approach Ivar and I started with the UI currently on the site allows for other developers to add their archetypes easily which could make adoption fun and could create a community if we promote that at conferences.

I think working on a single archetype will limit participation to those few already working on it and not stimulate participation at all.
At least that is how I feel.

I also agree with Emily Jiang that we should see if we can get metrics and our opinions should reflect what comes out of that.

I would vote for the double approach for now and get these statistics.

Other that that I am strongly of the opinion that real demo code should not be in an archetype but in tutorials.

Ivo.


On 10 Jan 2023, at 00:08, Jeyvison Nascimento <jeynoronha@xxxxxxxxx> wrote:

Hello, folks.

This is a follow up from the meeting we had today. As talked before and can be checked in the meeting records, we wanna have a final decision about the project structure so we can proceed with the modifications as soon as we can.

This proposal is about we keep the monolith approach and reevaluate when needed.

Since this decision will directly affect an on-going house cleaning PR made by Reza, I'd suggest Friday(January 13th) as an end date.

Let us know your vote.
_______________________________________________
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

_______________________________________________
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev

Back to the top