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 <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
