[
https://issues.apache.org/jira/browse/SLING-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14182602#comment-14182602
]
Felix Meschberger commented on SLING-4001:
------------------------------------------
bq. The Require-Bundle isn't good practice but clean from an OSGi point of view
Require-Bundle is actually bad practice and not clean at all from an OSGi point
of view. In my (and other's) opinion Require-Bundle is actually an anti-pattern
and a specification mistake. For backgrounds: AFAICT it was introduced into the
spec under pressure from Eclipse to help Eclipse migrate over to OSGi. Not sure
whether the Eclipse community would still push for it if they knew then what
they know now.
The problem with Require-Bundle is that (a) it creates tricky class loading
situations, (b) it actually creates strong coupling, and (c) it "wires" to a
deployment container rather than to its contents. I think the latter point is
the most problematic: Require-Bundle binds to a named container of anything.
And by anything I mean anything: It may be the expected classes today but may
not be tomorrow. Bundles and Jar files being containers don't define a
contract, they just happen to be collections of something.
Contrast this to Java Packages which have been defined as a way to "namespace"
the Java class space. Classes access other classes through fully qualified
class names which are made up of package names and (simple) class names. Such
class loading cares for packages and not for the containers of those packages.
Hence declaring the dependency on the actual namespace through Import-Package
is much closer to the truth and reality than declaring the dependency on the
semi-random container.
About strong coupling: If your bundle depends on the the XYZ container and the
provider of XYZ decides to split the functionality into XYA and XYB, your
bundle needs to at least be rebuilt to cope with the new containers -- even if
functionally nothing has changed.
So, please, don't use Require-Bundle and if I would be stating one rule in
Sling it would be "say no to Require-Bundle".
Thank you very much.
> Apache Sling Resource Editor contribution
> -----------------------------------------
>
> Key: SLING-4001
> URL: https://issues.apache.org/jira/browse/SLING-4001
> Project: Sling
> Issue Type: New Feature
> Reporter: Sandro Boehme
> Assignee: Bertrand Delacretaz
> Attachments: apache _sling_resource_editor.zip
>
>
> Based on the discussion at the dev list [1, 2] I would like to contribute the
> Apache Sling Resource Editor (previously named JCRBrowser and Apache Sling
> Content Editor).
> ++ Features ++
> Currently it can be used to rename and delete nodes. Rename works by double
> clicking the node and you can multi select nodes for the deletion with the
> 'del' key. The node names are HTML and URL escaped and it provides stateless
> deep links to the nodes.
> ++ Further development ++
> In the months to come I can work more intensely on the Sling Resource Editor
> and I might add commercial add-ons separately. This is why I would like to be
> able to point users to such an add-on from Sling. But judging from other
> Apache projects [6] I assume this is probably not a problem.
> I will continue the development at GitHub[7] and send patch files to Sling
> when new features are implemented.
> ++ Implementation ++
> It uses the Sling API.
> For the tree on the left the JSTree library is used. It expects a URL to a
> JSON that contains the data for the child nodes. This URL points to a
> Sling resource with a 'reseditor.nodes' selector and a 'json' extension. This
> way the JSPs [3] render the JSON for the resource that is consumed by the
> JSTree library.
> For the deletion and renaming of nodes I use jQuery Ajax calls to the Sling
> POST servlet.
> The properties list on the right is rendered [4] using JSTL and the
> currentNode variable of Sling.
> The html.jsp is registered for the 'reseditor' selector relatively to the
> default servlet. And for not getting overruled by servlets registered by
> paths and by other resources that are using the 'reseditor' selector I use a
> ResourceDecorator [5].
> After a hint from Dominik Süß I work on using a ResourceProvider instead.
> I'm looking forward to your feedback!
> [1] - http://comments.gmane.org/gmane.comp.apache.sling.devel/47292
> [2] - http://comments.gmane.org/gmane.comp.apache.sling.devel/47517
> [3] -
> https://github.com/sandroboehme/resourceeditor/tree/master/src/main/resources/SLING-INF/libs/sling/servlet/default/reseditor
> [4] -
> https://github.com/sandroboehme/resourceeditor/blob/master/src/main/resources/SLING-INF/libs/sling/servlet/default/reseditor/html.jsp
> line 174
> [5] -
> https://github.com/sandroboehme/resourceeditor/blob/master/src/main/java/org/apache/sling/reseditor/SelectorBasedResourceDecorator.java
> [6] - https://www.google.de/search?q=site%3Aapache.org+commercial
> [7] - https://github.com/sandroboehme/resourceeditor
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
