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 <romb...@apache.org> 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
