2014-02-27 17:26 GMT+01:00 Martin Hoeller <mar...@xss.co.at>: > On 27 Feb 2014, Antonio Petrelli wrote: > > > 2014-02-27 17:14 GMT+01:00 Martin Hoeller <mar...@xss.co.at>: > > > > > On 27 Feb 2014, Antonio Petrelli wrote: > > > > > > > 2014-02-27 17:05 GMT+01:00 Martin Hoeller <mar...@xss.co.at>: > > > > > > > > > I have another concrete example with a single WAR where OmniFaces > is a > > > > > dependency by the WAR and by some EJB JAR, both contained in the > EAR. > > > The > > > > > OmniFaces JAR goes in the EARs lib folder and thus OmniFaces ist > not > > > > > fully usable without workarounds. See also my question on > > > StackOverflow: > > > > > > > > > > > > > > http://stackoverflow.com/questions/22046464/how-to-correctly-use-omnifaces-in-an-ear > > > > > > > > > > > > > > Hi, > > > > the real question is: why do you want to use a JSF-specific library > > > inside > > > > an EJB? > > > > > > OmniFaces is a JSF library but not UI component focused like RichFaces. > > > It hast some really nice classes like BeanManager that could be useful > > > outside a JSF application. > > > > > > > If it's really BeanManager or few classes that you need, I suggest to use > > the Shade plugin, to create an artifact with one (or few) classes, > possibly > > moved to another package: > > > http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html > > I was already thinking of this :) > > However, I felt like there would be something wrong with this approach, as > I usually just need to declare a dependency when I want to use a library. > Not repackage it and include the classes twice in the EAR. >
In fact what I proposed is a workaround. Probably you could collaborate with OmniFaces to split the library into a "common" jar and a JSF-specific jar, so that the common can be safely put in the EAR. Antonio
