Re: [xwiki-devs] [Proposal] Changing the location of XED files
Sorry if my question looks late or stupid, but what is the benefit of those xed files, how are they added to the lib folder currently ? That might explains why these meta information are not integrated to the jar file, what I would have expected more than B. Thanks, -- Denis Gervalle SOFTEC sa - CEO On Fri, Jan 27, 2017 at 3:07 PM, Denis Gervalle <[email protected]> wrote: Sorry if my question looks late or stupid, but what is the benefit of those xed files, how are they added to the lib folder currently ? That might explains why these meta information are not integrated to the jar file, what I would have expected more than B. Thanks, -- Denis Gervalle SOFTEC sa - CEO On Wed, Jan 25, 2017 at 9:31 PM, Marius Dumitru Florea <[email protected]> wrote: I don't have a problem with keeping the XED files in WEB-INF/lib if the spec doesn't forbid it, especially if it simplifies the implementation. Thanks, Marius On Tue, Jan 24, 2017 at 2:26 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
In XWiki 9.0RC1 we’re putting XED files in WEB-INF/lib next to the JAR to which they correspond.
I have 2 issues with this: * We’re not really supposed to use WEB-INF/lib for that. WEB-INF/lib is meant for JAR files that are to be made available to the classloader. It’s even possible that some servlet container would emit warnings about this. * This is a WTF for admins when they discover this. The WAR has a spec and it’s standardised. Thus the WTF when you see this since you’re not used to seeing this anywhere else.
I’m thus proposing to move the XED files to a META-INF/xwiki/ directory inside the WAR instead since META-INF is meant to contain metadata information and is thus meant exactly for this.
WDTY?
Thanks -Vincent
They are here to associate all the JARs of the WAR (in this case but it's not WAR specific) to a complete descriptor to workaround the missing, incomplete or wrong pom.xml we can sometimes find. It gives use reliable information about all the core extensions (at least those coming from the WAR). It's not only for XWiki jars but all jars of the WAR so we can't just integrate those descriptors in the jars that we don't control for most of them. On Fri, Jan 27, 2017 at 3:08 PM, Denis Gervalle <[email protected]> wrote:
Sorry if my question looks late or stupid, but what is the benefit of those xed files, how are they added to the lib folder currently ? That might explains why these meta information are not integrated to the jar file, what I would have expected more than B. Thanks, -- Denis Gervalle SOFTEC sa - CEO On Fri, Jan 27, 2017 at 3:07 PM, Denis Gervalle <[email protected]> wrote: Sorry if my question looks late or stupid, but what is the benefit of those xed files, how are they added to the lib folder currently ? That might explains why these meta information are not integrated to the jar file, what I would have expected more than B. Thanks, -- Denis Gervalle SOFTEC sa - CEO On Wed, Jan 25, 2017 at 9:31 PM, Marius Dumitru Florea <[email protected]> wrote: I don't have a problem with keeping the XED files in WEB-INF/lib if the spec doesn't forbid it, especially if it simplifies the implementation.
Thanks, Marius
On Tue, Jan 24, 2017 at 2:26 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
In XWiki 9.0RC1 we’re putting XED files in WEB-INF/lib next to the JAR to which they correspond.
I have 2 issues with this: * We’re not really supposed to use WEB-INF/lib for that. WEB-INF/lib is meant for JAR files that are to be made available to the classloader. It’s even possible that some servlet container would emit warnings about this. * This is a WTF for admins when they discover this. The WAR has a spec and it’s standardised. Thus the WTF when you see this since you’re not used to seeing this anywhere else.
I’m thus proposing to move the XED files to a META-INF/xwiki/ directory inside the WAR instead since META-INF is meant to contain metadata information and is thus meant exactly for this.
WDTY?
Thanks -Vincent
-- Thomas Mortagne
participants (2)
-
Denis Gervalle -
Thomas Mortagne