Move some old contrib projects to xwiki-attic (batch 2)

Development
1

Hi devs,

This is the second batch after Move several contrib projects to the attic (batch 1).

Here are some dead projects I’m proposing to move to xwiki-attic (and add the information on their exo page when they have one):

WDYT?

Thanks

2

And remove their extension id on exo so that they won’t be listed/installed in the XWiki EM.

3

+1

I would not remove that unless someone try it and find it to not be working. What is sure is that I would not really expect this author to even touch it again (but that’s the case of many extensions).

Yes, that’s the page. Note that its id was removed already, so it’s not installable with EM.

+1

AFAIK it’s not working anymore and more importantly it’s entirely designed to work with a library which is long dead (meaning that the support it’s supposed to provide for well known providers is totally outdated, and most of those providers moved to OpenID Connect since) so I doubt anyone will ever want to work on fixing it (I would bet more on a new extension from scratch).

+1

More importantly, it has never been released, apparently.

+1

+1

4

If we don’t remove it, then we need to fix the CL2 dep and release a new version.

5

Sure, the reason I did not fix this one last week is that from git point of view it appeared as something which has never been released. Apparently it was attached to the page. Better make sure it actually works before investing time into making it releasable and do a 1.0 (probably) release.

But maybe it’s one more argument to just move it to the attic, indeed. I had forgotten how messy it was.

6

Done:

7

Done:

Done:

8

I can’t comment on the code, but I think we need this macro conceptually. We should make it possible to create a panel without writing Velocity code to reduce the need for scripting, which is a security liability. I would even suggest bundling such a macro and migrating existing panels to use it. I say “such a macro” because it doesn’t need to be this exact implementation, we would just need something with that functionality (updated to modern XWiki standards).

9

Done:

10

Done:

11

Yes, I agree. Almost everywhere we only allow velocity needs to be modified to support wiki markup instead. Another example is the scheduler app where the job script is groovy whereas it should be allow any markup instead (and then the user can use static content, or any script macro).

12

All repos move to xwiki-attic and exo pages updated, except for the Panel Macro: https://extensions.xwiki.org/xwiki/bin/view/Extension/Panel%20Macro

1 Like