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