-Eric
Jen Bourey wrote:
In addition to removeExisting=false, the build.properties.sample contains a default setting of "cleanShared=false." Unless you either change this setting or explicitly run "ant clean-shared," it's possible to also get multiple stranded jar versions in your tomcat shared/lib space.- JenOn Thu, Dec 11, 2008 at 8:02 PM, Eric Dalquist <[email protected] <mailto:[email protected]>> wrote:There was no uPortal.jar, just classes in the web-inf/classes directory. So you couldn't duplicate the whole tree but you still could get orphaned files if a file was renamed, moved or deleted. Also per a previous thread you were on we are changing this behavior for 3.1 such that the uPortal JAR will be extracted in WAR: http://www.ja-sig.org/issues/browse/UP-2131 I do realize this isn't exactly like uP2 but it is fairly similar. You could always get into trouble if you don't run clean between big updates. I would honestly like initportal to call clean but it did not to be more consistent with 2.x. Another flag that I think we should switch (maybe for 3.1?) is removeExisting=false in build.properties. If you set that to true the deployer will remove any existing webapp before redeploying it, this counts for both uPortal and portlets deployed with the EAR or with deployPortletApp. -Eric Cris J Holdorph wrote: Hmm... I wonder what was causing me to think it did clean out the stuff. I guess maybe because the default lifecycle is just so dang long, it seems to encompass the whole world. In any case, then, rethinking this a bit more, the problem is more related to the jar file having a version number in it, where in 2.x it would not have. So in uPortal 2.x if I ran 'ant initportal' at one point in time, I would get a 'uportal.jar'. And if there were any .class file ADDITIONS or CHANGES they would get populated, but at the end of the build there would only be one uPortal.jar file. In this maven+ant build system we have not a 'uportal.jar' but a 'uPortal-impl-3.0.3-SNAPSHOT.jar' file. So, if the version in the maven file changes between doing a build, you'll end up duplicate jar files in your target directory. In uPortal 2.x, you'd only have one. The behavior between uPortal 2.x and 3.x has clearly changed. The current behavior might be viewed as the closest we can get, but it's certainly not the same. ---- Cris J H Eric Dalquist wrote: Actually Maven does not run clean unless you explicitly request it, just running compile, package or install on a project with old files in the target directory will result in those old files being included in your final artifact. -Eric Cris J Holdorph wrote: Consistent, but only to a certain extent. We did not have the same maven-multi-project+ant situation in uPortal 2.x. The problem is not the same. Specifically, I guess I just really don't like the Ant calling maven to do things paradigm. In Maven, there are very clear semantics with running a certain lifecycle step. All the preceding steps are done. So if you're going to compile the code, it *WILL* run clean first. "ant initportal" does "build code", which in maven terms means it should probably clean as well. Anyway, I understand, and I will try to remember to do so in the future, but since we've started using maven in 3.x, I don't believe we're stuck with trying to remain consistent with 2.x conventions. ---- Cris J H Eric Dalquist wrote: Nope, you need to run ant 'ant clean' to clean things out. or 'ant clean initportal' this is consistent with initportal's behavior from 2.x -Eric Cris J Holdorph wrote: Ok, I was a little misleading when I said "relatively fresh checkout". It was an older checkout, but with a brand new 'svn update' and a run of 'svn status' to make sure I had not modified anything. Anyway, the problemm turns out that 'ant initportal' does NOT clean out things. And if you have a checkout that has existed across a release. then you can end up with multiple impl jars in your distribution. $ ls webapps/uPortal/WEB-INF/lib/uPortal* uportal-impl-3.0.1-SNAPSHOT.jar uportal-impl-3.0.3-SNAPSHOT.jar Completely removing tomcat, then redoing the build by first doing an "ant clean" then an "ant initportal", fixed my problem. While the above is certainly not a common case, what do people think about having "ant clean" be a dependency for "ant initportal" ? ---- Cris J H Cris J Holdorph wrote: Before I start chasing this down, I thought I would ask here to see if this is already a known bug or if anyone else is seeing the same thing. I tried a relatively fresh checkout/build/deploy of uPortal 3.0.x from the branch. https://www.ja-sig.org/svn/uPortal/branches/rel-3-0-patches My only changes are to rdbm.properties, dbloader.xml, personDirectoryContext.xml and pom.xml in order to use MySQL. I started with a fresh database and fresh tomcat. 'ant initportal' from the root complete successfully, tomcat starts successfully, however the uPortal web application does not. The following error (minus a several of the lest interesting lines of stack) occurs. ERROR [main] provider.ImpersonationFilter.[] Dec/11 16:35:17 - Falied to read security.properties java.lang.NullPointerException at org.jasig.portal.security.provider.ImpersonationFilter.init(ImpersonationFilter.java:119) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221) ... snip snip many uninteresting lines of the stack ... ERROR [main] [localhost].[/uPortal].[] Dec/11 16:35:17 - Exception starting filter Impersonation Filter javax.servlet.ServletException: Falied to read security.properties at org.jasig.portal.security.provider.ImpersonationFilter.init(ImpersonationFilter.java:153) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221) ... snip snip many uninteresting lines of the stack ... Does anyone else see this? Is this a partial commit from someone, or am I really missing a new deployment step that I am unaware of? ---- Cris J H -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
