portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Date Fri, 11 Jun 2004 20:23:52 GMT
I give up.
I tried all the thing you said. No go. Even completely reinstalled maven and deployed the
plugin again.
Still, no go.
I don't know: should all the plugins from the .maven/plugins be auto loaded? I didn't find
anything about in the 
documentation but as you seems to be using it like that I'm lost.
It just doesn't work on my machine.
I checked my environment variables and the only related things I have defined is MAVEN_HOME
and as classpath '.'.
Are there other variables I should set?
If not I can only conclude it doesn't work on my laptop and/or on Windows XP (if I remember
correctly you are using Linux).

Would there be any harm in defining the plugin dependency in portal/project.xml because without
it I can't get it to 
work...

Scott T Weaver wrote:

> I figured you did, just had to check ;)
> 
> try deleting all of the *.cache files in your .maven/plugins directory. 
> Also make sure that the maven-jetspeed2-plugin-1.0.0-SNAPSHOT has been
> deployed to the .maven/plugins directory.
> 
> On Fri, 2004-06-11 at 15:17, Ate Douma wrote:
> 
>>Yes, of course I did. I retrieved a fresh cvs HEAD so I had to do an allBuild first.
>>
>>jira@apache.org wrote:
>>
>>
>>>The following comment has been added to this issue:
>>>
>>>     Author: Scott T Weaver
>>>    Created: Fri, 11 Jun 2004 12:15 PM
>>>       Body:
>>>Ate,
>>>
>>>Did you do an allBuild or a /maven-plugin plugin:deploy prior to calling fullDeploy?.
 If not, that is what is causing your problem.
>>>---------------------------------------------------------------------
>>>View this comment:
>>>  http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36053
>>>
>>>---------------------------------------------------------------------
>>>View the issue:
>>>  http://issues.apache.org/jira/browse/JS2-74
>>>
>>>Here is an overview of the issue:
>>>---------------------------------------------------------------------
>>>        Key: JS2-74
>>>    Summary: Refactor PAM and Descriptor Utilities
>>>       Type: Improvement
>>>
>>>     Status: Closed
>>>   Priority: Major
>>> Resolution: FIXED
>>>
>>>    Project: Jetspeed 2
>>> Components: 
>>>             Deployment
>>>   Fix Fors:
>>>             2.0-dev/cvs
>>>             2.0-a1
>>>   Versions:
>>>             2.0-dev/cvs
>>>             2.0-a1
>>>
>>>   Assignee: Scott T Weaver
>>>   Reporter: Scott T Weaver
>>>
>>>    Created: Wed, 9 Jun 2004 7:25 AM
>>>    Updated: Fri, 11 Jun 2004 12:15 PM
>>>Environment: Mandrake Linux 10, Tomcat 4.1.30, HSQL
>>>
>>>Description:
>>>I am refactoring all of the Jetspeed desccriptor utility classes from static,
utility classes into objects.
>>>
>>>PortletDescriptorUtilities has been renamed to PortletApplicationDescriptor.
>>>
>>>WebDescriptorUtilities has been refactored into WebApplicationDescriptor.
>>>
>>>JetspeedDescriptorUtilities has been refactored into ExtendedPortletMetadata.
>>>
>>>Besides the rename, the static methods have been converted into instance methods.
>>>
>>>I have created a composite object, PortletApplicationWar, that uses these three
metadata classes to build up registry objects from a war file, which is either an actual war
file itself OR a war-like structure on the file system.  I am using commons-vfs to manipulate
the WAR as this allows me to work on the war as a FileObject, regardless if it is a file system
directory or a WAR file.
>>>
>>>All these descriptor classes have been moved to the org.apache.jetspeed.util.descriptor
package.
>>>
>>>FileSystemPAM uses the PortletApplicationWar class exclusively instead of directly
using the metadata classes themselves.  This makes the FSPAM code much more readable and easier
to debug.
>>>
>>>Looking over the logic for processWebXML, it does not appear to be adding the
JetspeedContainer servlet nor its mapping.  Also logic used to decide where to put the new
elements could possibly cause the elements to be placed in the wrong spot relative to the
DTD definition.
>>>
>>>I rewrote this logic using JDom and XPath expressions.  I am using an XPath query
to check for a specific servelet and servlet-mapping with the servlet-name "JetspeedContainer".
 If these elements do not exist, I use JDom to walk the top-level of elements until it finds
the correct location, per the DTD, to insert both the servlet and servlet-mapping elements.

>>>
>>>I have added an additional test, testInfuseWebXML, to TestPortletDescriptor to
verify that the infusing works correctly. 
>>>
>>>
>>>---------------------------------------------------------------------
>>>JIRA INFORMATION:
>>>This message is automatically generated by JIRA.
>>>
>>>If you think it was sent incorrectly contact one of the administrators:
>>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>>
>>>If you want more information on JIRA, or have a bug to report see:
>>>   http://www.atlassian.com/software/jira
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message