Bootstrap files-set for new Projects

[davidjgonzalez]

Create a maven archetype that extends the Adobe multi-module maven archetype but includes core organization and place holders.

Intermediary solution: a zip of the augmenting files to unzipped over a new multi-mod project.

Key elements:

• skeleton component (copy down to create new components; promotes a common impl structure)
• common osgi configs xmls
• component organization
  • content/pages
  • global.jsp
  • base components
  • other examples XML of various common nodes. Templates, widgets, etc.

[justinedelson]

Some other thigns...

• Enable checkstyle/PMD configurations by default (similar to how ACS Commons is built)
• Enable various commons features by default (versioned clientlibs is one specifically that comes to mind)

Could definitely contain a base page component and template.

[justinedelson]

oh, and obviously should include acs-commons as a subpackage by default :)

One thing to consider is doing this as a module within the overall acs-aem-commons reactor project. That would mean that we'd release it in lockstep wth acs-aem-commons. Advantage of this is that the latest archetype always uses the latest acs-aem-commons.

Re: 'skeleton component' - might be overkill, but what about doing this in tools? I was thinking about a "create a descendent component" tool which would would take a component in /libs and then create a new component based on it - one thing I find to be a pain is when I have a component based on a foundation component where I'm adding a new tab to the dialog. Presumably the process of building a dialog referencing the tabs from the foundation component could be automated.

[davidjgonzalez]

I like the idea of the archetype; and acs-commons should absolutely be included in there :)

My initial thought of the manual "drop in" overlay was being able to "bootstrap" existing (non acs commons projects; which is most of them right now); but that only makes sense w a few pieces like osgi config (ex. wouldn't make sense dropping in global.jsp).

Wrt to file templates (skeleton) .. Commons probably isnt the right place.. But here's the rationale of pushing it into the context of the IDE (copy/paste down).

All of this is IME/O of course :)

Templatizing for devs WITHIN their natural dev env is a HUGE boon. Code uniformity increases, barrier to coding decreases along innumerable decision points. Providing documentation/external references that outlines code org is great, but nothing beats providing it in context. Requiring a dev to go outside their natural dev environment is enough of a change of gears where they'll just wing it instead.

AEM component development isn't hard; but knowing what/where all the moving pieces go is - esp for new devs.

This may be best served in a future Samples proj w some pre-built zips to load them into Eclipse/IntelliJ/etc.

[justinedelson]

In the past, I've not had a lot of luck with using archetypes to modify an existing project. Although it is theoretically possible using so-called "partial" archetypes, there ends up being too much variance in the target projects. Plus, we have more opportunity at project initiation to be opinionated :) (e.g. by enabling versioned clientlibs by default).

I do agree with providing more templates in the IDE. I expect that once SlingIDE reaches 1.0, there will be a reasonable number of wizards to perform these common steps, similar to the New Component/Template/etc. wizards in CRX DE (Lite). I don't think SlingIDE will necessarily come with these, but instead are extensions which Adobe and/or the community will provide.

I guess in theory there's nothing blocking anyone from creating these today as it is just a matter of creating the right files. This would be especially true in Java-land as I don't expect SlingIDE to change too much of the Java development paradigm. What SlingIDE would be helpful for is limiting the avaialbillty of such wizards to just SlingIDE projects.

[davidjgonzalez]

I agree a (full) archetype is the most sensible. If you`re at the point you need a partial overlay, many of the benefits of the bootstrap (except maybe osgi config) is already lost. Better to have a single consistent experience than many disparate.

[davidjgonzalez]

Closed via https://github.com/Adobe-Consulting-Services/lazybones-aem-templates