Package per feature

[pacoolsky]

Number of features is growing and some of the features are quite independent of others. Lets assume I would like to use single feature e.g. Flush Rules only, I have to install the whole package. Would it possible to have package per feature, so I can install only these "plugins" which I would like to use ?

[pacoolsky]

This does not have to be 1-to-1 mapping (feature->package). e.g. would be nice to have combined "Dispatcher Flush UI" and "Dispatcher Flush Rules" and available as separate package.

[justinedelson]

The cost of doing this is rather high. What concrete value would be provided? If there are features which are overly intrusive by default, we should make them less intrusive.

[pacoolsky]

I see your point, there is definitely cost of doing this. Number of feature is growing and I wasn't even able to try all of them, cannot say if any features are intrusive or not .

So, maybe instead of making this as general rule do it only when it makes sense ? How about combining "Flush" plugins into one ? modularization is good thing :)

[justinedelson]

I guess what I'm not understanding is what the downside is from your perspective with our current one-package-to-rule-them-all approach is. If the features you haven't used weren't intrusive [and if they were, it seems like you would know :)], what's the downside?

Modularization is a good thing of course, but it needs to be balanced with simplicity. In most of the projects I've deployed ACS AEM Commons on, multiple features were used and the used features weren't necessarily related. This is, to be honest, exactly what I expect.

[pacoolsky]

I'm not saying that there is anything wrong with 'one-package' approach. It's just idea for discussion. I simply would like have an option to deploy the code which I would use and which have been tested in given setup.

Some projects can be very restrictive about deploying third party code, especially if the site went live already. I think that both "Flush plugins" it's something that could be added at later stage of the project to improve things.

What other option do I have ? Can I do a fork, and create such package for my own, would it be ok ?

[justinedelson]

You certainly can extract the code you want and package it in some other way. As long as you follow the terms of the Apache License.

But I really don't want you to do that :) Forks can be useful, but they can also create maintenance headaches.

I'd really like to understand the restrictions you are describing and how we can accomodate them without creating a lot of maintenance work for anyone. Let's say your project wanted to use Google Collections. Would you really try to decompose Guava into smaller pieces?

Please don't think I'm being dismissive of your request. I'm confident that you are representing a real world use case. I certainly appreciate this discussion and want to make sure that this project gets the widest distribution possible (within reason).

[pacoolsky]

As I wrote before already, I see your point, there are for sure pros & cons of both approaches, and probably I would try to keep it as it is for simplicity as well.

Not sure if Guava is good example here, contrary to this I can ask, would you prefer to have Sling released and deployed as single OSGi bundle ? :)

I definetely agree that feature per package is too fine-grained approach, when I look at the list of features now. However if number of features is growing, sooner or later some mudularisation can be required. Have you considered this ?

Regarding restrictions, I think I'm slightly skewed by feature-packs (and hotfixes) which can fix some issues and cause others, and some customers are also hypersensitive :)

I think it is still possible to find a good balance, and have an all-in-one package and some sub-modules at the same time without much overhead (and I would not like to go with fork as well).

[davidjgonzalez]

I understand w @pacoolsky pov here, esp w customer sensitivity - but, to @justinedelson's point - the typical use case seems to be enabling "random" features. Breaking features up into "logical modules" will still leave people unsatisfied (why do i need Dispatcher Rules if all i want is Dispatcher UI); wed never win unless it was ala carte.

TBH at the onset of this project my gut was w @pacoolsky, but - with the exception of some of the components and xtypes - our strategy of disabling features at the OSGi Component level, truly provides an unobtrusive deployment model; all that code is actually not "running" so it simply cannot interfere w original behaviors.

Maybe we need to do a better job of explaining of how we manage to be so unobtrusive as a all-in-one?

I worry even if we modularize, we'd run into inter-module dependencies which would force "unnecessary" modules to be installed just to satisfy said dependency (Ex. If DispatcherFlusher UI (in a dispatcher module) used the ComponentHelper (in a wcm module));

[stefanseifert]

i would also greatly prefer having different bundles per feature. indeed not having this is currently the reason we hesitate to use it in our projects.

ACS commons currently has over 50 different features. in a typical project we could perhaps need 2-5 of them. yes, this will be a "random pick", but still only a small subset.

splitting up into bundles will be a huge one-time effort (as always when you split up a monolith into single features). you can still release all bundles at once to keep the release process lean, and of course still provide an AEM content package containing all features as today. if the individual features are provided as OSGi modules in the maven repo projects could pick to use only some of them and do the bundling on their own side. (this would be easier if the JCR content of each feature are included in the OSGi bundle as sling initial-content, and not as a separate AEM package)

what are my main reasons to wish different bundles per features?

1. in general i want to install as few features/customizations on our customer systems as possible. i have no time to test all of them to check whether they are compatible with our projects and other libraries or not. i trust that you do the best job you can to make them "unobstrusive", but we are the first that have a problem when it's not the case; and if our project already depends on ACS commons we cannot simple remove it again if there is a problem with an unused feature.
2. perhaps i have a better solution for some of the features provided in ACS commons, but still want to use some others (e.g. http://wcm.io/sling/models/ vs. ACS commons AEM Objects Sling Models Injector). then i do not want to deploy both of them.
3. some bundles of ACS commons/tools do not start when additional third-party dependencies are not available. afaik this was solved in ACS commons with the introduction of the "min" variant, but for ACS tools this problem is still present. generally and from OSGi-perspective this is not a problem. but if you have an operations team on the customers side that is - well - not-so-well-trained - you need simple rules for them. like "make sure all bundles are active, if not there is a problem". having to explain them for which it is a problem and for which not sometimes overstrain them. same applies to monitoring tools just looking at all bundles statuses.

btw. - the same applies to ACS tools.

[justinedelson]

Not sure I understand the first point. If there is a feature which is overy obtrustive, where is the Issue/PR to fix that? This would, IMHO, be significantly more efficient than the solution you are suggesting.

Initial-content does not meet our requirements with respect to filtering or (soon) access control.

Also, ACS AEM Tools provides a min package now, so I don't really understand the problem in the third point.

[stefanseifert]

i was not aware AEM tools provides a min package as well, i created a PR to make it more obvious on the site: https://github.com/Adobe-Consulting-Services/adobe-consulting-services.github.io/pull/34

[davidjgonzalez]

Closing as this isnt the project paradigm; nice discussions tho!