Move to org.orderofthebee group and publish to Maven Central?

[jpotts]

Is there anything that keeps the js-console artifacts from being published to Maven Central other than possibly that none of the active maintainers control the current group (de.fmaul)?

If that is the only blocker, can we refactor the add-on to be in the org.orderofthebee group so we can push this to the public Maven repo?

[shazada]

I would agree on this as well. We're building the JS-console as an amp & jar internally and publishing it to our own Nexus, but would love to have in the Maven Central if everyone agrees.

[AFaust]

@jpotts / @shazada Given that Share is going to be EoL-ed at some point, I had already considered (re-) implementing JavaScript Console, or at least just a frontend for it, within the OOTBee Support Tools addon. Given that ACS 7.0 has introduced some library updates / changes breaking JavaScript Console (immediate issue I see is with Apache Commons Lang dependency), some change is definitely necessary to allow continued use of the important functionality the addon provides post ACS 7.0, and would definitely require the ability to push a new release to Maven Central.

[shazada]

Hi @AFaust great looking into this. I haven't had an implementation with acs 7.0 so didn't find an issue with that.

Regarding re-implementing elsewhere the js-console: I guess we use share just as a backend tool, this also becomes more necessary when one uses the RM-module where share is still the main UI.

We could spend some time to get this fixed in Share, I also had ideas to get it re-implemented in the Content-App. What are your thoughts on that?

[AFaust]

Cristina recently brought up the question of admin capabilities in the Content App and my view on this has not changed since I posted my reply to her idea: I see the Content App - or any other ADF-based app - as end-user UIs only. Putting effort into admin capabilities there - with the barely useable public ReST API requiring many custom web scripts to back it up - leaves a lot of customers who do not / never will use those kinds of UIs to miss on those capabilities or be forced to deploy an app they otherwise have no use for, i.e. like some ACA/ADF users right now may be feeling with Share.

The ACS Repository and its Admin Console are the common denominators in all deployments, so admin tooling should be made available there as a priority for the largest possible user base - which would still allow anyone interested in ACA/ADF-integrated capabilities to use the same backend for their custom frontend.

[AFaust]

The OOTBee Support Tools addon has finally been released in version 1.2.0.0 with the JavaScript Console fork, including Alfresco 7.x compatibility, even with the latest change in Enterprise hotfix for the scripting DoS vulnerability.

[shazada]

@AFaust where is the forked js-console found? We've just patched it ourselves for the time being.

[AFaust]

As always it is in Maven Central - and in this GitHub project