Resource files on classpath
13 views
Skip to first unread message
Martin Harris
Apr 30, 2014, 8:20:15 AM4/30/14
to brookl...@googlegroups.com
Hi Folks,
--
For the brooklyn usergrid project[1]. I'd like to create a distribution (.tar.gz) that include some files that are user-editable, and on brooklyn's classpath.
I've created a folder src/main/resources/resources and added this to the assembly.xml with the outputDirectory as 'resources', and the files are now extracted to a resources directory when you unzip the tarball
The issue is that I'd also like the files available for testing, both for testng tests and also just running the app from the IDE. I've added the resources/resources directory to the build section of the pom, but that means that the files are also included in the .jar. Is there a good pattern for ensuring that the editable files (i.e. the ones in the resources folder after unzipping) are at the start of the classpath?
Hope this makes sense!
Cheers
Alex Heneveld
Apr 30, 2014, 8:42:49 AM4/30/14
to brookl...@googlegroups.com
Hi Martin-
ISTR it is difficult if you want resource files both to:
(1) exist in a *directory* (not a jar) in the tgz (which as you and Andrea note is not hard setting up the assembly and the classpath appropriate)
(2) be available on the classpath of the IDE (or other maven-generated classpath)
The reason is that maven normally wants to compute a classpath, then build the JAR from that, also used for (2). The file copy (assembly) subsystem for (1) is totally different to the java (build) subsystem (2) so it will take some careful config to get the two to play nice.
That said there ought to be a nice solution someone has figured out. Worth a quick search and let us know if you find it. (I could use this in places!) Some more of my thoughts below FWIW.
Copying from src/main/resources is probably okay, just means files occur twice. Copying from src/test/resources might be better.
If you put it in a folder eg "src/main/resources/resources/resourcesA" you'll be referencing it as classpath://resourcesA/some_file, and you'll have to copy resourcesA to the directory which is on the classpath (e.g. "conf" we use a lot, so you'd also have "conf/resourcesA" -- so it probably makes sense either to give it a name which makes sense inside a conf dir, e.g. "blueprints", or else to explicitly list the files to copy.
Finally note a problem with this double-copying approach, esp if it is from src/main/resources, is that if the user unpacks the tarball then deletes something, it will still be picked up from the JAR.
Best
Alex
ISTR it is difficult if you want resource files both to:
(1) exist in a *directory* (not a jar) in the tgz (which as you and Andrea note is not hard setting up the assembly and the classpath appropriate)
(2) be available on the classpath of the IDE (or other maven-generated classpath)
The reason is that maven normally wants to compute a classpath, then build the JAR from that, also used for (2). The file copy (assembly) subsystem for (1) is totally different to the java (build) subsystem (2) so it will take some careful config to get the two to play nice.
That said there ought to be a nice solution someone has figured out. Worth a quick search and let us know if you find it. (I could use this in places!) Some more of my thoughts below FWIW.
Copying from src/main/resources is probably okay, just means files occur twice. Copying from src/test/resources might be better.
If you put it in a folder eg "src/main/resources/resources/resourcesA" you'll be referencing it as classpath://resourcesA/some_file, and you'll have to copy resourcesA to the directory which is on the classpath (e.g. "conf" we use a lot, so you'd also have "conf/resourcesA" -- so it probably makes sense either to give it a name which makes sense inside a conf dir, e.g. "blueprints", or else to explicitly list the files to copy.
Finally note a problem with this double-copying approach, esp if it is from src/main/resources, is that if the user unpacks the tarball then deletes something, it will still be picked up from the JAR.
Best
Alex
--
You received this message because you are subscribed to the Google Groups "brooklyn-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brooklyn-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages