From jdom at tuis.net Wed May 9 06:46:21 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 09 May 2012 09:46:21 -0400 Subject: [jdom-interest] Wish-list Message-ID: <4FAA752D.1000504@tuis.net> Hi all. So 2.0.1 has settled in nicely, with no apparent issues. I have also taken some 'JDOM down-time' to just get some of my life in order.... and to avoid some burn-out. I'm now at a cross-roads of sorts.... My personal goal when I got involved with JDOM 2.x was to 'make JDOM current again', and I believe it is now (again) the 'best in class' in-memory XML model for Java. So, what is the 'cross-roads'? JDOM 2.x is now just an up to date 1.x version, with a more consistent code base, and which implements the modern Java concepts. But, should JDOM now settle in to a maintenance-only mode again until the next major development cycle in another 5 years? Or should JDOM again 'pioneer' in some new directions that make XML processing easier. I know I have my eyes on the 'Resolver' aspect of XML parsing, and I am going to start playing with that some more, but maybe there are other interesting things JDOM could be doing. So, this is a call for any 'wish-list' items that you want to have available in JDOM. Is there anything else JDOM can do for you? I think it would be reasonable to consider a JDOM 2.1 'branch' which extends existing JDOM functionality in the next 6 months or so, if there is a feature that would be nice to have, and people with an interest in building it.... Rolf From gmills at library.berkeley.edu Wed May 9 08:31:36 2012 From: gmills at library.berkeley.edu (Garey Mills) Date: Wed, 09 May 2012 08:31:36 -0700 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAA752D.1000504@tuis.net> References: <4FAA752D.1000504@tuis.net> Message-ID: <4FAA8DD8.4030100@library.berkeley.edu> Rolf - I'd like to see a persistence layer integrated with BaseX. Garey Mills Library Systems Office UC Berkeley On 5/9/2012 6:46 AM, Rolf Lear wrote: > Hi all. > > So 2.0.1 has settled in nicely, with no apparent issues. I have also > taken some 'JDOM down-time' to just get some of my life in order.... > and to avoid some burn-out. I'm now at a cross-roads of sorts.... > > My personal goal when I got involved with JDOM 2.x was to 'make JDOM > current again', and I believe it is now (again) the 'best in class' > in-memory XML model for Java. > > So, what is the 'cross-roads'? JDOM 2.x is now just an up to date 1.x > version, with a more consistent code base, and which implements the > modern Java concepts. But, should JDOM now settle in to a > maintenance-only mode again until the next major development cycle in > another 5 years? Or should JDOM again 'pioneer' in some new directions > that make XML processing easier. > > I know I have my eyes on the 'Resolver' aspect of XML parsing, and I > am going to start playing with that some more, but maybe there are > other interesting things JDOM could be doing. > > So, this is a call for any 'wish-list' items that you want to have > available in JDOM. > > Is there anything else JDOM can do for you? > > I think it would be reasonable to consider a JDOM 2.1 'branch' which > extends existing JDOM functionality in the next 6 months or so, if > there is a feature that would be nice to have, and people with an > interest in building it.... > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From benjamin.graf at gmx.net Wed May 9 09:38:51 2012 From: benjamin.graf at gmx.net (Benjamin Graf) Date: Wed, 09 May 2012 18:38:51 +0200 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAA752D.1000504@tuis.net> References: <4FAA752D.1000504@tuis.net> Message-ID: <4FAA9D9B.9010709@gmx.net> Hi Rolf, as I mentioned in one of my posts before I'd like a tight saxon integration for proper XPath 2.0 handling to enhance those capabilities. Maybe there is also some effort possible for the XML 2 bean mapper actually being in the contrib part of JDOM. Since Java is a bean focused language this is in my opinion a feature that worth it. Best regards Benjamin On 09.05.2012 15:46, Rolf Lear wrote: > Hi all. > > So 2.0.1 has settled in nicely, with no apparent issues. I have also > taken some 'JDOM down-time' to just get some of my life in order.... > and to avoid some burn-out. I'm now at a cross-roads of sorts.... > > My personal goal when I got involved with JDOM 2.x was to 'make JDOM > current again', and I believe it is now (again) the 'best in class' > in-memory XML model for Java. > > So, what is the 'cross-roads'? JDOM 2.x is now just an up to date 1.x > version, with a more consistent code base, and which implements the > modern Java concepts. But, should JDOM now settle in to a > maintenance-only mode again until the next major development cycle in > another 5 years? Or should JDOM again 'pioneer' in some new directions > that make XML processing easier. > > I know I have my eyes on the 'Resolver' aspect of XML parsing, and I > am going to start playing with that some more, but maybe there are > other interesting things JDOM could be doing. > > So, this is a call for any 'wish-list' items that you want to have > available in JDOM. > > Is there anything else JDOM can do for you? > > I think it would be reasonable to consider a JDOM 2.1 'branch' which > extends existing JDOM functionality in the next 6 months or so, if > there is a feature that would be nice to have, and people with an > interest in building it.... > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From bcox at virtualschool.edu Wed May 9 14:26:08 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Wed, 9 May 2012 17:26:08 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAA752D.1000504@tuis.net> References: <4FAA752D.1000504@tuis.net> Message-ID: Some personal wishes (since you asked) - Do the resolver!! - One-stop API for parsing XML or JSON (perhaps MongoDB BSON?) - Lay to rest the lingering ambiguity as to whether JDOM (compared to W3C DOM) has a performance cost. Performance measurements, space and/or time. On Wed, May 9, 2012 at 9:46 AM, Rolf Lear wrote: > Hi all. > > So 2.0.1 has settled in nicely, with no apparent issues. I have also taken > some 'JDOM down-time' to just get some of my life in order.... and to avoid > some burn-out. I'm now at a cross-roads of sorts.... > > My personal goal when I got involved with JDOM 2.x was to 'make JDOM > current again', and I believe it is now (again) the 'best in class' > in-memory XML model for Java. > > So, what is the 'cross-roads'? JDOM 2.x is now just an up to date 1.x > version, with a more consistent code base, and which implements the modern > Java concepts. But, should JDOM now settle in to a maintenance-only mode > again until the next major development cycle in another 5 years? Or should > JDOM again 'pioneer' in some new directions that make XML processing easier. > > I know I have my eyes on the 'Resolver' aspect of XML parsing, and I am > going to start playing with that some more, but maybe there are other > interesting things JDOM could be doing. > > So, this is a call for any 'wish-list' items that you want to have > available in JDOM. > > Is there anything else JDOM can do for you? > > I think it would be reasonable to consider a JDOM 2.1 'branch' which > extends existing JDOM functionality in the next 6 months or so, if there is > a feature that would be nice to have, and people with an interest in > building it.... > > Rolf > ______________________________**_________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/**options/jdom-interest/** > youraddr at yourhost.com > -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Wed May 9 17:12:56 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 09 May 2012 20:12:56 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAA8DD8.4030100@library.berkeley.edu> References: <4FAA752D.1000504@tuis.net> <4FAA8DD8.4030100@library.berkeley.edu> Message-ID: <4FAB0808.8010700@tuis.net> Hi Garey. BaseX is new to me. I have just had a little poke around but I am a bit lost as to where you think the integration would 'fit', and what purpose it would solve.... can you elaborate a bit? Thanks Rolf On 09/05/2012 11:31 AM, Garey Mills wrote: > Rolf - > > I'd like to see a persistence layer integrated with BaseX. > > Garey Mills > Library Systems Office > UC Berkeley > > On 5/9/2012 6:46 AM, Rolf Lear wrote: >> Hi all. >> From jdom at tuis.net Wed May 9 17:58:28 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 09 May 2012 20:58:28 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAA9D9B.9010709@gmx.net> References: <4FAA752D.1000504@tuis.net> <4FAA9D9B.9010709@gmx.net> Message-ID: <4FAB12B4.6020003@tuis.net> Saxon, I forgot. Yes, I agree. I have had one stab at creating an interface with Saxon for the XPath layer. I got bogged down in the API details, but it seemed feasible... I think. I think there are two levels that need to be integrated, the first is to create a JDOM 'Node Handler' for Saxon, and the second is to 'wrap' the Saxon XPath handling in the JDOM layer. This should definitely be on the ToDo... The JavaBean contrib code is 'old', and unfamiliar to me. There are basically two parts, exposing JDOM parsing as a bean, and creating a 'persistence' layer for other beans. Are you interested in one or the other, or both? Do you have p On 09/05/2012 12:38 PM, Benjamin Graf wrote: > Hi Rolf, > > as I mentioned in one of my posts before I'd like a tight saxon > integration for proper XPath 2.0 handling to enhance those capabilities. > Maybe there is also some effort possible for the XML 2 bean mapper > actually being in the contrib part of JDOM. Since Java is a bean focused > language this is in my opinion a feature that worth it. > > Best regards > Benjamin > > On 09.05.2012 15:46, Rolf Lear wrote: >> Hi all. >> From jdom at tuis.net Wed May 9 19:24:56 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 09 May 2012 22:24:56 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: References: <4FAA752D.1000504@tuis.net> Message-ID: <4FAB26F8.6000206@tuis.net> The resolver is on the cards.... decisions need to be made whether it is specific enough to JDOM to be part of the JDOM project.... I am not objective enough to make that decision... ;-) Also, to be complete it requires items that are not really relevant to JDOM, like a mechanism to import/export/refresh the cache, etc.... The resolver can be built independently and merged later? The post I put on w3c.org and the git project have seen very little activity.... nothing, in fact. It *already* works.... I would *love* to hear how you expect JDOM (XML-based) and JSON to 'hang out' in the same place .... ;-) That's like getting VI and Emacs people to agree .... (odd how JDOM and JSON are just two typo's apart....) The DOM performance test is an interesting one.... something I could consider. Performance tests are very unreliable though, and nothing I could do would lay anything to rest, but it would be interesting to have a look-see, even if it is just to get an idea.... Based on the performance work I have done already it would appear that, for Hamlet at least, SAX+JDOM is faster than just DOM. Based on http://hunterhacker.github.com/jdom/jdom2/performance.html it would seem that the time taken to SAX+JDOM the hamlet file is about 4.75ms on my laptop, and the time to do DOM+JDOM is about 7.1ms with about 2.5ms of that being JDOM time.... (implying 4.6ms is DOM time) So, I would say it is currently neck-and-neck between SAX+JDOM and DOM... Rolf On 09/05/2012 5:26 PM, Brad Cox wrote: > Some personal wishes (since you asked) > > * Do the resolver!! > * One-stop API for parsing XML or JSON (perhaps MongoDB BSON?) > * Lay to rest the lingering ambiguity as to whether JDOM (compared to > W3C DOM) has a performance cost. Performance measurements, space > and/or time. > > On Wed, May 9, 2012 at 9:46 AM, Rolf Lear > wrote: > From bcox at virtualschool.edu Thu May 10 04:12:42 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Thu, 10 May 2012 07:12:42 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAB26F8.6000206@tuis.net> References: <4FAA752D.1000504@tuis.net> <4FAB26F8.6000206@tuis.net> Message-ID: This is based on experience using both, not a deep analysis. More with XML than JSON to date. This work was in the context of building XACML compilers that use the W3C DOM tree as their expression tree. And inspired by recent W3C mailing list discussions on standardizing a JSON syntax for XACML. They seem to be viewing JSON as I do, as a useful subset of XML, with lack of namespaces and attributes the main differences I can think of at the moment. Lack of attributes not a problem for XACML; it hardly uses them, just element values. The notion is to add a JSON parser in front that builds the same XML (J)DOM tree you build now, plus a output path that converts the tree to JSON on demand. The proposed extension is appealing because it would allow the same XACML compiler to accept standard XACML and/or standard JSON, and to trivially convert between the representations. On Wed, May 9, 2012 at 10:24 PM, Rolf Lear wrote: > I would *love* to hear how you expect JDOM (XML-based) and JSON to 'hang > out' in the same place .... ;-) -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noel at peralex.com Thu May 10 08:36:08 2012 From: noel at peralex.com (Noel Grandin) Date: Thu, 10 May 2012 17:36:08 +0200 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAA752D.1000504@tuis.net> References: <4FAA752D.1000504@tuis.net> Message-ID: <4FABE068.8090301@peralex.com> I would love a simple resolver, built into JDOM. Just some kind of simple API that I can call to say "Never, ever, touch the network". I just hate it when people phone me because they tried to load some other XML file with my application and it stalls for 10 seconds while it fetches some random DTD from the network. Disclaimer: http://www.peralex.com/disclaimer.html From jdom at tuis.net Thu May 10 08:39:08 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 10 May 2012 11:39:08 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FABE068.8090301@peralex.com> References: <4FAA752D.1000504@tuis.net> <4FABE068.8090301@peralex.com> Message-ID: Interesting option..... and I can see some value, but what is the correct response to such a situation? An exception? An empty input stream? Rolf On Thu, 10 May 2012 17:36:08 +0200, Noel Grandin wrote: > I would love a simple resolver, built into JDOM. > > Just some kind of simple API that I can call to say "Never, ever, touch > the network". > > I just hate it when people phone me because they tried to load some > other XML file with my application and it stalls for 10 seconds while it > fetches some random DTD from the network. > > > > Disclaimer: http://www.peralex.com/disclaimer.html From jdom at tuis.net Thu May 10 08:43:47 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 10 May 2012 11:43:47 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: References: <4FAA752D.1000504@tuis.net> <4FAB26F8.6000206@tuis.net> Message-ID: <1de845db6c2383e7965b8d52684f0f3c@tuis.net> So, searching the interweb, I see some discussion about JSON parsers... I don't see a SAX specific one, but there appear to be a number of StAX-like ones.... and we have StAX support directly now... ;-) Loading JSON in to JDOM is probably a lot simpler than the opposite though.... I don't see how anything but a simple XML document could be output as a JSON 'output'.... the challenge would be how to deal with the 'unusual' XML-like concepts, rather than the easy stuff? Like, if your XML has a namespace, then what? Rolf On Thu, 10 May 2012 08:38:03 -0700, Chris Pratt wrote: > Correct me if I'm wrong, but all that JDOM would need for that to work > would be a JSON SAX parser and a JSON Outputter. Those could even be > packaged in a companion jar file for those that want the JDOM JSON support. > (*Chris*) > > On Thu, May 10, 2012 at 4:12 AM, Brad Cox wrote: > >> This is based on experience using both, not a deep analysis. More with >> XML >> than JSON to date. This work was in the context of building XACML >> compilers >> that use the W3C DOM tree as their expression tree. And inspired by >> recent >> W3C mailing list discussions on standardizing a JSON syntax for XACML. >> >> They seem to be viewing JSON as I do, as a useful subset of XML, with >> lack of namespaces and attributes the main differences I can think of at >> the moment. Lack of attributes not a problem for XACML; it hardly uses >> them, just element values. >> >> The notion is to add a JSON parser in front that builds the same XML >> (J)DOM tree you build now, plus a output path that converts the tree to >> JSON on demand. The proposed extension is appealing because it would >> allow >> the same XACML compiler to accept standard XACML and/or standard JSON, >> and >> to trivially convert between the representations. >> >> On Wed, May 9, 2012 at 10:24 PM, Rolf Lear wrote: >> >>> I would *love* to hear how you expect JDOM (XML-based) and JSON to 'hang >>> out' in the same place .... ;-) >> >> -- >> Cell: 703-594-1883 >> Blog: http://bradjcox.blogspot.com >> Web: http://virtualschool.edu >> Manassas VA 20111 >> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> From noel at peralex.com Thu May 10 08:57:21 2012 From: noel at peralex.com (Noel Grandin) Date: Thu, 10 May 2012 17:57:21 +0200 Subject: [jdom-interest] Wish-list In-Reply-To: References: <4FAA752D.1000504@tuis.net> <4FABE068.8090301@peralex.com> Message-ID: <4FABE561.4040302@peralex.com> I would want an exception, preferably a unique one - JDOMSchemaNotFoundException? On 2012-05-10 17:39, Rolf Lear wrote: > Interesting option..... and I can see some value, but what is the correct > response to such a situation? An exception? An empty input stream? > > Rolf > > On Thu, 10 May 2012 17:36:08 +0200, Noel Grandin wrote: >> I would love a simple resolver, built into JDOM. >> >> Just some kind of simple API that I can call to say "Never, ever, touch >> the network". >> >> I just hate it when people phone me because they tried to load some >> other XML file with my application and it stalls for 10 seconds while it >> fetches some random DTD from the network. >> >> >> >> Disclaimer: http://www.peralex.com/disclaimer.html > Disclaimer: http://www.peralex.com/disclaimer.html From mike at saxonica.com Thu May 10 10:02:34 2012 From: mike at saxonica.com (Michael Kay) Date: Thu, 10 May 2012 18:02:34 +0100 Subject: [jdom-interest] Wish-list In-Reply-To: <1de845db6c2383e7965b8d52684f0f3c@tuis.net> References: <4FAA752D.1000504@tuis.net> <4FAB26F8.6000206@tuis.net> <1de845db6c2383e7965b8d52684f0f3c@tuis.net> Message-ID: <4FABF4AA.1050106@saxonica.com> There's been a lot of work on JSON-to-XML and XML-to-JSON transformations. There is no single answer that works well in all cases. There is a tension between being lossless and producing something that is usable. An XML-to-JSON transformation that can handle mixed content may produce indigestible output for simple data-oriented XML. I don't think there is any good architectural reason to regard XML-JSON transformation as being part of the same component in the architecture as an XML tree model. Just because it needs doing doesn't mean it needs doing in JDOM. To me it's best kept separate. Michael Kay Saxonica On 10/05/2012 16:43, Rolf Lear wrote: > So, searching the interweb, I see some discussion about JSON parsers... I > don't see a SAX specific one, but there appear to be a number of StAX-like > ones.... and we have StAX support directly now... ;-) > > Loading JSON in to JDOM is probably a lot simpler than the opposite > though.... > > I don't see how anything but a simple XML document could be output as a > JSON 'output'.... the challenge would be how to deal with the 'unusual' > XML-like concepts, rather than the easy stuff? > > Like, if your XML has a namespace, then what? > > Rolf > > On Thu, 10 May 2012 08:38:03 -0700, Chris Pratt > wrote: >> Correct me if I'm wrong, but all that JDOM would need for that to work >> would be a JSON SAX parser and a JSON Outputter. Those could even be >> packaged in a companion jar file for those that want the JDOM JSON > support. >> (*Chris*) >> >> On Thu, May 10, 2012 at 4:12 AM, Brad Cox > wrote: >>> This is based on experience using both, not a deep analysis. More with >>> XML >>> than JSON to date. This work was in the context of building XACML >>> compilers >>> that use the W3C DOM tree as their expression tree. And inspired by >>> recent >>> W3C mailing list discussions on standardizing a JSON syntax for XACML. >>> >>> They seem to be viewing JSON as I do, as a useful subset of XML, with >>> lack of namespaces and attributes the main differences I can think of > at >>> the moment. Lack of attributes not a problem for XACML; it hardly uses >>> them, just element values. >>> >>> The notion is to add a JSON parser in front that builds the same XML >>> (J)DOM tree you build now, plus a output path that converts the tree to >>> JSON on demand. The proposed extension is appealing because it would >>> allow >>> the same XACML compiler to accept standard XACML and/or standard JSON, >>> and >>> to trivially convert between the representations. >>> >>> On Wed, May 9, 2012 at 10:24 PM, Rolf Lear wrote: >>> >>>> I would *love* to hear how you expect JDOM (XML-based) and JSON to > 'hang >>>> out' in the same place .... ;-) >>> -- >>> Cell: 703-594-1883 >>> Blog: http://bradjcox.blogspot.com >>> Web: http://virtualschool.edu >>> Manassas VA 20111 >>> >>> >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From bcox at virtualschool.edu Thu May 10 11:22:20 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Thu, 10 May 2012 14:22:20 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FABF4AA.1050106@saxonica.com> References: <4FAA752D.1000504@tuis.net> <4FAB26F8.6000206@tuis.net> <1de845db6c2383e7965b8d52684f0f3c@tuis.net> <4FABF4AA.1050106@saxonica.com> Message-ID: The best reason for doing it in JDOM I know of is for the two external syntaxes to share EXACTLY the same DOM tree with flawless conversion between them (subject to the JDOM as XML subset notion). If that could be arranged with a separate tool that would do too. FWIW: The JDOM parser I settled on is Jackson. There are a bunch of others. On Thu, May 10, 2012 at 1:02 PM, Michael Kay wrote: > There's been a lot of work on JSON-to-XML and XML-to-JSON transformations. > There is no single answer that works well in all cases. There is a tension > between being lossless and producing something that is usable. An > XML-to-JSON transformation that can handle mixed content may produce > indigestible output for simple data-oriented XML. > > I don't think there is any good architectural reason to regard XML-JSON > transformation as being part of the same component in the architecture as > an XML tree model. Just because it needs doing doesn't mean it needs doing > in JDOM. To me it's best kept separate. > > Michael Kay > Saxonica > > > On 10/05/2012 16:43, Rolf Lear wrote: > >> So, searching the interweb, I see some discussion about JSON parsers... I >> don't see a SAX specific one, but there appear to be a number of StAX-like >> ones.... and we have StAX support directly now... ;-) >> >> Loading JSON in to JDOM is probably a lot simpler than the opposite >> though.... >> >> I don't see how anything but a simple XML document could be output as a >> JSON 'output'.... the challenge would be how to deal with the 'unusual' >> XML-like concepts, rather than the easy stuff? >> >> Like, if your XML has a namespace, then what? >> >> Rolf >> >> On Thu, 10 May 2012 08:38:03 -0700, Chris Pratt >> wrote: >> >>> Correct me if I'm wrong, but all that JDOM would need for that to work >>> would be a JSON SAX parser and a JSON Outputter. Those could even be >>> packaged in a companion jar file for those that want the JDOM JSON >>> >> support. >> >>> (*Chris*) >>> >>> On Thu, May 10, 2012 at 4:12 AM, Brad Cox >>> >> wrote: >> >>> This is based on experience using both, not a deep analysis. More with >>>> XML >>>> than JSON to date. This work was in the context of building XACML >>>> compilers >>>> that use the W3C DOM tree as their expression tree. And inspired by >>>> recent >>>> W3C mailing list discussions on standardizing a JSON syntax for XACML. >>>> >>>> They seem to be viewing JSON as I do, as a useful subset of XML, with >>>> lack of namespaces and attributes the main differences I can think of >>>> >>> at >> >>> the moment. Lack of attributes not a problem for XACML; it hardly uses >>>> them, just element values. >>>> >>>> The notion is to add a JSON parser in front that builds the same XML >>>> (J)DOM tree you build now, plus a output path that converts the tree to >>>> JSON on demand. The proposed extension is appealing because it would >>>> allow >>>> the same XACML compiler to accept standard XACML and/or standard JSON, >>>> and >>>> to trivially convert between the representations. >>>> >>>> On Wed, May 9, 2012 at 10:24 PM, Rolf Lear wrote: >>>> >>>> I would *love* to hear how you expect JDOM (XML-based) and JSON to >>>>> >>>> 'hang >> >>> out' in the same place .... ;-) >>>>> >>>> -- >>>> Cell: 703-594-1883 >>>> Blog: http://bradjcox.blogspot.com >>>> Web: http://virtualschool.edu >>>> Manassas VA 20111 >>>> >>>> >>>> ______________________________**_________________ >>>> To control your jdom-interest membership: >>>> http://www.jdom.org/mailman/**options/jdom-interest/** >>>> youraddr at yourhost.com >>>> >>>> ______________________________**_________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/**options/jdom-interest/** >> youraddr at yourhost.com >> >> ______________________________**_________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/**options/jdom-interest/** > youraddr at yourhost.com > -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at saxonica.com Thu May 10 14:21:06 2012 From: mike at saxonica.com (Michael Kay) Date: Thu, 10 May 2012 22:21:06 +0100 Subject: [jdom-interest] Wish-list In-Reply-To: References: <4FAA752D.1000504@tuis.net> <4FAB26F8.6000206@tuis.net> <1de845db6c2383e7965b8d52684f0f3c@tuis.net> <4FABF4AA.1050106@saxonica.com> Message-ID: <4FAC3142.5020500@saxonica.com> But JSON and XML are not just two different syntaxes. They are fundamentally different data models. It's not at all clear why someone would want to use something as complex as the XML data model to hold something as simple as JSON. Michael Kay Saxonica On 10/05/2012 19:22, Brad Cox wrote: > The best reason for doing it in JDOM I know of is for the two external > syntaxes to share EXACTLY the same DOM tree with flawless conversion > between them (subject to the JDOM as XML subset notion). If that could > be arranged with a separate tool that would do too. > > FWIW: The JDOM parser I settled on is Jackson. There are a bunch of > others. > > On Thu, May 10, 2012 at 1:02 PM, Michael Kay > wrote: > > There's been a lot of work on JSON-to-XML and XML-to-JSON > transformations. There is no single answer that works well in all > cases. There is a tension between being lossless and producing > something that is usable. An XML-to-JSON transformation that can > handle mixed content may produce indigestible output for simple > data-oriented XML. > > I don't think there is any good architectural reason to regard > XML-JSON transformation as being part of the same component in the > architecture as an XML tree model. Just because it needs doing > doesn't mean it needs doing in JDOM. To me it's best kept separate. > > Michael Kay > Saxonica > > > On 10/05/2012 16:43, Rolf Lear wrote: > > So, searching the interweb, I see some discussion about JSON > parsers... I > don't see a SAX specific one, but there appear to be a number > of StAX-like > ones.... and we have StAX support directly now... ;-) > > Loading JSON in to JDOM is probably a lot simpler than the > opposite > though.... > > I don't see how anything but a simple XML document could be > output as a > JSON 'output'.... the challenge would be how to deal with the > 'unusual' > XML-like concepts, rather than the easy stuff? > > Like, if your XML has a namespace, then what? > > Rolf > > On Thu, 10 May 2012 08:38:03 -0700, Chris > Pratt> > wrote: > > Correct me if I'm wrong, but all that JDOM would need for > that to work > would be a JSON SAX parser and a JSON Outputter. Those > could even be > packaged in a companion jar file for those that want the > JDOM JSON > > support. > > (*Chris*) > > On Thu, May 10, 2012 at 4:12 AM, Brad > Cox> > > wrote: > > This is based on experience using both, not a deep > analysis. More with > XML > than JSON to date. This work was in the context of > building XACML > compilers > that use the W3C DOM tree as their expression tree. > And inspired by > recent > W3C mailing list discussions on standardizing a JSON > syntax for XACML. > > They seem to be viewing JSON as I do, as a useful > subset of XML, with > lack of namespaces and attributes the main differences > I can think of > > at > > the moment. Lack of attributes not a problem for > XACML; it hardly uses > them, just element values. > > The notion is to add a JSON parser in front that > builds the same XML > (J)DOM tree you build now, plus a output path that > converts the tree to > JSON on demand. The proposed extension is appealing > because it would > allow > the same XACML compiler to accept standard XACML > and/or standard JSON, > and > to trivially convert between the representations. > > On Wed, May 9, 2012 at 10:24 PM, Rolf > Lear> wrote: > > I would *love* to hear how you expect JDOM > (XML-based) and JSON to > > 'hang > > out' in the same place .... ;-) > > -- > Cell: 703-594-1883 > Blog: http://bradjcox.blogspot.com > Web: http://virtualschool.edu > Manassas VA 20111 > > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > > > > > -- > Cell: 703-594-1883 > Blog: http://bradjcox.blogspot.com > Web: http://virtualschool.edu > Manassas VA 20111 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcox at virtualschool.edu Thu May 10 17:05:56 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Thu, 10 May 2012 20:05:56 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAC3142.5020500@saxonica.com> References: <4FAA752D.1000504@tuis.net> <4FAB26F8.6000206@tuis.net> <1de845db6c2383e7965b8d52684f0f3c@tuis.net> <4FABF4AA.1050106@saxonica.com> <4FAC3142.5020500@saxonica.com> Message-ID: Maybe you're seeing something I'm missing, but my reason for proposing this is to support JSON syntax (subsetted, minus namespaces and attributes) within the SAME (JDOM) data model. I see them as providing different syntax for the *same* semantics, in exactly the sense that the Java code my compilers generate for XACML are just another syntax with exactly the same semantics as in the original XML/XACML source. The same would/should be true of a JSON XACML source document. On Thu, May 10, 2012 at 5:21 PM, Michael Kay wrote: > But JSON and XML are not just two different syntaxes. They are > fundamentally different data models. It's not at all clear why someone > would want to use something as complex as the XML data model to hold > something as simple as JSON. > > Michael Kay > Saxonica > > > On 10/05/2012 19:22, Brad Cox wrote: > > The best reason for doing it in JDOM I know of is for the two external > syntaxes to share EXACTLY the same DOM tree with flawless conversion > between them (subject to the JDOM as XML subset notion). If that could be > arranged with a separate tool that would do too. > > FWIW: The JDOM parser I settled on is Jackson. There are a bunch of > others. > > On Thu, May 10, 2012 at 1:02 PM, Michael Kay wrote: > >> There's been a lot of work on JSON-to-XML and XML-to-JSON >> transformations. There is no single answer that works well in all cases. >> There is a tension between being lossless and producing something that is >> usable. An XML-to-JSON transformation that can handle mixed content may >> produce indigestible output for simple data-oriented XML. >> >> I don't think there is any good architectural reason to regard XML-JSON >> transformation as being part of the same component in the architecture as >> an XML tree model. Just because it needs doing doesn't mean it needs doing >> in JDOM. To me it's best kept separate. >> >> Michael Kay >> Saxonica >> >> >> On 10/05/2012 16:43, Rolf Lear wrote: >> >>> So, searching the interweb, I see some discussion about JSON parsers... I >>> don't see a SAX specific one, but there appear to be a number of >>> StAX-like >>> ones.... and we have StAX support directly now... ;-) >>> >>> Loading JSON in to JDOM is probably a lot simpler than the opposite >>> though.... >>> >>> I don't see how anything but a simple XML document could be output as a >>> JSON 'output'.... the challenge would be how to deal with the 'unusual' >>> XML-like concepts, rather than the easy stuff? >>> >>> Like, if your XML has a namespace, then what? >>> >>> Rolf >>> >>> On Thu, 10 May 2012 08:38:03 -0700, Chris Pratt >>> wrote: >>> >>>> Correct me if I'm wrong, but all that JDOM would need for that to work >>>> would be a JSON SAX parser and a JSON Outputter. Those could even be >>>> packaged in a companion jar file for those that want the JDOM JSON >>>> >>> support. >>> >>>> (*Chris*) >>>> >>>> On Thu, May 10, 2012 at 4:12 AM, Brad Cox >>>> >>> wrote: >>> >>>> This is based on experience using both, not a deep analysis. More with >>>>> XML >>>>> than JSON to date. This work was in the context of building XACML >>>>> compilers >>>>> that use the W3C DOM tree as their expression tree. And inspired by >>>>> recent >>>>> W3C mailing list discussions on standardizing a JSON syntax for XACML. >>>>> >>>>> They seem to be viewing JSON as I do, as a useful subset of XML, with >>>>> lack of namespaces and attributes the main differences I can think of >>>>> >>>> at >>> >>>> the moment. Lack of attributes not a problem for XACML; it hardly uses >>>>> them, just element values. >>>>> >>>>> The notion is to add a JSON parser in front that builds the same XML >>>>> (J)DOM tree you build now, plus a output path that converts the tree to >>>>> JSON on demand. The proposed extension is appealing because it would >>>>> allow >>>>> the same XACML compiler to accept standard XACML and/or standard JSON, >>>>> and >>>>> to trivially convert between the representations. >>>>> >>>>> On Wed, May 9, 2012 at 10:24 PM, Rolf Lear wrote: >>>>> >>>>> I would *love* to hear how you expect JDOM (XML-based) and JSON to >>>>>> >>>>> 'hang >>> >>>> out' in the same place .... ;-) >>>>>> >>>>> -- >>>>> Cell: 703-594-1883 >>>>> Blog: http://bradjcox.blogspot.com >>>>> Web: http://virtualschool.edu >>>>> Manassas VA 20111 >>>>> >>>>> >>>>> _______________________________________________ >>>>> To control your jdom-interest membership: >>>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>>>> >>>>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> >>> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > > > > -- > Cell: 703-594-1883 > Blog: http://bradjcox.blogspot.com > Web: http://virtualschool.edu > Manassas VA 20111 > > -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcox at virtualschool.edu Thu May 10 17:08:58 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Thu, 10 May 2012 20:08:58 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAC09E8.4000005@gmx.net> References: <4FAA752D.1000504@tuis.net> <4FAA9D9B.9010709@gmx.net> <4FAB12B4.6020003@tuis.net> <4FAC09E8.4000005@gmx.net> Message-ID: I didn't propose an XML2Bean converter. Jackson and others already do that. The proposal was to support JSON as a syntax for building the same JDOM tree that it does now from XML. On Thu, May 10, 2012 at 2:33 PM, Benjamin Graf wrote: > Hi Rolf, > > at the moment I'm not sure if it is a good idea to have yet another > XML2Bean mapper at all. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Thu May 10 17:19:37 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 10 May 2012 20:19:37 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: References: <4FAA752D.1000504@tuis.net> <4FAA9D9B.9010709@gmx.net> <4FAB12B4.6020003@tuis.net> <4FAC09E8.4000005@gmx.net> Message-ID: <4FAC5B19.9060103@tuis.net> Hi Brad. Benjamin was responding to a different suggestion to move some JvaBeans code from the contrib area to 'core'. Confusing wish-list. Probably a good time to break out the different proposals.... Rolf On 10/05/2012 8:08 PM, Brad Cox wrote: > I didn't propose an XML2Bean converter. Jackson and others already do > that. The proposal was to support JSON as a syntax for building the same > JDOM tree that it does now from XML. > > On Thu, May 10, 2012 at 2:33 PM, Benjamin Graf > wrote: > > Hi Rolf, > > at the moment I'm not sure if it is a good idea to have yet another > XML2Bean mapper at all. > From bcox at virtualschool.edu Thu May 10 17:42:48 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Thu, 10 May 2012 20:42:48 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAC5B19.9060103@tuis.net> References: <4FAA752D.1000504@tuis.net> <4FAA9D9B.9010709@gmx.net> <4FAB12B4.6020003@tuis.net> <4FAC09E8.4000005@gmx.net> <4FAC5B19.9060103@tuis.net> Message-ID: Coincidentally just discovered this. Maybe it will help. http://wiki.open311.org/index.php?title=JSON_and_XML_Conversion On Thu, May 10, 2012 at 8:19 PM, Rolf Lear wrote: > Hi Brad. > > Benjamin was responding to a different suggestion to move some JvaBeans > code from the contrib area to 'core'. > > Confusing wish-list. > > Probably a good time to break out the different proposals.... > > Rolf > > > On 10/05/2012 8:08 PM, Brad Cox wrote: > >> I didn't propose an XML2Bean converter. Jackson and others already do >> that. The proposal was to support JSON as a syntax for building the same >> JDOM tree that it does now from XML. >> >> On Thu, May 10, 2012 at 2:33 PM, Benjamin Graf > **> wrote: >> >> Hi Rolf, >> >> at the moment I'm not sure if it is a good idea to have yet another >> XML2Bean mapper at all. >> >> -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Thu May 10 18:03:53 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 10 May 2012 21:03:53 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FAA752D.1000504@tuis.net> References: <4FAA752D.1000504@tuis.net> Message-ID: <4FAC6579.2010003@tuis.net> Hi all. Just added the items I have seen so far to this list (did I miss some?): https://github.com/hunterhacker/jdom/issues?direction=desc&milestone=3&page=1&sort=created&state=open At the moment these issues are placeholders.... they are no indication that the items *will* be done, just an indication that they will be *considered*! I think it makes sense to look for 'champions' for each one, with a procedure as follows: 1. motivate the feature - describe the intended feature, and answer the questions: "is it really useful?" and "does it 'belong' in JDOM?". 2. put together a plan for the feature - what are the dependencies, goals. 3. partitipate and keep tabs on the development... keep it on track. 4. 'sign off' on the results - does it work as intended.... ? The reason I suggest this approach is: 1. I am not familiar with all the technologies out there, so I cannot adequately motivate/design/implement/validate these items. 2. I intend to tackle the Resolver (pet project) or Saxon integration (XPath 2.0 support is a 'headline' feature), and I am not particularly good at multitasking... so 'my day job' and 1 other thing is all I can do... 3. I don't want a huge time delay on 2.1 - I am thinking 6 months or so at most... and it is amazing how fast that time will go, and with me doing 1 thing at a time ... well... it won't all happen if it is only me doing it.... 4. 'Community', 'Knowledge Transfer' and 'Opportunity' - I have never wanted to be the only person working on JDOM.... it just turned out that way - I think the 'clean up' and 'testing' for JDOM 2.x was not very attractive work :) This is a good moment for people to step up and 'own' a chunk of the project. So, any volunteers? Rolf On 09/05/2012 9:46 AM, Rolf Lear wrote: > Hi all. > > So 2.0.1 has settled in nicely, with no apparent issues. I have also > taken some 'JDOM down-time' to just get some of my life in order.... and > to avoid some burn-out. I'm now at a cross-roads of sorts.... > > My personal goal when I got involved with JDOM 2.x was to 'make JDOM > current again', and I believe it is now (again) the 'best in class' > in-memory XML model for Java. > > So, what is the 'cross-roads'? JDOM 2.x is now just an up to date 1.x > version, with a more consistent code base, and which implements the > modern Java concepts. But, should JDOM now settle in to a > maintenance-only mode again until the next major development cycle in > another 5 years? Or should JDOM again 'pioneer' in some new directions > that make XML processing easier. > > I know I have my eyes on the 'Resolver' aspect of XML parsing, and I am > going to start playing with that some more, but maybe there are other > interesting things JDOM could be doing. > > So, this is a call for any 'wish-list' items that you want to have > available in JDOM. > > Is there anything else JDOM can do for you? > > I think it would be reasonable to consider a JDOM 2.1 'branch' which > extends existing JDOM functionality in the next 6 months or so, if there > is a feature that would be nice to have, and people with an interest in > building it.... > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From mike at saxonica.com Fri May 11 00:25:57 2012 From: mike at saxonica.com (Michael Kay) Date: Fri, 11 May 2012 08:25:57 +0100 Subject: [jdom-interest] Wish-list In-Reply-To: References: <4FAA752D.1000504@tuis.net> <4FAB26F8.6000206@tuis.net> <1de845db6c2383e7965b8d52684f0f3c@tuis.net> <4FABF4AA.1050106@saxonica.com> <4FAC3142.5020500@saxonica.com> Message-ID: <4FACBF05.5020502@saxonica.com> On 11/05/2012 01:05, Brad Cox wrote: > Maybe you're seeing something I'm missing, but my reason for proposing > this is to support JSON syntax (subsetted, minus namespaces and > attributes) within the SAME (JDOM) data model. I see them as providing > different syntax for the *same* semantics, OK, so what will the JDOM model look like if this is the JSON input: [ 23, null, {color:red}, [] ] Michael Kay Saxonica -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at saxonica.com Fri May 11 00:29:12 2012 From: mike at saxonica.com (Michael Kay) Date: Fri, 11 May 2012 08:29:12 +0100 Subject: [jdom-interest] Wish-list In-Reply-To: References: <4FAA752D.1000504@tuis.net> <4FAA9D9B.9010709@gmx.net> <4FAB12B4.6020003@tuis.net> <4FAC09E8.4000005@gmx.net> <4FAC5B19.9060103@tuis.net> Message-ID: <4FACBFC8.1000100@saxonica.com> On 11/05/2012 01:42, Brad Cox wrote: > Coincidentally just discovered this. Maybe it will help. > http://wiki.open311.org/index.php?title=JSON_and_XML_Conversion > It's a useful survey of half a dozen different attempts at XML to JSON mapping. I'm sure I could find another half a dozen if I had an hour to spare. Michael Kay Saxonica From bcox at virtualschool.edu Fri May 11 03:09:47 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Fri, 11 May 2012 06:09:47 -0400 Subject: [jdom-interest] Wish-list In-Reply-To: <4FACBF05.5020502@saxonica.com> References: <4FAA752D.1000504@tuis.net> <4FAB26F8.6000206@tuis.net> <1de845db6c2383e7965b8d52684f0f3c@tuis.net> <4FABF4AA.1050106@saxonica.com> <4FAC3142.5020500@saxonica.com> <4FACBF05.5020502@saxonica.com> Message-ID: Perhaps? > 23 > > red > On Fri, May 11, 2012 at 3:25 AM, Michael Kay wrote: > OK, so what will the JDOM model look like if this is the JSON input: > > [ 23, null, {color:red}, [] ] > > Michael Kay > Saxonica > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at saxonica.com Fri May 11 03:56:48 2012 From: mike at saxonica.com (Michael Kay) Date: Fri, 11 May 2012 11:56:48 +0100 Subject: [jdom-interest] Wish-list In-Reply-To: References: <4FAA752D.1000504@tuis.net> <4FAB26F8.6000206@tuis.net> <1de845db6c2383e7965b8d52684f0f3c@tuis.net> <4FABF4AA.1050106@saxonica.com> <4FAC3142.5020500@saxonica.com> <4FACBF05.5020502@saxonica.com> Message-ID: <4FACF070.9000301@saxonica.com> On 11/05/2012 11:09, Brad Cox wrote: > Perhaps? > > > 23 > > red > > > > That's an option. But you appear to be representing "null" in the same way as an empty map; and you have chosen to map the JSON key "color" to the element name "color", which raises the question how you will map JSON keys that are not legal element names. My point is that these problems can be solved in many different ways, which is why there are many different mappings of JSON to XML. I don't think there is any reason why JSON should work with only one of these mappings; the conversion of JSON to XML and the representation of XML in Java are two completely orthogonal decisions that do not need to be bundled together. Michael Kay Saxonica > > On Fri, May 11, 2012 at 3:25 AM, Michael Kay > wrote: > > OK, so what will the JDOM model look like if this is the JSON input: > > [ 23, null, {color:red}, [] ] > > Michael Kay > Saxonica > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.wall at myeastside.com Fri May 11 17:42:31 2012 From: david.wall at myeastside.com (David Wall) Date: Fri, 11 May 2012 17:42:31 -0700 Subject: [jdom-interest] JDOM 2 list of elements, remove nulls out entries and fails to remove? Message-ID: <4FADB1F7.2010701@myeastside.com> I believe I've run into a problem that I don't think I had with JDOM 1.1.3 before I upgraded to 2.0.1. I create a list of elements of a selected element using: List documentVersionElements = rootElement.getChildren("DocumentVersion", ns); I see that I have 6 elements as expected in my list. None are null. I am basically then trying to find a matching related element id in that list using something like: Element found = null; ListIterator iter = documentVersionElements .listIterator(); while( iter.hasNext() ) { Element checkElement = (Element)iter.next(); EsfUUID evParentId = new EsfUUID(checkElement.getChildText("documentId", ns)); if ( evParentId.equals(id) ) { found = checkElement; break; } } Then, assuming I find it (found != null), I process it as expected. But I then want to remove the found element from the element list so it cannot be found again, so I use this: documentVersionElements.remove(found); Most of the time, this seems to work as expected, and the documentVersionElements list is then shorter by 1. But there are times when a list of 6 elements remains 6 elements after the remove (and remove() returns false), with 4 of them now null (not removed, but actually a null element), so in when I return to the listIterator() above and get my next() element, the element is null. It's as if my Element objects are not unique in the list in terms of equals/hashCode as my elements should never be nulled out. I am not sure why an element I find by iterating cannot then be removed. How could it fail to remove? Why would it change other list elements to NULL instead? Is this not a valid usage pattern? Thanks, David From david.wall at myeastside.com Fri May 11 17:59:41 2012 From: david.wall at myeastside.com (David Wall) Date: Fri, 11 May 2012 17:59:41 -0700 Subject: [jdom-interest] JDOM 2 list of elements, remove nulls out entries and fails to remove? In-Reply-To: <4FADB1F7.2010701@myeastside.com> References: <4FADB1F7.2010701@myeastside.com> Message-ID: <4FADB5FD.10805@myeastside.com> By the way, when I changed the code to create my own "non-live" lists, the problem goes away and it works as expected: List documentVersionElements = new LinkedList(rootElement.getChildren("DocumentVersion", ns)); But the elements I'm removing aren't nested in the XML/JDOM, so removing one shouldn't cause anything else to change even with a "live" view of the JDOM. I suppose when I remove an Element, perhaps it moves the List element order for everything after it and so my live lists are then messed up? Anyway, it seems that the Element's hashCode/equals works as expected in a regular LinkedList of Elements. On 5/11/2012 5:42 PM, David Wall wrote: > I believe I've run into a problem that I don't think I had with JDOM > 1.1.3 before I upgraded to 2.0.1. > > I create a list of elements of a selected element using: > > List documentVersionElements = > rootElement.getChildren("DocumentVersion", ns); > > I see that I have 6 elements as expected in my list. None are null. > > I am basically then trying to find a matching related element id in > that list using something like: > > Element found = null; > ListIterator iter = > documentVersionElements.listIterator(); > while( iter.hasNext() ) { > Element checkElement = (Element)iter.next(); > EsfUUID evParentId = new > EsfUUID(checkElement.getChildText("documentId", ns)); > if ( evParentId.equals(id) ) { > found = checkElement; > break; > } > } > > Then, assuming I find it (found != null), I process it as expected. > But I then want to remove the found element from the element list so > it cannot be found again, so I use this: > > documentVersionElements.remove(found); > > Most of the time, this seems to work as expected, and the > documentVersionElements list is then shorter by 1. But there are > times when a list of 6 elements remains 6 elements after the remove > (and remove() returns false), with 4 of them now null (not removed, > but actually a null element), so in when I return to the > listIterator() above and get my next() element, the element is null. > > It's as if my Element objects are not unique in the list in terms of > equals/hashCode as my elements should never be nulled out. > > I am not sure why an element I find by iterating cannot then be > removed. How could it fail to remove? Why would it change other list > elements to NULL instead? Is this not a valid usage pattern? > > Thanks, > David From jdom at tuis.net Fri May 11 18:14:44 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 11 May 2012 21:14:44 -0400 Subject: [jdom-interest] JDOM 2 list of elements, remove nulls out entries and fails to remove? In-Reply-To: <4FADB1F7.2010701@myeastside.com> References: <4FADB1F7.2010701@myeastside.com> Message-ID: <4FADB984.1050002@tuis.net> Hi David. This problem you describe is very concerning, and should not, in 'supported' usage ever happen.... I am wracking my brains to figure out what it could be, but, the only think I can think is that you are accessing the JDOM objects from different threads.... JDOM is *not* thread safe. If this is happening in a single-threaded mechanism, would it be possible to put together a failing 'test case', any code that shows the problem? I have to admit that I thought he iteration/remove/add/etc. type code is very well tested, and I would be *very* suprised if there is a problem like this.... in fact, I know that there are test cases that cover this basic condition that you describe... and they never fail.... so, if you can confirm this is all happening in one thread.... and preferably if you can put together an example of the problem, I would look in to it immediately.... Rolf On 11/05/2012 8:42 PM, David Wall wrote: > I believe I've run into a problem that I don't think I had with JDOM > 1.1.3 before I upgraded to 2.0.1. > > I create a list of elements of a selected element using: > > List documentVersionElements = > rootElement.getChildren("DocumentVersion", ns); > > I see that I have 6 elements as expected in my list. None are null. > > I am basically then trying to find a matching related element id in > that list using something like: > > Element found = null; > ListIterator iter = documentVersionElements > .listIterator(); > while( iter.hasNext() ) { > Element checkElement = (Element)iter.next(); > EsfUUID evParentId = new > EsfUUID(checkElement.getChildText("documentId", ns)); > if ( evParentId.equals(id) ) { > found = checkElement; > break; > } > } > > Then, assuming I find it (found != null), I process it as expected. > But I then want to remove the found element from the element list so > it cannot be found again, so I use this: > > documentVersionElements.remove(found); > > Most of the time, this seems to work as expected, and the > documentVersionElements list is then shorter by 1. But there are > times when a list of 6 elements remains 6 elements after the remove > (and remove() returns false), with 4 of them now null (not removed, > but actually a null element), so in when I return to the > listIterator() above and get my next() element, the element is null. > > It's as if my Element objects are not unique in the list in terms of > equals/hashCode as my elements should never be nulled out. > > I am not sure why an element I find by iterating cannot then be > removed. How could it fail to remove? Why would it change other list > elements to NULL instead? Is this not a valid usage pattern? > > Thanks, > David > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From david.wall at myeastside.com Fri May 11 18:45:51 2012 From: david.wall at myeastside.com (David Wall) Date: Fri, 11 May 2012 18:45:51 -0700 Subject: [jdom-interest] JDOM 2 list of elements, remove nulls out entries and fails to remove? In-Reply-To: <4FADB984.1050002@tuis.net> References: <4FADB1F7.2010701@myeastside.com> <4FADB984.1050002@tuis.net> Message-ID: <4FADC0CF.8040805@myeastside.com> Thanks, Rolf. No, it's definitely not a threading issue. If you saw my second posting, it all works as expected if I create my own LinkedList from the list returned by getChildren(). If you think it's still a possible issue, I can attached the actual source code and the sample XML data I was parsing. I'm not familiar with JDOM's internals, but if I remove one Element, does that cause a shift for all subsequent elements? I ask this because I am actually creating two lists, one is the main object, and the second is an associated "version" object (the main object can have multiple versions associated with it). In the XML, they are ordered like OBJ, OBJVERSION, OBJ, OBJVERSION, OBJ, OBJVERSION. When I created to the two lists (one of OBJ and the other of OBJVERSION), I noted that as soon as I deleted the OBJ from the first list, the second list already showed a 'null' element at the end of its list. It made me think that the elements are shifting in the live lists from JDOM and thus I'm no longer working on the originally retrieved lists. So, if that's all it is and my usage scenario was bogus before, I'm good since I've changed to create my own lists now. But if you think it could still be an issue, I'm happy to send the code and XML to you (it's open source code anyway). Thanks, David On 5/11/2012 6:14 PM, Rolf Lear wrote: > Hi David. > > This problem you describe is very concerning, and should not, in > 'supported' usage ever happen.... > > I am wracking my brains to figure out what it could be, but, the only > think I can think is that you are accessing the JDOM objects from > different threads.... JDOM is *not* thread safe. > > If this is happening in a single-threaded mechanism, would it be > possible to put together a failing 'test case', any code that shows > the problem? > > I have to admit that I thought he iteration/remove/add/etc. type code > is very well tested, and I would be *very* suprised if there is a > problem like this.... in fact, I know that there are test cases that > cover this basic condition that you describe... and they never fail.... > > so, if you can confirm this is all happening in one thread.... and > preferably if you can put together an example of the problem, I would > look in to it immediately.... > > Rolf > > On 11/05/2012 8:42 PM, David Wall wrote: >> I believe I've run into a problem that I don't think I had with JDOM >> 1.1.3 before I upgraded to 2.0.1. >> >> I create a list of elements of a selected element using: >> >> List documentVersionElements = >> rootElement.getChildren("DocumentVersion", ns); >> >> I see that I have 6 elements as expected in my list. None are null. >> >> I am basically then trying to find a matching related element id in >> that list using something like: >> >> Element found = null; >> ListIterator iter = documentVersionElements >> .listIterator(); >> while( iter.hasNext() ) { >> Element checkElement = (Element)iter.next(); >> EsfUUID evParentId = new >> EsfUUID(checkElement.getChildText("documentId", ns)); >> if ( evParentId.equals(id) ) { >> found = checkElement; >> break; >> } >> } >> >> Then, assuming I find it (found != null), I process it as expected. >> But I then want to remove the found element from the element list so >> it cannot be found again, so I use this: >> >> documentVersionElements.remove(found); >> >> Most of the time, this seems to work as expected, and the >> documentVersionElements list is then shorter by 1. But there are >> times when a list of 6 elements remains 6 elements after the remove >> (and remove() returns false), with 4 of them now null (not removed, >> but actually a null element), so in when I return to the >> listIterator() above and get my next() element, the element is null. >> >> It's as if my Element objects are not unique in the list in terms of >> equals/hashCode as my elements should never be nulled out. >> >> I am not sure why an element I find by iterating cannot then be >> removed. How could it fail to remove? Why would it change other list >> elements to NULL instead? Is this not a valid usage pattern? >> >> Thanks, >> David >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > From jdom at tuis.net Fri May 11 19:02:26 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 11 May 2012 22:02:26 -0400 Subject: [jdom-interest] JDOM 2 list of elements, remove nulls out entries and fails to remove? In-Reply-To: <4FADC0CF.8040805@myeastside.com> References: <4FADB1F7.2010701@myeastside.com> <4FADB984.1050002@tuis.net> <4FADC0CF.8040805@myeastside.com> Message-ID: <4FADC4B2.2040601@tuis.net> Please send the code.... put a comment in it where you think the failure is..... Under no condition should JDOM return a null value... Rolf On 11/05/2012 9:45 PM, David Wall wrote: > Thanks, Rolf. No, it's definitely not a threading issue. If you saw my > second posting, it all works as expected if I create my own > LinkedList from the list returned by getChildren(). > > If you think it's still a possible issue, I can attached the actual > source code and the sample XML data I was parsing. I'm not familiar with > JDOM's internals, but if I remove one Element, does that cause a shift > for all subsequent elements? I ask this because I am actually creating > two lists, one is the main object, and the second is an associated > "version" object (the main object can have multiple versions associated > with it). In the XML, they are ordered like OBJ, OBJVERSION, OBJ, > OBJVERSION, OBJ, OBJVERSION. > > When I created to the two lists (one of OBJ and the other of > OBJVERSION), I noted that as soon as I deleted the OBJ from the first > list, the second list already showed a 'null' element at the end of its > list. It made me think that the elements are shifting in the live lists > from JDOM and thus I'm no longer working on the originally retrieved lists. > > So, if that's all it is and my usage scenario was bogus before, I'm good > since I've changed to create my own lists now. But if you think it could > still be an issue, I'm happy to send the code and XML to you (it's open > source code anyway). > > Thanks, > David > > > On 5/11/2012 6:14 PM, Rolf Lear wrote: >> Hi David. >> >> This problem you describe is very concerning, and should not, in >> 'supported' usage ever happen.... >> >> I am wracking my brains to figure out what it could be, but, the only >> think I can think is that you are accessing the JDOM objects from >> different threads.... JDOM is *not* thread safe. >> >> If this is happening in a single-threaded mechanism, would it be >> possible to put together a failing 'test case', any code that shows >> the problem? >> >> I have to admit that I thought he iteration/remove/add/etc. type code >> is very well tested, and I would be *very* suprised if there is a >> problem like this.... in fact, I know that there are test cases that >> cover this basic condition that you describe... and they never fail.... >> >> so, if you can confirm this is all happening in one thread.... and >> preferably if you can put together an example of the problem, I would >> look in to it immediately.... >> >> Rolf >> >> On 11/05/2012 8:42 PM, David Wall wrote: >>> I believe I've run into a problem that I don't think I had with JDOM >>> 1.1.3 before I upgraded to 2.0.1. >>> >>> I create a list of elements of a selected element using: >>> >>> List documentVersionElements = >>> rootElement.getChildren("DocumentVersion", ns); >>> >>> I see that I have 6 elements as expected in my list. None are null. >>> >>> I am basically then trying to find a matching related element id in >>> that list using something like: >>> >>> Element found = null; >>> ListIterator iter = documentVersionElements .listIterator(); >>> while( iter.hasNext() ) { >>> Element checkElement = (Element)iter.next(); >>> EsfUUID evParentId = new >>> EsfUUID(checkElement.getChildText("documentId", ns)); >>> if ( evParentId.equals(id) ) { >>> found = checkElement; >>> break; >>> } >>> } >>> >>> Then, assuming I find it (found != null), I process it as expected. >>> But I then want to remove the found element from the element list so >>> it cannot be found again, so I use this: >>> >>> documentVersionElements.remove(found); >>> >>> Most of the time, this seems to work as expected, and the >>> documentVersionElements list is then shorter by 1. But there are >>> times when a list of 6 elements remains 6 elements after the remove >>> (and remove() returns false), with 4 of them now null (not removed, >>> but actually a null element), so in when I return to the >>> listIterator() above and get my next() element, the element is null. >>> >>> It's as if my Element objects are not unique in the list in terms of >>> equals/hashCode as my elements should never be nulled out. >>> >>> I am not sure why an element I find by iterating cannot then be >>> removed. How could it fail to remove? Why would it change other list >>> elements to NULL instead? Is this not a valid usage pattern? >>> >>> Thanks, >>> David >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> >> > From jdom at tuis.net Fri May 11 19:47:34 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 11 May 2012 22:47:34 -0400 Subject: [jdom-interest] JDOM 2 list of elements, remove nulls out entries and fails to remove? In-Reply-To: <4FADC81F.9050705@myeastside.com> References: <4FADB1F7.2010701@myeastside.com> <4FADB984.1050002@tuis.net> <4FADC0CF.8040805@myeastside.com> <4FADC4B2.2040601@tuis.net> <4FADC81F.9050705@myeastside.com> Message-ID: <4FADCF46.3080507@tuis.net> Right, I believe I have reproduced it.... Hmmm... still working it. package org.jdom2.test.cases; import static org.junit.Assert.*; import java.util.List; import org.junit.Test; import org.jdom2.Element; @SuppressWarnings("javadoc") public class TestMultipleFilterLists { private static final Element getRoot() { Element root = new Element("root"); root.addContent(new Element("A")); root.addContent(new Element("B")); root.addContent(new Element("C")); root.addContent(new Element("A")); root.addContent(new Element("B")); root.addContent(new Element("C")); root.addContent(new Element("A")); root.addContent(new Element("B")); root.addContent(new Element("C")); root.addContent(new Element("A")); root.addContent(new Element("B")); root.addContent(new Element("C")); return root; } @Test public void testMultiLists() { Element root = getRoot(); List as = root.getChildren("A"); List bs = root.getChildren("B"); List cs = root.getChildren("C"); for (Element f : as) { assertTrue("A".equals(f.getName())); } for (Element f : bs) { assertTrue("B".equals(f.getName())); } for (Element f : cs) { assertTrue("C".equals(f.getName())); } final int bsz = bs.size(); final int csz = cs.size(); while (!as.isEmpty()) { final int sz = as.size() - 1; Element e = as.get(0); as.remove(e); assertTrue(sz == as.size()); assertTrue(bsz == bs.size()); assertTrue(csz == cs.size()); for (Element f : as) { assertTrue("A".equals(f.getName())); } for (Element f : bs) { /****** THROWS NULL POINTER ******/ assertTrue("B".equals(f.getName())); } for (Element f : cs) { assertTrue("C".equals(f.getName())); } } } } Rolf On 11/05/2012 10:17 PM, David Wall wrote: > Okay, > > Attached is the XML I was parsing. In particular, I noted the null > pointer on the elements DropDown and DropDownVersion. There should be a > one-to-one correspondence between these two elements, with the > DropDownVersion containing a dropDownId that links it to the DropDown > element. > > I have also attached the source code file, but it's not a nice test > case. I have a few areas with "JDOM:" comments that are geared for you. > > Thanks, > David > > On 5/11/2012 7:02 PM, Rolf Lear wrote: >> Please send the code.... put a comment in it where you think the >> failure is..... Under no condition should JDOM return a null value... >> >> Rolf >> >> On 11/05/2012 9:45 PM, David Wall wrote: >>> Thanks, Rolf. No, it's definitely not a threading issue. If you saw my >>> second posting, it all works as expected if I create my own >>> LinkedList from the list returned by getChildren(). >>> >>> If you think it's still a possible issue, I can attached the actual >>> source code and the sample XML data I was parsing. I'm not familiar with >>> JDOM's internals, but if I remove one Element, does that cause a shift >>> for all subsequent elements? I ask this because I am actually creating >>> two lists, one is the main object, and the second is an associated >>> "version" object (the main object can have multiple versions associated >>> with it). In the XML, they are ordered like OBJ, OBJVERSION, OBJ, >>> OBJVERSION, OBJ, OBJVERSION. >>> >>> When I created to the two lists (one of OBJ and the other of >>> OBJVERSION), I noted that as soon as I deleted the OBJ from the first >>> list, the second list already showed a 'null' element at the end of its >>> list. It made me think that the elements are shifting in the live lists >>> from JDOM and thus I'm no longer working on the originally retrieved >>> lists. >>> >>> So, if that's all it is and my usage scenario was bogus before, I'm good >>> since I've changed to create my own lists now. But if you think it could >>> still be an issue, I'm happy to send the code and XML to you (it's open >>> source code anyway). >>> >>> Thanks, >>> David >>> >>> >>> On 5/11/2012 6:14 PM, Rolf Lear wrote: >>>> Hi David. >>>> >>>> This problem you describe is very concerning, and should not, in >>>> 'supported' usage ever happen.... >>>> >>>> I am wracking my brains to figure out what it could be, but, the only >>>> think I can think is that you are accessing the JDOM objects from >>>> different threads.... JDOM is *not* thread safe. >>>> >>>> If this is happening in a single-threaded mechanism, would it be >>>> possible to put together a failing 'test case', any code that shows >>>> the problem? >>>> >>>> I have to admit that I thought he iteration/remove/add/etc. type code >>>> is very well tested, and I would be *very* suprised if there is a >>>> problem like this.... in fact, I know that there are test cases that >>>> cover this basic condition that you describe... and they never fail.... >>>> >>>> so, if you can confirm this is all happening in one thread.... and >>>> preferably if you can put together an example of the problem, I would >>>> look in to it immediately.... >>>> >>>> Rolf >>>> >>>> On 11/05/2012 8:42 PM, David Wall wrote: >>>>> I believe I've run into a problem that I don't think I had with JDOM >>>>> 1.1.3 before I upgraded to 2.0.1. >>>>> >>>>> I create a list of elements of a selected element using: >>>>> >>>>> List documentVersionElements = >>>>> rootElement.getChildren("DocumentVersion", ns); >>>>> >>>>> I see that I have 6 elements as expected in my list. None are null. >>>>> >>>>> I am basically then trying to find a matching related element id in >>>>> that list using something like: >>>>> >>>>> Element found = null; >>>>> ListIterator iter = documentVersionElements .listIterator(); >>>>> while( iter.hasNext() ) { >>>>> Element checkElement = (Element)iter.next(); >>>>> EsfUUID evParentId = new >>>>> EsfUUID(checkElement.getChildText("documentId", ns)); >>>>> if ( evParentId.equals(id) ) { >>>>> found = checkElement; >>>>> break; >>>>> } >>>>> } >>>>> >>>>> Then, assuming I find it (found != null), I process it as expected. >>>>> But I then want to remove the found element from the element list so >>>>> it cannot be found again, so I use this: >>>>> >>>>> documentVersionElements.remove(found); >>>>> >>>>> Most of the time, this seems to work as expected, and the >>>>> documentVersionElements list is then shorter by 1. But there are >>>>> times when a list of 6 elements remains 6 elements after the remove >>>>> (and remove() returns false), with 4 of them now null (not removed, >>>>> but actually a null element), so in when I return to the >>>>> listIterator() above and get my next() element, the element is null. >>>>> >>>>> It's as if my Element objects are not unique in the list in terms of >>>>> equals/hashCode as my elements should never be nulled out. >>>>> >>>>> I am not sure why an element I find by iterating cannot then be >>>>> removed. How could it fail to remove? Why would it change other list >>>>> elements to NULL instead? Is this not a valid usage pattern? >>>>> >>>>> Thanks, >>>>> David >>>>> _______________________________________________ >>>>> To control your jdom-interest membership: >>>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>>>> >>>>> >>>> >>> >> From jdom at tuis.net Fri May 11 20:51:26 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 11 May 2012 23:51:26 -0400 Subject: [jdom-interest] JDOM 2 list of elements, remove nulls out entries and fails to remove? In-Reply-To: <4FADCF46.3080507@tuis.net> References: <4FADB1F7.2010701@myeastside.com> <4FADB984.1050002@tuis.net> <4FADC0CF.8040805@myeastside.com> <4FADC4B2.2040601@tuis.net> <4FADC81F.9050705@myeastside.com> <4FADCF46.3080507@tuis.net> Message-ID: <4FADDE3E.3070208@tuis.net> Hi David. The issue is a bug in the remove(...) method. When this method is called it does not update the correct 'modcount' tracking value. As a consequence, any 'FilterList' values you may have (getChildren generates a Filterlist), do not re-synchronize themselves with the main 'live' list, and produce broken values, including nulls... but may include non-null, but still inappropriate values.... I have found & fixed this issue. If you want you can download the fixed jar from github at https://github.com/downloads/hunterhacker/jdom/jdom-2.x-issue81.zip This is a 'hotfix' download.... and it will be 'rolled up' in to JDOM 2.0.2 which will be released before month-end. You can do a drop-in replacement of your JDOM jar with the hotfix one. Rolf On 11/05/2012 10:47 PM, Rolf Lear wrote: > Right, I believe I have reproduced it.... > > Hmmm... still working it. > > > package org.jdom2.test.cases; > > import static org.junit.Assert.*; > import java.util.List; > import org.junit.Test; > import org.jdom2.Element; > > @SuppressWarnings("javadoc") > public class TestMultipleFilterLists { > > private static final Element getRoot() { > Element root = new Element("root"); > root.addContent(new Element("A")); > root.addContent(new Element("B")); > root.addContent(new Element("C")); > root.addContent(new Element("A")); > root.addContent(new Element("B")); > root.addContent(new Element("C")); > root.addContent(new Element("A")); > root.addContent(new Element("B")); > root.addContent(new Element("C")); > root.addContent(new Element("A")); > root.addContent(new Element("B")); > root.addContent(new Element("C")); > return root; > } > > @Test > public void testMultiLists() { > Element root = getRoot(); > List as = root.getChildren("A"); > List bs = root.getChildren("B"); > List cs = root.getChildren("C"); > > for (Element f : as) { > assertTrue("A".equals(f.getName())); > } > for (Element f : bs) { > assertTrue("B".equals(f.getName())); > } > for (Element f : cs) { > assertTrue("C".equals(f.getName())); > } > > final int bsz = bs.size(); > final int csz = cs.size(); > > while (!as.isEmpty()) { > final int sz = as.size() - 1; > Element e = as.get(0); > as.remove(e); > > assertTrue(sz == as.size()); > assertTrue(bsz == bs.size()); > assertTrue(csz == cs.size()); > > for (Element f : as) { > assertTrue("A".equals(f.getName())); > } > for (Element f : bs) { > /****** THROWS NULL POINTER ******/ > assertTrue("B".equals(f.getName())); > } > for (Element f : cs) { > assertTrue("C".equals(f.getName())); > } > } > > > } > > } > > > > Rolf > > > > On 11/05/2012 10:17 PM, David Wall wrote: >> Okay, >> >> Attached is the XML I was parsing. In particular, I noted the null >> pointer on the elements DropDown and DropDownVersion. There should be a >> one-to-one correspondence between these two elements, with the >> DropDownVersion containing a dropDownId that links it to the DropDown >> element. >> >> I have also attached the source code file, but it's not a nice test >> case. I have a few areas with "JDOM:" comments that are geared for you. >> >> Thanks, >> David >> >> On 5/11/2012 7:02 PM, Rolf Lear wrote: >>> Please send the code.... put a comment in it where you think the >>> failure is..... Under no condition should JDOM return a null value... >>> >>> Rolf >>> >>> On 11/05/2012 9:45 PM, David Wall wrote: >>>> Thanks, Rolf. No, it's definitely not a threading issue. If you saw my >>>> second posting, it all works as expected if I create my own >>>> LinkedList from the list returned by getChildren(). >>>> >>>> If you think it's still a possible issue, I can attached the actual >>>> source code and the sample XML data I was parsing. I'm not familiar >>>> with >>>> JDOM's internals, but if I remove one Element, does that cause a shift >>>> for all subsequent elements? I ask this because I am actually creating >>>> two lists, one is the main object, and the second is an associated >>>> "version" object (the main object can have multiple versions associated >>>> with it). In the XML, they are ordered like OBJ, OBJVERSION, OBJ, >>>> OBJVERSION, OBJ, OBJVERSION. >>>> >>>> When I created to the two lists (one of OBJ and the other of >>>> OBJVERSION), I noted that as soon as I deleted the OBJ from the first >>>> list, the second list already showed a 'null' element at the end of its >>>> list. It made me think that the elements are shifting in the live lists >>>> from JDOM and thus I'm no longer working on the originally retrieved >>>> lists. >>>> >>>> So, if that's all it is and my usage scenario was bogus before, I'm >>>> good >>>> since I've changed to create my own lists now. But if you think it >>>> could >>>> still be an issue, I'm happy to send the code and XML to you (it's open >>>> source code anyway). >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> On 5/11/2012 6:14 PM, Rolf Lear wrote: >>>>> Hi David. >>>>> >>>>> This problem you describe is very concerning, and should not, in >>>>> 'supported' usage ever happen.... >>>>> >>>>> I am wracking my brains to figure out what it could be, but, the only >>>>> think I can think is that you are accessing the JDOM objects from >>>>> different threads.... JDOM is *not* thread safe. >>>>> >>>>> If this is happening in a single-threaded mechanism, would it be >>>>> possible to put together a failing 'test case', any code that shows >>>>> the problem? >>>>> >>>>> I have to admit that I thought he iteration/remove/add/etc. type code >>>>> is very well tested, and I would be *very* suprised if there is a >>>>> problem like this.... in fact, I know that there are test cases that >>>>> cover this basic condition that you describe... and they never >>>>> fail.... >>>>> >>>>> so, if you can confirm this is all happening in one thread.... and >>>>> preferably if you can put together an example of the problem, I would >>>>> look in to it immediately.... >>>>> >>>>> Rolf >>>>> >>>>> On 11/05/2012 8:42 PM, David Wall wrote: >>>>>> I believe I've run into a problem that I don't think I had with JDOM >>>>>> 1.1.3 before I upgraded to 2.0.1. >>>>>> >>>>>> I create a list of elements of a selected element using: >>>>>> >>>>>> List documentVersionElements = >>>>>> rootElement.getChildren("DocumentVersion", ns); >>>>>> >>>>>> I see that I have 6 elements as expected in my list. None are null. >>>>>> >>>>>> I am basically then trying to find a matching related element id in >>>>>> that list using something like: >>>>>> >>>>>> Element found = null; >>>>>> ListIterator iter = documentVersionElements .listIterator(); >>>>>> while( iter.hasNext() ) { >>>>>> Element checkElement = (Element)iter.next(); >>>>>> EsfUUID evParentId = new >>>>>> EsfUUID(checkElement.getChildText("documentId", ns)); >>>>>> if ( evParentId.equals(id) ) { >>>>>> found = checkElement; >>>>>> break; >>>>>> } >>>>>> } >>>>>> >>>>>> Then, assuming I find it (found != null), I process it as expected. >>>>>> But I then want to remove the found element from the element list so >>>>>> it cannot be found again, so I use this: >>>>>> >>>>>> documentVersionElements.remove(found); >>>>>> >>>>>> Most of the time, this seems to work as expected, and the >>>>>> documentVersionElements list is then shorter by 1. But there are >>>>>> times when a list of 6 elements remains 6 elements after the remove >>>>>> (and remove() returns false), with 4 of them now null (not removed, >>>>>> but actually a null element), so in when I return to the >>>>>> listIterator() above and get my next() element, the element is null. >>>>>> >>>>>> It's as if my Element objects are not unique in the list in terms of >>>>>> equals/hashCode as my elements should never be nulled out. >>>>>> >>>>>> I am not sure why an element I find by iterating cannot then be >>>>>> removed. How could it fail to remove? Why would it change other list >>>>>> elements to NULL instead? Is this not a valid usage pattern? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> _______________________________________________ >>>>>> To control your jdom-interest membership: >>>>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From david.wall at myeastside.com Fri May 11 21:34:35 2012 From: david.wall at myeastside.com (David Wall) Date: Fri, 11 May 2012 21:34:35 -0700 Subject: [jdom-interest] JDOM 2 list of elements, remove nulls out entries and fails to remove? In-Reply-To: <4FADDE3E.3070208@tuis.net> References: <4FADB1F7.2010701@myeastside.com> <4FADB984.1050002@tuis.net> <4FADC0CF.8040805@myeastside.com> <4FADC4B2.2040601@tuis.net> <4FADC81F.9050705@myeastside.com> <4FADCF46.3080507@tuis.net> <4FADDE3E.3070208@tuis.net> Message-ID: <4FADE85B.50004@myeastside.com> Wow! Thanks, Rolf. That was fast and furious. I'll wait for the 2.0.2 since I have a workaround for now by creating my own list to manipulate. And that may even make more sense because there's really no need in my case to update the JDOM itself when I remove Elements as I process them (which clearly has more housekeeping than just being removed from a list). But thanks for the fix since I'll no doubt need it when manipulating an actual JDOM to produce new XML. On 5/11/2012 8:51 PM, Rolf Lear wrote: > Hi David. > > The issue is a bug in the remove(...) method. When this method is > called it does not update the correct 'modcount' tracking value. > > As a consequence, any 'FilterList' values you may have (getChildren > generates a Filterlist), do not re-synchronize themselves with the > main 'live' list, and produce broken values, including nulls... but > may include non-null, but still inappropriate values.... > > I have found & fixed this issue. If you want you can download the > fixed jar from github at > > https://github.com/downloads/hunterhacker/jdom/jdom-2.x-issue81.zip > > This is a 'hotfix' download.... and it will be 'rolled up' in to JDOM > 2.0.2 which will be released before month-end. You can do a drop-in > replacement of your JDOM jar with the hotfix one. > > Rolf > > On 11/05/2012 10:47 PM, Rolf Lear wrote: >> Right, I believe I have reproduced it.... >> >> Hmmm... still working it. >> >> >> package org.jdom2.test.cases; >> >> import static org.junit.Assert.*; >> import java.util.List; >> import org.junit.Test; >> import org.jdom2.Element; >> >> @SuppressWarnings("javadoc") >> public class TestMultipleFilterLists { >> >> private static final Element getRoot() { >> Element root = new Element("root"); >> root.addContent(new Element("A")); >> root.addContent(new Element("B")); >> root.addContent(new Element("C")); >> root.addContent(new Element("A")); >> root.addContent(new Element("B")); >> root.addContent(new Element("C")); >> root.addContent(new Element("A")); >> root.addContent(new Element("B")); >> root.addContent(new Element("C")); >> root.addContent(new Element("A")); >> root.addContent(new Element("B")); >> root.addContent(new Element("C")); >> return root; >> } >> >> @Test >> public void testMultiLists() { >> Element root = getRoot(); >> List as = root.getChildren("A"); >> List bs = root.getChildren("B"); >> List cs = root.getChildren("C"); >> >> for (Element f : as) { >> assertTrue("A".equals(f.getName())); >> } >> for (Element f : bs) { >> assertTrue("B".equals(f.getName())); >> } >> for (Element f : cs) { >> assertTrue("C".equals(f.getName())); >> } >> >> final int bsz = bs.size(); >> final int csz = cs.size(); >> >> while (!as.isEmpty()) { >> final int sz = as.size() - 1; >> Element e = as.get(0); >> as.remove(e); >> >> assertTrue(sz == as.size()); >> assertTrue(bsz == bs.size()); >> assertTrue(csz == cs.size()); >> >> for (Element f : as) { >> assertTrue("A".equals(f.getName())); >> } >> for (Element f : bs) { >> /****** THROWS NULL POINTER ******/ >> assertTrue("B".equals(f.getName())); >> } >> for (Element f : cs) { >> assertTrue("C".equals(f.getName())); >> } >> } >> >> >> } >> >> } >> >> >> >> Rolf >> >> >> >> On 11/05/2012 10:17 PM, David Wall wrote: >>> Okay, >>> >>> Attached is the XML I was parsing. In particular, I noted the null >>> pointer on the elements DropDown and DropDownVersion. There should be a >>> one-to-one correspondence between these two elements, with the >>> DropDownVersion containing a dropDownId that links it to the DropDown >>> element. >>> >>> I have also attached the source code file, but it's not a nice test >>> case. I have a few areas with "JDOM:" comments that are geared for you. >>> >>> Thanks, >>> David >>> >>> On 5/11/2012 7:02 PM, Rolf Lear wrote: >>>> Please send the code.... put a comment in it where you think the >>>> failure is..... Under no condition should JDOM return a null value... >>>> >>>> Rolf >>>> >>>> On 11/05/2012 9:45 PM, David Wall wrote: >>>>> Thanks, Rolf. No, it's definitely not a threading issue. If you >>>>> saw my >>>>> second posting, it all works as expected if I create my own >>>>> LinkedList from the list returned by getChildren(). >>>>> >>>>> If you think it's still a possible issue, I can attached the actual >>>>> source code and the sample XML data I was parsing. I'm not familiar >>>>> with >>>>> JDOM's internals, but if I remove one Element, does that cause a >>>>> shift >>>>> for all subsequent elements? I ask this because I am actually >>>>> creating >>>>> two lists, one is the main object, and the second is an associated >>>>> "version" object (the main object can have multiple versions >>>>> associated >>>>> with it). In the XML, they are ordered like OBJ, OBJVERSION, OBJ, >>>>> OBJVERSION, OBJ, OBJVERSION. >>>>> >>>>> When I created to the two lists (one of OBJ and the other of >>>>> OBJVERSION), I noted that as soon as I deleted the OBJ from the first >>>>> list, the second list already showed a 'null' element at the end >>>>> of its >>>>> list. It made me think that the elements are shifting in the live >>>>> lists >>>>> from JDOM and thus I'm no longer working on the originally retrieved >>>>> lists. >>>>> >>>>> So, if that's all it is and my usage scenario was bogus before, I'm >>>>> good >>>>> since I've changed to create my own lists now. But if you think it >>>>> could >>>>> still be an issue, I'm happy to send the code and XML to you (it's >>>>> open >>>>> source code anyway). >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> On 5/11/2012 6:14 PM, Rolf Lear wrote: >>>>>> Hi David. >>>>>> >>>>>> This problem you describe is very concerning, and should not, in >>>>>> 'supported' usage ever happen.... >>>>>> >>>>>> I am wracking my brains to figure out what it could be, but, the >>>>>> only >>>>>> think I can think is that you are accessing the JDOM objects from >>>>>> different threads.... JDOM is *not* thread safe. >>>>>> >>>>>> If this is happening in a single-threaded mechanism, would it be >>>>>> possible to put together a failing 'test case', any code that shows >>>>>> the problem? >>>>>> >>>>>> I have to admit that I thought he iteration/remove/add/etc. type >>>>>> code >>>>>> is very well tested, and I would be *very* suprised if there is a >>>>>> problem like this.... in fact, I know that there are test cases that >>>>>> cover this basic condition that you describe... and they never >>>>>> fail.... >>>>>> >>>>>> so, if you can confirm this is all happening in one thread.... and >>>>>> preferably if you can put together an example of the problem, I >>>>>> would >>>>>> look in to it immediately.... >>>>>> >>>>>> Rolf >>>>>> >>>>>> On 11/05/2012 8:42 PM, David Wall wrote: >>>>>>> I believe I've run into a problem that I don't think I had with >>>>>>> JDOM >>>>>>> 1.1.3 before I upgraded to 2.0.1. >>>>>>> >>>>>>> I create a list of elements of a selected element using: >>>>>>> >>>>>>> List documentVersionElements = >>>>>>> rootElement.getChildren("DocumentVersion", ns); >>>>>>> >>>>>>> I see that I have 6 elements as expected in my list. None are null. >>>>>>> >>>>>>> I am basically then trying to find a matching related element id in >>>>>>> that list using something like: >>>>>>> >>>>>>> Element found = null; >>>>>>> ListIterator iter = documentVersionElements .listIterator(); >>>>>>> while( iter.hasNext() ) { >>>>>>> Element checkElement = (Element)iter.next(); >>>>>>> EsfUUID evParentId = new >>>>>>> EsfUUID(checkElement.getChildText("documentId", ns)); >>>>>>> if ( evParentId.equals(id) ) { >>>>>>> found = checkElement; >>>>>>> break; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Then, assuming I find it (found != null), I process it as expected. >>>>>>> But I then want to remove the found element from the element >>>>>>> list so >>>>>>> it cannot be found again, so I use this: >>>>>>> >>>>>>> documentVersionElements.remove(found); >>>>>>> >>>>>>> Most of the time, this seems to work as expected, and the >>>>>>> documentVersionElements list is then shorter by 1. But there are >>>>>>> times when a list of 6 elements remains 6 elements after the remove >>>>>>> (and remove() returns false), with 4 of them now null (not removed, >>>>>>> but actually a null element), so in when I return to the >>>>>>> listIterator() above and get my next() element, the element is >>>>>>> null. >>>>>>> >>>>>>> It's as if my Element objects are not unique in the list in >>>>>>> terms of >>>>>>> equals/hashCode as my elements should never be nulled out. >>>>>>> >>>>>>> I am not sure why an element I find by iterating cannot then be >>>>>>> removed. How could it fail to remove? Why would it change other >>>>>>> list >>>>>>> elements to NULL instead? Is this not a valid usage pattern? >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> _______________________________________________ >>>>>>> To control your jdom-interest membership: >>>>>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > From bashiro at myway.com Sun May 13 04:08:47 2012 From: bashiro at myway.com (Bashiro) Date: Sun, 13 May 2012 07:08:47 -0400 Subject: [jdom-interest] Editing Attributes Message-ID: <20120513070847.29264@web005.roc2.bluetie.com> Hello, I wonder if one has the following in XML file example; Username is unique so its the primary Key. If I want to edit address of say bashiro, I search for bashiro and when found, the address attributes of bashiro is set to the new attributes. My question is; should the whole bashiro be removed and then the new attributes set, or one can simply edit only address ? Bashiro Drammen-Norway From jdom at tuis.net Sun May 13 05:37:48 2012 From: jdom at tuis.net (Rolf Lear) Date: Sun, 13 May 2012 08:37:48 -0400 Subject: [jdom-interest] Editing Attributes In-Reply-To: <20120513070847.29264@web005.roc2.bluetie.com> References: <20120513070847.29264@web005.roc2.bluetie.com> Message-ID: You can simply change the value of the Address attribute. XPathExpression xp = XPathFactory.instance().compile("//contact_properties[@user_name='bashiro']", Filters.element()); Element contactprops = xp.evaluateFirst(document); contactprops.setAttribute("addess", "newaddress"); Technically you can go direct to the Attribute and do it like: XPathExpression xp = XPathFactory.instance().compile("//contact_properties/@address[../@user_name='bashiro']", Filters.attribute()); Attribute address = xp.evaluateFirst(document); address.setValue("newaddress"); Rolf On 13/05/2012 7:08 AM, Bashiro wrote: > Hello, > > I wonder if one has the following in XML file example; > > > > > > Username is unique so its the primary Key. > > If I want to edit address of say bashiro, I search for bashiro and when found, the address attributes of bashiro is set to the > new attributes. > My question is; should the whole bashiro be removed and then the new attributes set, or one can simply edit only address ? > > Bashiro > Drammen-Norway > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From garydgregory at gmail.com Thu May 17 20:21:30 2012 From: garydgregory at gmail.com (Gary Gregory) Date: Thu, 17 May 2012 23:21:30 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x Message-ID: <7099262884711530915@unknownmsgid> Hello JDOM, I cannot use both v2 and v1 in the same Maven or Ivy project because both use the same id in Maven repositories like Maven Central. I want to use v2 in my app but 3rd party jars I use depends on v1. Gary From jdom at tuis.net Fri May 18 03:55:24 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 18 May 2012 06:55:24 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: <7099262884711530915@unknownmsgid> References: <7099262884711530915@unknownmsgid> Message-ID: <4FB62A9C.8060606@tuis.net> Hi Gary. I am not a Maven expert.... and there is not a huge amount of Maven *owner* expertise on this list (we have a number of maven *users*, but not many people who 'publish'). I have learned enough to 'publish' to maven, but I do not even *use* it. As such, our maven 'support' may be broken. But.... this is a limitation of maven.... not the way we deploy it. Can you show us how we should do it differently? For your information though, have you seen these sorts of questions.... ? http://stackoverflow.com/questions/9308366/copy-two-versions-of-same-jar-using-maven Rolf On 17/05/2012 11:21 PM, Gary Gregory wrote: > Hello JDOM, > > I cannot use both v2 and v1 in the same Maven or Ivy project because > both use the same id in Maven repositories like Maven Central. > > I want to use v2 in my app but 3rd party jars I use depends on v1. > > Gary > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From garydgregory at gmail.com Fri May 18 05:29:28 2012 From: garydgregory at gmail.com (Gary Gregory) Date: Fri, 18 May 2012 08:29:28 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: <4FB62A9C.8060606@tuis.net> References: <7099262884711530915@unknownmsgid> <4FB62A9C.8060606@tuis.net> Message-ID: Hi All, For good or bad, I ended learning more than I care about Maven being the release manager for several Apache Commons components. Our rule in Commons is that when you change a package name, you must change the Maven artifact id. My suggestion is to do this in your POM: org.jdom jdom2 2.0.2 Depending on your philosophy, you could also re-publish the Maven artifacts for 2.0.1. But this is usually considered bad form because the POM needs to change and you would then have 2 2.0.1 version with different pom.xml in your sources jar. Gary On Fri, May 18, 2012 at 6:55 AM, Rolf Lear wrote: > Hi Gary. > > I am not a Maven expert.... and there is not a huge amount of Maven > *owner* expertise on this list (we have a number of maven *users*, but not > many people who 'publish'). I have learned enough to 'publish' to maven, > but I do not even *use* it. > > As such, our maven 'support' may be broken. > > But.... this is a limitation of maven.... not the way we deploy it. > > Can you show us how we should do it differently? > > For your information though, have you seen these sorts of questions.... ? > http://stackoverflow.com/**questions/9308366/copy-two-** > versions-of-same-jar-using-**maven > > Rolf > > > On 17/05/2012 11:21 PM, Gary Gregory wrote: > >> Hello JDOM, >> >> I cannot use both v2 and v1 in the same Maven or Ivy project because >> both use the same id in Maven repositories like Maven Central. >> >> I want to use v2 in my app but 3rd party jars I use depends on v1. >> >> Gary >> ______________________________**_________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/**options/jdom-interest/** >> youraddr at yourhost.com >> >> > -- E-Mail: garydgregory at gmail.com | ggregory at apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Fri May 18 07:27:32 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 18 May 2012 10:27:32 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: References: <7099262884711530915@unknownmsgid> <4FB62A9C.8060606@tuis.net> Message-ID: <63e4deed8accc55a5aab172832b4c38f@tuis.net> Where were you for this discussion: http://markmail.org/message/yjojwj26bwrxj5nx#query:+page:1+mid:buwh5fismpdahuoi+state:results ;-) So, the problem is as follows.... Maven imposes naming requirements for artifacts. 'We' decided that this is JDOM 2.0.0, not JDOM2 1.0.0, and also not JDOM2 2.0.0, etc. Thus, the *main* download will be the jar jdom-2.0.0.jar. This means that the maven artifact id *must* be 'jdom', not 'jdom2'. At the time I was not aware how hard/impossible it would be to have both jdom 1.x and 2.x sourced from maven.... Maven is the 'secondary' distribution system for JDOM. The primary JDOM source is from www.jdom.org. The jars downloaded from maven should be identical to the ones from jdom.org. There are about 15k downloads a month from www.jdom.org of 1.x versions of JDOM. There are about 35k downloads a month from maven-central of 1.x versions of JDOM. There are about 10k downloads a month from www.jdom.org of 2.0.x versions of JDOM There are about 1k downloads a month from maven-central of 2.0.x versions of JDOM. The maven downloads show an *opposite* distribution of downloads compared to www.jdom.org: Here are maven's statistics for the three months Feb, Mar, Apr: version,count,% "1.1","92301","0.8971452713012695" "1.1.2","6406","0.062264904379844666" "1.1.3","3425","0.03329024091362953" "2.0.0","716","0.006959361489862204" "2.0.1","35","3.4019225859083235E-4" here's the graph.... http://chart.apis.google.com/chart?cht=p3&chs=400x400&chp=4.71&chco=326A9F|32349F|67329F|9D329F|9F326A&chtt=Downloads+From+Last%203%20Months|For+org.jdom:jdom&chds=0,92301&chd=t:92301,6406,3425,716,35&chdl=1.1|1.1.2|1.1.3|2.0.0|2.0.1 JDOM 1.1 (released 2007) was downloaded 92K times in 3 months. 1.1.2 (released last Aug) downloaded 6.5k times in 3 months. 1.1.3 (released in Feb) just 3.5k times in 3 months Note that Maven does not even have JDOM 1.1.1 (from 2009) ..... So, it shows a distinct 'inertia' in maven users. For all I know they are not even aware that JDOM 2.x has happened.... My guess would be that 90% of maven users do not pay attention to their code.... In a 'short while' I want to be in the position to say: "JDOM 1.x is no longer being maintained". It is not in *my* interests to do it.... it is essentially unchanged since 2007. If people have problems in JDOM 1.x I'm going to want to say "Upgrade to 2.x". I am targeting about December 2012 for that.... What all this rambling boils down to is: 1. I don't want to have to change JDOM's jar file name from jdom-2.0.x.jar to jdom2-x.y.z.jar 2. maven is the 'secondary' distribution system 3. you can ask your 'dependency' code to upgrade to jdom 2.x (they should be doing it anyway). 4. The bell has already been rung on this... I can't un-ring this maven problem. 5. maven users are 'lazy' about keeping in touch with their dependencies, and this will 'prod' them. 6. This is all a maven problem (by design or implementation, I am not sure) 7. maven 'users' (including apache commons) are happy to do their own thing anyway... http://search.maven.org/#search|ga|1|a%3A%22org.apache.servicemix.bundles.jdom%22 8. maven is a PITA ..... :( As you can tell, maven support 'requirement' has not been a happy process.... in hindsight I probably should have just said no .... On the other hand, now that I have the automated build system working, it is not hard to publish to maven, as long as it conforms to JDOM's standards, I'm OK. Now that I have established my 'aversion' to the maven model, can you suggest a way out of this predicament that also conforms to the JDOM 'standard'... ? I promise to consider any suggestions.... Rolf On Fri, 18 May 2012 08:29:28 -0400, Gary Gregory wrote: > Hi All, > > For good or bad, I ended learning more than I care about Maven being the > release manager for several Apache Commons components. > > Our rule in Commons is that when you change a package name, you must change > the Maven artifact id. > > My suggestion is to do this in your POM: > > org.jdom > jdom2 > 2.0.2 > > Depending on your philosophy, you could also re-publish the Maven artifacts > for 2.0.1. But this is usually considered bad form because the POM needs to > change and you would then have 2 2.0.1 version with different pom.xml in > your sources jar. > > Gary > From garydgregory at gmail.com Fri May 18 08:24:11 2012 From: garydgregory at gmail.com (Gary Gregory) Date: Fri, 18 May 2012 11:24:11 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: <63e4deed8accc55a5aab172832b4c38f@tuis.net> References: <7099262884711530915@unknownmsgid> <4FB62A9C.8060606@tuis.net> <63e4deed8accc55a5aab172832b4c38f@tuis.net> Message-ID: Hi Rolf, Thank you for detailed reply. Let me address several points below. I'll probably ramble on too... :) On Fri, May 18, 2012 at 10:27 AM, Rolf Lear wrote: > > Where were you for this discussion: > > http://markmail.org/message/yjojwj26bwrxj5nx#query:+page:1+mid:buwh5fismpdahuoi+state:results > > ;-) > > So, the problem is as follows.... Maven imposes naming requirements for > artifacts. > The problem is not that Maven has to give things names, the issue, IMO, is how does *any* automated build system deal with using multiple versions of the same component. By 'build system' here, I am not talking about just compiling and jaring at the Ant level, I am talking about continuous integration, automatically dealing with pulling down project dependencies (I use Ant + Ivy at work and Maven at Apache.) and publishing the build results up the food chain (I use Ant + Ivy + Bamboo + Artifactory at work, and Maven + Nexus at Apache.) At work (and to a lesser extent at Apache), I deal with multiple product lines with multiple branches, each with their own set of large dependency list. As you can imagine, doing anything build related by hand is not good. So here I am building a large application server and I want update my code to JDOM2. Several of my 3rd party dependencies from various products (some open source, some not) use JDOM1. They each use different versions of JDOM1, luckily, overriding all dependencies to use 1.1.1 has not been a problem. In Ivy, I cannot say this and expect it to work: This works OTOH: If you want to use both commons-lang 2.6 and 3.1 at the same time, you need to pull down both using a different "name" which corresponds to the Maven "artifact Id" This example also shows that the "org" was changed but it is irrelevant to this example. What matters is that you can uniquely identify each artifact. > 'We' decided that this is JDOM 2.0.0, not JDOM2 1.0.0, and also not JDOM2 > 2.0.0, etc. Thus, the *main* download will be the jar jdom-2.0.0.jar. > Great ;) The jar name and project name are your own should not matter. > > This means that the maven artifact id *must* be 'jdom', not 'jdom2'. > I do not think so. Naming the jar and the artifact are separate issues. >From the Ivy POV at least, once an artifact is found, Ivy can download it and rename it on the fly to a custom name pattern (with a version in the jar name or not, it's up to the user) > At the time I was not aware how hard/impossible it would be to have both > jdom 1.x and 2.x sourced from maven.... > That's the joy of serving people who build large complex systems ;) > > Maven is the 'secondary' distribution system for JDOM. The primary JDOM > source is from www.jdom.org. The jars downloaded from maven should be > identical to the ones from jdom.org. > A jar is a jar, it just need to be uniquely identifiable whether it lives in an FTP directory, a Maven or Ivy repository. > > > There are about 15k downloads a month from www.jdom.org of 1.x versions of > JDOM. > There are about 35k downloads a month from maven-central of 1.x versions > of JDOM. > > There are about 10k downloads a month from www.jdom.org of 2.0.x versions > of JDOM > There are about 1k downloads a month from maven-central of 2.0.x versions > of JDOM. > > The maven downloads show an *opposite* distribution of downloads compared > to www.jdom.org: > > Here are maven's statistics for the three months Feb, Mar, Apr: > > version,count,% > "1.1","92301","0.8971452713012695" > "1.1.2","6406","0.062264904379844666" > "1.1.3","3425","0.03329024091362953" > "2.0.0","716","0.006959361489862204" > "2.0.1","35","3.4019225859083235E-4" > > here's the graph.... > > > http://chart.apis.google.com/chart?cht=p3&chs=400x400&chp=4.71&chco=326A9F|32349F|67329F|9D329F|9F326A&chtt=Downloads+From+Last%203%20Months|For+org.jdom:jdom&chds=0,92301&chd=t:92301,6406,3425,716,35&chdl=1.1|1.1.2|1.1.3|2.0.0|2.0.1 > > > JDOM 1.1 (released 2007) was downloaded 92K times in 3 months. > 1.1.2 (released last Aug) downloaded 6.5k times in 3 months. > 1.1.3 (released in Feb) just 3.5k times in 3 months > > Note that Maven does not even have JDOM 1.1.1 (from 2009) ..... > Uh... Who's fault is that? > > So, it shows a distinct 'inertia' in maven users. For all I know they are > not even aware that JDOM 2.x has happened.... My guess would be that 90% of > maven users do not pay attention to their code.... > > In a 'short while' I want to be in the position to say: "JDOM 1.x is no > longer being maintained". It is not in *my* interests to do it.... it is > essentially unchanged since 2007. If people have problems in JDOM 1.x I'm > going to want to say "Upgrade to 2.x". I am targeting about December 2012 > for that.... > > What all this rambling boils down to is: > > 1. I don't want to have to change JDOM's jar file name from jdom-2.0.x.jar > to jdom2-x.y.z.jar > You do not have to do that. You can call the jars whatever you want. > 2. maven is the 'secondary' distribution system > 3. you can ask your 'dependency' code to upgrade to jdom 2.x (they should > be doing it anyway). > This is unrealistic for several reasons. What if a jar using JDOM1 is not longer active? And closed source to boot? There are plenty of scenario where JDOM 1 and 2 need to co-exist. 4. The bell has already been rung on this... I can't un-ring this maven > problem. > This can be addresses in future releases. > 5. maven users are 'lazy' about keeping in touch with their dependencies, > and this will 'prod' them. > What about people who build in Grail, Buildr, Groovy and Scala? > 6. This is all a maven problem (by design or implementation, I am not > sure) > Au contraire, this is not a Maven problem. This is a generic issue as I described above when building large systems automatically with complex dependencies. 7. maven 'users' (including apache commons) are happy to do their own > thing anyway... > True of any user on any build system. > > http://search.maven.org/#search|ga|1|a%3A%22org.apache.servicemix.bundles.jdom%22 > 8. maven is a PITA ..... :( > True of any build on any build system once it gets large and complex enough. > > As you can tell, maven support 'requirement' has not been a happy > process.... in hindsight I probably should have just said no .... On the > other hand, now that I have the automated build system working, it is not > hard to publish to maven, as long as it conforms to JDOM's standards, I'm > OK. > > Now that I have established my 'aversion' to the maven model, can you > suggest a way out of this predicament that also conforms to the JDOM > 'standard'... ? I promise to consider any suggestions.... > I suggest that you publish JDOM2 under the jdom2 artifact id to match the package name. You can call the jar whatever you want. Thank you for reading this far! Gary > Rolf > > > > On Fri, 18 May 2012 08:29:28 -0400, Gary Gregory > wrote: > > Hi All, > > > > For good or bad, I ended learning more than I care about Maven being the > > release manager for several Apache Commons components. > > > > Our rule in Commons is that when you change a package name, you must > change > > the Maven artifact id. > > > > My suggestion is to do this in your POM: > > > > org.jdom > > jdom2 > > 2.0.2 > > > > Depending on your philosophy, you could also re-publish the Maven > artifacts > > for 2.0.1. But this is usually considered bad form because the POM needs > to > > change and you would then have 2 2.0.1 version with different pom.xml in > > your sources jar. > > > > Gary > > > > -- E-Mail: garydgregory at gmail.com | ggregory at apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcox at virtualschool.edu Fri May 18 09:04:57 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Fri, 18 May 2012 12:04:57 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: References: <7099262884711530915@unknownmsgid> <4FB62A9C.8060606@tuis.net> <63e4deed8accc55a5aab172832b4c38f@tuis.net> Message-ID: To add fuel to this fire... I stopped using JDOM 1.x altogether when it wasn't available on maven (awhile back) and started again only when JDOM 2.x became available on maven. The "alternative" distro argument doesn't persuade; its just too much a PITA to adjust to each and every developer's idiosyncratic objections to a well-established model, regardless of its deficiencies. Its far easier to adjust to the idiosyncacies of the many DOM alternatives that ARE available on maven. My main interest is SIMPLIFYING my life in this overly-complex world, and maven is the only tool that does that for me. I'd go back to W3C DOM if that were the only way to achieve it, as much as I detest working with that. On Fri, May 18, 2012 at 11:24 AM, Gary Gregory wrote: > Hi Rolf, > > Thank you for detailed reply. Let me address several points below. I'll > probably ramble on too... :) > > On Fri, May 18, 2012 at 10:27 AM, Rolf Lear wrote: > >> >> Where were you for this discussion: >> >> http://markmail.org/message/yjojwj26bwrxj5nx#query:+page:1+mid:buwh5fismpdahuoi+state:results >> >> ;-) >> >> So, the problem is as follows.... Maven imposes naming requirements for >> artifacts. >> > > The problem is not that Maven has to give things names, the issue, IMO, is > how does *any* automated build system deal with using multiple versions of > the same component. > > By 'build system' here, I am not talking about just compiling and jaring > at the Ant level, I am talking about continuous integration, automatically > dealing with pulling down project dependencies (I use Ant + Ivy at work and > Maven at Apache.) and publishing the build results up the food chain (I use > Ant + Ivy + Bamboo + Artifactory at work, and Maven + Nexus at Apache.) > > At work (and to a lesser extent at Apache), I deal with multiple product > lines with multiple branches, each with their own set of large dependency > list. > > As you can imagine, doing anything build related by hand is not good. > > So here I am building a large application server and I want update my code > to JDOM2. Several of my 3rd party dependencies from various products (some > open source, some not) use JDOM1. They each use different versions of > JDOM1, luckily, overriding all dependencies to use 1.1.1 has not been a > problem. > > In Ivy, I cannot say this and expect it to work: > > > > > This works OTOH: > > rev="2.6" /> > conf="blah,blah" rev="3.1" /> > > If you want to use both commons-lang 2.6 and 3.1 at the same time, you > need to pull down both using a different "name" which corresponds to the > Maven "artifact Id" > > This example also shows that the "org" was changed but it is irrelevant to > this example. What matters is that you can uniquely identify each artifact. > > >> 'We' decided that this is JDOM 2.0.0, not JDOM2 1.0.0, and also not JDOM2 >> 2.0.0, etc. Thus, the *main* download will be the jar jdom-2.0.0.jar. >> > > Great ;) The jar name and project name are your own should not matter. > > >> >> This means that the maven artifact id *must* be 'jdom', not 'jdom2'. >> > > I do not think so. Naming the jar and the artifact are separate issues. > > From the Ivy POV at least, once an artifact is found, Ivy can download it > and rename it on the fly to a custom name pattern (with a version in the > jar name or not, it's up to the user) > > >> At the time I was not aware how hard/impossible it would be to have both >> jdom 1.x and 2.x sourced from maven.... >> > > That's the joy of serving people who build large complex systems ;) > > >> >> Maven is the 'secondary' distribution system for JDOM. The primary JDOM >> source is from www.jdom.org. The jars downloaded from maven should be >> identical to the ones from jdom.org. >> > > A jar is a jar, it just need to be uniquely identifiable whether it lives > in an FTP directory, a Maven or Ivy repository. > > >> >> >> There are about 15k downloads a month from www.jdom.org of 1.x versions >> of >> JDOM. >> There are about 35k downloads a month from maven-central of 1.x versions >> of JDOM. >> >> There are about 10k downloads a month from www.jdom.org of 2.0.x versions >> of JDOM >> There are about 1k downloads a month from maven-central of 2.0.x versions >> of JDOM. >> >> The maven downloads show an *opposite* distribution of downloads compared >> to www.jdom.org: >> >> Here are maven's statistics for the three months Feb, Mar, Apr: >> >> version,count,% >> "1.1","92301","0.8971452713012695" >> "1.1.2","6406","0.062264904379844666" >> "1.1.3","3425","0.03329024091362953" >> "2.0.0","716","0.006959361489862204" >> "2.0.1","35","3.4019225859083235E-4" >> >> here's the graph.... >> >> >> http://chart.apis.google.com/chart?cht=p3&chs=400x400&chp=4.71&chco=326A9F|32349F|67329F|9D329F|9F326A&chtt=Downloads+From+Last%203%20Months|For+org.jdom:jdom&chds=0,92301&chd=t:92301,6406,3425,716,35&chdl=1.1|1.1.2|1.1.3|2.0.0|2.0.1 >> >> >> JDOM 1.1 (released 2007) was downloaded 92K times in 3 months. >> 1.1.2 (released last Aug) downloaded 6.5k times in 3 months. >> 1.1.3 (released in Feb) just 3.5k times in 3 months >> >> Note that Maven does not even have JDOM 1.1.1 (from 2009) ..... >> > > Uh... Who's fault is that? > > >> >> So, it shows a distinct 'inertia' in maven users. For all I know they are >> not even aware that JDOM 2.x has happened.... My guess would be that 90% >> of >> maven users do not pay attention to their code.... >> >> In a 'short while' I want to be in the position to say: "JDOM 1.x is no >> longer being maintained". It is not in *my* interests to do it.... it is >> essentially unchanged since 2007. If people have problems in JDOM 1.x I'm >> going to want to say "Upgrade to 2.x". I am targeting about December 2012 >> for that.... >> >> What all this rambling boils down to is: >> >> 1. I don't want to have to change JDOM's jar file name from jdom-2.0.x.jar >> to jdom2-x.y.z.jar >> > > You do not have to do that. You can call the jars whatever you want. > > >> 2. maven is the 'secondary' distribution system >> > 3. you can ask your 'dependency' code to upgrade to jdom 2.x (they should >> be doing it anyway). >> > > This is unrealistic for several reasons. > What if a jar using JDOM1 is not longer active? > And closed source to boot? > There are plenty of scenario where JDOM 1 and 2 need to co-exist. > > 4. The bell has already been rung on this... I can't un-ring this maven >> problem. >> > > This can be addresses in future releases. > > >> 5. maven users are 'lazy' about keeping in touch with their dependencies, >> and this will 'prod' them. >> > > What about people who build in Grail, Buildr, Groovy and Scala? > > >> 6. This is all a maven problem (by design or implementation, I am not >> sure) >> > > Au contraire, this is not a Maven problem. This is a generic issue as I > described above when building large systems automatically with complex > dependencies. > > 7. maven 'users' (including apache commons) are happy to do their own >> thing anyway... >> > > True of any user on any build system. > > >> >> http://search.maven.org/#search|ga|1|a%3A%22org.apache.servicemix.bundles.jdom%22 >> 8. maven is a PITA ..... :( >> > > True of any build on any build system once it gets large and complex > enough. > > >> >> As you can tell, maven support 'requirement' has not been a happy >> process.... in hindsight I probably should have just said no .... On the >> other hand, now that I have the automated build system working, it is not >> hard to publish to maven, as long as it conforms to JDOM's standards, I'm >> OK. >> >> Now that I have established my 'aversion' to the maven model, can you >> suggest a way out of this predicament that also conforms to the JDOM >> 'standard'... ? I promise to consider any suggestions.... >> > > I suggest that you publish JDOM2 under the jdom2 artifact id to match the > package name. You can call the jar whatever you want. > > Thank you for reading this far! > > Gary > > >> Rolf >> >> >> >> On Fri, 18 May 2012 08:29:28 -0400, Gary Gregory >> wrote: >> > Hi All, >> > >> > For good or bad, I ended learning more than I care about Maven being the >> > release manager for several Apache Commons components. >> > >> > Our rule in Commons is that when you change a package name, you must >> change >> > the Maven artifact id. >> > >> > My suggestion is to do this in your POM: >> > >> > org.jdom >> > jdom2 >> > 2.0.2 >> > >> > Depending on your philosophy, you could also re-publish the Maven >> artifacts >> > for 2.0.1. But this is usually considered bad form because the POM needs >> to >> > change and you would then have 2 2.0.1 version with different pom.xml in >> > your sources jar. >> > >> > Gary >> > >> >> > > > -- > E-Mail: garydgregory at gmail.com | ggregory at apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Fri May 18 10:30:37 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 18 May 2012 13:30:37 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: References: <7099262884711530915@unknownmsgid> <4FB62A9C.8060606@tuis.net> <63e4deed8accc55a5aab172832b4c38f@tuis.net> Message-ID: <2f1597bc7d9346b8e9e985d5ec7f9d21@tuis.net> So, a general comment, and four questions.... The inability of maven to accommodate the flexibility of 'real life' development in an automated way is not the fault of JDOM. The very fact that I have spent so much time already 'dealing' with maven indicates that it has something fundamentally wrong with its design/model. I get the impression that Maven developers expect the world to conform to them, rather than tolerating the heterogeneous we live in. It is "everyone else's fault" if things don't work the maven way..... 1. you say that the artifact does not need to be the same as the 'base name' of the jar, yet everything i have read suggests it does need to be the same: http://maven.apache.org/maven-conventions.html Further, while I have no record of it, I recall that when I tried to upload maven bundles to sonatype, the jar name has to be of the specific form --.jar, If your artifact is abc123 and the version is 1.2.3 then it expects abc123-1.2.3.jar, abc123-1.2.3-sources.jar, abc123-1.2.3-javadocs.jar, etc. When I get home I can try something different to double-check, but i am pretty certain.... If maven were actually 'easy' to work with, there should be an easy way for anyone to actually try that.... is there a way? 2. If it is possible to load jdom-2.0.2.jar in to the jdom2 artifact, I will consider it... but what about people who are already pulling 2.0.0 and 2.0.1 from the jdom artifact? How will they know to 'move' if their dependencies are not going to move with the artifact....? If I can keep the jdom-2.0.x.jar, I would also consider deploying to *both* jdom2 and jdom artifacts.... 3. How do I 'notify' the 30k people a month using 1.1 that they should upgrade/change their artifact to jdom2? 4. Maven provides no way to 'test' something... (at least not with the simple 'bundle' upload). How do I do a 'dry run'? I have already got the JDOM beta's in the jdom2 artifact because I needed to get some 'practice' in..... Frankly, I would rather be spending my time building 'fun' things than untangling this mess.... Rolf On Fri, 18 May 2012 11:24:11 -0400, Gary Gregory wrote: > Hi Rolf, > > Thank you for detailed reply. Let me address several points below. I'll > probably ramble on too... :) > > On Fri, May 18, 2012 at 10:27 AM, Rolf Lear wrote: > >> >> Where were you for this discussion: >> >> http://markmail.org/message/yjojwj26bwrxj5nx#query:+page:1+mid:buwh5fismpdahuoi+state:results >> >> ;-) >> >> So, the problem is as follows.... Maven imposes naming requirements for >> artifacts. >> > > The problem is not that Maven has to give things names, the issue, IMO, is > how does *any* automated build system deal with using multiple versions of > the same component. > > By 'build system' here, I am not talking about just compiling and jaring at > the Ant level, I am talking about continuous integration, automatically > dealing with pulling down project dependencies (I use Ant + Ivy at work and > Maven at Apache.) and publishing the build results up the food chain (I use > Ant + Ivy + Bamboo + Artifactory at work, and Maven + Nexus at Apache.) > > At work (and to a lesser extent at Apache), I deal with multiple product > lines with multiple branches, each with their own set of large dependency > list. > > As you can imagine, doing anything build related by hand is not good. > > So here I am building a large application server and I want update my code > to JDOM2. Several of my 3rd party dependencies from various products (some > open source, some not) use JDOM1. They each use different versions of > JDOM1, luckily, overriding all dependencies to use 1.1.1 has not been a > problem. > > In Ivy, I cannot say this and expect it to work: > > > > > This works OTOH: > > rev="2.6" /> > conf="blah,blah" rev="3.1" /> > > If you want to use both commons-lang 2.6 and 3.1 at the same time, you need > to pull down both using a different "name" which corresponds to the Maven > "artifact Id" > > This example also shows that the "org" was changed but it is irrelevant to > this example. What matters is that you can uniquely identify each artifact. > > >> 'We' decided that this is JDOM 2.0.0, not JDOM2 1.0.0, and also not JDOM2 >> 2.0.0, etc. Thus, the *main* download will be the jar jdom-2.0.0.jar. >> > > Great ;) The jar name and project name are your own should not matter. > > >> >> This means that the maven artifact id *must* be 'jdom', not 'jdom2'. >> > > I do not think so. Naming the jar and the artifact are separate issues. > > From the Ivy POV at least, once an artifact is found, Ivy can download it > and rename it on the fly to a custom name pattern (with a version in the > jar name or not, it's up to the user) > > >> At the time I was not aware how hard/impossible it would be to have both >> jdom 1.x and 2.x sourced from maven.... >> > > That's the joy of serving people who build large complex systems ;) > > >> >> Maven is the 'secondary' distribution system for JDOM. The primary JDOM >> source is from www.jdom.org. The jars downloaded from maven should be >> identical to the ones from jdom.org. >> > > A jar is a jar, it just need to be uniquely identifiable whether it lives > in an FTP directory, a Maven or Ivy repository. > > >> >> >> There are about 15k downloads a month from www.jdom.org of 1.x versions >> of >> JDOM. >> There are about 35k downloads a month from maven-central of 1.x versions >> of JDOM. >> >> There are about 10k downloads a month from www.jdom.org of 2.0.x versions >> of JDOM >> There are about 1k downloads a month from maven-central of 2.0.x versions >> of JDOM. >> >> The maven downloads show an *opposite* distribution of downloads compared >> to www.jdom.org: >> >> Here are maven's statistics for the three months Feb, Mar, Apr: >> >> version,count,% >> "1.1","92301","0.8971452713012695" >> "1.1.2","6406","0.062264904379844666" >> "1.1.3","3425","0.03329024091362953" >> "2.0.0","716","0.006959361489862204" >> "2.0.1","35","3.4019225859083235E-4" >> >> here's the graph.... >> >> >> http://chart.apis.google.com/chart?cht=p3&chs=400x400&chp=4.71&chco=326A9F|32349F|67329F|9D329F|9F326A&chtt=Downloads+From+Last%203%20Months|For+org.jdom:jdom&chds=0,92301&chd=t:92301,6406,3425,716,35&chdl=1.1|1.1.2|1.1.3|2.0.0|2.0.1 >> >> >> JDOM 1.1 (released 2007) was downloaded 92K times in 3 months. >> 1.1.2 (released last Aug) downloaded 6.5k times in 3 months. >> 1.1.3 (released in Feb) just 3.5k times in 3 months >> >> Note that Maven does not even have JDOM 1.1.1 (from 2009) ..... >> > > Uh... Who's fault is that? > > >> >> So, it shows a distinct 'inertia' in maven users. For all I know they are >> not even aware that JDOM 2.x has happened.... My guess would be that 90% >> of >> maven users do not pay attention to their code.... >> >> In a 'short while' I want to be in the position to say: "JDOM 1.x is no >> longer being maintained". It is not in *my* interests to do it.... it is >> essentially unchanged since 2007. If people have problems in JDOM 1.x I'm >> going to want to say "Upgrade to 2.x". I am targeting about December 2012 >> for that.... >> >> What all this rambling boils down to is: >> >> 1. I don't want to have to change JDOM's jar file name from >> jdom-2.0.x.jar >> to jdom2-x.y.z.jar >> > > You do not have to do that. You can call the jars whatever you want. > > >> 2. maven is the 'secondary' distribution system >> > 3. you can ask your 'dependency' code to upgrade to jdom 2.x (they should >> be doing it anyway). >> > > This is unrealistic for several reasons. > What if a jar using JDOM1 is not longer active? > And closed source to boot? > There are plenty of scenario where JDOM 1 and 2 need to co-exist. > > 4. The bell has already been rung on this... I can't un-ring this maven >> problem. >> > > This can be addresses in future releases. > > >> 5. maven users are 'lazy' about keeping in touch with their dependencies, >> and this will 'prod' them. >> > > What about people who build in Grail, Buildr, Groovy and Scala? > > >> 6. This is all a maven problem (by design or implementation, I am not >> sure) >> > > Au contraire, this is not a Maven problem. This is a generic issue as I > described above when building large systems automatically with complex > dependencies. > > 7. maven 'users' (including apache commons) are happy to do their own >> thing anyway... >> > > True of any user on any build system. > > >> >> http://search.maven.org/#search|ga|1|a%3A%22org.apache.servicemix.bundles.jdom%22 >> 8. maven is a PITA ..... :( >> > > True of any build on any build system once it gets large and complex > enough. > > >> >> As you can tell, maven support 'requirement' has not been a happy >> process.... in hindsight I probably should have just said no .... On the >> other hand, now that I have the automated build system working, it is not >> hard to publish to maven, as long as it conforms to JDOM's standards, I'm >> OK. >> >> Now that I have established my 'aversion' to the maven model, can you >> suggest a way out of this predicament that also conforms to the JDOM >> 'standard'... ? I promise to consider any suggestions.... >> > > I suggest that you publish JDOM2 under the jdom2 artifact id to match the > package name. You can call the jar whatever you want. > > Thank you for reading this far! > > Gary > > >> Rolf >> From jdom at tuis.net Fri May 18 10:53:32 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 18 May 2012 13:53:32 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: References: Message-ID: <05a323c88ebfb65df661b8bcc1837d8e@tuis.net> No, the problem is not like that, it won't affect the stats. What *could* be possible is that people have not moved to 2.x because they have compile dependencies from components that *require* 1.1, and thus they need 1.1 too.... Remember, they did not move from 1.1 to 1.1.2 and 1.1.3 either. I think the stats are a fair representation of the 'demand' for JDOM, but that people set up their maven systems 'a long time ago' and they are on 'auto pilot' so they are not aware of the bug fixes, performance gains, etc that are in 1.1.2, 1.1.3, and 2.0.x. Also, I think the 'automated' systems that download from maven are overestimating the number of maven downloads when compared to the www.jdom.org site. I would guess that a lot of the 30k downloads a month are from a few people who have badly configured build environments that just download JDOM multiple times a day..... thus inflating the doanload numbers. My guess would be that the 'big' users of JDOM download the zip file once, and install it in to their 'build' process, and then never touch it again until the next version is out. I know that we do that where I work, and thus we have just 1 donload hit for many many thousands of builds, developers, versions, etc. On the other hand, a poorly configured maven 'shop' will likely have one download per developer, per 'clean' build, per day.... Rolf On Fri, 18 May 2012 09:21:28 -0700, Joe Bowbeer wrote: > If there is a problem with the way jdom2 was published to maven, this might > affect your stats? > From bcox at virtualschool.edu Fri May 18 11:06:44 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Fri, 18 May 2012 14:06:44 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: <2f1597bc7d9346b8e9e985d5ec7f9d21@tuis.net> References: <7099262884711530915@unknownmsgid> <4FB62A9C.8060606@tuis.net> <63e4deed8accc55a5aab172832b4c38f@tuis.net> <2f1597bc7d9346b8e9e985d5ec7f9d21@tuis.net> Message-ID: The maven dox are clear about its adherence to "convention over configuration", which is the very thing I found compelling after my own bout of grumbling over its noncompliance with *my* conventions (src/main/java indeed when src should be enough, sez' I). That said, it provide way to override almost anything, although that's usually painful enough that its best avoided. Think of it this way. For the problems I work on, JDOM is a very small tree in a very large forest of jars that must work together. I need it to fit in to that forest and "just work" without having to think about your reasons for wanting (or needing) your own set of conventions. Regardless of its (many) flaws, maven projects generally more or less deliver on that promise. Outlier conventions create problems for me and I avoid packages that create problems. On Fri, May 18, 2012 at 1:30 PM, Rolf Lear wrote: > > So, a general comment, and four questions.... > > The inability of maven to accommodate the flexibility of 'real life' > development in an automated way is not the fault of JDOM. The very fact > that I have spent so much time already 'dealing' with maven indicates that > it has something fundamentally wrong with its design/model. I get the > impression that Maven developers expect the world to conform to them, > rather than tolerating the heterogeneous we live in. It is "everyone else's > fault" if things don't work the maven way..... > > 1. you say that the artifact does not need to be the same as the 'base > name' of the jar, yet everything i have read suggests it does need to be > the same: http://maven.apache.org/maven-conventions.html Further, while I > have no record of it, I recall that when I tried to upload maven bundles to > sonatype, the jar name has to be of the specific form > --.jar, If your artifact is abc123 and the > version is 1.2.3 then it expects abc123-1.2.3.jar, > abc123-1.2.3-sources.jar, abc123-1.2.3-javadocs.jar, etc. When I get home I > can try something different to double-check, but i am pretty certain.... If > maven were actually 'easy' to work with, there should be an easy way for > anyone to actually try that.... is there a way? > > 2. If it is possible to load jdom-2.0.2.jar in to the jdom2 artifact, I > will consider it... but what about people who are already pulling 2.0.0 and > 2.0.1 from the jdom artifact? How will they know to 'move' if their > dependencies are not going to move with the artifact....? If I can keep the > jdom-2.0.x.jar, I would also consider deploying to *both* jdom2 and jdom > artifacts.... > > 3. How do I 'notify' the 30k people a month using 1.1 that they should > upgrade/change their artifact to jdom2? > > 4. Maven provides no way to 'test' something... (at least not with the > simple 'bundle' upload). How do I do a 'dry run'? I have already got the > JDOM beta's in the jdom2 artifact because I needed to get some 'practice' > in..... > > Frankly, I would rather be spending my time building 'fun' things than > untangling this mess.... > > Rolf > > On Fri, 18 May 2012 11:24:11 -0400, Gary Gregory > wrote: > > Hi Rolf, > > > > Thank you for detailed reply. Let me address several points below. I'll > > probably ramble on too... :) > > > > On Fri, May 18, 2012 at 10:27 AM, Rolf Lear wrote: > > > >> > >> Where were you for this discussion: > >> > >> > > http://markmail.org/message/yjojwj26bwrxj5nx#query:+page:1+mid:buwh5fismpdahuoi+state:results > >> > >> ;-) > >> > >> So, the problem is as follows.... Maven imposes naming requirements for > >> artifacts. > >> > > > > The problem is not that Maven has to give things names, the issue, IMO, > is > > how does *any* automated build system deal with using multiple versions > of > > the same component. > > > > By 'build system' here, I am not talking about just compiling and jaring > at > > the Ant level, I am talking about continuous integration, automatically > > dealing with pulling down project dependencies (I use Ant + Ivy at work > and > > Maven at Apache.) and publishing the build results up the food chain (I > use > > Ant + Ivy + Bamboo + Artifactory at work, and Maven + Nexus at Apache.) > > > > At work (and to a lesser extent at Apache), I deal with multiple product > > lines with multiple branches, each with their own set of large > dependency > > list. > > > > As you can imagine, doing anything build related by hand is not good. > > > > So here I am building a large application server and I want update my > code > > to JDOM2. Several of my 3rd party dependencies from various products > (some > > open source, some not) use JDOM1. They each use different versions of > > JDOM1, luckily, overriding all dependencies to use 1.1.1 has not been a > > problem. > > > > In Ivy, I cannot say this and expect it to work: > > > > /> > > /> > > > > This works OTOH: > > > > > rev="2.6" /> > > > conf="blah,blah" rev="3.1" /> > > > > If you want to use both commons-lang 2.6 and 3.1 at the same time, you > need > > to pull down both using a different "name" which corresponds to the > Maven > > "artifact Id" > > > > This example also shows that the "org" was changed but it is irrelevant > to > > this example. What matters is that you can uniquely identify each > artifact. > > > > > >> 'We' decided that this is JDOM 2.0.0, not JDOM2 1.0.0, and also not > JDOM2 > >> 2.0.0, etc. Thus, the *main* download will be the jar jdom-2.0.0.jar. > >> > > > > Great ;) The jar name and project name are your own should not matter. > > > > > >> > >> This means that the maven artifact id *must* be 'jdom', not 'jdom2'. > >> > > > > I do not think so. Naming the jar and the artifact are separate issues. > > > > From the Ivy POV at least, once an artifact is found, Ivy can download > it > > and rename it on the fly to a custom name pattern (with a version in the > > jar name or not, it's up to the user) > > > > > >> At the time I was not aware how hard/impossible it would be to have > both > >> jdom 1.x and 2.x sourced from maven.... > >> > > > > That's the joy of serving people who build large complex systems ;) > > > > > >> > >> Maven is the 'secondary' distribution system for JDOM. The primary JDOM > >> source is from www.jdom.org. The jars downloaded from maven should be > >> identical to the ones from jdom.org. > >> > > > > A jar is a jar, it just need to be uniquely identifiable whether it > lives > > in an FTP directory, a Maven or Ivy repository. > > > > > >> > >> > >> There are about 15k downloads a month from www.jdom.org of 1.x versions > >> of > >> JDOM. > >> There are about 35k downloads a month from maven-central of 1.x > versions > >> of JDOM. > >> > >> There are about 10k downloads a month from www.jdom.org of 2.0.x > versions > >> of JDOM > >> There are about 1k downloads a month from maven-central of 2.0.x > versions > >> of JDOM. > >> > >> The maven downloads show an *opposite* distribution of downloads > compared > >> to www.jdom.org: > >> > >> Here are maven's statistics for the three months Feb, Mar, Apr: > >> > >> version,count,% > >> "1.1","92301","0.8971452713012695" > >> "1.1.2","6406","0.062264904379844666" > >> "1.1.3","3425","0.03329024091362953" > >> "2.0.0","716","0.006959361489862204" > >> "2.0.1","35","3.4019225859083235E-4" > >> > >> here's the graph.... > >> > >> > >> > > http://chart.apis.google.com/chart?cht=p3&chs=400x400&chp=4.71&chco=326A9F|32349F|67329F|9D329F|9F326A&chtt=Downloads+From+Last%203%20Months|For+org.jdom:jdom&chds=0,92301&chd=t:92301,6406,3425,716,35&chdl=1.1|1.1.2|1.1.3|2.0.0|2.0.1 > < > http://chart.apis.google.com/chart?cht=p3&chs=400x400&chp=4.71&chco=326A9F%7C32349F%7C67329F%7C9D329F%7C9F326A&chtt=Downloads+From+Last%203%20Months%7CFor+org.jdom:jdom&chds=0,92301&chd=t:92301,6406,3425,716,35&chdl=1.1%7C1.1.2%7C1.1.3%7C2.0.0%7C2.0.1 > > > >> > >> > >> JDOM 1.1 (released 2007) was downloaded 92K times in 3 months. > >> 1.1.2 (released last Aug) downloaded 6.5k times in 3 months. > >> 1.1.3 (released in Feb) just 3.5k times in 3 months > >> > >> Note that Maven does not even have JDOM 1.1.1 (from 2009) ..... > >> > > > > Uh... Who's fault is that? > > > > > >> > >> So, it shows a distinct 'inertia' in maven users. For all I know they > are > >> not even aware that JDOM 2.x has happened.... My guess would be that > 90% > >> of > >> maven users do not pay attention to their code.... > >> > >> In a 'short while' I want to be in the position to say: "JDOM 1.x is no > >> longer being maintained". It is not in *my* interests to do it.... it > is > >> essentially unchanged since 2007. If people have problems in JDOM 1.x > I'm > >> going to want to say "Upgrade to 2.x". I am targeting about December > 2012 > >> for that.... > >> > >> What all this rambling boils down to is: > >> > >> 1. I don't want to have to change JDOM's jar file name from > >> jdom-2.0.x.jar > >> to jdom2-x.y.z.jar > >> > > > > You do not have to do that. You can call the jars whatever you want. > > > > > >> 2. maven is the 'secondary' distribution system > >> > > 3. you can ask your 'dependency' code to upgrade to jdom 2.x (they > should > >> be doing it anyway). > >> > > > > This is unrealistic for several reasons. > > What if a jar using JDOM1 is not longer active? > > And closed source to boot? > > There are plenty of scenario where JDOM 1 and 2 need to co-exist. > > > > 4. The bell has already been rung on this... I can't un-ring this maven > >> problem. > >> > > > > This can be addresses in future releases. > > > > > >> 5. maven users are 'lazy' about keeping in touch with their > dependencies, > >> and this will 'prod' them. > >> > > > > What about people who build in Grail, Buildr, Groovy and Scala? > > > > > >> 6. This is all a maven problem (by design or implementation, I am not > >> sure) > >> > > > > Au contraire, this is not a Maven problem. This is a generic issue as I > > described above when building large systems automatically with complex > > dependencies. > > > > 7. maven 'users' (including apache commons) are happy to do their own > >> thing anyway... > >> > > > > True of any user on any build system. > > > > > >> > >> > > http://search.maven.org/#search|ga|1|a%3A%22org.apache.servicemix.bundles.jdom%22 > < > http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22org.apache.servicemix.bundles.jdom%22 > > > >> 8. maven is a PITA ..... :( > >> > > > > True of any build on any build system once it gets large and complex > > enough. > > > > > >> > >> As you can tell, maven support 'requirement' has not been a happy > >> process.... in hindsight I probably should have just said no .... On > the > >> other hand, now that I have the automated build system working, it is > not > >> hard to publish to maven, as long as it conforms to JDOM's standards, > I'm > >> OK. > >> > >> Now that I have established my 'aversion' to the maven model, can you > >> suggest a way out of this predicament that also conforms to the JDOM > >> 'standard'... ? I promise to consider any suggestions.... > >> > > > > I suggest that you publish JDOM2 under the jdom2 artifact id to match > the > > package name. You can call the jar whatever you want. > > > > Thank you for reading this far! > > > > Gary > > > > > >> Rolf > >> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Fri May 18 11:21:31 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 18 May 2012 14:21:31 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: References: <7099262884711530915@unknownmsgid> <4FB62A9C.8060606@tuis.net> <63e4deed8accc55a5aab172832b4c38f@tuis.net> <2f1597bc7d9346b8e9e985d5ec7f9d21@tuis.net> Message-ID: You never answered any of the 4 questions ;-) A few months ago I was begging for maven-experienced people to 'do it right'.... There was some help putting together a POM, but by far the biggest challenge is getting all the 'protocols' in place to actually deliver projects to maven-central. And that makes things difficult. Especially difficult because there is no easy way to do a 'sand-box' test-like process, and it is not available for 'anyone' to do.... it took me weeks just to understand, submit, and process the 'paperwork'. Then, once you are on, you have *no* second-chances.... get one little-bitsy-teeny thing wrong, and you're screwed. If I do something simple like have a piece of uncommitted code when I build the JDOM Build, then that is unrecoverable.... So, in essence, based on the information available 'back then', I have done everything *right*, and JDOM 2.x is correctly installed in maven. What's not working is the condition where someone wants to use two different versions of JDOM at one time.... Rolf Paul Libbrecht appears to have anticipated this problem On Fri, 18 May 2012 14:06:44 -0400, Brad Cox wrote: > The maven dox are clear about its adherence to "convention over > configuration", which is the very thing I found compelling after my own > bout of grumbling over its noncompliance with *my* conventions > (src/main/java indeed when src should be enough, sez' I). That said, it > provide way to override almost anything, although that's usually painful > enough that its best avoided. > > Think of it this way. For the problems I work on, JDOM is a very small tree > in a very large forest of jars that must work together. I need it to fit > in to that forest and "just work" without having to think about your > reasons for wanting (or needing) your own set of conventions. Regardless of > its (many) flaws, maven projects generally more or less deliver on that > promise. Outlier conventions create problems for me and I avoid packages > that create problems. > > On Fri, May 18, 2012 at 1:30 PM, Rolf Lear wrote: > From jdom at tuis.net Fri May 18 11:24:56 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 18 May 2012 14:24:56 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: <1337364650.25238.YahooMailNeo@web161002.mail.bf1.yahoo.com> References: <4FB63178.1090804@expertsystems.se> <1337364650.25238.YahooMailNeo@web161002.mail.bf1.yahoo.com> Message-ID: Tatu That's a pretty strong opinion. three things. there is nothing stopping you from using JDOM 1.x and 2.x at the same time. You can easily put both jars in your classpath.... it is *maven* that is stopping you from doing that. I am only allowed to have one group-id - it is the oss-sonatype nexus that stops me from doing adding more. if this all seems 'a very bad idea', why did you not prevent this problem from happening when I asked numerous times for experienced maven users to assist? All in all, I think it is fair to blame maven here. Rolf On Fri, 18 May 2012 11:10:50 -0700 (PDT), Tatu Saloranta wrote: > +1 to this -- I think it is a very bad idea for a major backwards > incompatible version to use the same artifact name OR group id for exactly > this reason.While there are ways around this -- namely, using OSGi -- the > most practical way otherwise is to change artifact name. > > I do not think Maven is to blame for this: while Maven can help in > detecting the problem -- assuming that major version upgrade represents > incompatible changes, which is not given for all projects either -- one > will still get into trouble for transitive dependencies. > Problem is much more fundamental than package dependency or repository > system, and will either bite users, or prevent other libs from upgrading to > use JDOM 2. Or most likely, both. > > This is a particularly nasty problem for "low level" libraries, projects, > which are added as transitive dependencies. > > Blaming Maven here is not very productive, it's just a messenger. At the > same time, if the version is out, well, shit has hit the fan. > > > -+ Tatu +- > > > > ________________________________ > From: Mattias Jiderhamn > To: > Cc: jdom-interest at jdom.org > Sent: Friday, May 18, 2012 4:24 AM > Subject: Re: [jdom-interest] V2.x not usable next to V1.x > > > > JDOM 2 should have used an artifactId separate from that of JDOM 1 (just > like the package is renamed to allow for parallell versions). > > For example > > ??? org.jdom > ??? jdom2 > ??? 2.0.1 > ??????????? > ? > > ----- Original Message ----- > Subject: Re: [jdom-interest] V2.x not usable next to V1.x > Date: Fri, 18 May 2012 06:55:24 -0400 > From: Rolf Lear > > Hi Gary. > > I am not a Maven expert.... and there is not a huge amount of Maven > *owner* expertise on this list (we have a number of maven *users*, > but > not many people who 'publish'). I have learned enough to 'publish' > to > maven, but I do not even *use* it. > > As such, our maven 'support' may be broken. > > But.... this is a limitation of maven.... not the way we deploy it. > > Can you show us how we should do it differently? > > For your information though, have you seen these sorts of > questions.... > ? > http://stackoverflow.com/questions/9308366/copy-two-versions-of-same-jar-using-maven > > > Rolf > > On 17/05/2012 11:21 PM, Gary Gregory wrote: >> Hello JDOM, >> >> I cannot use both v2 and v1 in the same Maven or Ivy project > because >> both use the same id in Maven repositories like Maven Central. >> >> I want to use v2 in my app but 3rd party jars I use depends on > v1. >> >> Gary >> _______________________________________________ >> To control your jdom-interest membership: >> > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Fri May 18 12:12:15 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 18 May 2012 15:12:15 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: References: <7099262884711530915@unknownmsgid> <4FB62A9C.8060606@tuis.net> <63e4deed8accc55a5aab172832b4c38f@tuis.net> <2f1597bc7d9346b8e9e985d5ec7f9d21@tuis.net> Message-ID: <113786dd816f8c11e1bfc7f345f242a3@tuis.net> bear with me, I really am trying to get a working solution here... but I am 'South African', so I may come across a little rough ;-) Also, understand that I do not use maven/ivy/whatever. Getting maven working at all without expert advice was a challenge. I was literally begging for help.... http://markmail.org/message/wcn5woeer2abez6m Also understand that it is highly unlikely that jdom will move to the full maven-build type model. It is going to stay as an ant-based build. The massive re-organization of the code would be a huge impact on the version history would be a PITA for a start.... Currently the maven deploy is done using a maven 'bundle' approach. I do not see this changing any time soon. https://github.com/hunterhacker/jdom/wiki/JDOM1.1.2-and-Maven See more comments inline..... Rolf On Fri, 18 May 2012 14:19:13 -0400, Gary Gregory wrote: > Hello All, > > All right, let's see... let me point out again that this is not a Maven > problem. This will happen no matter what dependency management system you > use. Maven happens to be the grand-daddy of them all in the Java world. Let me fix that statement for you :) > let me point out again that this is not a Maven-only problem and that other dependency management systems have the same problem. > 'ant' is the grand-daddy of dependency management in the Java world, and Maven is the 'whippersnapper' ;-) hehe. > > In my case I use Ant and Ivy. So all the Maven bashing is pointless because > this can happen outside of Maven as is in my case. Maven has pros and cons > for sure and outside the scope of this thread. > > The bottom line is that JDOM is broken for use from dependency management > tools like Ivy and Maven. My guess is that it is also broken for Scala SBT, > Buildr, and Graddle. Tools that rely on artifact ids cannot use two > different code bases/packages/jars if they have the same id. > > More below. > > On Fri, May 18, 2012 at 1:30 PM, Rolf Lear wrote: > >> >> So, a general comment, and four questions.... >> >> The inability of maven to accommodate the flexibility of 'real life' >> development in an automated way is not the fault of JDOM. The very fact >> that I have spent so much time already 'dealing' with maven indicates >> that >> it has something fundamentally wrong with its design/model. I get the >> impression that Maven developers expect the world to conform to them, >> rather than tolerating the heterogeneous we live in. It is "everyone >> else's >> fault" if things don't work the maven way..... >> > > I disagree but I do not want to spend more time attributing blame. That's > not going to help anyone today. Perhaps, I *know* there are emotions involved,... but the problem is really quite simple.... I'll get to it. > > >> >> 1. you say that the artifact does not need to be the same as the 'base >> name' of the jar, yet everything i have read suggests it does need to be >> the same: http://maven.apache.org/maven-conventions.html Further, while I >> have no record of it, I recall that when I tried to upload maven bundles >> to >> sonatype, the jar name has to be of the specific form >> --.jar, If your artifact is abc123 and the >> version is 1.2.3 then it expects abc123-1.2.3.jar, >> abc123-1.2.3-sources.jar, abc123-1.2.3-javadocs.jar, etc. When I get >> home I >> can try something different to double-check, but i am pretty certain.... >> If >> maven were actually 'easy' to work with, there should be an easy way for >> anyone to actually try that.... is there a way? >> > > You might be right in the end WRT jar names matching artifact id. I like > you do not care to fight Maven more than I already do. What I do know is > that Maven is overridable is all sorts of advanced and magical ways that I > do not fully grok. So it might be possible of course to end up with the jar > file name you want in the end. > > FWIW, for all of the Apache Commons projects I've seen that required a > package name change (Math 3.0, Lang 3.0, VFS 2.0), we've ended up with a > jar file that matches the artifact id. That's never bothered anyone enough > to change the default I suppose. > For what it's worth, JDOM *has* changed the jar file, from jdom-1.1.3.jar to jdom-2.0.1.jar I know, you meant that you expected jdom2.jar or something.... but *why*? Because *maven* needs it? Because *ivy* needs it? > >> 2. If it is possible to load jdom-2.0.2.jar in to the jdom2 artifact, I >> will consider it... but what about people who are already pulling 2.0.0 >> and >> 2.0.1 from the jdom artifact? How will they know to 'move' if their >> dependencies are not going to move with the artifact....? If I can keep >> the >> jdom-2.0.x.jar, I would also consider deploying to *both* jdom2 and jdom >> artifacts.... >> > > This is where I think JDOM2 made a big mistake. > > JDOM 1 is not binary compatible with JDOM 2 because of the package name > change. It was incompatible for other reasons, so 'formalizing' it with a package change made it very obvious ... ;-) And this is where I think your logic step breaks down.... java -cp .:jdom-1.1.3.jar:jdom-2.0.1.jar MyApp is just fine. What you are saying is that it is JDOM's fault that Maven cannot build a class path..... ;-) There is *no* problem with running both jdom 1.x and 2.x in the same system. The problem is how to 'package'/'build'/'deliver' the jars. So, I am an 'old fashioned' ant-build type person. I am very happy with that, but I know it is not 'cool'. On the other hand, I acknowledge there are other ways to do it. So, it comes down to the fact that *JDOM* is fine, the JDOM 2.x jars have a perfectly good name, but they are not being *exposed* correctly in Maven/ivy/whatever. So I messed up with the maven deploy, again, how to fix it? As I said before, I am willing to consider fixing things, this is not a dead issue.... (but I take offense when people say it is JDOM's fault that maven cannot build a classpath.... Hell, ant can do it, so why then is maven 'better'!). > > So I cannot just change my ivy.xml (or pom.xml) and say I want "2.0.1" > instead of "1.1.1" and have it work. or ivy > > I must change all of my source files to use the new package. If I have to > do that, then surely, changing the artifact id from "jdom" to "jdom2" makes > sense and is not an added burden IMO. > The decision to put JDOM 2.x in the jdom artifact is/was (at the time) reasonable.... now I see that it's not necessarily so reasonable, but I am stuck.... I am stuck with deciding what the *right* solution is... I agree that when changing package names that changing the artifactID is easy too... but changing the artifactID has implications for JDOM.... Technically there is nothing wrong with the way that JDOM is released, as jdom-1.1.3.jar and jdom-2.0.1.jar. Technically they are both successfully released to maven. Technically they should probably have had different artifact ID's.... but, do I have to rename (the future) jdom-2.0.2.jar jdom2-2.0.2.jar just to make maven (and ivy.... etc.) happy? So, the fix for this problem appears to be putting future versions of jdom 2.x in to a separate artifact. If the fix is accomplished by changing the artifact ID, then great... the way I see it is: 1. leave it the way it is and have psycho's on jdom-interest whining ;-) 2. put jdom-2.0.2.jar in the jdom artifact, as now, but also deploy jdom2-2.0.2.jar to jdom2 artifact (double-release to maven) 3. put jdom-2.0.2.jar and future versions in jdom2 artifact (assuming I can have a different jar 'base' name than artifact name). 4. put jdom2-2.0.2.jar and future versions in jdom2 artifact, and keep the 'standard' jdom-2.0.2.jar on jdom.org, but that *sux* to have different jars on www.jdom.org and maven-central. 5. rename all of JDOM's future jars to jdom2-2.x.y.jar to accomodate the maven 'problem' ( ;-) ) and then 'conform' to maven-mantra. >> >> 3. How do I 'notify' the 30k people a month using 1.1 that they should >> upgrade/change their artifact to jdom2? >> > > The same way you tell them there is a new version. At Apache we use an > announcement mailing list, some folks use Twitter, and so on. > > In the end you cannot force people to upgrade, each developer has to make a > conscious decision to update a jar (which might drag in other jars with it > and so on.) Agreed, I was just whining about no-one liking jdom 2.x ;-) > > >> 4. Maven provides no way to 'test' something... (at least not with the >> simple 'bundle' upload). How do I do a 'dry run'? I have already got the >> JDOM beta's in the jdom2 artifact because I needed to get some 'practice' >> in..... >> > > This is how we do it for Apache Commons including dry runs: > http://wiki.apache.org/commons/UsingNexus That *requires* using 'mvn' to build JDOM.... which is not going to happen (short/medium term). > > Gary > From mike at saxonica.com Fri May 18 13:13:00 2012 From: mike at saxonica.com (Michael Kay) Date: Fri, 18 May 2012 21:13:00 +0100 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: References: <4FB63178.1090804@expertsystems.se> <1337364650.25238.YahooMailNeo@web161002.mail.bf1.yahoo.com> Message-ID: <4FB6AD4C.1060308@saxonica.com> >All in all, I think it is fair to blame maven here. I have a great deal of sympathy with both sides of this debate. Maven is a pig to use. We've given up trying several times. The documentation is awful, the process is awful, there is no way of testing your artefacts, and when you get them wrong (as we have done) there is no way of putting it right. On the other hand, Maven is quite rightly focused on meeting the needs of its users rather than package developers. Those users do have complex requirements, and individual components like JDOM or Saxon are tiny parts of their overall systems; they don't want to tailor their working methods to the idiosyncracies of individual packages. (And they certainly don't want to have upgrades foisted on them: when something isn't broken, they don't want to fix it). So as developers, I think it's reasonable that we should make some effort to fit into the process the way it has been designed. But it *is* an extremely frustrating experience, and I'm not convinced it needs to be. Michael Kay Saxonica From bcox at virtualschool.edu Fri May 18 13:28:16 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Fri, 18 May 2012 16:28:16 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: References: <7099262884711530915@unknownmsgid> <4FB62A9C.8060606@tuis.net> <63e4deed8accc55a5aab172832b4c38f@tuis.net> <2f1597bc7d9346b8e9e985d5ec7f9d21@tuis.net> Message-ID: As I recall, you turned down my offer to help with the end of the problem I could help with (replicating your ant build process with *NO* source changes) and never used the pom I sent you for the first step, the compile. I told you then I couldn't help with the deploy process having never been that far. Seems to me these are consequences of a decision to buck the conventions and jump to right to the deep end (deployment) just to maintain a legacy build system regardless the costs. These are the costs. Its not maven that dictates the artifact name must match the jar name. That comes from ant not maven. For all I know there's a plugin that can remap that even now but I'll defer to the experts for that. I didn't answer the questions because they are deployment questions. Again I've ever been there. On Fri, May 18, 2012 at 2:21 PM, Rolf Lear wrote: > > You never answered any of the 4 questions ;-) > > A few months ago I was begging for maven-experienced people to 'do it > right'.... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcox at virtualschool.edu Fri May 18 13:34:25 2012 From: bcox at virtualschool.edu (Brad Cox) Date: Fri, 18 May 2012 16:34:25 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: <4FB6AD4C.1060308@saxonica.com> References: <4FB63178.1090804@expertsystems.se> <1337364650.25238.YahooMailNeo@web161002.mail.bf1.yahoo.com> <4FB6AD4C.1060308@saxonica.com> Message-ID: +1 to both paragraphs! On Fri, May 18, 2012 at 4:13 PM, Michael Kay wrote: > >All in all, I think it is fair to blame maven here. > > I have a great deal of sympathy with both sides of this debate. > > Maven is a pig to use. We've given up trying several times. The > documentation is awful, the process is awful, there is no way of testing > your artefacts, and when you get them wrong (as we have done) there is no > way of putting it right. > > On the other hand, Maven is quite rightly focused on meeting the needs of > its users rather than package developers. Those users do have complex > requirements, and individual components like JDOM or Saxon are tiny parts > of their overall systems; they don't want to tailor their working methods > to the idiosyncracies of individual packages. (And they certainly don't > want to have upgrades foisted on them: when something isn't broken, they > don't want to fix it). So as developers, I think it's reasonable that we > should make some effort to fit into the process the way it has been > designed. But it *is* an extremely frustrating experience, and I'm not > convinced it needs to be. > > Michael Kay > Saxonica > > ______________________________**_________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/**options/jdom-interest/** > youraddr at yourhost.com > -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Fri May 18 15:23:20 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 18 May 2012 18:23:20 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: References: <7099262884711530915@unknownmsgid> <4FB62A9C.8060606@tuis.net> <63e4deed8accc55a5aab172832b4c38f@tuis.net> <2f1597bc7d9346b8e9e985d5ec7f9d21@tuis.net> Message-ID: <4FB6CBD8.8000600@tuis.net> Hi Brad. This whole thing is frustrating me... sorry to take it out on your reply.... Yes, you offered help. In fact, I *did* use your pom. At least for a while. The reality is that your pom was enough to complete maybe 5% of the problem, and the *wrong* 5%. Your help was all about changing from an ant build to a mvn build, and that was what I was trying to avoid (even if the code was not moving locations). The other 95% is all about *deploying* to maven-central, which is a massive procedure.... (not really POM related). But, one of the pre-conditions I made was that I was not going to convert the 1.1.x branch to maven (which was when you were offering help). I think that was fair. I said I had *zero* experience with maven... (and still essentially have none, I have never built a project with maven.... *never*). The 1.1.2 and 1.1.3 releases to maven are *fine*. The procedure for building a maven bundle is *fine*, Zero problems. The reality is that it was not the right time for me to learn a whole dependency environment while trying to get 2.x out too. The mistakes in doing that outweigh the benefits. I can't possibly be the right person to do it. Apart from the fact that converting JDOM to a maven build process is completely unnecessary, the ant build is simple and works. The only complaint people actually have is the lack of a '2' character on the JDOM 2.x artifactID. Everything else is fine. Further, none of your assistance would have prevented the issue at hand, the mis-named artifactID... which is completely unrelated to anything you have done. I sent e-mails to the list notifying everyone of the intention to name the jdom 2.0.0 artifact 'jdom' *before* I released it and I asked for feedback. So, this is the fault of everyone except me ;-) *you* and everyone else with maven experience should have picked up that 'very bad idea'. While I am the only (active) maintainer of JDOM I see zero point in converting it to maven. I do not know the day-to-day procedures, I see no value in learning them, I don't need them for (paid) work, and I see no 'fun' value in it (in fact, the more I deal with it the more un-fun it becomes), etc. I have learned more than enough to get a *good* (maybe not great) deployment process going. So, getting back on track.... I am willing to consider solutions to the missing '2' on the artifactID... The solution is probably much simpler than dealing with this sort of mail-thread. Now that I am home (and have the right encryption keys available to try), I will see if I can put in a jdom2 artifact with a jdom jar. Otherwise I will investigate some other alternatives. It would be useful But I am getting more and more stubborn about getting grief about maven being 'easy', etc. Rolf On 18/05/2012 4:28 PM, Brad Cox wrote: > As I recall, you turned down my offer to help with the end of the > problem I could help with (replicating your ant build process with *NO* > source changes) and never used the pom I sent you for the first step, > the compile. I told you then I couldn't help with the deploy process > having never been that far. > > Seems to me these are consequences of a decision to buck the conventions > and jump to right to the deep end (deployment) just to maintain a legacy > build system regardless the costs. These are the costs. Its not maven > that dictates the artifact name must match the jar name. That comes from > ant not maven. For all I know there's a plugin that can remap that even > now but I'll defer to the experts for that. > From jdom at tuis.net Fri May 18 15:32:07 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 18 May 2012 18:32:07 -0400 Subject: [jdom-interest] Maven Whining Message-ID: <4FB6CDE7.8040903@tuis.net> So, why is it that there is: http://mvnrepository.com http://search.maven.org Which one is 'maven'. Why does the IVY project reference mvnrepository.com, but that repository is out of date...? It does not have JDOM 2.0.1 released 3 weeks ago. Why is there no xerces 2.11 on maven? It was released in 2010 ? The recent Jaxen release is not on maven. JDOM could not be built with the current maven system.... right? Rolf From jdom at tuis.net Fri May 18 15:49:33 2012 From: jdom at tuis.net (Rolf Lear) Date: Fri, 18 May 2012 18:49:33 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: <7099262884711530915@unknownmsgid> References: <7099262884711530915@unknownmsgid> Message-ID: <4FB6D1FD.40003@tuis.net> On 17/05/2012 11:21 PM, Gary Gregory wrote: > Hello JDOM, > > I cannot use both v2 and v1 in the same Maven or Ivy project because > both use the same id in Maven repositories like Maven Central. > > I want to use v2 in my app but 3rd party jars I use depends on v1. > > Gary > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > Hi Gary Sorry to drag you though the maven stress on JDOM. So, I cannot have a jdom-2.0.2.jar deployed in the artifact 'jdom2'. Does not validate when I try.... My options are: - change the (perfectly valid) JDOM naming convention from jdom-2.0.2.jar to jdom2-2.0.2.jar, or should that be jdom2-1.0.0, or what? What is the 'expected convention'? - should I do that for the maven deploy only, or should I do it for the offical JDOM release as well? - should I double-deploy, to both jdom and jdom2 For whatever reason I am resistant to renaming the official JDOM release standard to jdom2-x.y.z.jar from jdom-x.y.z.jar. From elharo at ibiblio.org Sat May 19 06:08:16 2012 From: elharo at ibiblio.org (Elliotte Rusty Harold) Date: Sat, 19 May 2012 09:08:16 -0400 Subject: [jdom-interest] Maven Whining In-Reply-To: <4FB6CDE7.8040903@tuis.net> References: <4FB6CDE7.8040903@tuis.net> Message-ID: On Fri, May 18, 2012 at 6:32 PM, Rolf Lear wrote: > The recent Jaxen release is not on maven. Regarding jaxen, there used to be a bug filing procedure but nowadays I think that all Codehaus releases are supposed to hit maven automatically. In any case, the old instructions definitely don't work, so if there's something else we need to do, holler and I'll see if I can make it work if it's not too onerous. I.e. if just need to fill out a form somewhere I can do that. If it requires a full upgrade to maven 3, or some fancy key signing protocol, then it may require another volunteer stepping forward. -- Elliotte Rusty Harold elharo at ibiblio.org From jdom at tuis.net Sat May 19 06:17:07 2012 From: jdom at tuis.net (Rolf Lear) Date: Sat, 19 May 2012 09:17:07 -0400 Subject: [jdom-interest] Maven Whining In-Reply-To: References: <4FB6CDE7.8040903@tuis.net> Message-ID: <4FB79D53.8060808@tuis.net> Hi Elliotte. Don't get me wrong, I was just whining ... ;-) I (personally) have no immediate push to get 1.1.4 in to maven. On the serious side though, if you do need to push to maven central, and the codehaus process does not do it automatically, you may want to see what I did with JDOM.... Between this page: https://github.com/hunterhacker/jdom/wiki/JDOM1.1.2-and-Maven and the JDOM Build file: https://github.com/hunterhacker/jdom/blob/master/build.xml#L503 Also, there is the open ticket JAXEN-217 which can probably be closed.... Rolf On 19/05/2012 9:08 AM, Elliotte Rusty Harold wrote: > On Fri, May 18, 2012 at 6:32 PM, Rolf Lear wrote: > >> The recent Jaxen release is not on maven. > Regarding jaxen, there used to be a bug filing procedure but nowadays > I think that all Codehaus releases are supposed to hit maven > automatically. In any case, the old instructions definitely don't > work, so if there's something else we need to do, holler and I'll see > if I can make it work if it's not too onerous. I.e. if just need to > fill out a form somewhere I can do that. If it requires a full upgrade > to maven 3, or some fancy key signing protocol, then it may require > another volunteer stepping forward. > From garydgregory at gmail.com Sat May 19 07:31:24 2012 From: garydgregory at gmail.com (Gary Gregory) Date: Sat, 19 May 2012 10:31:24 -0400 Subject: [jdom-interest] V2.x not usable next to V1.x In-Reply-To: <4FB6D1FD.40003@tuis.net> References: <7099262884711530915@unknownmsgid> <4FB6D1FD.40003@tuis.net> Message-ID: <-808803632784303752@unknownmsgid> On May 18, 2012, at 18:49, Rolf Lear wrote: > On 17/05/2012 11:21 PM, Gary Gregory wrote: >> Hello JDOM, >> >> I cannot use both v2 and v1 in the same Maven or Ivy project because >> both use the same id in Maven repositories like Maven Central. >> >> I want to use v2 in my app but 3rd party jars I use depends on v1. >> >> Gary >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > > > Hi Gary > > Sorry to drag you though the maven stress on JDOM. C'est la vie, I hope we will all learn something out of this, process wise and technically. :) > > So, I cannot have a jdom-2.0.2.jar deployed in the artifact 'jdom2'. Does not validate when I try.... > > My options are: > > - change the (perfectly valid) JDOM naming convention from jdom-2.0.2.jar to jdom2-2.0.2.jar, or should that be jdom2-1.0.0, or what? What is the 'expected convention'? See below. > - should I do that for the maven deploy only, or should I do it for the offical JDOM release as well? I would think it simpler for users if the jar file names are the same for v2. So use jdom2-2.x.x for both. > - should I double-deploy, to both jdom and jdom2 That's a pickle. IMO jdom should revert to 1.x but the cat is out of the bag here because you cannot undeploy. So let it be. > > For whatever reason I am resistant to renaming the official JDOM release standard to jdom2-x.y.z.jar from jdom-x.y.z.jar. > I think the path of least resistance from the tooling POV is to use the artifact Id jdom for v1 and jdom2 for v2 and accept the jar naming that comes out of it. Yes, you end up with the name jdom2-2.0.2.jar. That is what I've seen come out of other apache projects. I'm not a big fan of the naming convention but I am a big fan of dependency management and automated tools. So I take the good with the less tasty. Gary From jdom at tuis.net Wed May 23 04:58:30 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 23 May 2012 07:58:30 -0400 Subject: [jdom-interest] JDOM and Axis2 In-Reply-To: <252B352F2D8FAA48A44122A6CE15593004FCB9D0F3@MX05A.corp.emc.com> References: <252B352F2D8FAA48A44122A6CE15593004FCB9D0F3@MX05A.corp.emc.com> Message-ID: <4FBCD0E6.6050902@tuis.net> Hi Aaron. I hate being doubtful about your question, but what you're suggesting just does not make sense..... For example, in JDOM2, the 'default' XPathFactory has the following implementation for 'compile'.... public XPathExpression compile(String expression) { return compile(expression, Filters.fpassthrough(), null, EMPTYNS); } and that method calls: public XPathExpression compile(String expression, Filter filter, Map variables, Namespace... namespaces) { return new JaxenCompiled(expression, filter, variables, namespaces); } There is just no way for that to return a null value.... It has to return a value, or throw an exception.... In the JDOM 1.x code, the code is more complicated, but again, it either returns a new instance, or throws an exception. Ther ei sno way to return 'null'. There must be something in your code that is resetting it.... or Axis2 is doing something bizarre.... You should probably ask a question on the Axis2 support areas.... this is not a JDOM problem. Rolf On 22/05/2012 11:50 AM, aaron.stromas at rsa.com wrote: > Hi, > > I tried both JDOM and now JDOM2. > > For JDOM2, > > XPathFactory xpfac = XPathFactory./instance/(); > > _XPathExpression_xp = xpfac.compile("//foo/bar"); > > The xp is null. > > For JDOM, > > XPath xp = XPath.newInstance("//foo/bar"); > > The xp is null. > > Both work in the simple java application. > > I tried to putting the JDOM jar in webapps/axis2/WEB-INF/lib along with > Jaxen ? doesn?t do a thing. > > Any ideas? TIA > > Best regards, > > -a > > > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jsolana at indra.es Thu May 24 01:56:25 2012 From: jsolana at indra.es (Solana Huertas, Javier) Date: Thu, 24 May 2012 10:56:25 +0200 Subject: [jdom-interest] JDOM 0.9b Compatibility In-Reply-To: <4FBCD0E6.6050902@tuis.net> References: <252B352F2D8FAA48A44122A6CE15593004FCB9D0F3@MX05A.corp.emc.com> <4FBCD0E6.6050902@tuis.net> Message-ID: <5F3FABBA19A7AC4EBFD0E9904E5BB301414A81@MADARRMAILBOX02.indra.es> Hi all! I've a problem with jdom 0.9b and it compatibility with jaxen 1.1.3. When I run Xpath.selectNodes(...,..) internally I get a fail and print the next Exception: Caused by: java.lang.NoClassDefFoundError: org/jdom/Parent at org.jaxen.jdom.JDOMXPath.(JDOMXPath.java:91) at org.jdom.xpath.JaxenXPath.setXPath(JaxenXPath.java:284) at org.jdom.xpath.JaxenXPath.(JaxenXPath.java:101) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.jdom.xpath.XPath.newInstance(XPath.java:150) If DocumentNavigator is in WEB-INF/classes, it works fine but if it is in jaxen lib, the execution finishes showing the previous error. We have in mind the upgrade jdom 0.9b to JDOM 2 in a few months but until this moment, we need to work with 0.9b and jaxen 1.1.3 if it's possible. Have any idea? Thanks so much Este correo electr?nico y, en su caso, cualquier fichero anexo al mismo, contiene informaci?n de car?cter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no es vd. el destinatario indicado, queda notificado que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n est? prohibida en virtud de la legislaci?n vigente. En el caso de haber recibido este correo electr?nico por error, se ruega notificar inmediatamente esta circunstancia mediante reenv?o a la direcci?n electr?nica del remitente. Evite imprimir este mensaje si no es estrictamente necesario. This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address. Avoid printing this message if it is not absolutely necessary. From jsolana at indra.es Thu May 24 05:04:27 2012 From: jsolana at indra.es (Solana Huertas, Javier) Date: Thu, 24 May 2012 14:04:27 +0200 Subject: [jdom-interest] JDOM 0.9b Compatibility References: <252B352F2D8FAA48A44122A6CE15593004FCB9D0F3@MX05A.corp.emc.com> <4FBCD0E6.6050902@tuis.net> Message-ID: <5F3FABBA19A7AC4EBFD0E9904E5BB3014150EF@MADARRMAILBOX02.indra.es> Hi Again I'm answer to myself. I haven't idea about Maven and the build of 1.1.3 distribution of jaxen (jaxen_1.1.3.jar) is on Maven and defines the dependency with jdom 1.0. If I build a .jar from it java resources, all works "fine" (im not sure at all). Thanks and sorry Javier Solana Huertas Indra Software Labs -----Mensaje original----- De: Solana Huertas, Javier Enviado el: jueves, 24 de mayo de 2012 10:56 Para: 'Rolf Lear' CC: jdom-interest at jdom.org Asunto: RE: [jdom-interest] JDOM 0.9b Compatibility Hi all! I've a problem with jdom 0.9b and it compatibility with jaxen 1.1.3. When I run Xpath.selectNodes(...,..) internally I get a fail and print the next Exception: Caused by: java.lang.NoClassDefFoundError: org/jdom/Parent at org.jaxen.jdom.JDOMXPath.(JDOMXPath.java:91) at org.jdom.xpath.JaxenXPath.setXPath(JaxenXPath.java:284) at org.jdom.xpath.JaxenXPath.(JaxenXPath.java:101) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.jdom.xpath.XPath.newInstance(XPath.java:150) If DocumentNavigator is in WEB-INF/classes, it works fine but if it is in jaxen lib, the execution finishes showing the previous error. We have in mind the upgrade jdom 0.9b to JDOM 2 in a few months but until this moment, we need to work with 0.9b and jaxen 1.1.3 if it's possible. Have any idea? Thanks so much Este correo electr?nico y, en su caso, cualquier fichero anexo al mismo, contiene informaci?n de car?cter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no es vd. el destinatario indicado, queda notificado que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n est? prohibida en virtud de la legislaci?n vigente. En el caso de haber recibido este correo electr?nico por error, se ruega notificar inmediatamente esta circunstancia mediante reenv?o a la direcci?n electr?nica del remitente. Evite imprimir este mensaje si no es estrictamente necesario. This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address. Avoid printing this message if it is not absolutely necessary. From jdom at tuis.net Mon May 28 04:47:18 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 28 May 2012 07:47:18 -0400 Subject: [jdom-interest] Preparing next release Message-ID: <150dd369ca87ab8f8b712f7d507144ae@tuis.net> Hi All. I am getting ready to push out version 2.0.2 of the JDOM 2.x stream. Currently in this release is the fix for issue #81 (resetting live FitlerLists after a remove()). This is the only known bug in JDOM 2.x and a 'hotfix' has been available for a few weeks. It is time to push out the official release. Additionally, there are issues/concerns regarding the maven artifiacts. The core issue is that currently it is not possible to 'require' both JDOM 1.x and 2.x in your maven project. There appears to be only one solution to this issue and that is to have different 'artifacts' for JDOM 1 and JDOM 2. Obviously (in hindsight) it should have been done this way originally, but there was simply not enough 'expert' feedback/input/assistance when the decisions were being made, and this mistake is now something that just has to be lived with. As a result, it appears necessary to deploy JDOM 2.0.2 to the maven artifact 'jdom2' (previous versions were deployed to 'jdom'). While this change will make it possible to include both JDOM 1.x and 2.x in your maven projects it will also introduce a number of irritating side-effects: For 'regular' users, note: 1. previous versions of JDOM 2.x were called jdom-2.0.0.jar and jdom-2.0.1.jar. This new version will be called jdom2-2.0.2.jar, and the 'zip' file will be called jdom2-2.0.2.zip For maven users, note: 1. if you have already incorporated JDOM 2.x in your project you should update your dependency to be for artifact jdom2, not jdom 2. ensure any maven project you require that also depends on JDOM aware of this problem... because, if that required project 'upgrades' to the jdom artifact version 2.0.1 (instead of jdom2) then you will get two different versions of jdom 2.x in your classpath, and there is no telling what will result..... So, it is quite possible that by 'solving' the issue relating to requiring both JDOM 1.x and 2.x, that we will instead be introducing even worse problems, but I have been assured that this is the 'only' way to move forward from here. If anyone has comments, concerns, suggestions, I am all ears. Rolf From jdom at tuis.net Wed May 30 13:26:24 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 30 May 2012 16:26:24 -0400 Subject: [jdom-interest] XPath examples In-Reply-To: References: Message-ID: <4FC68270.60005@tuis.net> Hi Peter, Yes, the examples are sparse. A few things though: Check out https://github.com/hunterhacker/jdom/wiki/JDOM2-Feature-XPath-Upgrade That gives an overview of the changes in XPath processing in JDOM 2.x As for your comment on having a compile(expression, namespace, filter) method, I think that you are 'over-thinking' the problem, and even if you do need a namespace, then the existing compile method would work well too: http://www.jdom.org/docs/apidocs/org/jdom2/xpath/XPathFactory.html#compile%28java.lang.String,%20org.jdom2.filter.Filter,%20java.util.Map,%20org.jdom2.Namespace...%29 You just need to add a null value for the variable Map... like: compile(expression, filter, null, namespace); The Javadoc on that compile method is fairly comprehensive... even if only on the technical side, and not so much the 'example' side I think. Now, about the broader concept of variables.... XPath allows you to use variables in your expression. For example, you could have the 'simple' XPath query: //emt[@name = 'hello'] Which would select all elements with an attribute called 'name' where the 'name' attribute's value is 'hello'. You could build a JDOM XPathExpression with: XPathExpression xp = XPathFactory.instance(). compile("//emt[@name = 'hello']", Filter.element()); However, perhaps you want to check for a different 'name' each time, you could then change the XPath query to: //emt[@name = '$varname'] Now, as soon as your XPath has variables, you need to define them when you compile.... Map vars = new HashMap(); vars.put("name", null); XPathExpression xp = XPathFactory.instance(). compile("//emt[@name = '$varname']", Filter.element(), vars); Then you need to give the variable a value before you use the XPath expression: xp.setVariable("varname", "hello"); Then if you evaluate the expression it will return 'emt' elements with the attribute name="hello". If you change the variable again: xp.setVariable("varname", "world"); ... when you evaluate the expression it will return 'emt' elements with the attribute name="world". Note, I have not used any namespaces in these examples. The XPathBuilder in theory could make it easier to create a complex XPath expression by 'encapsulating' the XPath process prior to compiling it. The same variable example could be: XPathBuilder xpb = new XPathBuilder( "//emt[@name = '$varname']", Filter.element() xpb.setVariable("varname", "hello"); XPathExpression xp = xpb.compileWith(XPathFactory.instance()); If your XML Document has Namespaces then you will probably need to have namespaces as part of your XPath expression... For example, if the actual XML Document is: then the root and both emt elements are in the 'http://example.org' namespace. To select these using an XPath you will need to identify their namespace... the simple XPath query '//emt' will return *nothing*. You need a namespace-correct XPath query. In this case, we need a namespace-prefixed query: '//ns:emt' with prefix 'ns' mapped to 'http://example.org'. Note how I simply 'created' the namespace prefix 'ns'. Like othr namespace prefixes, it does not matter what the actual prefix is, just the URI. There is one core concept though in XPaths.... that the "" empty-string prefix is *always* mapped to the "" empty-string URI.... there is no such thing as a 'default' namespace in an XPath query. To do this in JDOM you would do: XPathExpression xp = XPathFactory.instance(). compile("//ns:emt", Filter.element(), null, Namespace.getNamespace("ns", "http://example.org")); The concepts of Namespace and Variables in XPath are 'orthogonal', although variables themselves may have a namespace... I guess they are not totally orthogonal. Hope this helps .... Rolf On 30/05/2012 3:10 PM, Peter Kronenberg wrote: > Where can I find some more examples of Xpath usage in JDOM2? The online > documentation is a bit sparse. > > I?m specifically confused about how the variables are used. And if I?m > not using variables, it seems that I must use the XPathBuilder to set > the namespace. Wouldn?t it make sense for XPathFactory to have a > compile(String expression, Namespace ns, Filter filter) version? > > Or XPathExpression could have a setNamespace() method. > > Thanks > > Peter Kronenberg > > Software Engineer > > Technica Corporation > > pkronenberg at technicacorp.com > > 703.885.1222 (Office) > From PKronenberg at technicacorp.com Wed May 30 13:48:56 2012 From: PKronenberg at technicacorp.com (Peter Kronenberg) Date: Wed, 30 May 2012 20:48:56 +0000 Subject: [jdom-interest] XPath examples In-Reply-To: <4FC68270.60005@tuis.net> References: <4FC68270.60005@tuis.net> Message-ID: Thanks for the quick and comprehensive response. I guess I realized I could pass null for the variables in the compile() method, but still think it would be a bit cleaner to have a method without the variables, since I almost always uses namespaces and might not be using variables so much. Do the variables have to be xpath values (i.e., in quotes), or can any part of the xpath expression be put into a variable? Peter Kronenberg Software Engineer Technica Corporation pkronenberg at technicacorp.com 703.885.1222 (Office) -----Original Message----- From: Rolf Lear [mailto:jdom at tuis.net] Sent: Wednesday, May 30, 2012 4:26 PM To: Peter Kronenberg Cc: jdom-interest at jdom.org Subject: Re: [jdom-interest] XPath examples Hi Peter, Yes, the examples are sparse. A few things though: Check out https://github.com/hunterhacker/jdom/wiki/JDOM2-Feature-XPath-Upgrade That gives an overview of the changes in XPath processing in JDOM 2.x As for your comment on having a compile(expression, namespace, filter) method, I think that you are 'over-thinking' the problem, and even if you do need a namespace, then the existing compile method would work well too: http://www.jdom.org/docs/apidocs/org/jdom2/xpath/XPathFactory.html#compile%28java.lang.String,%20org.jdom2.filter.Filter,%20java.util.Map,%20org.jdom2.Namespace...%29 You just need to add a null value for the variable Map... like: compile(expression, filter, null, namespace); The Javadoc on that compile method is fairly comprehensive... even if only on the technical side, and not so much the 'example' side I think. Now, about the broader concept of variables.... XPath allows you to use variables in your expression. For example, you could have the 'simple' XPath query: //emt[@name = 'hello'] Which would select all elements with an attribute called 'name' where the 'name' attribute's value is 'hello'. You could build a JDOM XPathExpression with: XPathExpression xp = XPathFactory.instance(). compile("//emt[@name = 'hello']", Filter.element()); However, perhaps you want to check for a different 'name' each time, you could then change the XPath query to: //emt[@name = '$varname'] Now, as soon as your XPath has variables, you need to define them when you compile.... Map vars = new HashMap(); vars.put("name", null); XPathExpression xp = XPathFactory.instance(). compile("//emt[@name = '$varname']", Filter.element(), vars); Then you need to give the variable a value before you use the XPath expression: xp.setVariable("varname", "hello"); Then if you evaluate the expression it will return 'emt' elements with the attribute name="hello". If you change the variable again: xp.setVariable("varname", "world"); ... when you evaluate the expression it will return 'emt' elements with the attribute name="world". Note, I have not used any namespaces in these examples. The XPathBuilder in theory could make it easier to create a complex XPath expression by 'encapsulating' the XPath process prior to compiling it. The same variable example could be: XPathBuilder xpb = new XPathBuilder( "//emt[@name = '$varname']", Filter.element() xpb.setVariable("varname", "hello"); XPathExpression xp = xpb.compileWith(XPathFactory.instance()); If your XML Document has Namespaces then you will probably need to have namespaces as part of your XPath expression... For example, if the actual XML Document is: then the root and both emt elements are in the 'http://example.org' namespace. To select these using an XPath you will need to identify their namespace... the simple XPath query '//emt' will return *nothing*. You need a namespace-correct XPath query. In this case, we need a namespace-prefixed query: '//ns:emt' with prefix 'ns' mapped to 'http://example.org'. Note how I simply 'created' the namespace prefix 'ns'. Like othr namespace prefixes, it does not matter what the actual prefix is, just the URI. There is one core concept though in XPaths.... that the "" empty-string prefix is *always* mapped to the "" empty-string URI.... there is no such thing as a 'default' namespace in an XPath query. To do this in JDOM you would do: XPathExpression xp = XPathFactory.instance(). compile("//ns:emt", Filter.element(), null, Namespace.getNamespace("ns", "http://example.org")); The concepts of Namespace and Variables in XPath are 'orthogonal', although variables themselves may have a namespace... I guess they are not totally orthogonal. Hope this helps .... Rolf On 30/05/2012 3:10 PM, Peter Kronenberg wrote: > Where can I find some more examples of Xpath usage in JDOM2? The online > documentation is a bit sparse. > > I'm specifically confused about how the variables are used. And if I'm > not using variables, it seems that I must use the XPathBuilder to set > the namespace. Wouldn't it make sense for XPathFactory to have a > compile(String expression, Namespace ns, Filter filter) version? > > Or XPathExpression could have a setNamespace() method. > > Thanks > > Peter Kronenberg > > Software Engineer > > Technica Corporation > > pkronenberg at technicacorp.com > > 703.885.1222 (Office) > The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Technica Corporation does not represent this e-mail to be free from any virus, fault or defect and it is therefore the responsibility of the recipient to first scan it for viruses, faults and defects. To reply to our e-mail administrator directly, please send an e-mail to postmaster at technicacorp.com. Thank you. From jdom at tuis.net Wed May 30 14:21:08 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 30 May 2012 17:21:08 -0400 Subject: [jdom-interest] XPath examples In-Reply-To: References: <4FC68270.60005@tuis.net> Message-ID: <4FC68F44.9030801@tuis.net> Hi Peter One of the issues with using var-args for the Namespace is that it becomes ambiguous if I take away the 'Variables' argument.... so it would not work to add a new method without the variables map. In my head when I put the two major compile methods together, it was 'simple' and 'complex' xpaths .... simple have no variables and Namespaces. Complex ones do.... As for whether the variables have to be XPath values.... I believe so - it would not make sense of the variable value is expected to be 'compiled', and that maks me realize that I got the examples wrong.... there should not be quotes around the $varname in the examples I gave.... Yes, reading the XPath syntax here: http://www.w3.org/TR/xpath/#NT-VariableReference The variable reference is only allowed to be a discrete part of the query, and additionally, it later says: The variable bindings consist of a mapping from variable names to variable values. The value of a variable is an object, which can be of any of the types that are possible for the value of an expression, and may also be of additional types not specified here. which implies that the variable value is not re-evaluated On 30/05/2012 4:48 PM, Peter Kronenberg wrote: > Thanks for the quick and comprehensive response. > > I guess I realized I could pass null for the variables in the compile() method, but still think it would be a bit cleaner to have a method without the variables, since I almost always uses namespaces and might not be using variables so much. > > Do the variables have to be xpath values (i.e., in quotes), or can any part of the xpath expression be put into a variable? > > Peter Kronenberg > Software Engineer > Technica Corporation > pkronenberg at technicacorp.com > 703.885.1222 (Office) > > -----Original Message----- > From: Rolf Lear [mailto:jdom at tuis.net] > Sent: Wednesday, May 30, 2012 4:26 PM > To: Peter Kronenberg > Cc: jdom-interest at jdom.org > Subject: Re: [jdom-interest] XPath examples > > Hi Peter, > > Yes, the examples are sparse. A few things though: Check out https://github.com/hunterhacker/jdom/wiki/JDOM2-Feature-XPath-Upgrade > > That gives an overview of the changes in XPath processing in JDOM 2.x > > As for your comment on having a compile(expression, namespace, filter) method, I think that you are 'over-thinking' the problem, and even if you do need a namespace, then the existing compile method would work well too: > > http://www.jdom.org/docs/apidocs/org/jdom2/xpath/XPathFactory.html#compile%28java.lang.String,%20org.jdom2.filter.Filter,%20java.util.Map,%20org.jdom2.Namespace...%29 > > You just need to add a null value for the variable Map... like: > > compile(expression, filter, null, namespace); > > The Javadoc on that compile method is fairly comprehensive... even if only on the technical side, and not so much the 'example' side I think. > > > Now, about the broader concept of variables.... XPath allows you to use > variables in your expression. For example, you could have the 'simple' > XPath query: > > //emt[@name = 'hello'] > > Which would select all elements with an attribute called 'name' where > the 'name' attribute's value is 'hello'. > > You could build a JDOM XPathExpression with: > > XPathExpression xp = XPathFactory.instance(). > compile("//emt[@name = 'hello']", Filter.element()); > > However, perhaps you want to check for a different 'name' each time, you > could then change the XPath query to: > > //emt[@name = '$varname'] > > Now, as soon as your XPath has variables, you need to define them when > you compile.... > > Map vars = new HashMap(); > vars.put("name", null); > XPathExpression xp = XPathFactory.instance(). > compile("//emt[@name = '$varname']", Filter.element(), vars); > > Then you need to give the variable a value before you use the XPath > expression: > > xp.setVariable("varname", "hello"); > > Then if you evaluate the expression it will return 'emt' elements with > the attribute name="hello". > > If you change the variable again: > > xp.setVariable("varname", "world"); > > ... when you evaluate the expression it will return 'emt' elements with > the attribute name="world". > > > Note, I have not used any namespaces in these examples. > > The XPathBuilder in theory could make it easier to create a complex > XPath expression by 'encapsulating' the XPath process prior to compiling it. > > The same variable example could be: > > XPathBuilder xpb = new XPathBuilder( > "//emt[@name = '$varname']", Filter.element() > xpb.setVariable("varname", "hello"); > > XPathExpression xp = xpb.compileWith(XPathFactory.instance()); > > > If your XML Document has Namespaces then you will probably need to have > namespaces as part of your XPath expression... > > For example, if the actual XML Document is: > > > > > > > then the root and both emt elements are in the 'http://example.org' > namespace. To select these using an XPath you will need to identify > their namespace... the simple XPath query '//emt' will return *nothing*. > > You need a namespace-correct XPath query. > > In this case, we need a namespace-prefixed query: '//ns:emt' with prefix > 'ns' mapped to 'http://example.org'. Note how I simply 'created' the > namespace prefix 'ns'. Like othr namespace prefixes, it does not matter > what the actual prefix is, just the URI. There is one core concept > though in XPaths.... that the "" empty-string prefix is *always* mapped > to the "" empty-string URI.... there is no such thing as a 'default' > namespace in an XPath query. > > To do this in JDOM you would do: > > XPathExpression xp = XPathFactory.instance(). > compile("//ns:emt", Filter.element(), null, > Namespace.getNamespace("ns", "http://example.org")); > > > The concepts of Namespace and Variables in XPath are 'orthogonal', > although variables themselves may have a namespace... I guess they are > not totally orthogonal. > > Hope this helps .... > > Rolf > > > On 30/05/2012 3:10 PM, Peter Kronenberg wrote: >> Where can I find some more examples of Xpath usage in JDOM2? The online >> documentation is a bit sparse. >> >> I'm specifically confused about how the variables are used. And if I'm >> not using variables, it seems that I must use the XPathBuilder to set >> the namespace. Wouldn't it make sense for XPathFactory to have a >> compile(String expression, Namespace ns, Filter filter) version? >> >> Or XPathExpression could have a setNamespace() method. >> >> Thanks >> >> Peter Kronenberg >> >> Software Engineer >> >> Technica Corporation >> >> pkronenberg at technicacorp.com >> >> 703.885.1222 (Office) From jdom at tuis.net Wed May 30 16:23:35 2012 From: jdom at tuis.net (Rolf Lear) Date: Wed, 30 May 2012 19:23:35 -0400 Subject: [jdom-interest] Preparing next release In-Reply-To: <150dd369ca87ab8f8b712f7d507144ae@tuis.net> References: <150dd369ca87ab8f8b712f7d507144ae@tuis.net> Message-ID: <4FC6ABF7.4070102@tuis.net> Hi again. Just to let you know that while I was originally going to release 2.0.2 before month-end, I have instead decided to release it probably some time next week. In the interim I am learning a bunch about maven, and I am tracking down some additional input to how to resolve the maven problems. It seems that learning maven to the extent I need is not going to be a 1-day exercise. So, expect 2.0.2 before the 9th of June. Rolf On 28/05/2012 7:47 AM, Rolf Lear wrote: > > Hi All. > > I am getting ready to push out version 2.0.2 of the JDOM 2.x stream. > > Currently in this release is the fix for issue #81 (resetting live > FitlerLists after a remove()). > > This is the only known bug in JDOM 2.x and a 'hotfix' has been available > for a few weeks. It is time to push out the official release. > > > Additionally, there are issues/concerns regarding the maven artifiacts. > The core issue is that currently it is not possible to 'require' both JDOM > 1.x and 2.x in your maven project. There appears to be only one solution to > this issue and that is to have different 'artifacts' for JDOM 1 and JDOM 2. > Obviously (in hindsight) it should have been done this way originally, but > there was simply not enough 'expert' feedback/input/assistance when the > decisions were being made, and this mistake is now something that just has > to be lived with. > > As a result, it appears necessary to deploy JDOM 2.0.2 to the maven > artifact 'jdom2' (previous versions were deployed to 'jdom'). > > While this change will make it possible to include both JDOM 1.x and 2.x > in your maven projects it will also introduce a number of irritating > side-effects: > > For 'regular' users, note: > 1. previous versions of JDOM 2.x were called jdom-2.0.0.jar and > jdom-2.0.1.jar. This new version will be called jdom2-2.0.2.jar, and the > 'zip' file will be called jdom2-2.0.2.zip > > For maven users, note: > > 1. if you have already incorporated JDOM 2.x in your project you should > update your dependency to be for artifact jdom2, not jdom > 2. ensure any maven project you require that also depends on JDOM aware of > this problem... because, if that required project 'upgrades' to the jdom > artifact version 2.0.1 (instead of jdom2) then you will get two different > versions of jdom 2.x in your classpath, and there is no telling what will > result..... > > > So, it is quite possible that by 'solving' the issue relating to requiring > both JDOM 1.x and 2.x, that we will instead be introducing even worse > problems, but I have been assured that this is the 'only' way to move > forward from here. > > If anyone has comments, concerns, suggestions, I am all ears. > > Rolf > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From mike at saxonica.com Thu May 31 00:59:48 2012 From: mike at saxonica.com (Michael Kay) Date: Thu, 31 May 2012 08:59:48 +0100 Subject: [jdom-interest] XPath examples In-Reply-To: <4FC68F44.9030801@tuis.net> References: <4FC68270.60005@tuis.net> <4FC68F44.9030801@tuis.net> Message-ID: <4FC724F4.8080901@saxonica.com> >> >> Do the variables have to be xpath values (i.e., in quotes), or can >> any part of the xpath expression be put into a variable? >> >> Peter Kronenberg Variables in XPath represent values, not fragments of expression text: XPath isn't like shell scripts where variables are essentially macros. So you can't put "+" or "-" into a variable $op and then do (3 $op 2). Because the language is orthogonal, a variable reference can be used anywhere an expression can be used. That rules out things like child::$e, a/$e (which becomes acceptable in XPath 2.0, but doesn't mean what people sometimes imagine), or $e(2) (which becomes acceptable in XPath 3.0, where functions are first-class values). Michael Kay Saxonica