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:[email protected]]
Sent: Thursday, September 12, 2019 5:53 PM
To: [email protected]
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 <[email protected]> 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
