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!
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.
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.
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
