portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject [jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Date Fri, 11 Jun 2004 19:04:18 GMT
The following comment has been added to this issue:

     Author: Ate Douma
    Created: Fri, 11 Jun 2004 12:02 PM
I don't get it.
I retrieved a fresh cvs HEAD, cleared out all of J2 from my local maven repository and the
J2 plugin.

fullDeploy goal fails again though because it can't find the jetspeed2:deploy goal.
AFAIK, using a local plugin requires it to be defined as dependency, otherwise maven won't
know anything about it.
How is it possible you can deploy without it?

Below my console output:

    [echo] Deploying jetspeed2:jetspeed, Jetspeed-2 Portal Engine
    [copy] Copying 1 file to C:\jetspeed-base\tomcat4\webapps
    [unwar] Expanding: \jetspeed-base\tomcat4\webapps\jetspeed.war into \jetspeed-base\tomcat4\webapps\jetspeed
    [copy] Copying 1 file to C:\jetspeed-base\tomcat4\webapps
    [copy] Copying 1 file to C:\jetspeed-base\tomcat4\conf\Catalina\localhost
Tag library requested that is not present: 'reactor' in plugin: 'null'
    [echo] Copying from c:\java\maven-local/repository to /jetspeed-base/tomcat4/shared/lib...
Tag library requested that is not present: 'reactor' in plugin: 'null'
Tag library requested that is not present: 'reactor' in plugin: 'null'

File...... C:\workspace\jakarta-jetspeed-2\maven.xml
Element... maven:reactor
Line...... 485
Column.... 40
Unable to obtain goal [fullDeploy] -- C:\workspace\jakarta-jetspeed-2\portal\maven.xml:250:41:
<attainGoal> No goal [jet
Total time: 39 seconds
Finished at: Fri Jun 11 20:50:45 CEST 2004
View this comment:

View the issue:

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
   Fix Fors:

   Assignee: Scott T Weaver
   Reporter: Scott T Weaver

    Created: Wed, 9 Jun 2004 7:25 AM
    Updated: Fri, 11 Jun 2004 12:02 PM
Environment: Mandrake Linux 10, Tomcat 4.1.30, HSQL

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. 

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

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

View raw message