I was looking at the stacktrace you posted, it is find the jetspeed2 plugin just fine but appears to be blowing chunks on:
Tag library requested that is not present: 'reactor' in plugin: 'null' I have no idea what would be causing that. Are you still getting this same error? On Fri, 2004-06-11 at 16:23, Ate Douma wrote: > 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. > >> > >>[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
