Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Robert Munteanu]

On Wed, 2020-11-11 at 18:03 +0100, Radu Cotescu wrote:
> Hi,
> 
> > On 6 Nov 2020, at 16:24, Ruben Reusser  wrote:
> > 
> > I totally understand the idea behind why to put a simple html
> > component into the content package. I however struggle with the
> > fact that Java Use Objects are probably not a best practice for
> > sling projects or other upstream projects. Maybe I am wrong here.
> 
> Ruben is right - Java Use Objects in the resource tree are not the
> best idea. With HTL it’s better to use Sling Models for the Use API,
> albeit these are not content structures. However, I’d really avoid
> encouraging people to still use Java Use Objects, even though they’re
> still supported.

Ack, thanks. Then I guess there would be no need to bundle anything
like that in the archetype. We _could_ use a Sling Model, but I don't
think we have anything OOTB in the Sling Starter, and that's probably
best left to comprehensive archetypes like [1].

Thanks,
Robert

[1]: https://github.com/apache/sling-project-archetype

Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Radu Cotescu]

Hi,

> On 6 Nov 2020, at 16:24, Ruben Reusser  wrote:
> 
> I totally understand the idea behind why to put a simple html component into 
> the content package. I however struggle with the fact that Java Use Objects 
> are probably not a best practice for sling projects or other upstream 
> projects. Maybe I am wrong here.

Ruben is right - Java Use Objects in the resource tree are not the best idea. 
With HTL it’s better to use Sling Models for the Use API, albeit these are not 
content structures. However, I’d really avoid encouraging people to still use 
Java Use Objects, even though they’re still supported.

Thanks,
Radu

[CANCELLED] [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Robert Munteanu]

Hi,

I'm cancelling this vote to address the feedback raised by Ruben and
Konrad.

Thanks,
Robert

Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Robert Munteanu]

Hi Konrad,

On Fri, 2020-11-06 at 16:47 +0100, Konrad Windszus wrote:
> Sorry I haven't checked the code up till now.
> Some questions/remarks:
> 
> 1. Why filevault-package-maven-plugin 1.1.2 and not the latest
> version 1.1.4?

It was the latest version available at the time. I just pushed an
update

  https://github.com/apache/sling-content-package-archetype/commit/6286389

> 2. It is using a mixed package (mutable/potentially immutable
> content), why do we propose that instead of a clear separation with
> three different modules (apps. content, container)

I wanted to go with something very simple. But on the other hand I
don't want to go with something that is against current best practices.
Would you mind filing an issue for points 2-5? I will cancel the
current vote and get back to dev@ once I think it's ready.

Thanks!
Robert

> 3. I would recommend setting a dedicated package type in the
> configuration (
> https://github.com/apache/sling-content-package-archetype/blob/30380a1d75abfaafa1aa67d487f01b3123575777/src/main/resources/archetype-resources/pom.xml#L49
> <
> https://github.com/apache/sling-content-package-archetype/blob/30380a1d75abfaafa1aa67d487f01b3123575777/src/main/resources/archetype-resources/pom.xml#L49>
> ;)
> 4. Would it make sense to embed a bundle here as well?
> 5. As archetypes don't allow speaking description for properties
> these either need a documentation and/or a very speaking name. IMHO
> shortName (
> https://github.com/apache/sling-content-package-archetype/blob/30380a1d75abfaafa1aa67d487f01b3123575777/src/main/resources/META-INF/maven/archetype-metadata.xml#L39
> <
> https://github.com/apache/sling-content-package-archetype/blob/30380a1d75abfaafa1aa67d487f01b3123575777/src/main/resources/META-INF/maven/archetype-metadata.xml#L39>
> ;) is not good enough, given that there is not a readme
> 
> Thanks and sorry for the late feedback,
> Konrad
> 
> > On 6. Nov 2020, at 13:18, Robert Munteanu 
> > wrote:
> > 
> > Hi,
> > 
> > This is a first release of the tooling, so no issues fixed (but a
> > version was created):
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12349357
> > 
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2369/
> > 
> > You can use this UNIX script to download the release and verify the
> > signatures:
> > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
> > 
> > Usage:
> > sh check_staged_release.sh 2369 /tmp/sling-staging
> > 
> > Please vote to approve this release:
> > 
> >  [ ] +1 Approve the release
> >  [ ]  0 Don't care
> >  [ ] -1 Don't release, because ...
> > 
> > This majority vote is open for at least 72 hours.
> > 
> > Regards,
> > Robert Munteanu
> > 

Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Konrad Windszus]

Sorry I haven't checked the code up till now.
Some questions/remarks:

1. Why filevault-package-maven-plugin 1.1.2 and not the latest version 1.1.4?
2. It is using a mixed package (mutable/potentially immutable content), why do 
we propose that instead of a clear separation with three different modules 
(apps. content, container)
3. I would recommend setting a dedicated package type in the configuration 
(https://github.com/apache/sling-content-package-archetype/blob/30380a1d75abfaafa1aa67d487f01b3123575777/src/main/resources/archetype-resources/pom.xml#L49
 
)
4. Would it make sense to embed a bundle here as well?
5. As archetypes don't allow speaking description for properties these either 
need a documentation and/or a very speaking name. IMHO shortName 
(https://github.com/apache/sling-content-package-archetype/blob/30380a1d75abfaafa1aa67d487f01b3123575777/src/main/resources/META-INF/maven/archetype-metadata.xml#L39
 
)
 is not good enough, given that there is not a readme

Thanks and sorry for the late feedback,
Konrad

> On 6. Nov 2020, at 13:18, Robert Munteanu  wrote:
> 
> Hi,
> 
> This is a first release of the tooling, so no issues fixed (but a
> version was created):
> https://issues.apache.org/jira/browse/SLING/fixforversion/12349357
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2369/
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
> 
> Usage:
> sh check_staged_release.sh 2369 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Regards,
> Robert Munteanu
> 

Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Robert Munteanu]

On Fri, 2020-11-06 at 07:24 -0800, Ruben Reusser wrote:
> Robert,
> 
> On 11/6/2020 6:07 AM, Robert Munteanu wrote:
> > Hi Ruben and thanks for looking into this.
> > 
> > On Fri, 2020-11-06 at 05:36 -0800, Ruben Reusser wrote:
> > > Robert,
> > > 
> > > had a quick look at this archetype - for a 1.0.0 release I am
> > > missing
> > > documentation around this archetype.
> > What kind of documentation are you looking for? The archetype is
> > referenced at [2], but nowhere else I guess. I find it simple and
> > self-
> > explanatory, but would be happy to add more information.
> 
> I was hoping for something along the lines of the readme in the
> project 
> archetype [3]

Thanks, added https://issues.apache.org/jira/browse/SLING-9882 .

> 
> > > I am also curious if the Java Use Object it creates in apps is
> > > really
> > > a
> > > good idea? After all, this is just a content archetype.
> > The idea behind the archetype was to allow users to quickly
> > generate a
> > content package. They are free to adjust it how they see fit
> > afterwards, e.g. by removing rendering scripts.
> > 
> > Generally, I think it's more useful to bake more stuff in the
> > archetype
> > and allow users to remove it, rather than give them too many
> > options or
> > very 'slim' archetypes. And it makes maintenance for us much
> > easier.
> I totally understand the idea behind why to put a simple html
> component 
> into the content package. I however struggle with the fact that Java
> Use 
> Objects are probably not a best practice for sling projects or other 
> upstream projects. Maybe I am wrong here.

I'm not saying you're wrong, I am not an expert in HTL. I added an use
objects since I usually found it problematic to properly create one.
What would say are best practices in this context?

Thanks,
Robert

Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Ruben Reusser]

Robert,

On 11/6/2020 6:07 AM, Robert Munteanu wrote:

Hi Ruben and thanks for looking into this.

On Fri, 2020-11-06 at 05:36 -0800, Ruben Reusser wrote:

Robert,

had a quick look at this archetype - for a 1.0.0 release I am
missing
documentation around this archetype.

What kind of documentation are you looking for? The archetype is
referenced at [2], but nowhere else I guess. I find it simple and self-
explanatory, but would be happy to add more information.


I was hoping for something along the lines of the readme in the project 
archetype [3]



I am also curious if the Java Use Object it creates in apps is really
a
good idea? After all, this is just a content archetype.

The idea behind the archetype was to allow users to quickly generate a
content package. They are free to adjust it how they see fit
afterwards, e.g. by removing rendering scripts.

Generally, I think it's more useful to bake more stuff in the archetype
and allow users to remove it, rather than give them too many options or
very 'slim' archetypes. And it makes maintenance for us much easier.
I totally understand the idea behind why to put a simple html component 
into the content package. I however struggle with the fact that Java Use 
Objects are probably not a best practice for sling projects or other 
upstream projects. Maybe I am wrong here.

looking at the sling-package-archetype at [1] you also decided to
not
use a profile for the package installation - not sure if it would be
better to follow  similar pattern in both archetypes

Right, that should be adjusted. I started with my personal perference
and forgot to to switch to the profile. Can you please file a Sling
issue so it is fixed for the next version?


will do. Looks like the documentation is a bit out of sync as well on 
this topic (project archetype readme vs docs)



Thanks,
Robert

[2]: 
https://sling.apache.org/documentation/development/content-packages.html#maven-projects-1


Ruben

[1]
https://github.com/apache/sling-project-archetype/blob/master/src/main/resources/archetype-resources/README.NotAll.md


[3] https://github.com/apache/sling-project-archetype/blob/master/README.md

Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Robert Munteanu]

Hi Ruben and thanks for looking into this.

On Fri, 2020-11-06 at 05:36 -0800, Ruben Reusser wrote:
> Robert,
> 
> had a quick look at this archetype - for a 1.0.0 release I am
> missing 
> documentation around this archetype.

What kind of documentation are you looking for? The archetype is
referenced at [2], but nowhere else I guess. I find it simple and self-
explanatory, but would be happy to add more information.

> 
> I am also curious if the Java Use Object it creates in apps is really
> a 
> good idea? After all, this is just a content archetype.

The idea behind the archetype was to allow users to quickly generate a
content package. They are free to adjust it how they see fit
afterwards, e.g. by removing rendering scripts.

Generally, I think it's more useful to bake more stuff in the archetype
and allow users to remove it, rather than give them too many options or
very 'slim' archetypes. And it makes maintenance for us much easier.

> 
> looking at the sling-package-archetype at [1] you also decided to
> not 
> use a profile for the package installation - not sure if it would be 
> better to follow  similar pattern in both archetypes

Right, that should be adjusted. I started with my personal perference
and forgot to to switch to the profile. Can you please file a Sling
issue so it is fixed for the next version?

Thanks,
Robert

[2]: 
https://sling.apache.org/documentation/development/content-packages.html#maven-projects-1

> 
> Ruben
> 
> [1] 
> https://github.com/apache/sling-project-archetype/blob/master/src/main/resources/archetype-resources/README.NotAll.md
> 
> On 11/6/2020 4:18 AM, Robert Munteanu wrote:
> > Hi,
> > 
> > This is a first release of the tooling, so no issues fixed (but a
> > version was created):
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12349357
> > 
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2369/
> > 
> > You can use this UNIX script to download the release and verify the
> > signatures:
> > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
> > 
> > Usage:
> > sh check_staged_release.sh 2369 /tmp/sling-staging
> > 
> > Please vote to approve this release:
> > 
> >[ ] +1 Approve the release
> >[ ]  0 Don't care
> >[ ] -1 Don't release, because ...
> > 
> > This majority vote is open for at least 72 hours.
> > 
> > Regards,
> > Robert Munteanu
> > 

Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Ruben Reusser]

Robert,

had a quick look at this archetype - for a 1.0.0 release I am missing 
documentation around this archetype.


I am also curious if the Java Use Object it creates in apps is really a 
good idea? After all, this is just a content archetype.


looking at the sling-package-archetype at [1] you also decided to not 
use a profile for the package installation - not sure if it would be 
better to follow  similar pattern in both archetypes


Ruben

[1] 
https://github.com/apache/sling-project-archetype/blob/master/src/main/resources/archetype-resources/README.NotAll.md


On 11/6/2020 4:18 AM, Robert Munteanu wrote:

Hi,

This is a first release of the tooling, so no issues fixed (but a
version was created):
https://issues.apache.org/jira/browse/SLING/fixforversion/12349357

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2369/

You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 2369 /tmp/sling-staging

Please vote to approve this release:

   [ ] +1 Approve the release
   [ ]  0 Don't care
   [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
Robert Munteanu

Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Robert Munteanu]

On Fri, 2020-11-06 at 13:18 +0100, Robert Munteanu wrote:
> Please vote to approve this release:

+1
Robert


signature.asc
Description: This is a digitally signed message part

[VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Robert Munteanu]

Hi,

This is a first release of the tooling, so no issues fixed (but a
version was created):
https://issues.apache.org/jira/browse/SLING/fixforversion/12349357

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2369/

You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 2369 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards,
Robert Munteanu