| Re: [krazo-dev] Future of Krazo extensions |
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
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