sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konrad Windszus <konra...@gmx.de>
Subject Re: [hackathon] maven archetypes
Date Thu, 12 Sep 2019 15:52:53 GMT
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 <rombert@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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message