[hackathon] maven archetypes

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[hackathon] maven archetypes

Stefan Seifert
- currently there are lots of sling maven archetypes, and most of them not well maintained
- we would favor to have only one single "project" archetypes, probably the new "project" archetype contributed by andy
- add parameters to switch features on and off, e.g. for generating only with bundle but not with the content packages
  - this can be done using the groovy prost process
  - there is already a groovy script with a lot of logic in it, to be reviewed if it already covers all use cases
- the plan is to no longer have the need to maintain multiple archetypes
- review the generated structure of the current project archetypes. the structure is derived from the adobe AEM project archetype, but we like not all of it. e.g. the "ui." prefix for the contant packages, probably introduce "bundles" and "content-packages" folders to but bundles and content packages in.

stefan

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] maven archetypes

Robert Munteanu-2
On Thu, 2019-09-05 at 14:43 +0000, Stefan Seifert wrote:

> - currently there are lots of sling maven archetypes, and most of
> them not well maintained
> - we would favor to have only one single "project" archetypes,
> probably the new "project" archetype contributed by andy
> - add parameters to switch features on and off, e.g. for generating
> only with bundle but not with the content packages
>   - this can be done using the groovy prost process
>   - there is already a groovy script with a lot of logic in it, to be
> reviewed if it already covers all use cases
> - the plan is to no longer have the need to maintain multiple
> archetypes
> - review the generated structure of the current project archetypes.
> the structure is derived from the adobe AEM project archetype, but we
> like not all of it. e.g. the "ui." prefix for the contant packages,
> probably introduce "bundles" and "content-packages" folders to but
> bundles and content packages in.

I would like to propose the following:

A. deprecate all project archetype ( + parent ) except the sling-
project-archetype

1. sling-slingstart-archetype
2. sling-archetype-parent
3. sling-taglib-archetype
4. sling-servlet-archetype
5. sling-bundle-archetype
6. sling-initial-content-archetype
7. sling-launchpad-standalone-archetype
8. sling-launchpad-webapp-archetype
9. sling-jcrinstall-bundle-archetype

B. include the following artifacts in the project

1. core ( Java bundle )
2. content ( content package, sample data )
3. apps ( content package, Sling scripts )
4. launcher ( feature model project )

C. I like the fact that the project includes sample data. Would it
simplify maintenance if we always generated the sample data? I would
expect the user to tweak it anyway.

D. We _could_ heavily tweak the project and make it generate a single
module, by e.g. deleting anything but the one of the modules and then
making them top-level after generation has run (groovy script).

That would effectively replace the other 8 existing projects, but I'm
not sure if the complexity is worth it.

Thoughts?

Thanks,
Robert

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] maven archetypes

Konrad Windszus
Definitely +1 on having only one archetype. In case D is too much effort, we could even leave it out.
A maintained archetype is better than what we currently have.
And it should be pretty easy for every developer to just copy over from a blueprint project created from the archetype only the desired modules...

Konrad

> On 12. Sep 2019, at 16:50, Robert Munteanu <[hidden email]> wrote:
>
> On Thu, 2019-09-05 at 14:43 +0000, Stefan Seifert wrote:
>> - currently there are lots of sling maven archetypes, and most of
>> them not well maintained
>> - we would favor to have only one single "project" archetypes,
>> probably the new "project" archetype contributed by andy
>> - add parameters to switch features on and off, e.g. for generating
>> only with bundle but not with the content packages
>>  - this can be done using the groovy prost process
>>  - there is already a groovy script with a lot of logic in it, to be
>> reviewed if it already covers all use cases
>> - the plan is to no longer have the need to maintain multiple
>> archetypes
>> - review the generated structure of the current project archetypes.
>> the structure is derived from the adobe AEM project archetype, but we
>> like not all of it. e.g. the "ui." prefix for the contant packages,
>> probably introduce "bundles" and "content-packages" folders to but
>> bundles and content packages in.
>
> I would like to propose the following:
>
> A. deprecate all project archetype ( + parent ) except the sling-
> project-archetype
>
> 1. sling-slingstart-archetype
> 2. sling-archetype-parent
> 3. sling-taglib-archetype
> 4. sling-servlet-archetype
> 5. sling-bundle-archetype
> 6. sling-initial-content-archetype
> 7. sling-launchpad-standalone-archetype
> 8. sling-launchpad-webapp-archetype
> 9. sling-jcrinstall-bundle-archetype
>
> B. include the following artifacts in the project
>
> 1. core ( Java bundle )
> 2. content ( content package, sample data )
> 3. apps ( content package, Sling scripts )
> 4. launcher ( feature model project )
>
> C. I like the fact that the project includes sample data. Would it
> simplify maintenance if we always generated the sample data? I would
> expect the user to tweak it anyway.
>
> D. We _could_ heavily tweak the project and make it generate a single
> module, by e.g. deleting anything but the one of the modules and then
> making them top-level after generation has run (groovy script).
>
> That would effectively replace the other 8 existing projects, but I'm
> not sure if the complexity is worth it.
>
> Thoughts?
>
> Thanks,
> Robert

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] maven archetypes

Andreas Schaefer-5
In reply to this post by Robert Munteanu-2
With respect to C:

The Sling Project Archetype has two versions of each module in it:
- plain (no code)
- sample code

The archetype can do the following:
- merge samples into module aka having only one module
- delete samples
- keep them separate. Only the plain code module is active in the build but the user can copy them over pretty easily

D:

I did not yet start working on it but technically there should be no reason why this can’t be done.

The only problem is the number of parameters that have to be handled as all parameters must be specified when the archetype is launched.

- Andy

> On Sep 12, 2019, at 7:50 AM, Robert Munteanu <[hidden email]> wrote:
>
> On Thu, 2019-09-05 at 14:43 +0000, Stefan Seifert wrote:
>> - currently there are lots of sling maven archetypes, and most of
>> them not well maintained
>> - we would favor to have only one single "project" archetypes,
>> probably the new "project" archetype contributed by andy
>> - add parameters to switch features on and off, e.g. for generating
>> only with bundle but not with the content packages
>>  - this can be done using the groovy prost process
>>  - there is already a groovy script with a lot of logic in it, to be
>> reviewed if it already covers all use cases
>> - the plan is to no longer have the need to maintain multiple
>> archetypes
>> - review the generated structure of the current project archetypes.
>> the structure is derived from the adobe AEM project archetype, but we
>> like not all of it. e.g. the "ui." prefix for the contant packages,
>> probably introduce "bundles" and "content-packages" folders to but
>> bundles and content packages in.
>
> I would like to propose the following:
>
> A. deprecate all project archetype ( + parent ) except the sling-
> project-archetype
>
> 1. sling-slingstart-archetype
> 2. sling-archetype-parent
> 3. sling-taglib-archetype
> 4. sling-servlet-archetype
> 5. sling-bundle-archetype
> 6. sling-initial-content-archetype
> 7. sling-launchpad-standalone-archetype
> 8. sling-launchpad-webapp-archetype
> 9. sling-jcrinstall-bundle-archetype
>
> B. include the following artifacts in the project
>
> 1. core ( Java bundle )
> 2. content ( content package, sample data )
> 3. apps ( content package, Sling scripts )
> 4. launcher ( feature model project )
>
> C. I like the fact that the project includes sample data. Would it
> simplify maintenance if we always generated the sample data? I would
> expect the user to tweak it anyway.
>
> D. We _could_ heavily tweak the project and make it generate a single
> module, by e.g. deleting anything but the one of the modules and then
> making them top-level after generation has run (groovy script).
>
> That would effectively replace the other 8 existing projects, but I'm
> not sure if the complexity is worth it.
>
> Thoughts?
>
> Thanks,
> Robert

Reply | Threaded
Open this post in threaded view
|

RE: [hackathon] maven archetypes

Stefan Seifert
In reply to this post by Konrad Windszus
+1

i also think we can omit D) for the first step.
i'm also fine with C) that it always include sample data - we can always add a switch later to remove it.

for B) we might consider putting all bundle projects below a bundles/ folder
and all content package projects below a /content-packages folder
it's not unusual you create more of them for bigger projects, and then they are nicely grouped.

stefan

>-----Original Message-----
>From: Konrad Windszus [mailto:[hidden email]]
>Sent: Thursday, September 12, 2019 5:53 PM
>To: [hidden email]
>Subject: Re: [hackathon] maven archetypes
>
>Definitely +1 on having only one archetype. In case D is too much effort,
>we could even leave it out.
>A maintained archetype is better than what we currently have.
>And it should be pretty easy for every developer to just copy over from a
>blueprint project created from the archetype only the desired modules...
>
>Konrad
>
>> On 12. Sep 2019, at 16:50, Robert Munteanu <[hidden email]> wrote:
>>
>> On Thu, 2019-09-05 at 14:43 +0000, Stefan Seifert wrote:
>>> - currently there are lots of sling maven archetypes, and most of
>>> them not well maintained
>>> - we would favor to have only one single "project" archetypes,
>>> probably the new "project" archetype contributed by andy
>>> - add parameters to switch features on and off, e.g. for generating
>>> only with bundle but not with the content packages
>>>  - this can be done using the groovy prost process
>>>  - there is already a groovy script with a lot of logic in it, to be
>>> reviewed if it already covers all use cases
>>> - the plan is to no longer have the need to maintain multiple
>>> archetypes
>>> - review the generated structure of the current project archetypes.
>>> the structure is derived from the adobe AEM project archetype, but we
>>> like not all of it. e.g. the "ui." prefix for the contant packages,
>>> probably introduce "bundles" and "content-packages" folders to but
>>> bundles and content packages in.
>>
>> I would like to propose the following:
>>
>> A. deprecate all project archetype ( + parent ) except the sling-
>> project-archetype
>>
>> 1. sling-slingstart-archetype
>> 2. sling-archetype-parent
>> 3. sling-taglib-archetype
>> 4. sling-servlet-archetype
>> 5. sling-bundle-archetype
>> 6. sling-initial-content-archetype
>> 7. sling-launchpad-standalone-archetype
>> 8. sling-launchpad-webapp-archetype
>> 9. sling-jcrinstall-bundle-archetype
>>
>> B. include the following artifacts in the project
>>
>> 1. core ( Java bundle )
>> 2. content ( content package, sample data )
>> 3. apps ( content package, Sling scripts )
>> 4. launcher ( feature model project )
>>
>> C. I like the fact that the project includes sample data. Would it
>> simplify maintenance if we always generated the sample data? I would
>> expect the user to tweak it anyway.
>>
>> D. We _could_ heavily tweak the project and make it generate a single
>> module, by e.g. deleting anything but the one of the modules and then
>> making them top-level after generation has run (groovy script).
>>
>> That would effectively replace the other 8 existing projects, but I'm
>> not sure if the complexity is worth it.
>>
>> Thoughts?
>>
>> Thanks,
>> Robert


Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] maven archetypes

Ruben Reusser
for B) - the module names the archetype currently uses have been chosen
to be aligned with the names the AEM Project Archetype uses. While I
understand the ui.* may look odd it was meant to make it easier for a
developer familiar with AEM to work on a sling project.

The archetype also supports the common profiles to deploy packages such
as autoInstallBundle and autoInstallPackage

I am not opposed to changing the module names or the profile names, I
just like consistency and the ease of moving from one product to another.

Ruben

On 9/12/2019 9:32 AM, Stefan Seifert wrote:

> +1
>
> i also think we can omit D) for the first step.
> i'm also fine with C) that it always include sample data - we can always add a switch later to remove it.
>
> for B) we might consider putting all bundle projects below a bundles/ folder
> and all content package projects below a /content-packages folder
> it's not unusual you create more of them for bigger projects, and then they are nicely grouped.
>
> stefan
>
>> -----Original Message-----
>> From: Konrad Windszus [mailto:[hidden email]]
>> Sent: Thursday, September 12, 2019 5:53 PM
>> To: [hidden email]
>> Subject: Re: [hackathon] maven archetypes
>>
>> Definitely +1 on having only one archetype. In case D is too much effort,
>> we could even leave it out.
>> A maintained archetype is better than what we currently have.
>> And it should be pretty easy for every developer to just copy over from a
>> blueprint project created from the archetype only the desired modules...
>>
>> Konrad
>>
>>> On 12. Sep 2019, at 16:50, Robert Munteanu <[hidden email]> wrote:
>>>
>>> On Thu, 2019-09-05 at 14:43 +0000, Stefan Seifert wrote:
>>>> - currently there are lots of sling maven archetypes, and most of
>>>> them not well maintained
>>>> - we would favor to have only one single "project" archetypes,
>>>> probably the new "project" archetype contributed by andy
>>>> - add parameters to switch features on and off, e.g. for generating
>>>> only with bundle but not with the content packages
>>>>   - this can be done using the groovy prost process
>>>>   - there is already a groovy script with a lot of logic in it, to be
>>>> reviewed if it already covers all use cases
>>>> - the plan is to no longer have the need to maintain multiple
>>>> archetypes
>>>> - review the generated structure of the current project archetypes.
>>>> the structure is derived from the adobe AEM project archetype, but we
>>>> like not all of it. e.g. the "ui." prefix for the contant packages,
>>>> probably introduce "bundles" and "content-packages" folders to but
>>>> bundles and content packages in.
>>> I would like to propose the following:
>>>
>>> A. deprecate all project archetype ( + parent ) except the sling-
>>> project-archetype
>>>
>>> 1. sling-slingstart-archetype
>>> 2. sling-archetype-parent
>>> 3. sling-taglib-archetype
>>> 4. sling-servlet-archetype
>>> 5. sling-bundle-archetype
>>> 6. sling-initial-content-archetype
>>> 7. sling-launchpad-standalone-archetype
>>> 8. sling-launchpad-webapp-archetype
>>> 9. sling-jcrinstall-bundle-archetype
>>>
>>> B. include the following artifacts in the project
>>>
>>> 1. core ( Java bundle )
>>> 2. content ( content package, sample data )
>>> 3. apps ( content package, Sling scripts )
>>> 4. launcher ( feature model project )
>>>
>>> C. I like the fact that the project includes sample data. Would it
>>> simplify maintenance if we always generated the sample data? I would
>>> expect the user to tweak it anyway.
>>>
>>> D. We _could_ heavily tweak the project and make it generate a single
>>> module, by e.g. deleting anything but the one of the modules and then
>>> making them top-level after generation has run (groovy script).
>>>
>>> That would effectively replace the other 8 existing projects, but I'm
>>> not sure if the complexity is worth it.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Robert
>
Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] maven archetypes

Robert Munteanu-2
Hi Ruben,

On Thu, 2019-09-19 at 08:12 -0700, Ruben Reusser wrote:
> for B) - the module names the archetype currently uses have been
> chosen
> to be aligned with the names the AEM Project Archetype uses. While I
> understand the ui.* may look odd it was meant to make it easier for
> a
> developer familiar with AEM to work on a sling project.

I think this consistency is a good point, we should not try and deviate
just for the sake of doing so. On the other hand, I think we will
deviate anyway. Some ideas that come to mind:

- include a launcher module that assembles a sling application
- integration tests inside the same module
- bundles/ and content-packages/ folders, as Stefan mentioned

Since we are converging towards the sling-project-archetype as _the_
archetype for Sling, we should make it a good introduction to Sling.
Easy migration to/from AEM is a good goal to keep in mind, but it
should not IMO be the only one.

Also, I think moving from ui.content to content and ui.apps to apps is
not such a huge move.

Thanks,
Robert

>
> The archetype also supports the common profiles to deploy packages
> such
> as autoInstallBundle and autoInstallPackage
>
> I am not opposed to changing the module names or the profile names,
> I
> just like consistency and the ease of moving from one product to
> another.
>
> Ruben
>
> On 9/12/2019 9:32 AM, Stefan Seifert wrote:
> > +1
> >
> > i also think we can omit D) for the first step.
> > i'm also fine with C) that it always include sample data - we can
> > always add a switch later to remove it.
> >
> > for B) we might consider putting all bundle projects below a
> > bundles/ folder
> > and all content package projects below a /content-packages folder
> > it's not unusual you create more of them for bigger projects, and
> > then they are nicely grouped.
> >
> > stefan
> >
> > > -----Original Message-----
> > > From: Konrad Windszus [mailto:[hidden email]]
> > > Sent: Thursday, September 12, 2019 5:53 PM
> > > To: [hidden email]
> > > Subject: Re: [hackathon] maven archetypes
> > >
> > > Definitely +1 on having only one archetype. In case D is too much
> > > effort,
> > > we could even leave it out.
> > > A maintained archetype is better than what we currently have.
> > > And it should be pretty easy for every developer to just copy
> > > over from a
> > > blueprint project created from the archetype only the desired
> > > modules...
> > >
> > > Konrad
> > >
> > > > On 12. Sep 2019, at 16:50, Robert Munteanu <[hidden email]>
> > > > wrote:
> > > >
> > > > On Thu, 2019-09-05 at 14:43 +0000, Stefan Seifert wrote:
> > > > > - currently there are lots of sling maven archetypes, and
> > > > > most of
> > > > > them not well maintained
> > > > > - we would favor to have only one single "project"
> > > > > archetypes,
> > > > > probably the new "project" archetype contributed by andy
> > > > > - add parameters to switch features on and off, e.g. for
> > > > > generating
> > > > > only with bundle but not with the content packages
> > > > >   - this can be done using the groovy prost process
> > > > >   - there is already a groovy script with a lot of logic in
> > > > > it, to be
> > > > > reviewed if it already covers all use cases
> > > > > - the plan is to no longer have the need to maintain multiple
> > > > > archetypes
> > > > > - review the generated structure of the current project
> > > > > archetypes.
> > > > > the structure is derived from the adobe AEM project
> > > > > archetype, but we
> > > > > like not all of it. e.g. the "ui." prefix for the contant
> > > > > packages,
> > > > > probably introduce "bundles" and "content-packages" folders
> > > > > to but
> > > > > bundles and content packages in.
> > > > I would like to propose the following:
> > > >
> > > > A. deprecate all project archetype ( + parent ) except the
> > > > sling-
> > > > project-archetype
> > > >
> > > > 1. sling-slingstart-archetype
> > > > 2. sling-archetype-parent
> > > > 3. sling-taglib-archetype
> > > > 4. sling-servlet-archetype
> > > > 5. sling-bundle-archetype
> > > > 6. sling-initial-content-archetype
> > > > 7. sling-launchpad-standalone-archetype
> > > > 8. sling-launchpad-webapp-archetype
> > > > 9. sling-jcrinstall-bundle-archetype
> > > >
> > > > B. include the following artifacts in the project
> > > >
> > > > 1. core ( Java bundle )
> > > > 2. content ( content package, sample data )
> > > > 3. apps ( content package, Sling scripts )
> > > > 4. launcher ( feature model project )
> > > >
> > > > C. I like the fact that the project includes sample data. Would
> > > > it
> > > > simplify maintenance if we always generated the sample data? I
> > > > would
> > > > expect the user to tweak it anyway.
> > > >
> > > > D. We _could_ heavily tweak the project and make it generate a
> > > > single
> > > > module, by e.g. deleting anything but the one of the modules
> > > > and then
> > > > making them top-level after generation has run (groovy script).
> > > >
> > > > That would effectively replace the other 8 existing projects,
> > > > but I'm
> > > > not sure if the complexity is worth it.
> > > >
> > > > Thoughts?
> > > >
> > > > Thanks,
> > > > Robert

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] maven archetypes

Robert Munteanu-2
In reply to this post by Andreas Schaefer-5
On Thu, 2019-09-12 at 09:28 -0700, Andreas Schaefer wrote:
> The only problem is the number of parameters that have to be handled
> as all parameters must be specified when the archetype is launched.

+1, that is a big problem and we should keep it under control.

Robert

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] maven archetypes

klcodanr
Sorry to add a wrinkle here, but I'm also wondering if it'd make sense to
make the sample options more flexible than just merge, keep or delete to
support different content use cases. For the Sling CMS reference, it'd be
nice to be able to populate more content than you'd need for a "base" Sling
instance. In particular, CA Configurations to enable a template and basic
settings. I'm sure we could also come up with other sample content sets
which would support different use cases which may be helpful for
on-boarding new developers.

I've put together a simple project archetype for Sling CMS here, but I'd
wonder if it'd be similar to back it into the overall
sling-project-archetype as a separate content option from the sample
content. Options for sample content like:

all - keep all the sample modules
default - keep the current sample modules
slingcms - keep the slingcms modules
none - delete all sample modules

Do you all think that'd be workable?


On Fri, Sep 20, 2019 at 6:46 AM Robert Munteanu <[hidden email]> wrote:

> On Thu, 2019-09-12 at 09:28 -0700, Andreas Schaefer wrote:
> > The only problem is the number of parameters that have to be handled
> > as all parameters must be specified when the archetype is launched.
>
> +1, that is a big problem and we should keep it under control.
>
> Robert
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] maven archetypes

Robert Munteanu-2
On Sat, 2019-10-05 at 23:32 -0500, Daniel Klco wrote:

(snip)

> I've put together a simple project archetype for Sling CMS here, but
> I'd
> wonder if it'd be similar to back it into the overall
> sling-project-archetype as a separate content option from the sample
> content. Options for sample content like:
>
> all - keep all the sample modules
> default - keep the current sample modules
> slingcms - keep the slingcms modules
> none - delete all sample modules
>
> Do you all think that'd be workable?

I guess it's a matter of complexity, in terms of implementation, as
Maven archetypes are limited. We also should not add user-visible
options unless really needed.

I think it would be interesting to have some shared infrastructure
between the two archetypes, but I'm not sure how that can be
accomplished without greatly increasing complexity and the testing
burden. Thoughts welcome :-)

Thanks,
Robert