You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Craig Doremus <cd...@apache.org> on 2007/03/03 16:22:12 UTC
The 1.1 bundled build is still broken!! (was: Re: How do you build
the bundled distribution?)
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
>
>
> CDoremus@hannaford.com 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" <em...@jhuadig.admin.jhu.edu>*
>>
>> 03/02/2007 10:04 AM
>> Please respond to
>> pluto-dev@portals.apache.org
>>
>>
>>
>> To
>> <pl...@portals.apache.org>
>> 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 <cd...@apache.org> 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
>>
>
>
>
Re: The 1.1 bundled build is still broken!!
Posted by Elliot Metsger <em...@jhu.edu>.
Hey Craig, quick reply from me now then more later (I need to finish
pluto-312 quick-like)
Craig Doremus wrote:
>
> 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.
Ugh. Yes. If you run mvn with the -up switch i think it upgrades your
plugins.
>
> 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!
yeah. maven is not always the abstraction people want it to be. I
have, in my m2 travels, spent much time and love with the maven2 core
jars, decoration model, and plexus. I have created *-debug.jar versions
of many of those jars :-)
> 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 don't have two copies of the file. Is it vestigal?
>
> 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.
I've not tried 2.0.5. So I think in our docs we should state that 2.0.5
is untested and we recommend 2.0.4 - with updated versions of the 2.0.4
plugins.
I'd rather not backtrack and work forward to fix this issue -
I gotta get to 312 but more later.
>
> 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
>>
>>
>> CDoremus@hannaford.com 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" <em...@jhuadig.admin.jhu.edu>*
>>>
>>> 03/02/2007 10:04 AM
>>> Please respond to
>>> pluto-dev@portals.apache.org
>>>
>>>
>>> To
>>> <pl...@portals.apache.org>
>>> 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 <cd...@apache.org> 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
>>>
>>
>>
>>
Re: The 1.1 bundled build is still broken!!
Posted by "David H. DeWolf" <dd...@apache.org>.
Craig Doremus wrote:
>
>>>
>>> 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: I'm not suggesting that we backtrack to the Ant build -- just
> move the pluto-portal-driver-config.xml back into the WEB-INF directory
> from the resources directory. At any rate, this issue should not hold up
> the Pluto 1.1.1 release.
Gotcha -- so the reason we did that was to automate the inclusion of the
correct version number. I think that's more important. Do you agree?
-D
> /Craig
>
>
>
>
Re: The 1.1 bundled build is still broken!!
Posted by Craig Doremus <cd...@apache.org>.
>>
>> 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: I'm not suggesting that we backtrack to the Ant build -- just
move the pluto-portal-driver-config.xml back into the WEB-INF directory
from the resources directory. At any rate, this issue should not hold up
the Pluto 1.1.1 release.
/Craig
Re: The 1.1 bundled build is still broken!!
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
>> 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.
My bad - I should have put the version in the pom.
I spent the time to put in the comment, you'd think I would have put the
version in there :/
Sorry Craig for making you chase this down.
Elliot
Re: The 1.1 bundled build is still broken!!
Posted by "David H. DeWolf" <dd...@apache.org>.
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
>>
>>
>> CDoremus@hannaford.com 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" <em...@jhuadig.admin.jhu.edu>*
>>>
>>> 03/02/2007 10:04 AM
>>> Please respond to
>>> pluto-dev@portals.apache.org
>>>
>>>
>>> To
>>> <pl...@portals.apache.org>
>>> 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 <cd...@apache.org> 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
>>>
>>
>>
>>
>
>
>