| Re: [krazo-dev] Future of Krazo extensions |
Hi all,
because there was no more feedback and we reached the 4th august, I'm closing the 'poll' by this mail. According to the answers, variant (1) is preferred. So I'm going to organize a repository inside the Eclipse Foundation which will be called 'krazo-extensions' (or similar) and migrate the extensions inside this repository. Also I'll add the required Jenkins jobs so we can build and release these artifacts.
Thanks for your participation and feedback. I'll get in touch with you as soon as the migration has been done.
Best regards,
Tobias
Thanks for the clarification, Tobias. Then for sure my preference would be (1). It's cool that Krazo can do all these view engines, but maintaining them should not go at the cost of progressing Krazo.
Thanks,
Maarten
On 01/08/2022 20:57, Tobias Erdle wrote:
Hi Maarten,
thanks for your feedback!
A view engine is the integration of a template engine. The specification expects JSP and JSF to be a mandatory view engines in each Jakarta MVC implementation at the moment, so those are part of the Krazo Core. In addition, we have the „Extensions“ (ext module inside the repository), which provide support for additional template engines like Thymeleaf.So Krazo will always have at least one template engine, but we‘d like to reduce the maintenance effort for additional engines, which is the cause for this mail :)
Thanks,
Tobias
Am 01.08.2022 um 20:30 schrieb Maarten Mulders <m.th.mulders@xxxxxxxxx>:
Hi all,
Thanks for the reminder! First of all, I think it makes sense to focus the limited time there is to what matters most.
Do I understand correctly that a view engine is not always an extension, but view engine could be an extension? If so, I would say we should keep at least 1 view engine in Krazo itself. I guess that would be JSP, since that is available in Servlet Containers anyway.
With the assumption that Krazo would still have at least 1 view engine available "out of the box", I would also prefer option (1).
Thanks,
Maarten
On 31/07/2022 15:38, Christian Kaltepoth wrote:
_______________________________________________Hi all,
sorry for the delayed response. I was on vacation and tried to stay away from any kind of computer for some time. ;-)
I agree that having many view engine extensions in Krazo isn't optimal. Especially because most of them were created actually just for showing how easy it is to build a custom view engine. But maintaining them and keeping them updated is a lot of work.
Therefore, I would also prefer option (1) which means that we would move them to a separate repo/project.
Christian
Am So., 31. Juli 2022 um 15:07 Uhr schrieb Tobias Erdle <tobi.erdle@xxxxxxxxx>:
Hello again,
because there was just one reaction to this mail (thanks again), I‘ll extend the feedback period until next thursday, the 08/04/2022. It‘d be great to get any more feedback, even something like „I‘m not interesed in those extensions, do whatever you want“ ;)
Thanks and best regards,
Tobias
> Am 23.07.2022 um 14:46 schrieb Tobias Erdle <tobi.erdle@xxxxxxxxx>:
>
> Hi all,
>
> in the last MVC meeting on Thursday, 07/21/2022, we talked about the future of Krazo Extensions.
>
> For a while now, the situation is that we have hardly any active developers, but a lot of code with external dependencies, which almost always need CQs with every update. Anyone who has ever created one knows how cumbersome this is and how much time it can cost. In addition, the development of Krazo Core is slow. For this reason we want to try to focus more on core development and minimize effort with extensions etc.. To achieve this, there are several ideas:
>
> 1. the extensions are completely outsourced to a separate repository and the maintenance runs in parallel to Krazo, if necessary by other people. Whether this runs under the umbrella of the Eclipse Foundation or not has to be clarified.
>
> 2. only selected extensions are kept in the Krazo repository, for whose engines there are regular updates or which are widely used. For these, however, maintainers should be found.
>
> 3. everything stays as it is, but extensions are kept alive with minimal effort or removed if the maintenance effort becomes too high.
>
> Since this is a breaking change and Krazo 3.0.0 is slowly moving towards release, the topic should be discussed soon. I would suggest that there is at least a majority in favor of one of the variants by 07/30/2022, so that further action can then be taken. If there are any other ideas or thoughts, feel free to mention them.
>
> Thanks and best regards
>
> Tobias
>
> P. S.
> Personally, I would currently prefer variant 1, because this way, if necessary, new maintainers can be found and at the same time the Krazo repository would become leaner. Since I like to use Thymeleaf and the extension, I would also take over the maintenance.
>
> P. P. S.
>
> You can also comment into https://github.com/eclipse-ee4j/krazo/issues/319, which is the corresponding issue to this mail.
>
_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
--
_______________________________________________ krazo-dev mailing list krazo-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
_______________________________________________ krazo-dev mailing list krazo-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
_______________________________________________ krazo-dev mailing list krazo-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
Attachment:
OpenPGP_0x1A46056E808BB830.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature