You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Konrad Windszus <kw...@apache.org> on 2022/06/02 09:56:33 UTC
Re: Custom Maven Enforcer Rule hosted at Sling
Coming back to this topic after a long time I propose to use the repository name "sling-org-apache-sling-maven-enforcer-rules" for this and give it artifact id "org.apache.sling.maven.enforcer.rules".
If I don't hear any objections I would create the repo at the end of the week.
Konrad
On 2021/05/28 07:04:45 Konrad Windszus wrote:
>
> Hi,
> I tried to contribute a Enforcer Rule to Apache Maven Enforcer in https://issues.apache.org/jira/browse/MENFORCER-385 (PR in https://github.com/apache/maven-enforcer/pull/97)
> Unfortunately the Maven committers consider this rule covering too much of an edge case to be considered for integration in the standard rule set.
>
> The rule is useful for Sling (but not limited to it). For use cases look at
> 1. https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/16 (uber-jar with maven-shader-plugin)
> 2. https://issues.apache.org/jira/browse/JCRVLT-394 (Maven plugin)
> 3. https://github.com/adobe/aemanalyser-maven-plugin/issues/58 (Maven plugin)
>
> I propose to create a dedicated repository in Sling containing Enforcer Rules starting with this one rule.
> WDYT?
>
> I know that Sling is maybe not the perfect fit, but MojoHaus Extra Enforcer Rules (https://github.com/mojohaus/extra-enforcer-rules) does not have much activity and lots of unmerged PRs and Apache Maven Enforcer already declined it.
> The other alternative is that I publish the rule on my personal GitHub space, but I would like have it under the Apache umbrella....
>
> Once we have it in Sling and have a release I would like to include it in https://github.com/apache/sling-org-apache-sling-feature-extension-content and probably some more Sling projects....
> WDYT,
> Konrad
>
>
>
Re: Custom Maven Enforcer Rule hosted at Sling
Posted by Konrad Windszus <kw...@apache.org>.
>
> I will not argue about the names as they make totally sense but we should try
> to be more consistent. Back then I was asked to use a more specific project/
> repo: sling-org-apache-sling-bnd-plugin-headers-parameters-remove¹ instead of
> just sling-org-apache-sling-bnd-plugins²
>
> O.
>
> 1) https://github.com/apache/sling-org-apache-sling-bnd-plugin-headers-parameters-remove
> 2) https://github.com/apache/sling-org-apache-sling-bnd-plugins
IIRC the problem back then was rather that there were already other Bnd plugins in dedicated repos
https://github.com/apache/sling-org-apache-sling-bnd-models and
https://github.com/apache/sling-org-apache-sling-caconfig-bnd-plugin
which made the generic name for another Bnd plugin kind of problematic.
But IMHO for Maven Enforcer we don’t yet have anything related up till now in Sling.
If in the future we have lots of different enforcer rules in Sling, I am happy to rename them in case keeping them in the same artifact and repository is problematic for some reason.
Konrad
Re: Custom Maven Enforcer Rule hosted at Sling
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday, 2 June 2022 14:05:22 CEST Konrad Windszus wrote:
> I see, then “sling-maven-enforcer-rules” and "maven-enforcer-rules” make
> more sense. WDYT?
I will not argue about the names as they make totally sense but we should try
to be more consistent. Back then I was asked to use a more specific project/
repo: sling-org-apache-sling-bnd-plugin-headers-parameters-remove¹ instead of
just sling-org-apache-sling-bnd-plugins²
O.
1) https://github.com/apache/sling-org-apache-sling-bnd-plugin-headers-parameters-remove
2) https://github.com/apache/sling-org-apache-sling-bnd-plugins
> Konrad
>
> > On 2. Jun 2022, at 13:58, Robert Munteanu <ro...@apache.org> wrote:
> >
> > On Thu, 2022-06-02 at 09:56 +0000, Konrad Windszus wrote:
> >> Coming back to this topic after a long time I propose to use the
> >> repository name "sling-org-apache-sling-maven-enforcer-rules" for
> >> this and give it artifact id "org.apache.sling.maven.enforcer.rules".
> >>
> >> If I don't hear any objections I would create the repo at the end of
> >> the week.
> >
> > No objections here. We usually have artifact ids that are unqualified
> > (not prefixed with org.apache.sling) in case of Maven tooling. Out of
> > curiosity, why did you decide for a qualified artifact id / git repo
> > name?
> >
> > Thanks,
> > Robert
> >
> >> Konrad
> >>
> >> On 2021/05/28 07:04:45 Konrad Windszus wrote:
> >>> Hi,
> >>> I tried to contribute a Enforcer Rule to Apache Maven Enforcer in
> >>> https://issues.apache.org/jira/browse/MENFORCER-385 (PR in
> >>> https://github.com/apache/maven-enforcer/pull/97)
> >>> Unfortunately the Maven committers consider this rule covering too
> >>> much of an edge case to be considered for integration in the
> >>> standard rule set.
> >>>
> >>> The rule is useful for Sling (but not limited to it). For use cases
> >>> look at
> >>> 1.
> >>> https://github.com/apache/sling-org-apache-sling-feature-extension-conte
> >>> nt/pull/16>>>
> >>> (uber-jar with maven-shader-plugin)
> >>>
> >>> 2. https://issues.apache.org/jira/browse/JCRVLT-394 (Maven plugin)
> >>> 3.
> >>> https://github.com/adobe/aemanalyser-maven-plugin/issues/58 (Maven
> >>> plugin)
> >>>
> >>> I propose to create a dedicated repository in Sling containing
> >>> Enforcer Rules starting with this one rule.
> >>> WDYT?
> >>>
> >>> I know that Sling is maybe not the perfect fit, but MojoHaus Extra
> >>> Enforcer Rules (https://github.com/mojohaus/extra-enforcer-rules)
> >>> does not have much activity and lots of unmerged PRs and Apache
> >>> Maven Enforcer already declined it.
> >>> The other alternative is that I publish the rule on my personal
> >>> GitHub space, but I would like have it under the Apache
> >>> umbrella....
> >>>
> >>> Once we have it in Sling and have a release I would like to include
> >>> it in
> >>> https://github.com/apache/sling-org-apache-sling-feature-extension-conte
> >>> nt
> >>>
> >>> and probably some more Sling projects....
> >>>
> >>> WDYT,
> >>> Konrad
Re: Custom Maven Enforcer Rule hosted at Sling
Posted by Robert Munteanu <ro...@apache.org>.
Sounds good to me. You could go with the other one as well, I was just
curious :-)
Thanks,
Robert
On Thu, 2022-06-02 at 14:05 +0200, Konrad Windszus wrote:
> I see, then “sling-maven-enforcer-rules” and "maven-enforcer-rules”
> make more sense.
> WDYT?
> Konrad
>
> > On 2. Jun 2022, at 13:58, Robert Munteanu <ro...@apache.org>
> > wrote:
> >
> > On Thu, 2022-06-02 at 09:56 +0000, Konrad Windszus wrote:
> > > Coming back to this topic after a long time I propose to use the
> > > repository name "sling-org-apache-sling-maven-enforcer-rules" for
> > > this and give it artifact id
> > > "org.apache.sling.maven.enforcer.rules".
> > >
> > > If I don't hear any objections I would create the repo at the end
> > > of
> > > the week.
> >
> > No objections here. We usually have artifact ids that are
> > unqualified
> > (not prefixed with org.apache.sling) in case of Maven tooling. Out
> > of
> > curiosity, why did you decide for a qualified artifact id / git
> > repo
> > name?
> >
> > Thanks,
> > Robert
> >
> > > Konrad
> > >
> > > On 2021/05/28 07:04:45 Konrad Windszus wrote:
> > > >
> > > > Hi,
> > > > I tried to contribute a Enforcer Rule to Apache Maven Enforcer
> > > > in
> > > > https://issues.apache.org/jira/browse/MENFORCER-385 (PR in
> > > > https://github.com/apache/maven-enforcer/pull/97)
> > > > Unfortunately the Maven committers consider this rule covering
> > > > too
> > > > much of an edge case to be considered for integration in the
> > > > standard rule set.
> > > >
> > > > The rule is useful for Sling (but not limited to it). For use
> > > > cases
> > > > look at
> > > > 1.
> > > > https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/16
> > > > (uber-jar with maven-shader-plugin)
> > > > 2. https://issues.apache.org/jira/browse/JCRVLT-394 (Maven
> > > > plugin)
> > > > 3.
> > > > https://github.com/adobe/aemanalyser-maven-plugin/issues/58 (Ma
> > > > ven
> > > > plugin)
> > > >
> > > > I propose to create a dedicated repository in Sling containing
> > > > Enforcer Rules starting with this one rule.
> > > > WDYT?
> > > >
> > > > I know that Sling is maybe not the perfect fit, but MojoHaus
> > > > Extra
> > > > Enforcer Rules
> > > > (https://github.com/mojohaus/extra-enforcer-rules)
> > > > does not have much activity and lots of unmerged PRs and Apache
> > > > Maven Enforcer already declined it.
> > > > The other alternative is that I publish the rule on my personal
> > > > GitHub space, but I would like have it under the Apache
> > > > umbrella....
> > > >
> > > > Once we have it in Sling and have a release I would like to
> > > > include
> > > > it in
> > > > https://github.com/apache/sling-org-apache-sling-feature-extension-content
> > > > and probably some more Sling projects....
> > > > WDYT,
> > > > Konrad
> > > >
> > > >
> > > >
> >
>
Re: Custom Maven Enforcer Rule hosted at Sling
Posted by Konrad Windszus <kw...@apache.org>.
I see, then “sling-maven-enforcer-rules” and "maven-enforcer-rules” make more sense.
WDYT?
Konrad
> On 2. Jun 2022, at 13:58, Robert Munteanu <ro...@apache.org> wrote:
>
> On Thu, 2022-06-02 at 09:56 +0000, Konrad Windszus wrote:
>> Coming back to this topic after a long time I propose to use the
>> repository name "sling-org-apache-sling-maven-enforcer-rules" for
>> this and give it artifact id "org.apache.sling.maven.enforcer.rules".
>>
>> If I don't hear any objections I would create the repo at the end of
>> the week.
>
> No objections here. We usually have artifact ids that are unqualified
> (not prefixed with org.apache.sling) in case of Maven tooling. Out of
> curiosity, why did you decide for a qualified artifact id / git repo
> name?
>
> Thanks,
> Robert
>
>> Konrad
>>
>> On 2021/05/28 07:04:45 Konrad Windszus wrote:
>>>
>>> Hi,
>>> I tried to contribute a Enforcer Rule to Apache Maven Enforcer in
>>> https://issues.apache.org/jira/browse/MENFORCER-385 (PR in
>>> https://github.com/apache/maven-enforcer/pull/97)
>>> Unfortunately the Maven committers consider this rule covering too
>>> much of an edge case to be considered for integration in the
>>> standard rule set.
>>>
>>> The rule is useful for Sling (but not limited to it). For use cases
>>> look at
>>> 1.
>>> https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/16
>>> (uber-jar with maven-shader-plugin)
>>> 2. https://issues.apache.org/jira/browse/JCRVLT-394 (Maven plugin)
>>> 3.
>>> https://github.com/adobe/aemanalyser-maven-plugin/issues/58 (Maven
>>> plugin)
>>>
>>> I propose to create a dedicated repository in Sling containing
>>> Enforcer Rules starting with this one rule.
>>> WDYT?
>>>
>>> I know that Sling is maybe not the perfect fit, but MojoHaus Extra
>>> Enforcer Rules (https://github.com/mojohaus/extra-enforcer-rules)
>>> does not have much activity and lots of unmerged PRs and Apache
>>> Maven Enforcer already declined it.
>>> The other alternative is that I publish the rule on my personal
>>> GitHub space, but I would like have it under the Apache
>>> umbrella....
>>>
>>> Once we have it in Sling and have a release I would like to include
>>> it in
>>> https://github.com/apache/sling-org-apache-sling-feature-extension-content
>>> and probably some more Sling projects....
>>> WDYT,
>>> Konrad
>>>
>>>
>>>
>
Re: Custom Maven Enforcer Rule hosted at Sling
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, 2022-06-02 at 09:56 +0000, Konrad Windszus wrote:
> Coming back to this topic after a long time I propose to use the
> repository name "sling-org-apache-sling-maven-enforcer-rules" for
> this and give it artifact id "org.apache.sling.maven.enforcer.rules".
>
> If I don't hear any objections I would create the repo at the end of
> the week.
No objections here. We usually have artifact ids that are unqualified
(not prefixed with org.apache.sling) in case of Maven tooling. Out of
curiosity, why did you decide for a qualified artifact id / git repo
name?
Thanks,
Robert
> Konrad
>
> On 2021/05/28 07:04:45 Konrad Windszus wrote:
> >
> > Hi,
> > I tried to contribute a Enforcer Rule to Apache Maven Enforcer in
> > https://issues.apache.org/jira/browse/MENFORCER-385 (PR in
> > https://github.com/apache/maven-enforcer/pull/97)
> > Unfortunately the Maven committers consider this rule covering too
> > much of an edge case to be considered for integration in the
> > standard rule set.
> >
> > The rule is useful for Sling (but not limited to it). For use cases
> > look at
> > 1.
> > https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/16
> > (uber-jar with maven-shader-plugin)
> > 2. https://issues.apache.org/jira/browse/JCRVLT-394 (Maven plugin)
> > 3.
> > https://github.com/adobe/aemanalyser-maven-plugin/issues/58 (Maven
> > plugin)
> >
> > I propose to create a dedicated repository in Sling containing
> > Enforcer Rules starting with this one rule.
> > WDYT?
> >
> > I know that Sling is maybe not the perfect fit, but MojoHaus Extra
> > Enforcer Rules (https://github.com/mojohaus/extra-enforcer-rules)
> > does not have much activity and lots of unmerged PRs and Apache
> > Maven Enforcer already declined it.
> > The other alternative is that I publish the rule on my personal
> > GitHub space, but I would like have it under the Apache
> > umbrella....
> >
> > Once we have it in Sling and have a release I would like to include
> > it in
> > https://github.com/apache/sling-org-apache-sling-feature-extension-content
> > and probably some more Sling projects....
> > WDYT,
> > Konrad
> >
> >
> >