You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Lukasz Lenart <lu...@apache.org> on 2019/04/17 07:49:38 UTC

Re: struts2-portlet-plugin dependency issue

So it would be good to provide our own stubbing classes for
Request/Response? I think we can copy/paste Spring once as they based
on AFL.

niedz., 25 lis 2018 o 17:47 Yasser Zamani <ya...@apache.org> napisał(a):
>
> I found Spring officially says:
>
> "The Spring Framework no longer supports: Portlet, Velocity,
> JasperReports, XMLBeans, JDO, Guava (replaced by the Caffeine support).
> If those are critical to your project, you should stay on Spring
> Framework 4.3.x (supported until 2020). Alternatively, you may create
> custom adapter classes in your own project (possibly derived from Spring
> Framework 4.x)." [1]
>
> So we at Struts may also deprecate Portlet or we may create custom
> adapter classes (possibly derived from Spring Framework 4.x) in junit or
> portlet plugin.
>
> Could you please register an issue including your test code and the
> class not found exception's full stack trace at [2]?
>
> Thanks for your report!
>
> [1]
> https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-5.x
> [2] https://issues.apache.org/jira/projects/WW/summary
>
> On 11/24/2018 1:40 PM, John Bush wrote:
> > The missing package org.springframework.mock.web.portlet was in
> > spring-test. If you use the appropriate spring-test 5 then
> > struts2-junit-plugin will fail with class not found. If you test using
> > spring-test 4 then struts2-junit-plugin will run but all the tests for
> > anything using Spring 5 would be at risk or at least questionable. As
> > Spring moves on 5+ the risk goes up and the unit testing confidence goes
> > down. For now I'll have to stick with Spring 4 until I find a longer
> > term solution.
> > Thanks for the suggestion - John B
> >
> >
> > On 11/23/2018 6:27 AM, Yasser Zamani wrote:
> >> Hi John,
> >>
> >> I think it's possible to keep spring updated to 5 and in same time, to
> >> have needed old dependencies in scope `test` to save unit tests, e.g:
> >>
> >>          <!-- Mocks for unit testing (by Spring) -->
> >>          <dependency>
> >>              <groupId>org.springframework</groupId>
> >>              <artifactId>spring-test</artifactId>
> >>              <scope>test</scope>
> >>          </dependency>
> >>          <dependency>
> >>              <groupId>org.springframework</groupId>
> >>              <artifactId>spring-webmvc-portlet</artifactId>
> >>              <scope>test</scope>
> >>          </dependency>
> >>
> >> Regards.
> >>
> >> On 11/22/2018 8:45 PM, John Bush wrote:
> >>> I'm by no means a struts inner-workings expert so the following
> >>> statements may totally be wrong. I'm not sure a portlet guru is needed
> >>> since the problem isn't in struts2-portlet-plugin. It still provides the
> >>> portlet request/response life-cycle emulation for the application
> >>> appropriately with no reliance on Spring Portlet MVC. That said I am
> >>> also not a mocking guru either. I'm not sure how involved it would be to
> >>> recreate the mocked classes required that
> >>> org.springframework.mock.web.portlet provided.
> >>> What's the process to create a bug? I'd like the problem documented if
> >>> it's supported, there might be others using it. If I have to solve it
> >>> I'll do my best to do it in a way it can be contributed back.
> >>> Just to make you aware there is a new portlet spec pretty much final -
> >>> JSR 362: Portlet Specification 3.0. You might need a caveat added to
> >>> struts2-portlet-plugin stating the specs supported.
> >>> Thanks - John B
> >>>
> >>> On 11/15/2018 1:16 AM, Lukasz Lenart wrote:
> >>>> śr., 14 lis 2018 o 08:48 John Bush<jt...@mchsi.com>  napisał(a):
> >>>>> WW-3826 solved a problem running JUnit tests on portlet actions via
> >>>>> struts2-portlet-plugin and struts2-junit-plugin. The solution used
> >>>>> Spring's org.springframework.mock.web.portlet package in the
> >>>>> spring-test
> >>>>> framework. Spring Portlet MVC is no longer supported (SPR-14129)
> >>>>> and the
> >>>>> package has been removed starting with Spring 5. I'm not able to
> >>>>> upgrade
> >>>>> to Spring 5 without loosing my unit testing since having both versions
> >>>>> of spring-test in my classpath creates many other issues. Any short
> >>>>> term
> >>>>> suggestion would be appreciated.
> >>>>> Thanks John B
> >>>> I think no one can help you, we really miss a portlet guru on this
> >>>> list :( I was trying few time to upgrade tests and some portlet
> >>>> dependencies and I failed :\
> >>>>
> >>>>
> >>>> Kind regards
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: struts2-portlet-plugin dependency issue

Posted by Lukasz Lenart <lu...@apache.org>.
czw., 18 kwi 2019 o 08:10 John Bush <jt...@mchsi.com> napisał(a):
>
> I think that makes sense. Anyone using the portlet-plugin in an
> enterprise setting will want to maintain their testing. I also wondered
> if Spring or the license would allow repackaging the code, especially
> since they no longer support it. Sorry I didn't open an issue - missed
> the request. What would you need a zip of a trivial web app?

I think we can copy/paste most of the code, Apache 2.0 license allows
to do it. And the sample app would be great, I always have problems
with setting up a Portlet base app :)


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: struts2-portlet-plugin dependency issue

Posted by John Bush <jt...@mchsi.com>.
I think that makes sense. Anyone using the portlet-plugin in an 
enterprise setting will want to maintain their testing. I also wondered 
if Spring or the license would allow repackaging the code, especially 
since they no longer support it. Sorry I didn't open an issue - missed 
the request. What would you need a zip of a trivial web app?

John B

On 4/17/2019 2:49 AM, Lukasz Lenart wrote:
> So it would be good to provide our own stubbing classes for
> Request/Response? I think we can copy/paste Spring once as they based
> on AFL.
>
> niedz., 25 lis 2018 o 17:47 Yasser Zamani <ya...@apache.org> napisał(a):
>> I found Spring officially says:
>>
>> "The Spring Framework no longer supports: Portlet, Velocity,
>> JasperReports, XMLBeans, JDO, Guava (replaced by the Caffeine support).
>> If those are critical to your project, you should stay on Spring
>> Framework 4.3.x (supported until 2020). Alternatively, you may create
>> custom adapter classes in your own project (possibly derived from Spring
>> Framework 4.x)." [1]
>>
>> So we at Struts may also deprecate Portlet or we may create custom
>> adapter classes (possibly derived from Spring Framework 4.x) in junit or
>> portlet plugin.
>>
>> Could you please register an issue including your test code and the
>> class not found exception's full stack trace at [2]?
>>
>> Thanks for your report!
>>
>> [1]
>> https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-5.x
>> [2] https://issues.apache.org/jira/projects/WW/summary
>>
>> On 11/24/2018 1:40 PM, John Bush wrote:
>>> The missing package org.springframework.mock.web.portlet was in
>>> spring-test. If you use the appropriate spring-test 5 then
>>> struts2-junit-plugin will fail with class not found. If you test using
>>> spring-test 4 then struts2-junit-plugin will run but all the tests for
>>> anything using Spring 5 would be at risk or at least questionable. As
>>> Spring moves on 5+ the risk goes up and the unit testing confidence goes
>>> down. For now I'll have to stick with Spring 4 until I find a longer
>>> term solution.
>>> Thanks for the suggestion - John B
>>>
>>>
>>> On 11/23/2018 6:27 AM, Yasser Zamani wrote:
>>>> Hi John,
>>>>
>>>> I think it's possible to keep spring updated to 5 and in same time, to
>>>> have needed old dependencies in scope `test` to save unit tests, e.g:
>>>>
>>>>           <!-- Mocks for unit testing (by Spring) -->
>>>>           <dependency>
>>>>               <groupId>org.springframework</groupId>
>>>>               <artifactId>spring-test</artifactId>
>>>>               <scope>test</scope>
>>>>           </dependency>
>>>>           <dependency>
>>>>               <groupId>org.springframework</groupId>
>>>>               <artifactId>spring-webmvc-portlet</artifactId>
>>>>               <scope>test</scope>
>>>>           </dependency>
>>>>
>>>> Regards.
>>>>
>>>> On 11/22/2018 8:45 PM, John Bush wrote:
>>>>> I'm by no means a struts inner-workings expert so the following
>>>>> statements may totally be wrong. I'm not sure a portlet guru is needed
>>>>> since the problem isn't in struts2-portlet-plugin. It still provides the
>>>>> portlet request/response life-cycle emulation for the application
>>>>> appropriately with no reliance on Spring Portlet MVC. That said I am
>>>>> also not a mocking guru either. I'm not sure how involved it would be to
>>>>> recreate the mocked classes required that
>>>>> org.springframework.mock.web.portlet provided.
>>>>> What's the process to create a bug? I'd like the problem documented if
>>>>> it's supported, there might be others using it. If I have to solve it
>>>>> I'll do my best to do it in a way it can be contributed back.
>>>>> Just to make you aware there is a new portlet spec pretty much final -
>>>>> JSR 362: Portlet Specification 3.0. You might need a caveat added to
>>>>> struts2-portlet-plugin stating the specs supported.
>>>>> Thanks - John B
>>>>>
>>>>> On 11/15/2018 1:16 AM, Lukasz Lenart wrote:
>>>>>> śr., 14 lis 2018 o 08:48 John Bush<jt...@mchsi.com>  napisał(a):
>>>>>>> WW-3826 solved a problem running JUnit tests on portlet actions via
>>>>>>> struts2-portlet-plugin and struts2-junit-plugin. The solution used
>>>>>>> Spring's org.springframework.mock.web.portlet package in the
>>>>>>> spring-test
>>>>>>> framework. Spring Portlet MVC is no longer supported (SPR-14129)
>>>>>>> and the
>>>>>>> package has been removed starting with Spring 5. I'm not able to
>>>>>>> upgrade
>>>>>>> to Spring 5 without loosing my unit testing since having both versions
>>>>>>> of spring-test in my classpath creates many other issues. Any short
>>>>>>> term
>>>>>>> suggestion would be appreciated.
>>>>>>> Thanks John B
>>>>>> I think no one can help you, we really miss a portlet guru on this
>>>>>> list :( I was trying few time to upgrade tests and some portlet
>>>>>> dependencies and I failed :\
>>>>>>
>>>>>>
>>>>>> Kind regards
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org