Re: [uportal-dev] Property files in up3
I gave this a go in the trunk and checked in the necessary changes to the pom. I haven't done a lot of testing with it but it looks like it should work and results in the source and config being deployed unpacked in the webapp. The change was made in revision 44060 and it should be applicable to the 3.0.x releases easily for those interested. -Eric Eric Dalquist wrote: Files are in a jar in up3 because of how the maven project is organized. To be able to have the command line tools (ant tasks) work the uPortal source and config needed to be bundled into a stand-along jar project since a WAR isn't really useful on a classpath. After chating with Lennard and your email I found a few options linked to online the most interesting being this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg71453.html It is a bit of a maven side hack but it should work for us. The idea being is you have the Maven build extract the uP3 JAR when bundling it into the WAR. If you happen to have a few cycles to try getting something like that working it would be great. -Eric Cris J Holdorph wrote: Two of us (myself and Lennard Fuller) here at Unicon have both separately found out the hard way, that property files in up3 are packaged up in a jar file. I was wondering what the theory for that is. As both a developer and system deployer, I find this needlessly painful. It's a lot easier if the file is unarchived and can be modified directly, without having to unjar the files and remove the jar file first. Lennard, actually discovered that the jar file access was taking a fair amount of CPU time as well. Is there some benefit to the property files being in a jar file, that I'm overlooking. All I can see, at the moment are several downsides, and would like to know if we can switch back to non-jarred propety files. Also, I think it would be useful, if we could look into a facility similar to Sakai's sakai.properties file, where you can potentially override properties without having to modify the original file at all. Anyone who has had to maintain propeties on a per machine basis will know the value of having a 'machine specific' properties file, that overrides the defaults for the 'generic system'. Cris J H smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] Property files in up3
Eric discovered the related resource loader performance issue... he was running the profiler at the time:) The pearson system administrators both noticed and commented on the lack of easily accessible properties files and voiced their concerns about the move. I pointed out that they were easily accessible in the src, but they, in turn pointed out that waiting several minutes on a build for a property change was painful. Personally, I would prefer to see the property files readily available. If this is not to be a standard deployment, it would be nice if a production target were created which would make the properties accessible. -Lennard - Original Message - From: "Cris J Holdorph" <[EMAIL PROTECTED]> To: uportal-dev@lists.ja-sig.org Sent: Tuesday, July 29, 2008 5:01:28 PM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] Property files in up3 Two of us (myself and Lennard Fuller) here at Unicon have both separately found out the hard way, that property files in up3 are packaged up in a jar file. I was wondering what the theory for that is. As both a developer and system deployer, I find this needlessly painful. It's a lot easier if the file is unarchived and can be modified directly, without having to unjar the files and remove the jar file first. Lennard, actually discovered that the jar file access was taking a fair amount of CPU time as well. Is there some benefit to the property files being in a jar file, that I'm overlooking. All I can see, at the moment are several downsides, and would like to know if we can switch back to non-jarred propety files. Also, I think it would be useful, if we could look into a facility similar to Sakai's sakai.properties file, where you can potentially override properties without having to modify the original file at all. Anyone who has had to maintain propeties on a per machine basis will know the value of having a 'machine specific' properties file, that overrides the defaults for the 'generic system'. Cris J H -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Property files in up3
Files are in a jar in up3 because of how the maven project is organized. To be able to have the command line tools (ant tasks) work the uPortal source and config needed to be bundled into a stand-along jar project since a WAR isn't really useful on a classpath. After chating with Lennard and your email I found a few options linked to online the most interesting being this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg71453.html It is a bit of a maven side hack but it should work for us. The idea being is you have the Maven build extract the uP3 JAR when bundling it into the WAR. If you happen to have a few cycles to try getting something like that working it would be great. -Eric Cris J Holdorph wrote: Two of us (myself and Lennard Fuller) here at Unicon have both separately found out the hard way, that property files in up3 are packaged up in a jar file. I was wondering what the theory for that is. As both a developer and system deployer, I find this needlessly painful. It's a lot easier if the file is unarchived and can be modified directly, without having to unjar the files and remove the jar file first. Lennard, actually discovered that the jar file access was taking a fair amount of CPU time as well. Is there some benefit to the property files being in a jar file, that I'm overlooking. All I can see, at the moment are several downsides, and would like to know if we can switch back to non-jarred propety files. Also, I think it would be useful, if we could look into a facility similar to Sakai's sakai.properties file, where you can potentially override properties without having to modify the original file at all. Anyone who has had to maintain propeties on a per machine basis will know the value of having a 'machine specific' properties file, that overrides the defaults for the 'generic system'. Cris J H smime.p7s Description: S/MIME Cryptographic Signature
[uportal-dev] Property files in up3
Two of us (myself and Lennard Fuller) here at Unicon have both separately found out the hard way, that property files in up3 are packaged up in a jar file. I was wondering what the theory for that is. As both a developer and system deployer, I find this needlessly painful. It's a lot easier if the file is unarchived and can be modified directly, without having to unjar the files and remove the jar file first. Lennard, actually discovered that the jar file access was taking a fair amount of CPU time as well. Is there some benefit to the property files being in a jar file, that I'm overlooking. All I can see, at the moment are several downsides, and would like to know if we can switch back to non-jarred propety files. Also, I think it would be useful, if we could look into a facility similar to Sakai's sakai.properties file, where you can potentially override properties without having to modify the original file at all. Anyone who has had to maintain propeties on a per machine basis will know the value of having a 'machine specific' properties file, that overrides the defaults for the 'generic system'. Cris J H -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
