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.
- Jen On Thu, Dec 11, 2008 at 8:02 PM, Eric Dalquist <[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
