Am 13.04.2021 um 14:35 schrieb Oliver Lietz:
On Tuesday, 13 April 2021 08:03:02 CEST Carsten Ziegeler wrote:
IMHO Resource versioning is now a common practice is Sling/AEM projects.
I strongly suggest keeping API and helpers/utils in a single place (as we have
done it so far) instead of spreading it over multiple modules. Any consumer of
Scripting SPI is anyways depending on Sling API.
We are not putting each and every utility api into Sling API. If it is
of general purpose *and* of interest to users of the Sling API, then
yes, it makes sense to consider adding it there.
But for example utility api for eventing is part of the event api.
I still fail to see what a general user of the resource api can do with
the ResourceType class?
It is scripting related, so why not have it part of scripting?
We can easily inline org.osgi.framework.Version into the API bundle to remove
the dependency if required. Commons Lang3 is only used in the test and was
already present:
Sure we can solve the dependency problem, the important point is that we
consider and look at this.
Regards
Carsten
https://github.com/apache/sling-org-apache-sling-api/commit/
02cb7f1bbc4836865afd7e9964d3be1380daf734
Regards,
O.
Regards
Carsten
Am 12.04.2021 um 18:32 schrieb Radu Cotescu:
Hi Julian,
The reason for pushing back on this is that ResourceType [1] is more of a
utility class, rather than an API one. It’s a final class, used to:
Generate require and provide capabilities with the help of the
scriptingbundle-maven-plugin Set up the servlets for each provided
capability in org.apache.sling.servlets.resolver
Granted, we can move it into a dedicated package in o.a.s.api, but I
really don’t see the value. Moving it will also make o.a.s.scripting.spi
(providing the rest of the API needed to support bundled scripts) depend
on o.a.s.api. Is it really worth it?
Regards,
Radu
[1] -
https://github.com/apache/sling-org-apache-sling-scripting-spi/blob/e14f6
c23df591646d01fb3aaa185e9360cadcaa0/src/main/java/org/apache/sling/scripti
ng/spi/bundle/ResourceType.java#L41>
On 12 Apr 2021, at 16:57, Julian Sedding <jsedd...@gmail.com> wrote:
Hi *
I agree with Olli that moving ResourceType later will not happen,
because it causes too much disruption. I also agree that it is
generally useful and not inherently linked to scripting.
Why can't we just move it now, before we make our lives harder? If
o.a.s.scripting.spi should not depend on o.a.s.api, then it would
still be possible to embed/inline a self-contained class ResourceType.
Regards
Julian
On Thu, Apr 8, 2021 at 10:56 PM Oliver Lietz <apa...@oliverlietz.de>
wrote:
On Thursday, 8 April 2021 15:48:27 CEST Radu Cotescu wrote:
Hi Olli,
Hi Radu,
On 1 Apr 2021, at 21:26, Oliver Lietz <apa...@oliverlietz.de> wrote:
I have a use case for ResourceType not related to Scripting and would
like
to see it in Sling API (see SLING-9999 for reasons) where it fits
well.
https://github.com/apache/sling-org-apache-sling-scripting-spi/blob/ma
ster
/
<https://github.com/apache/sling-org-apache-sling-scripting-spi/blob/m
ast
er/>
src/main/java/org/apache/sling/scripting/spi/bundle/ResourceType.java
WDYT?
I’ve already replied to your concern at [0], but I don’t mind repeating
what I said:
“If we really need to use the ResourceType class somewhere else, we can
move it to the o.a.s.api bundle when the time comes. We can then
deprecate the one from o.a.s.scripting.spi and remove it once there
will be other incompatible changes added by the other interfaces.
Until then, I really don't see the need to spread 5 interfaces over 2
bundles and increase the dependency footprint for the current
consumers.”
And still it does not make sense nor is it consistent.
My initial proposal was to have the Bundle API in bundle
o.a.s.scripting.api (no additional bundle) but you rejected to not
depend on Scripting API.
The o.a.s.scripting.spi bundle is fine but the class (not an interface)
ResourceType should be in Sling API from the beginning:
- it is useful in different contexts not related to Scripting
- better visibility in Sling API
- most modules depend on Sling API anyways
- close to Resource classes (o.a.s.api.resource), similar helpers (e.g.
o.a.s.api.resource.path)
- BundledRenderUnitCapability depends on ResourceType, moving/changing
it
later is a major change (we try to prevent such breaking changes in
Sling)
- it is no effort to do it now, we need a new release of Sling API
anyways
Unless you have something already committed to a repository from which
you
plan to cut a release soon I'd prefer to go ahead without it for now.
So for now would mean never, see above.
Regards,
O.
Cheers,
Radu
[0] -
https://issues.apache.org/jira/browse/SLING-9999?focusedCommentId=17295
320&
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#c
ommen t-17295320
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
