+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:konra...@gmx.de] >Sent: Thursday, September 12, 2019 5:53 PM >To: dev@sling.apache.org >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 <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
