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 21:53:00 GMT
I found it!

You must have done a plugin:install at least once.
After I done that it all works.

After the install which copies the plugin to {MAVEN_HOME}/plugins new versions deployed using
plugin:deploy (which 
*only* extracts the new plugin into {MAVEN_LOCAL_HOME}/plugins) take precedence over the original
plugin definition.
But, it *is* required to do an plugin:install at least once. Otherwise, a project dependency
is needed.

It would be nice if the maven documentation would be a bit more informative.
Not even the developers guide, which addresses developing new plugins describes these kind
of requirements clearly :(

Bloody hell, I lost almost half a days work only just this one issue.
We better make sure to document this clearly for future users.

Scott T Weaver wrote:

> I really don't know what it is, it's just very strange.  I just ran
> fullDeploy from /portal and it runs just fine.
> 
> The only time I have seen that exception is when the plugin is missing
> from .maven/plugins.  
> 
> On Fri, 2004-06-11 at 16:45, Ate Douma wrote:
> 
>>Scott T Weaver wrote:
>>
>>>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'
>>
>>Yes. I have that since I upgraded from maven 1.0-rc1 to rc2.
>>It never resulted in any problem so I thought it to be some kind of deprecated error
message or such.
>>You're saying you don't have those messages?
>>Maybe there really is something wrong in my setup.
>>But then, I completely reinstalled java and maven at least once after the first time
I saw this message so how could it 
>>be related to my setup?
>>I'll see if I can find more about this message. If anyone else had/has this please
let me know.
>>
>>
>>>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.
>>>>>>
>>>>>>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
>>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>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