IBX-3644: [Doc] Fixed usage text suggested dest dir path

[alongosz]

Question	Answer
JIRA issue	IBX-3644
Type	improvement
Target Ibexa version	v4.2
BC breaks	no

This PR aligns usage (help) text of ./bin/generate-solr-config.sh script with the changes agreed in ibexa/documentation-developer#1742

[vidarl]

In the doc PR, it is also added information about merging in the schema changes needed by Commerce. Shouldn't this script also do that part ?

[adamwojs]

Bonus point for fixing references to "eZ Platform"/"eZ Platform Cloud" 😉

[adamwojs]

>In the doc PR, it is also added information about merging in the schema changes needed by Commerce. Shouldn't this script also do that part ?

This package is part of open source edition so it shouldn't handle anything related to content/expirance and commerce editions.

[vidarl]

This package is part of open source edition so it shouldn't handle anything related to content/expirance and commerce editions.

Well, it wouldn't hurt if it supported an --commerce command option.
The alternative is to have an almost exact copy of this script in an commerce bundle, but in regards to maintainability I don't think that would be a good suggestion ?

[alongosz]

This package is part of open source edition so it shouldn't handle anything related to content/expirance and commerce editions.

Well, it wouldn't hurt if it supported an --commerce command option. The alternative is to have an almost exact copy of this script in an commerce bundle, but in regards to maintainability I don't think that would be a good suggestion ?

To handle it in a clean way we would need some extension point which would delegate work to the other 1st party package scripts. Given the doc is simple and easy to apply I find it to be a bit overkill. Nevertheless contributions welcomed :) The only requirement would be that it cannot be a redundant copy, but some smart mechanism adding feature on top of the existing one.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[alongosz]

Bonus point for fixing references to "eZ Platform"/"eZ Platform Cloud" wink

@adamwojs 720759b

[vidarl]

To handle it in a clean way we would need some extension point which would delegate work to the other 1st party package scripts. Given the doc is simple and easy to apply I find it to be a bit overkill. Nevertheless contributions welcomed :) The only requirement would be that it cannot be a redundant copy, but some smart mechanism adding feature on top of the existing one.

If I create a PR in this very repo, adding option like the following be accepted ? :

[--ibexa-commerce]                   : Make the solr schema compatible with Ibexa Commerce. This option requires Ibexa Commerce

It is a simple solution to a simple problem. Instead of adding complexity of extension points etc.

Adding a extension point where 1st party packages may add things to the schema wouldn't be hard. But if we would need the possibility for one package to change something already defined by another package would be a mess. I think we are just better off having all the logic for the solr schema in one place

[alongosz]

To handle it in a clean way we would need some extension point which would delegate work to the other 1st party package scripts. Given the doc is simple and easy to apply I find it to be a bit overkill. Nevertheless contributions welcomed :) The only requirement would be that it cannot be a redundant copy, but some smart mechanism adding feature on top of the existing one.

If I create a PR in this very repo, adding option like the following be accepted ? :

[--ibexa-commerce]                   : Make the solr schema compatible with Ibexa Commerce. This option requires Ibexa Commerce

It is a simple solution to a simple problem. Instead of adding complexity of extension points etc.

Adding a extension point where 1st party packages may add things to the schema wouldn't be hard. But if we would need the possibility for one package to change something already defined by another package would be a mess. I think we are just better off having all the logic for the solr schema in one place

The problem with that is that you're exposing details of a closed-source package to an open source one, which is:

• LICENSE-wise questionable
• not clean
• not SOLID, because it violates Open-Closed principle.

[vidarl]

Okay, so that is a no go then