You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Andreas Schaefer <sc...@me.com.INVALID> on 2019/07/16 14:50:53 UTC
Issue with Sling Feature Maven Plugin
Hi Simone
I ran into a snafu with the Sling Feature Maven Plugin. This plugin is doing a blank check during the initialization phase which is causing headaches for the CP Converter goal.
There are various issues but the most glaring is the fact that when I use placeholders in the FM id like "${project.groupId}” then it will fail to even clean the project with ‘mvn clean’ or when there is no feature at all.
Can we either disable these tests or move them in the respective Mojos (phase) ?
Cheers - Andy Schaefer
Re: Issue with Sling Feature Maven Plugin
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
Hi
I committed my changes to sling-slingfeature-maven-plugin branch: merge-cpconverter-plugin.
With these changes I was able to convert Sling Starter Provisioning and Headwire’s Peregrine Content Packages into a feature launcher system in one maven built step (mvn clean install) and launch it successfully.
There are still a few things I need to iron out but this is a good starting point I think.
Cheers - Andy Schaefer
> On Jul 16, 2019, at 4:36 PM, Andreas Schaefer <sc...@me.com.INVALID> wrote:
>
> Hi
>
> I found a solution by moving the code into the Mojos. The entire code is now here:
>
> AbstractFeatureMojo.prepareProject()
>
> And all Mojos interested can call them at the beginning of the execute() method.
>
> This way my Mojo can work w/o any features present and w/o having issues during the different phases and goals.
>
> Let me know if that is an acceptable solution.
>
> Cheers - Andy Schaefer
>
>> On Jul 16, 2019, at 7:50 AM, Andreas Schaefer <sc...@me.com.INVALID> wrote:
>>
>> Hi Simone
>>
>> I ran into a snafu with the Sling Feature Maven Plugin. This plugin is doing a blank check during the initialization phase which is causing headaches for the CP Converter goal.
>>
>> There are various issues but the most glaring is the fact that when I use placeholders in the FM id like "${project.groupId}” then it will fail to even clean the project with ‘mvn clean’ or when there is no feature at all.
>>
>> Can we either disable these tests or move them in the respective Mojos (phase) ?
>>
>> Cheers - Andy Schaefer
>
Re: Issue with Sling Feature Maven Plugin
Posted by Carsten Ziegeler <cz...@apache.org>.
I've added a proposal to SLING-8541 to deal with the use case
Let's continue there
Carsten
Carsten Ziegeler wrote
>
> I started to remove the DependencyLifecycleParticipant just to find out
> that this might create problems in reactor builds where one feature
> project depends on another feature: with the DLP these inter feature
> dependencies are managed as maven dependencies and the build order is
> correctly handled. Without the DLP, maven has no clue about these
> dependencies and might build them in the wrong order.
>
> With that I don't think removing the DLP is a good idea.
>
> As mentioned, we can solve the "mvn clean" problem easily and I'll fix
> that.
>
> Second, we need to look into how the converter comes into play. I don't
> want to have the conversion as part of the featureplugin. At this point
> in time, the use case of the converter and the featureplugin in
> combination is a little bit unclear to me. Maybe you can explain a
> little bit about this?
>
>
> Regards
>
> Carsten
>
> Carsten Ziegeler wrote
>> Hi,
>>
>> I gave this a second thought and maybe we should drop the
>> DependencyLifecycleParticipant from this plugin and simply handle it
>> in the mojos. Probably the first mojo requiring a feature will
>> initiate the work. I have the feeling that this could also simplify
>> some of the code.
>>
>> For my use case of having a feature as a maven dependency, we could
>> simply build a different maven plugin. It's a different usage of
>> features so splitting it into another plugin makes sense. I don't have
>> any sample project for that to share.
>>
>> Regards
>> Carsten
>>
>> Andreas Schaefer wrote
>>> Hi Carsten
>>>
>>> Yes, moving the ‘feature exists’ check would fix the issue of no
>>> features in certain Mojos.
>>> That said I think the Plugin must be able to pick up changes to
>>> feature models files during the build is it now the converter or
>>> copying in FMs as resources during the build.
>>>
>>> We could have a static flag within Plugin that would indicate when a
>>> re-evaluation needs to be done so copying resources or generating FMs
>>> (aka converter) could trigger a re-evaluation.
>>>
>>> Do you have a sample project regarding the use case of dependency
>>> through FM? I would like to add a IT test so that this is covered.
>>>
>>> - Andy
>>>
>>>> On Jul 22, 2019, at 10:16 AM, Carsten Ziegeler
>>>> <cz...@apache.org> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>> for a normal feature build it is not required to have the
>>>> DependencyLifecycleParticipant, that's why your build works. For
>>>> additional functionality like using the mvn versions plugin etc t is
>>>> required.
>>>>
>>>> And you're correct that any changes to features after the
>>>> DependencyLifecycleParticipant has run are not picked up.
>>>>
>>>> One main one reason for the current way of doing things was actually
>>>> the mvn versions plugin. However, the feature plugin has now a
>>>> similar functionality.
>>>>
>>>> The other reason is to use feature files to define dependencies for
>>>> a java project. So instead of listing all your dependencies in the
>>>> pom, you can simply reference a feature file and through the
>>>> DependencyLifecycleParticipant these are added as dependencies to
>>>> your project. This is very useful for bundle development as well as
>>>> for developing small applications where you take a base stack
>>>> defined as a feature and just add another bundle. I don't want to
>>>> loose that functionality.
>>>>
>>>> We can solve the "mvn clean" problem by just moving the check to the
>>>> mojos. Each mojo calls already a central method that verifies if the
>>>> DependencyLifecycleParticipant has run and if we move the "no
>>>> features found" check there, that problem is solved.
>>>>
>>>> I understand that the converter use case is a different one, in that
>>>> case you probably don't need a DependencyLifecycleParticipant at all.
>>>>
>>>> I think we already have a configuration for whether the
>>>> DependencyLifecycleParticipant is adding the artifacts from feature
>>>> files to the maven project as dependencies. We could now defer all
>>>> the functionality of the DependencyLifecycleParticipant to the
>>>> first mojo if that flag is turned off.
>>>>
>>>>
>>>> WDYT?
>>>>
>>>>
>>>> Regards
>>>>
>>>> Carsten
>>>>
>>>>
>>>> Andreas Schaefer wrote
>>>>> Hi Carsten
>>>>> There are a few issues with the current way the plugin works:
>>>>> 1. If for whatever reason the features folder does not contain any
>>>>> features then a ‘mvn clean’ will fail. That check should be moved
>>>>> to a Mojo that requires a feature file and not being done for all
>>>>> Mojos
>>>>> 2. The DependencyLifecycleParticipant has a state which means that
>>>>> changes to features after the loading of the project is not
>>>>> reflected in that state meaning that when I generate feature files
>>>>> (CQ / PM converter) then it will not be considered by the feature
>>>>> Mojos (I did not do a thorough investigation so I might be wrong)
>>>>> 3. All the tests and a full Sling / Peregrine CMS conversion (9 CP
>>>>> packages), built and launch worked just fine for me.
>>>>> I do not think the converter runs too late but it runs within the
>>>>> confines of the plugin meaning the DependencyLifecycleParticipant
>>>>> is fire ahead of the converters invocation. This is the firing
>>>>> sequence:
>>>>> - Convert Sling PM to FM
>>>>> - Convert Peregrine CMS CP to FM
>>>>> - Aggregate FMs
>>>>> - Attach FMs
>>>>> - Analyze FMs
>>>>> BTW there is also the issue that the ‘slingosgifeature’ packaging /
>>>>> our Plugin does not copy resource to the target. This is normally
>>>>> not a problem but I need to add a static FM (jcr packageinit) to
>>>>> the converted FMs to make Sling launch. I think it would be best to
>>>>> support copying resources and look for features in the /target
>>>>> folder instead.
>>>>> Cheers - Andy
>>>>>> On Jul 22, 2019, at 12:28 AM, Carsten Ziegeler
>>>>>> <cz...@apache.org> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> moving this code out of the DependencyLifecycleParticipant will
>>>>>> break some functionality. A DependencyLifecycleParticipant is run
>>>>>> *before* any mojos and allwos to add dependencies to projects. We
>>>>>> use this to add the artifacts from the feature files as
>>>>>> dependencies to the maven project in order to use mavens
>>>>>> dependency mechanism. For example this allows to use mavens
>>>>>> mechanism to check for updates of artifacts etc.
>>>>>>
>>>>>>
>>>>>> If we speak about the converter, I guess the problem is that the
>>>>>> converter runs too late. So maybe we should rather fix that?
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Carsten
>>>>>>
>>>>>>
>>>>>> Andreas Schaefer wrote
>>>>>>> Hi
>>>>>>> I found a solution by moving the code into the Mojos. The entire
>>>>>>> code is now here:
>>>>>>> AbstractFeatureMojo.prepareProject()
>>>>>>> And all Mojos interested can call them at the beginning of the
>>>>>>> execute() method.
>>>>>>> This way my Mojo can work w/o any features present and w/o having
>>>>>>> issues during the different phases and goals.
>>>>>>> Let me know if that is an acceptable solution.
>>>>>>> Cheers - Andy Schaefer
>>>>>>>> On Jul 16, 2019, at 7:50 AM, Andreas Schaefer
>>>>>>>> <sc...@me.com.INVALID> wrote:
>>>>>>>>
>>>>>>>> Hi Simone
>>>>>>>>
>>>>>>>> I ran into a snafu with the Sling Feature Maven Plugin. This
>>>>>>>> plugin is doing a blank check during the initialization phase
>>>>>>>> which is causing headaches for the CP Converter goal.
>>>>>>>>
>>>>>>>> There are various issues but the most glaring is the fact that
>>>>>>>> when I use placeholders in the FM id like "${project.groupId}”
>>>>>>>> then it will fail to even clean the project with ‘mvn clean’ or
>>>>>>>> when there is no feature at all.
>>>>>>>>
>>>>>>>> Can we either disable these tests or move them in the respective
>>>>>>>> Mojos (phase) ?
>>>>>>>>
>>>>>>>> Cheers - Andy Schaefer
>>>>>> --
>>>>>> Carsten Ziegeler
>>>>>> Adobe Research Switzerland
>>>>>> cziegeler@apache.org
>>>> --
>>>> Carsten Ziegeler
>>>> Adobe Research Switzerland
>>>> cziegeler@apache.org
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Issue with Sling Feature Maven Plugin
Posted by Carsten Ziegeler <cz...@apache.org>.
I started to remove the DependencyLifecycleParticipant just to find out
that this might create problems in reactor builds where one feature
project depends on another feature: with the DLP these inter feature
dependencies are managed as maven dependencies and the build order is
correctly handled. Without the DLP, maven has no clue about these
dependencies and might build them in the wrong order.
With that I don't think removing the DLP is a good idea.
As mentioned, we can solve the "mvn clean" problem easily and I'll fix that.
Second, we need to look into how the converter comes into play. I don't
want to have the conversion as part of the featureplugin. At this point
in time, the use case of the converter and the featureplugin in
combination is a little bit unclear to me. Maybe you can explain a
little bit about this?
Regards
Carsten
Carsten Ziegeler wrote
> Hi,
>
> I gave this a second thought and maybe we should drop the
> DependencyLifecycleParticipant from this plugin and simply handle it in
> the mojos. Probably the first mojo requiring a feature will initiate the
> work. I have the feeling that this could also simplify some of the code.
>
> For my use case of having a feature as a maven dependency, we could
> simply build a different maven plugin. It's a different usage of
> features so splitting it into another plugin makes sense. I don't have
> any sample project for that to share.
>
> Regards
> Carsten
>
> Andreas Schaefer wrote
>> Hi Carsten
>>
>> Yes, moving the ‘feature exists’ check would fix the issue of no
>> features in certain Mojos.
>> That said I think the Plugin must be able to pick up changes to
>> feature models files during the build is it now the converter or
>> copying in FMs as resources during the build.
>>
>> We could have a static flag within Plugin that would indicate when a
>> re-evaluation needs to be done so copying resources or generating FMs
>> (aka converter) could trigger a re-evaluation.
>>
>> Do you have a sample project regarding the use case of dependency
>> through FM? I would like to add a IT test so that this is covered.
>>
>> - Andy
>>
>>> On Jul 22, 2019, at 10:16 AM, Carsten Ziegeler <cz...@apache.org>
>>> wrote:
>>>
>>>
>>> Hi,
>>>
>>>
>>> for a normal feature build it is not required to have the
>>> DependencyLifecycleParticipant, that's why your build works. For
>>> additional functionality like using the mvn versions plugin etc t is
>>> required.
>>>
>>> And you're correct that any changes to features after the
>>> DependencyLifecycleParticipant has run are not picked up.
>>>
>>> One main one reason for the current way of doing things was actually
>>> the mvn versions plugin. However, the feature plugin has now a
>>> similar functionality.
>>>
>>> The other reason is to use feature files to define dependencies for a
>>> java project. So instead of listing all your dependencies in the pom,
>>> you can simply reference a feature file and through the
>>> DependencyLifecycleParticipant these are added as dependencies to
>>> your project. This is very useful for bundle development as well as
>>> for developing small applications where you take a base stack defined
>>> as a feature and just add another bundle. I don't want to loose that
>>> functionality.
>>>
>>> We can solve the "mvn clean" problem by just moving the check to the
>>> mojos. Each mojo calls already a central method that verifies if the
>>> DependencyLifecycleParticipant has run and if we move the "no
>>> features found" check there, that problem is solved.
>>>
>>> I understand that the converter use case is a different one, in that
>>> case you probably don't need a DependencyLifecycleParticipant at all.
>>>
>>> I think we already have a configuration for whether the
>>> DependencyLifecycleParticipant is adding the artifacts from feature
>>> files to the maven project as dependencies. We could now defer all
>>> the functionality of the DependencyLifecycleParticipant to the first
>>> mojo if that flag is turned off.
>>>
>>>
>>> WDYT?
>>>
>>>
>>> Regards
>>>
>>> Carsten
>>>
>>>
>>> Andreas Schaefer wrote
>>>> Hi Carsten
>>>> There are a few issues with the current way the plugin works:
>>>> 1. If for whatever reason the features folder does not contain any
>>>> features then a ‘mvn clean’ will fail. That check should be moved to
>>>> a Mojo that requires a feature file and not being done for all Mojos
>>>> 2. The DependencyLifecycleParticipant has a state which means that
>>>> changes to features after the loading of the project is not
>>>> reflected in that state meaning that when I generate feature files
>>>> (CQ / PM converter) then it will not be considered by the feature
>>>> Mojos (I did not do a thorough investigation so I might be wrong)
>>>> 3. All the tests and a full Sling / Peregrine CMS conversion (9 CP
>>>> packages), built and launch worked just fine for me.
>>>> I do not think the converter runs too late but it runs within the
>>>> confines of the plugin meaning the DependencyLifecycleParticipant is
>>>> fire ahead of the converters invocation. This is the firing sequence:
>>>> - Convert Sling PM to FM
>>>> - Convert Peregrine CMS CP to FM
>>>> - Aggregate FMs
>>>> - Attach FMs
>>>> - Analyze FMs
>>>> BTW there is also the issue that the ‘slingosgifeature’ packaging /
>>>> our Plugin does not copy resource to the target. This is normally
>>>> not a problem but I need to add a static FM (jcr packageinit) to the
>>>> converted FMs to make Sling launch. I think it would be best to
>>>> support copying resources and look for features in the /target
>>>> folder instead.
>>>> Cheers - Andy
>>>>> On Jul 22, 2019, at 12:28 AM, Carsten Ziegeler
>>>>> <cz...@apache.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> moving this code out of the DependencyLifecycleParticipant will
>>>>> break some functionality. A DependencyLifecycleParticipant is run
>>>>> *before* any mojos and allwos to add dependencies to projects. We
>>>>> use this to add the artifacts from the feature files as
>>>>> dependencies to the maven project in order to use mavens dependency
>>>>> mechanism. For example this allows to use mavens mechanism to check
>>>>> for updates of artifacts etc.
>>>>>
>>>>>
>>>>> If we speak about the converter, I guess the problem is that the
>>>>> converter runs too late. So maybe we should rather fix that?
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Carsten
>>>>>
>>>>>
>>>>> Andreas Schaefer wrote
>>>>>> Hi
>>>>>> I found a solution by moving the code into the Mojos. The entire
>>>>>> code is now here:
>>>>>> AbstractFeatureMojo.prepareProject()
>>>>>> And all Mojos interested can call them at the beginning of the
>>>>>> execute() method.
>>>>>> This way my Mojo can work w/o any features present and w/o having
>>>>>> issues during the different phases and goals.
>>>>>> Let me know if that is an acceptable solution.
>>>>>> Cheers - Andy Schaefer
>>>>>>> On Jul 16, 2019, at 7:50 AM, Andreas Schaefer
>>>>>>> <sc...@me.com.INVALID> wrote:
>>>>>>>
>>>>>>> Hi Simone
>>>>>>>
>>>>>>> I ran into a snafu with the Sling Feature Maven Plugin. This
>>>>>>> plugin is doing a blank check during the initialization phase
>>>>>>> which is causing headaches for the CP Converter goal.
>>>>>>>
>>>>>>> There are various issues but the most glaring is the fact that
>>>>>>> when I use placeholders in the FM id like "${project.groupId}”
>>>>>>> then it will fail to even clean the project with ‘mvn clean’ or
>>>>>>> when there is no feature at all.
>>>>>>>
>>>>>>> Can we either disable these tests or move them in the respective
>>>>>>> Mojos (phase) ?
>>>>>>>
>>>>>>> Cheers - Andy Schaefer
>>>>> --
>>>>> Carsten Ziegeler
>>>>> Adobe Research Switzerland
>>>>> cziegeler@apache.org
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Issue with Sling Feature Maven Plugin
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
I gave this a second thought and maybe we should drop the
DependencyLifecycleParticipant from this plugin and simply handle it in
the mojos. Probably the first mojo requiring a feature will initiate the
work. I have the feeling that this could also simplify some of the code.
For my use case of having a feature as a maven dependency, we could
simply build a different maven plugin. It's a different usage of
features so splitting it into another plugin makes sense. I don't have
any sample project for that to share.
Regards
Carsten
Andreas Schaefer wrote
> Hi Carsten
>
> Yes, moving the ‘feature exists’ check would fix the issue of no features in certain Mojos.
> That said I think the Plugin must be able to pick up changes to feature models files during the build is it now the converter or copying in FMs as resources during the build.
>
> We could have a static flag within Plugin that would indicate when a re-evaluation needs to be done so copying resources or generating FMs (aka converter) could trigger a re-evaluation.
>
> Do you have a sample project regarding the use case of dependency through FM? I would like to add a IT test so that this is covered.
>
> - Andy
>
>> On Jul 22, 2019, at 10:16 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>>
>> Hi,
>>
>>
>> for a normal feature build it is not required to have the DependencyLifecycleParticipant, that's why your build works. For additional functionality like using the mvn versions plugin etc t is required.
>>
>> And you're correct that any changes to features after the DependencyLifecycleParticipant has run are not picked up.
>>
>> One main one reason for the current way of doing things was actually the mvn versions plugin. However, the feature plugin has now a similar functionality.
>>
>> The other reason is to use feature files to define dependencies for a java project. So instead of listing all your dependencies in the pom, you can simply reference a feature file and through the DependencyLifecycleParticipant these are added as dependencies to your project. This is very useful for bundle development as well as for developing small applications where you take a base stack defined as a feature and just add another bundle. I don't want to loose that functionality.
>>
>> We can solve the "mvn clean" problem by just moving the check to the mojos. Each mojo calls already a central method that verifies if the DependencyLifecycleParticipant has run and if we move the "no features found" check there, that problem is solved.
>>
>> I understand that the converter use case is a different one, in that case you probably don't need a DependencyLifecycleParticipant at all.
>>
>> I think we already have a configuration for whether the DependencyLifecycleParticipant is adding the artifacts from feature files to the maven project as dependencies. We could now defer all the functionality of the DependencyLifecycleParticipant to the first mojo if that flag is turned off.
>>
>>
>> WDYT?
>>
>>
>> Regards
>>
>> Carsten
>>
>>
>> Andreas Schaefer wrote
>>> Hi Carsten
>>> There are a few issues with the current way the plugin works:
>>> 1. If for whatever reason the features folder does not contain any features then a ‘mvn clean’ will fail. That check should be moved to a Mojo that requires a feature file and not being done for all Mojos
>>> 2. The DependencyLifecycleParticipant has a state which means that changes to features after the loading of the project is not reflected in that state meaning that when I generate feature files (CQ / PM converter) then it will not be considered by the feature Mojos (I did not do a thorough investigation so I might be wrong)
>>> 3. All the tests and a full Sling / Peregrine CMS conversion (9 CP packages), built and launch worked just fine for me.
>>> I do not think the converter runs too late but it runs within the confines of the plugin meaning the DependencyLifecycleParticipant is fire ahead of the converters invocation. This is the firing sequence:
>>> - Convert Sling PM to FM
>>> - Convert Peregrine CMS CP to FM
>>> - Aggregate FMs
>>> - Attach FMs
>>> - Analyze FMs
>>> BTW there is also the issue that the ‘slingosgifeature’ packaging / our Plugin does not copy resource to the target. This is normally not a problem but I need to add a static FM (jcr packageinit) to the converted FMs to make Sling launch. I think it would be best to support copying resources and look for features in the /target folder instead.
>>> Cheers - Andy
>>>> On Jul 22, 2019, at 12:28 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> moving this code out of the DependencyLifecycleParticipant will break some functionality. A DependencyLifecycleParticipant is run *before* any mojos and allwos to add dependencies to projects. We use this to add the artifacts from the feature files as dependencies to the maven project in order to use mavens dependency mechanism. For example this allows to use mavens mechanism to check for updates of artifacts etc.
>>>>
>>>>
>>>> If we speak about the converter, I guess the problem is that the converter runs too late. So maybe we should rather fix that?
>>>>
>>>>
>>>> Regards
>>>>
>>>> Carsten
>>>>
>>>>
>>>> Andreas Schaefer wrote
>>>>> Hi
>>>>> I found a solution by moving the code into the Mojos. The entire code is now here:
>>>>> AbstractFeatureMojo.prepareProject()
>>>>> And all Mojos interested can call them at the beginning of the execute() method.
>>>>> This way my Mojo can work w/o any features present and w/o having issues during the different phases and goals.
>>>>> Let me know if that is an acceptable solution.
>>>>> Cheers - Andy Schaefer
>>>>>> On Jul 16, 2019, at 7:50 AM, Andreas Schaefer <sc...@me.com.INVALID> wrote:
>>>>>>
>>>>>> Hi Simone
>>>>>>
>>>>>> I ran into a snafu with the Sling Feature Maven Plugin. This plugin is doing a blank check during the initialization phase which is causing headaches for the CP Converter goal.
>>>>>>
>>>>>> There are various issues but the most glaring is the fact that when I use placeholders in the FM id like "${project.groupId}” then it will fail to even clean the project with ‘mvn clean’ or when there is no feature at all.
>>>>>>
>>>>>> Can we either disable these tests or move them in the respective Mojos (phase) ?
>>>>>>
>>>>>> Cheers - Andy Schaefer
>>>> --
>>>> Carsten Ziegeler
>>>> Adobe Research Switzerland
>>>> cziegeler@apache.org
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Issue with Sling Feature Maven Plugin
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
Hi Carsten
Yes, moving the ‘feature exists’ check would fix the issue of no features in certain Mojos.
That said I think the Plugin must be able to pick up changes to feature models files during the build is it now the converter or copying in FMs as resources during the build.
We could have a static flag within Plugin that would indicate when a re-evaluation needs to be done so copying resources or generating FMs (aka converter) could trigger a re-evaluation.
Do you have a sample project regarding the use case of dependency through FM? I would like to add a IT test so that this is covered.
- Andy
> On Jul 22, 2019, at 10:16 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>
>
> Hi,
>
>
> for a normal feature build it is not required to have the DependencyLifecycleParticipant, that's why your build works. For additional functionality like using the mvn versions plugin etc t is required.
>
> And you're correct that any changes to features after the DependencyLifecycleParticipant has run are not picked up.
>
> One main one reason for the current way of doing things was actually the mvn versions plugin. However, the feature plugin has now a similar functionality.
>
> The other reason is to use feature files to define dependencies for a java project. So instead of listing all your dependencies in the pom, you can simply reference a feature file and through the DependencyLifecycleParticipant these are added as dependencies to your project. This is very useful for bundle development as well as for developing small applications where you take a base stack defined as a feature and just add another bundle. I don't want to loose that functionality.
>
> We can solve the "mvn clean" problem by just moving the check to the mojos. Each mojo calls already a central method that verifies if the DependencyLifecycleParticipant has run and if we move the "no features found" check there, that problem is solved.
>
> I understand that the converter use case is a different one, in that case you probably don't need a DependencyLifecycleParticipant at all.
>
> I think we already have a configuration for whether the DependencyLifecycleParticipant is adding the artifacts from feature files to the maven project as dependencies. We could now defer all the functionality of the DependencyLifecycleParticipant to the first mojo if that flag is turned off.
>
>
> WDYT?
>
>
> Regards
>
> Carsten
>
>
> Andreas Schaefer wrote
>> Hi Carsten
>> There are a few issues with the current way the plugin works:
>> 1. If for whatever reason the features folder does not contain any features then a ‘mvn clean’ will fail. That check should be moved to a Mojo that requires a feature file and not being done for all Mojos
>> 2. The DependencyLifecycleParticipant has a state which means that changes to features after the loading of the project is not reflected in that state meaning that when I generate feature files (CQ / PM converter) then it will not be considered by the feature Mojos (I did not do a thorough investigation so I might be wrong)
>> 3. All the tests and a full Sling / Peregrine CMS conversion (9 CP packages), built and launch worked just fine for me.
>> I do not think the converter runs too late but it runs within the confines of the plugin meaning the DependencyLifecycleParticipant is fire ahead of the converters invocation. This is the firing sequence:
>> - Convert Sling PM to FM
>> - Convert Peregrine CMS CP to FM
>> - Aggregate FMs
>> - Attach FMs
>> - Analyze FMs
>> BTW there is also the issue that the ‘slingosgifeature’ packaging / our Plugin does not copy resource to the target. This is normally not a problem but I need to add a static FM (jcr packageinit) to the converted FMs to make Sling launch. I think it would be best to support copying resources and look for features in the /target folder instead.
>> Cheers - Andy
>>> On Jul 22, 2019, at 12:28 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> moving this code out of the DependencyLifecycleParticipant will break some functionality. A DependencyLifecycleParticipant is run *before* any mojos and allwos to add dependencies to projects. We use this to add the artifacts from the feature files as dependencies to the maven project in order to use mavens dependency mechanism. For example this allows to use mavens mechanism to check for updates of artifacts etc.
>>>
>>>
>>> If we speak about the converter, I guess the problem is that the converter runs too late. So maybe we should rather fix that?
>>>
>>>
>>> Regards
>>>
>>> Carsten
>>>
>>>
>>> Andreas Schaefer wrote
>>>> Hi
>>>> I found a solution by moving the code into the Mojos. The entire code is now here:
>>>> AbstractFeatureMojo.prepareProject()
>>>> And all Mojos interested can call them at the beginning of the execute() method.
>>>> This way my Mojo can work w/o any features present and w/o having issues during the different phases and goals.
>>>> Let me know if that is an acceptable solution.
>>>> Cheers - Andy Schaefer
>>>>> On Jul 16, 2019, at 7:50 AM, Andreas Schaefer <sc...@me.com.INVALID> wrote:
>>>>>
>>>>> Hi Simone
>>>>>
>>>>> I ran into a snafu with the Sling Feature Maven Plugin. This plugin is doing a blank check during the initialization phase which is causing headaches for the CP Converter goal.
>>>>>
>>>>> There are various issues but the most glaring is the fact that when I use placeholders in the FM id like "${project.groupId}” then it will fail to even clean the project with ‘mvn clean’ or when there is no feature at all.
>>>>>
>>>>> Can we either disable these tests or move them in the respective Mojos (phase) ?
>>>>>
>>>>> Cheers - Andy Schaefer
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Issue with Sling Feature Maven Plugin
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
for a normal feature build it is not required to have the
DependencyLifecycleParticipant, that's why your build works. For
additional functionality like using the mvn versions plugin etc t is
required.
And you're correct that any changes to features after the
DependencyLifecycleParticipant has run are not picked up.
One main one reason for the current way of doing things was actually the
mvn versions plugin. However, the feature plugin has now a similar
functionality.
The other reason is to use feature files to define dependencies for a
java project. So instead of listing all your dependencies in the pom,
you can simply reference a feature file and through the
DependencyLifecycleParticipant these are added as dependencies to your
project. This is very useful for bundle development as well as for
developing small applications where you take a base stack defined as a
feature and just add another bundle. I don't want to loose that
functionality.
We can solve the "mvn clean" problem by just moving the check to the
mojos. Each mojo calls already a central method that verifies if the
DependencyLifecycleParticipant has run and if we move the "no features
found" check there, that problem is solved.
I understand that the converter use case is a different one, in that
case you probably don't need a DependencyLifecycleParticipant at all.
I think we already have a configuration for whether the
DependencyLifecycleParticipant is adding the artifacts from feature
files to the maven project as dependencies. We could now defer all the
functionality of the DependencyLifecycleParticipant to the first mojo
if that flag is turned off.
WDYT?
Regards
Carsten
Andreas Schaefer wrote
> Hi Carsten
>
> There are a few issues with the current way the plugin works:
>
> 1. If for whatever reason the features folder does not contain any features then a ‘mvn clean’ will fail. That check should be moved to a Mojo that requires a feature file and not being done for all Mojos
> 2. The DependencyLifecycleParticipant has a state which means that changes to features after the loading of the project is not reflected in that state meaning that when I generate feature files (CQ / PM converter) then it will not be considered by the feature Mojos (I did not do a thorough investigation so I might be wrong)
> 3. All the tests and a full Sling / Peregrine CMS conversion (9 CP packages), built and launch worked just fine for me.
>
> I do not think the converter runs too late but it runs within the confines of the plugin meaning the DependencyLifecycleParticipant is fire ahead of the converters invocation. This is the firing sequence:
> - Convert Sling PM to FM
> - Convert Peregrine CMS CP to FM
> - Aggregate FMs
> - Attach FMs
> - Analyze FMs
>
> BTW there is also the issue that the ‘slingosgifeature’ packaging / our Plugin does not copy resource to the target. This is normally not a problem but I need to add a static FM (jcr packageinit) to the converted FMs to make Sling launch. I think it would be best to support copying resources and look for features in the /target folder instead.
>
> Cheers - Andy
>
>> On Jul 22, 2019, at 12:28 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>> Hi,
>>
>> moving this code out of the DependencyLifecycleParticipant will break some functionality. A DependencyLifecycleParticipant is run *before* any mojos and allwos to add dependencies to projects. We use this to add the artifacts from the feature files as dependencies to the maven project in order to use mavens dependency mechanism. For example this allows to use mavens mechanism to check for updates of artifacts etc.
>>
>>
>> If we speak about the converter, I guess the problem is that the converter runs too late. So maybe we should rather fix that?
>>
>>
>> Regards
>>
>> Carsten
>>
>>
>> Andreas Schaefer wrote
>>> Hi
>>> I found a solution by moving the code into the Mojos. The entire code is now here:
>>> AbstractFeatureMojo.prepareProject()
>>> And all Mojos interested can call them at the beginning of the execute() method.
>>> This way my Mojo can work w/o any features present and w/o having issues during the different phases and goals.
>>> Let me know if that is an acceptable solution.
>>> Cheers - Andy Schaefer
>>>> On Jul 16, 2019, at 7:50 AM, Andreas Schaefer <sc...@me.com.INVALID> wrote:
>>>>
>>>> Hi Simone
>>>>
>>>> I ran into a snafu with the Sling Feature Maven Plugin. This plugin is doing a blank check during the initialization phase which is causing headaches for the CP Converter goal.
>>>>
>>>> There are various issues but the most glaring is the fact that when I use placeholders in the FM id like "${project.groupId}” then it will fail to even clean the project with ‘mvn clean’ or when there is no feature at all.
>>>>
>>>> Can we either disable these tests or move them in the respective Mojos (phase) ?
>>>>
>>>> Cheers - Andy Schaefer
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Issue with Sling Feature Maven Plugin
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
Hi Carsten
There are a few issues with the current way the plugin works:
1. If for whatever reason the features folder does not contain any features then a ‘mvn clean’ will fail. That check should be moved to a Mojo that requires a feature file and not being done for all Mojos
2. The DependencyLifecycleParticipant has a state which means that changes to features after the loading of the project is not reflected in that state meaning that when I generate feature files (CQ / PM converter) then it will not be considered by the feature Mojos (I did not do a thorough investigation so I might be wrong)
3. All the tests and a full Sling / Peregrine CMS conversion (9 CP packages), built and launch worked just fine for me.
I do not think the converter runs too late but it runs within the confines of the plugin meaning the DependencyLifecycleParticipant is fire ahead of the converters invocation. This is the firing sequence:
- Convert Sling PM to FM
- Convert Peregrine CMS CP to FM
- Aggregate FMs
- Attach FMs
- Analyze FMs
BTW there is also the issue that the ‘slingosgifeature’ packaging / our Plugin does not copy resource to the target. This is normally not a problem but I need to add a static FM (jcr packageinit) to the converted FMs to make Sling launch. I think it would be best to support copying resources and look for features in the /target folder instead.
Cheers - Andy
> On Jul 22, 2019, at 12:28 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Hi,
>
> moving this code out of the DependencyLifecycleParticipant will break some functionality. A DependencyLifecycleParticipant is run *before* any mojos and allwos to add dependencies to projects. We use this to add the artifacts from the feature files as dependencies to the maven project in order to use mavens dependency mechanism. For example this allows to use mavens mechanism to check for updates of artifacts etc.
>
>
> If we speak about the converter, I guess the problem is that the converter runs too late. So maybe we should rather fix that?
>
>
> Regards
>
> Carsten
>
>
> Andreas Schaefer wrote
>> Hi
>> I found a solution by moving the code into the Mojos. The entire code is now here:
>> AbstractFeatureMojo.prepareProject()
>> And all Mojos interested can call them at the beginning of the execute() method.
>> This way my Mojo can work w/o any features present and w/o having issues during the different phases and goals.
>> Let me know if that is an acceptable solution.
>> Cheers - Andy Schaefer
>>> On Jul 16, 2019, at 7:50 AM, Andreas Schaefer <sc...@me.com.INVALID> wrote:
>>>
>>> Hi Simone
>>>
>>> I ran into a snafu with the Sling Feature Maven Plugin. This plugin is doing a blank check during the initialization phase which is causing headaches for the CP Converter goal.
>>>
>>> There are various issues but the most glaring is the fact that when I use placeholders in the FM id like "${project.groupId}” then it will fail to even clean the project with ‘mvn clean’ or when there is no feature at all.
>>>
>>> Can we either disable these tests or move them in the respective Mojos (phase) ?
>>>
>>> Cheers - Andy Schaefer
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Issue with Sling Feature Maven Plugin
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
moving this code out of the DependencyLifecycleParticipant will break
some functionality. A DependencyLifecycleParticipant is run *before* any
mojos and allwos to add dependencies to projects. We use this to add the
artifacts from the feature files as dependencies to the maven project in
order to use mavens dependency mechanism. For example this allows to use
mavens mechanism to check for updates of artifacts etc.
If we speak about the converter, I guess the problem is that the
converter runs too late. So maybe we should rather fix that?
Regards
Carsten
Andreas Schaefer wrote
> Hi
>
> I found a solution by moving the code into the Mojos. The entire code is now here:
>
> AbstractFeatureMojo.prepareProject()
>
> And all Mojos interested can call them at the beginning of the execute() method.
>
> This way my Mojo can work w/o any features present and w/o having issues during the different phases and goals.
>
> Let me know if that is an acceptable solution.
>
> Cheers - Andy Schaefer
>
>> On Jul 16, 2019, at 7:50 AM, Andreas Schaefer <sc...@me.com.INVALID> wrote:
>>
>> Hi Simone
>>
>> I ran into a snafu with the Sling Feature Maven Plugin. This plugin is doing a blank check during the initialization phase which is causing headaches for the CP Converter goal.
>>
>> There are various issues but the most glaring is the fact that when I use placeholders in the FM id like "${project.groupId}” then it will fail to even clean the project with ‘mvn clean’ or when there is no feature at all.
>>
>> Can we either disable these tests or move them in the respective Mojos (phase) ?
>>
>> Cheers - Andy Schaefer
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Issue with Sling Feature Maven Plugin
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
Hi
I found a solution by moving the code into the Mojos. The entire code is now here:
AbstractFeatureMojo.prepareProject()
And all Mojos interested can call them at the beginning of the execute() method.
This way my Mojo can work w/o any features present and w/o having issues during the different phases and goals.
Let me know if that is an acceptable solution.
Cheers - Andy Schaefer
> On Jul 16, 2019, at 7:50 AM, Andreas Schaefer <sc...@me.com.INVALID> wrote:
>
> Hi Simone
>
> I ran into a snafu with the Sling Feature Maven Plugin. This plugin is doing a blank check during the initialization phase which is causing headaches for the CP Converter goal.
>
> There are various issues but the most glaring is the fact that when I use placeholders in the FM id like "${project.groupId}” then it will fail to even clean the project with ‘mvn clean’ or when there is no feature at all.
>
> Can we either disable these tests or move them in the respective Mojos (phase) ?
>
> Cheers - Andy Schaefer