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
