[shrinkwrap-issues] [JBoss JIRA] Updated: (SHRINKWRAP-318) Support adding web and WEB-INF resources with relative path of source

[ https://issues.jboss.org/browse/SHRINKWRAP-318?page=com.atlassian.jira.pl... ] Ian Brandt updated SHRINKWRAP-318: ---------------------------------- Description: I've noticed with WebArchives that {{addAsResource(String)}} preserves the relative path of the source. E.g. {{addAsResource("some/file")}} is added to the archive as "WEB-INF/classes/some/file". On the other hand {{addAsWebResource(String)}} and {{addAsWebInfResource(String)}} do not preserve the relative source path. I have the webapp resources for my app under test copied to the test classpath relative from the web root. Any time I have a WEB-INF resource under one or more subfolders I find that I have to do {{addAsWebInfResource("WEB-INF/jsp/path/to/some.jsp", "jsp/path/to/some.jsp")}} or {{addAsWebResource("WEB-INF/jsp/path/to/some.jsp", "WEB-INF/jsp/path/to/some.jsp")}}. It would be preferable to just be able to say {{addAsWebResource("WEB-INF/jsp/path/to/some.jsp")}}, but when I do that the JSP is added to the archive as "some.jsp" at the web root. I believe the API would be more intuitive if the {{addAs{_}X{_}(String{_}\[, ...\]{_})}} methods were consistent with regards to preserving the relative path of the source resource. It would also be useful to have the option of preserving the source resource's path, or not. Perhaps {{addAsResource(String)}} and {{addAsRelativeResource(String)}}, etc.? Note however that I haven't considered the other {{add}} overloads ({{Asset}}, {{File}}, etc.) as I haven't used them yet. was: I've noticed with WebArchives that {{addAsResource(String)}} preserves the relative path of the source. E.g. {{addAsResource("some/file")}} is added to the archive as "WEB-INF/classes/some/file". On the other hand {{addAsWebResource(String)}} and {{addAsWebInfResource(String)}} do not preserve the relative source path. I have the webapp resources for my app under test copied to the test classpath relative from the web root. Any time I have a WEB-INF resource under one or more subfolders I find that I have to do {{addAsWebInfResource("WEB-INF/jsp/path/to/some.jsp", "jsp/path/to/some.jsp")}} or {{addAsWebInfResource("WEB-INF/jsp/path/to/some.jsp", "WEB-INF/jsp/path/to/some.jsp")}}. It would be preferable to just be able to say {{addAsWebResource("WEB-INF/jsp/path/to/some.jsp")}}, but when I do that the JSP is added to the archive as "some.jsp" at the web root. I believe the API would be more intuitive if the {{addAs{_}X{_}(String{_}\[, ...\]{_})}} methods were consistent with regards to preserving the relative path of the source resource. It would also be useful to have the option of preserving the source resource's path, or not. Perhaps {{addAsResource(String)}} and {{addAsRelativeResource(String)}}, etc.? Note however that I haven't considered the other {{add}} overloads ({{Asset}}, {{File}}, etc.) as I haven't used them yet. I can certainly give it a shot. Any guidance or preferences you'd like to offer before I begin? My use case is thus: * I'm using Shrinkwrap with Arquillian and Maven. * As mentioned I have my WAR resources available from the root of my test classpath: {code:xml} <testResources> <testResource> <directory>src/test/resources</directory> </testResource> <testResource> <directory>src/main/webapp</directory> </testResource> </testResources> {code} * I have more resources under subfolders of the web root and WEB-INF than not. ** As such having {{addAsWebResource(String)}} preserve the source resource's relative path would be the most convenient option. * I wouldn't foresee using a {{addAsWebInfResource(String)}} that preserved relative path because I'd end up with "WEB-INF/WEB-INF/some/file". ** So should it be changed for consistencies sake, or _if it ain't broke don't fix it_? I'd greatly appreciate hearing other's use cases, and the thoughts of those with more Shrinkwrap experience than I. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira