Thanks for the details Craig. This is great investigation.
Craig Doremus wrote:
Thank you, Elliot. I did what you suggested, but the build did not work.
I should clarify, but what I mean by 'work' is that the build would
produce a bundled archive that worked when it is deployed. The build
built the archive, but tomcat would not properly deploy pluto when the
archive was unzipped and tomcat started.
I did a little snooping around and discovered that
pluto-portal-driver-config.xml got deployed to the root pluto webapp
directory. When I moved the file to WEB-INF, the pluto deployment
worked. I did a little more snooping and came across a note in the
pom.xml of pluto-portal that you needed version 2.0.2 of the
maven-war-plugin. Low and behold, I have version 2.0.1 of that plugin in
my local repository.
Sometimes it is very hard to 'feel the love' for maven;). Anyway, when I
deleted the maven-war-plugin from my repository and ran mvn -P assembly
install, everything worked including the deployment of pluto, when the
bundled archive was deployed and tomcat started. I threw up my hands and
did my end-zone dance. Whoohoo!
Cool. So, if we add a plugin configuration in the pom requiring 2.0.2
we should be fine.
Still, everything was not hunky dory up here in snowy Maine. What
happens is that there are now two copies of
pluto-portal-driver-config.xml in the pluto webapp: one in WEB-INF and
another in WEB-INF/classes. This is not acceptable since this file needs
to be modified when a new portlet is deployed and you can't expect
people to modify the same file in two places.
While this is not "ideal", I don't think a second copy (that's not used)
of a file is anything that should hold up a 1.1.1 release. If we can
find the issue and fix it quickly, than great, but otherwise, I have no
problem rolling a release with this type of minor issue - especially
since this is a PORTAL and NOT CONTAINER related issue. Again, if we
seek perfection for every release, we will never release.
The other thing that note is that portlet deployments DO NOT require
editing the pluto-portal-driver-config.xml. Auto deployment will handle
the portlet app registration, and even though you'd have to do it at
every restart (granted, a pain), portlets can be added to pages without
mod of the xml file.
I have a caveat to this story: I am using Maven 2.0.4. Is all this fixed
in 2.0.5? If so, we should state that in our docs or backtrack to
putting pluto-portal-driver-config.xml in WEB-INF of the pluto-portal
module (in src/main/webapp) and removing the maven-war-plugin voodoo
from the pom.xml file of the pluto-portal module. In other words, we
should backtrack to the way it was working in the Pluto 1.1.0 beta builds.
Disagree. We should not. The mechanism we have in place right now
simplifies our release process immensely. This is a minor issue, let's
not blow it out of proportion.
David
Please advise. Thank you.
/Craig
You do need the following in settings.xml.
<pluginGroups>
<pluginGroup>org.apache.pluto</pluginGroup>
</pluginGroups>
Also, the other day I caught something. I was running pluto:install
on the Pluto *1.1.0* tag, yet *1.1.0-SNAPSHOT* jars were being installed.
The culprit was Maven 2. It turned out that even though I was
executing version 1.1.0 of the pluto plugin, it was resolving SNAPSHOT
artifacts. It turns out I had a stale plugin directory and stale
maven 2 metadata for the Pluto Maven Plugin in:
~/.m2/repository/org/apache/maven/plugins/maven-pluto-plugin (this
directory shoudln't exist, so rm -rf it if it does)
~/.m2/repository/org/apache/maven/plugins/maven-metadata-local.xml
(remove any references to the maven-pluto-plugin in this file)
HTH,
Elliot
PS if you are stuck post the output somewhere (rafb.net/paste) with
debugging output
[EMAIL PROTECTED] wrote:
Elliot/David,
Thanks for the response. The build still fails for me, but I'll try
again with a fresh checkout.
Are there any special incantations you need to put in settings.xml?
TIA
/Craig
*"Elliot Metsger" <[EMAIL PROTECTED]>*
03/02/2007 10:04 AM
Please respond to
[email protected]
To
<[email protected]>
cc
Subject
Re: How do you build the bundled distribution?
Hey craig,
I can build the 1.1.0 tag using 'mvn -P assembly install' and it runs
fine (with the exception of the single testsuite error).
I used the bundled dist from
assembly/target/assembly/out/pluto-1.1.0-bundle.zip.
I agree with you we need the docs up. What do you think about using
the wiki instead of the pluto website? As long as you activate the
assembly profile with '-P assembly' and go through the maven 2
package and install lifecycle, the distributions should be created in
assembly/target/assembly/out.
Elliot
Sent from webmail (apologies for the poor quoting)
>>> Craig Doremus <[EMAIL PROTECTED]> 03/02/07 8:49 AM >>>
Hi all,
How do you build the bundled distribution of Pluto 1.1? I found some
reference to the command 'mvn install -P assembly' on the mail list that
builds a bundled distribution. But this distribution does not work. When
Tomcat is started, there is a note on the console that /pluto failed to
start, but no other reference there or in the logs to the error. I did
this build on two machines and got the same result.
We really need to document this process on the web site.
TIA
/Craig
