[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [krazo-dev] Future of Krazo extensions
|
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,
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
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