Different ways to define initial content :: Content.xml vs Json equivalent

[Greg Fullard]

Hi All

I see that there is some difference between how content projects are
handled between the Sling IDE tools and the Maven archetypes.


   1. The "Sling Content Project" wizard creates a project with a jcr_root
   folder which then contains folders and content.xml files. This is very
   similar to what I'm used to with AEM Archetype 10.
   2. The sling-initial-content-archetype, on the other hand, generates a
   SLING-INF folder with an XML node descriptor file (as explained at
   
http://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html
   )
   3. The Slingbucks example uses JSON descriptor files.


Obviously all these methods work, but I'm interested to get an idea of what
the recommended method is. Perhaps based on specific criteria of my
project?

Much appreciated

Greg

-- 


--
*Unlock Interaction*
CIC = Correspondence, Interactions & Communications


*8 BIT PLATOON disclaimer*
This e-mail transmission contains confidential information, which is the 
property of EOH Holdings Limited and its subsidiaries (“EOH”). No person, 
other than the recipient (so indicated by the sender) may use or disclose 
the contents of this message, links or attachments hereto, to any person 
whatsoever. Unauthorised disclosure and/or use may result in civil and 
criminal liability.
Any views expressed in this message are those of the individual sender, 
except where the message states otherwise and the sender is authorised to 
state them to be the views of any such entity.
The disclaimer forms part of the content of this e-mail in terms of section 
11 of the Electronic Communications and Transactions Act, 25 of 2002. Refer 
to http://www.eoh.co.za/disclaimer 
--

Re: Fling Installation on Trunk

[Roy Teeuwen]

Hey Andreas,

You can make your own custom launchpads with a maven project.

In your pom.xml you use the following plugin:


org.apache.sling
slingstart-maven-plugin
true


Until sling 9 is released you use the following snapshot dependency, or you 
could also use sling version 8:


org.apache.sling
org.apache.sling.launchpad
9-SNAPSHOT
slingstart


Add a boot.txt in the directory src/main/provisioning containing the following 
info:

[feature name=:boot]

[artifacts]
org.apache.sling/org.apache.sling.launchpad/9-SNAPSHOT/slingstart

Add any txt file in the same directory to add your custom stuff you need. For 
example add a thymeleaf.txt containing:

[feature name=thymeleaf]

# Add the dependencies on the Model exporter
[artifacts]
   org.attoparser/attoparser/2.0.2.RELEASE
   org.unbescape/unbescape/1.1.4.RELEASE
   org.apache.servicemix.bundles/org.apache.servicemix.bundles.ognl/3.2_1
   org.javassist/javassist/3.20.0-GA
   org.apache.sling/org.apache.sling.scripting.thymeleaf/1.1.1-SNAPSHOT

Now build your project, and in your target folder you will have your custom 
created launchpad jar

Greets,
Roy



> On 31 Mar 2017, at 23:39, Andreas Schaefer Sr.  wrote:
> 
> For something else I delved into Sling Provisioning and I
> came up with a way to import Thymeleaf. Not sure if  that
> is the best way but it seems to work.
> 
> When I add a file called thymeleaf.txt to 
> launchpad/builder/src/main/provisioning
> with that content:
> 
> [feature name=thymeleaf]
> 
> # Add the dependencies on the Model exporter
> [artifacts]
>org.attoparser/attoparser/2.0.2.RELEASE
>org.unbescape/unbescape/1.1.4.RELEASE
>org.apache.servicemix.bundles/org.apache.servicemix.bundles.ognl/3.2_1
>org.javassist/javassist/3.20.0-GA
>org.apache.sling/org.apache.sling.scripting.thymeleaf/1.1.1-SNAPSHOT
> 
> Build and start sling (just the builder) I have thymeleaf installed and 
> prepped
> and ready.
> 
> So I am wondering if there is a better way or if I can create my own 
> provisioning
> models but keep them in a separate folder.
> 
> Thanks - Andy Schaefer
> 
>> On Mar 28, 2017, at 1:22 AM, Oliver Lietz  wrote:
>> 
>> On Monday 27 March 2017 13:05:38 Andreas Schaefer Sr. wrote:
>>> Hi
>>> 
>>> I tried to install Fling from the Samples but failed with the latest Sling.
>>> 
>>> First I had to install Sling Messaging and Sling Query but then
>>> I gave up on Sling Thymeleaf which has dependencies on
>>> com.fasterxml.jackson.ocre etc that are not deployed in Sling and it also
>>> looks like they are not deployed by any other bundle.
>>> 
>>> A sample does not much good if I cannot build and install it, right?
>> 
>> *sigh
>> 
>>> I am pretty fluent with package dependencies and so if I cannot
>>> figure it out in an acceptable time frame then who will.
>> 
>> Stop whining and start reading, please.
>> 
>>> Any pointers on how to get this working would be very much
>>> appreciated.
>> 
>> The version of Fling is 0.0.1-SNAPSHOT which clearly indicates that it is 
>> work
>> in progress. Fling itself depends on some snapshots namely Validation and
>> Messaging (and therefore has to be adjusted sometimes when those dependencies
>> do incompatible changes – see my latest commits). Fling's prerequisites are
>> listed in the README: 
>> https://github.com/apache/sling/tree/trunk/samples/fling
>> 
>> How to install Scripting Thymeleaf is described in its README (and btw.
>> Jackson is optional):
>> https://github.com/apache/sling/tree/trunk/contrib/scripting/org.apache.sling.scripting.thymeleaf
>> 
>> If you are unable to install those dependencies into Launchpad you can try
>> with Sling's Karaf Distribution:
>> https://github.com/apache/sling/tree/trunk/karaf
>> 
>> Start Karaf and open http://localhost:8181/system/console/features, install
>> sling-launchpad-oak-tar and sling-samples-fling by clicking the play/install
>> buttons on the right. Open http://localhost:8181/fling.html
>> 
>> O.
>> 
>>> Thanks - Andy Schaefer
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Fling Installation on Trunk

[Oliver Lietz]

On Friday 31 March 2017 14:39:46 Andreas Schaefer Sr. wrote:
> For something else I delved into Sling Provisioning and I
> came up with a way to import Thymeleaf. Not sure if  that
> is the best way but it seems to work.
> 
> When I add a file called thymeleaf.txt to
> launchpad/builder/src/main/provisioning with that content:
> 
> [feature name=thymeleaf]
> 
> # Add the dependencies on the Model exporter
> [artifacts]
> org.attoparser/attoparser/2.0.2.RELEASE
> org.unbescape/unbescape/1.1.4.RELEASE
> org.apache.servicemix.bundles/org.apache.servicemix.bundles.ognl/3.2_1
> org.javassist/javassist/3.20.0-GA
> org.apache.sling/org.apache.sling.scripting.thymeleaf/1.1.1-SNAPSHOT
> 
> Build and start sling (just the builder) I have thymeleaf installed and
> prepped and ready.
> 
> So I am wondering if there is a better way or if I can create my own
> provisioning models but keep them in a separate folder.

That way is totally perfect, but you can use Scripting Thymeleaf 1.1.0 of 
course.

Feel free to open an issue if you want Scripting Thymeleaf be part of 
Launchpad builder. We should provide run modes for Sightly and Thymeleaf then 
until SLING-4330 is done as both use .html extension per default which leads 
to errors when running both.

Regards,
O.

> Thanks - Andy Schaefer

Re: Different ways to define initial content :: Content.xml vs Json equivalent

[Chris Millar]

>
> I see that there is some difference between how content projects are
> handled between the Sling IDE tools and the Maven archetypes.
>
>
>1. The "Sling Content Project" wizard creates a project with a jcr_root
>folder which then contains folders and content.xml files. This is very
>similar to what I'm used to with AEM Archetype 10.
>2. The sling-initial-content-archetype, on the other hand, generates a
>SLING-INF folder with an XML node descriptor file (as explained at
>http://sling.apache.org/documentation/bundles/content-
> loading-jcr-contentloader.html
>)
>3. The Slingbucks example uses JSON descriptor files.
>
>
> Obviously all these methods work, but I'm interested to get an idea of what
> the recommended method is. Perhaps based on specific criteria of my
> project?
>

The Sling Content Project
This won't come with a pom.xml, so it can make scaling and deployment a
little tough. It does use the .content.xml method which I think is a little
cleaner than the other methods.

The Sling Initial Content Maven Project
This uses the XML node descriptor method. It also (obviously) comes with a
pom.xml, so CI is not really an issue.

Slingbucks Example
Using JSON is arguably cleaner than XML, but it can come with trade-offs.
In my opinion, Slingbucks is an effective use of this method.

What are the trade-offs of using JSON?

If your node needs to have it described (I.E. resourceSuperType) AND it
needs to have content (I.E. HTML), you can end up having a funky looking
project structure:

my-node.json
my-node
|--- my-node.html
|--- body.html

To me it has always seemed a little weird to have two files describe what a
resource should look like.

My recommendations:
If you're working with someone adverse to XML, go the JSON route. If you're
wanting something more verbose, go the XML node descriptor route. If you're
used to AEM, go the .content.xml route.

Re: Different ways to define initial content :: Content.xml vs Json equivalent

[Andreas Schaefer Sr.]

Hi Greg

One difference between an JCR Content Package (ZIP file) is that you can use
the exploded tree inside the Eclipse or IntelliJ plugin and edit / deploy / 
import (from
server) one file at a time. With the Bundle Content you have to deploy it
as an entire bundle.

If working with JSon you have to keep in mind that:

1) You don’t have comments but you can add a comment attribute but
see that as JCR property

2) There is only a SINGLE LINE text in JSon

This works:

“attributeOne” : “One line is ok”

This does not:

“attributeTwo” : “This line will
  fail as it is multi line”

For most part this is ok but certain configurations that is not good.

Having worked on bigger AEM projects we ended up having many
JCR Content Packages and OSGi Bundles and so eventually we
used a dedicated ALL JCR Package which is just there to bundle up
all artifacts and deploy them in one swoop.

For most part I prefer the Bundle Contents over JCR Packages especially
with Sling as Composum prints outs node properties as JSon. That said
I never worked on a big project with it and so I don’t know what issues
I would face. A friend of mine said they ran into issues with it.

As far as I know SLING-INF is not needed but I would recommend to
place your content is a specially marked folder and not just 
/scr/main/resources.

This line is more instructive:


SLING-INF/libs/sling/validation/i18n;overwrite:=true;path:=/libs/sling/validation/i18n

than this:

apps/fling;path:=/apps/fling;overwrite:=true;uninstall:=true

In Sling 9 you can have both JCR Packages and Bundle Content w/o any issues.

Cheers - Andy

> On Apr 1, 2017, at 4:18 AM, Greg Fullard  wrote:
> 
> Hi All
> 
> I see that there is some difference between how content projects are
> handled between the Sling IDE tools and the Maven archetypes.
> 
> 
>   1. The "Sling Content Project" wizard creates a project with a jcr_root
>   folder which then contains folders and content.xml files. This is very
>   similar to what I'm used to with AEM Archetype 10.
>   2. The sling-initial-content-archetype, on the other hand, generates a
>   SLING-INF folder with an XML node descriptor file (as explained at
>   
> http://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html
>   )
>   3. The Slingbucks example uses JSON descriptor files.
> 
> 
> Obviously all these methods work, but I'm interested to get an idea of what
> the recommended method is. Perhaps based on specific criteria of my
> project?
> 
> Much appreciated
> 
> Greg
> 
> -- 
> 
> 
> --
> *Unlock Interaction*
> CIC = Correspondence, Interactions & Communications
> 
> 
> *8 BIT PLATOON disclaimer*
> This e-mail transmission contains confidential information, which is the 
> property of EOH Holdings Limited and its subsidiaries (“EOH”). No person, 
> other than the recipient (so indicated by the sender) may use or disclose 
> the contents of this message, links or attachments hereto, to any person 
> whatsoever. Unauthorised disclosure and/or use may result in civil and 
> criminal liability.
> Any views expressed in this message are those of the individual sender, 
> except where the message states otherwise and the sender is authorised to 
> state them to be the views of any such entity.
> The disclaimer forms part of the content of this e-mail in terms of section 
> 11 of the Electronic Communications and Transactions Act, 25 of 2002. Refer 
> to http://www.eoh.co.za/disclaimer 
> --
> 
>