But maybe creating a section in the Convention Plugin Documentation how to enable/fix problems with Lambda Expression is enough?
Creating a plugin which fix a JDK related problem of another plugin and mark it as deprecated at the same time when introducing it feels wrong to me. Best Regards Johannes ################################################# web: http://www.jgeppert.com twitter: http://twitter.com/jogep 2015-01-02 11:18 GMT+01:00 Lukasz Lenart <lukaszlen...@apache.org>: > 2015-01-02 11:04 GMT+01:00 Johannes Geppert <jo...@apache.org>: > > Hi, > > > > thanks Lukasz for preparing this new release. One question to the new > Java8 > > Plugin. > > Is this a real use case for creating a official plugin we want to support > > in future? > > > > I mean it is a fix for the convention plugin in a specific JDK version. > > Developers are maybe are confused when later Java9 or Java1X is released. > > > > Is it not better to move this logic directly to the convention plugin and > > name it like LambdaExpressionClassFinder or something similar? > > The problem is with dependencies - you cannot have two the same > dependencies but with different versions, it won't compile :( I > started with this approach but because of classpath conflicts I had to > move this into the plugin. Compare the dependencies: > > XWork > https://github.com/apache/struts/blob/develop/xwork-core/pom.xml#L128-L135 > > Plugin > > https://github.com/apache/struts/blob/develop/plugins/java8-support/pom.xml#L33-L46 > > Both ASM dependencies defined in parent > https://github.com/apache/struts/blob/develop/pom.xml#L590-L609 > > It wouldn't have been a problem if ASM had used different package > names, the same as we use for S1 and S2 - now you end up with class > name clash :| > > I'm not sure if this is the right approach - but it was the best > possible idea and we can throw it away in S2.5 or just drop the plugin > and tell people how to add support for Java8 (you must implement > interface and that's all) > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
