Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM]
Hi I was looking for a lightweight struts and by chance found this project. Unfortunately I have got a problem with conflicting jdom versions. I saw in the archive that there was a discussion about this last november. What happend to the idea of a 2.2.4 release? Cheers mike What are the thoughts of updating the jdom dependency of maverick? If there are no objections I will do the updates and do a 2.2.4 release. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar [INVALID FOOTER]
Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM
Hi --
I think upgrading the jdom library is a good idea -- keeping up-to-date
with libraries is a worthy goal. Velocity 1.4 has a dependency on the
older jdom as well. This means that us Mav/Velocity users must
simultaneously upgrade Velocity to an as of yet unreleased Velocity 1.5.
-- Dan
At 01:22 AM 11/27/2004, Mike Moulton wrote:
Responses inline...
I've had a look at changing Maverick to use jdom 1.0, but as I've never
used jdom myself, I am unsure what the changes should be and their
implications. I've identified the three place in the Maverick code that
need altered. #1 should be fine but I need help on #2 and #3. See below
for what I've done so far, with some in-line comments. I gleaned most
information from changes.txt in the jdom 1.0 distribution.
#1 and #3 look good. See notes by #2.
#2 org.infohazard.maverick.util.XML.java
public static Map getParams(Element node)
{
...
if (value == null)
{
/* OLD CODE: Checks for presence of children if no value present
* getChildren() now removed from v1.0
if (paramNode.hasChildren())
value = paramNode.getChildren();
else
value = paramNode.getTextTrim();
*/
/* NEW CODE: Since this method expects what the name/value pair
* param nodes should look like (from this methods javadoc), is there
* actually any need to check for child elements?
*/
value = paramNode.getTextTrim();
}
Though the javadocs say the that a param should only look like param
name= value=/, there has been support for child elements inside a
param/ for a while. Not sure about others, but I know I have used this
'feature' many times in the past. With that being the case I would do
something like this for #2.
List paramChildren = paramNode.getChildren();
if (!paramChildren.isEmpty())
value = paramChildren;
else
value = paramNode.getTextTrim();
What are the thoughts of updating the jdom dependency of maverick? If
there are no objections I will do the updates and do a 2.2.4 release.
-- Mike
: mike moulton
: meltmedia
: 1429 north 1st street
: phoenix az 85004
:
: [EMAIL PROTECTED]
: mmoulton66| aim
: 602.340.9440 | ofc
: 602.432.2568 | cel
: 602.340.1003 | fax
:
: meltmedia.com
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
[INVALID FOOTER]
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
[INVALID FOOTER]
Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM
Responses inline...
I've had a look at changing Maverick to use jdom 1.0, but as I've
never used jdom myself, I am unsure what the changes should be and
their implications. I've identified the three place in the Maverick
code that need altered. #1 should be fine but I need help on #2 and
#3. See below for what I've done so far, with some in-line comments. I
gleaned most information from changes.txt in the jdom 1.0
distribution.
#1 and #3 look good. See notes by #2.
#2 org.infohazard.maverick.util.XML.java
public static Map getParams(Element node)
{
...
if (value == null)
{
/* OLD CODE: Checks for presence of children if no value present
* getChildren() now removed from v1.0
if (paramNode.hasChildren())
value = paramNode.getChildren();
else
value = paramNode.getTextTrim();
*/
/* NEW CODE: Since this method expects what the name/value pair
* param nodes should look like (from this methods javadoc), is there
* actually any need to check for child elements?
*/
value = paramNode.getTextTrim();
}
Though the javadocs say the that a param should only look like param
name= value=/, there has been support for child elements inside a
param/ for a while. Not sure about others, but I know I have used
this 'feature' many times in the past. With that being the case I would
do something like this for #2.
List paramChildren = paramNode.getChildren();
if (!paramChildren.isEmpty())
value = paramChildren;
else
value = paramNode.getTextTrim();
What are the thoughts of updating the jdom dependency of maverick? If
there are no objections I will do the updates and do a 2.2.4 release.
-- Mike
: mike moulton
: meltmedia
: 1429 north 1st street
: phoenix az 85004
:
: [EMAIL PROTECTED]
: mmoulton66| aim
: 602.340.9440 | ofc
: 602.432.2568 | cel
: 602.340.1003 | fax
:
: meltmedia.com
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
[INVALID FOOTER]
Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM
No objections here. Regards, Eelco What are the thoughts of updating the jdom dependency of maverick? If there are no objections I will do the updates and do a 2.2.4 release. -- Mike --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ [INVALID FOOTER]
Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM
Regarding #2, I agree with your code changes. This is exactly what I originally had (honest!) but missed the trick with child elements and was trying to avoid the potentially unnecessary List creation. I agree on the List creation, however I don't see a way around it given the API changes. Mike, have you had the chance to test #3 against some of the more esoteric uses of the mav xml file? My personal usage is fairly straightforward, so if other users could give some feedback on this to ensure we don't break anything... #3 only effects the use of the maverick config command (command used to display the mav.xml file; used during development). I see no problems with your code change. Obviously, if all is well, I vote for these changes in a new release. I will let the list know once a release is available. -- Mike : mike moulton : meltmedia : 1429 north 1st street : phoenix az 85004 : : [EMAIL PROTECTED] : mmoulton66| aim : 602.340.9440 | ofc : 602.432.2568 | cel : 602.340.1003 | fax : : meltmedia.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ [INVALID FOOTER]
