xmlenc-devel Mailing List for xmlenc
Brought to you by:
znerd
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(30) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
|
2010 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <bf7...@si...> - 2009-11-05 18:20:04
|
021948 本站重金引進日片dvd25元,趕快近來瞧瞧!! 業界出貨最快~包裝隱密~品質保證~價格最低 業界最優質!商品一率採用硬紙盒安全包裝,絕對保密您的隱私! 高優質DVD,只需要25元,幾萬片優質影片任您挑選! 滿千元即可在贈送市價399高級情趣用品 按此可馬進上入!請點我^^~~把我帶回家! 如無法點選請點以下網址入內選購 http://snipurl.com/sh2q2 021948 |
From: <f0e...@si...> - 2009-10-20 00:42:23
|
業界出片速度最快,品質最好,售後服務最佳,價格最優惠, 本站絕不濫竽充數~由下列網址進入 "『完美陰莖戰鬥手冊』第三課讓你撐久久篇 085103"   "★w i i 遊 戲 情 報09年最 新情 報都到 齊了★ 085103"   "WII情`報 PSII情`報 X!BOX情`報攻略暑假Fun一夏 085103"   "網友期盼終於開通--正!台灣視訊妹!! 085103"   "情趣愛愛商品價格保證超級便宜,歡迎來比價~ 085103" 另有超夯A片線上看和下載全面免費085103 請在雅虎 搜尋上打『爆爆爽A片免費看 bbs3.x383.com/ds168』查詢網站085103 |
From: <vd4...@si...> - 2009-09-28 06:44:53
|
業界出片速度最快,品質最好,售後服務最佳,價格最優惠, 本站絕不濫竽充數~由下列網址進入 "美麗OL上班壓力大,找性按摩師解壓 145013"   "W i i 遊 戲 資 訊 攻 略超低70 145013"   "p s2 x b360 遊 戲 資 訊 攻 略超低80 145013"   "看 不 夠 嗎?一 對 一免 費視 訊讓 您絕 對滿 足 145013"   "G點用品、情趣按摩棒、男女用自慰套、棒、角色扮演道具、情趣娃娃…等 145013" 另有超夯A片線上看和下載全面免費145013 請在雅虎 搜尋上打『爆爆爽A片免費看 bbs3.x383.com/ds168』查詢網站145013 |
From: <shr...@si...> - 2009-09-16 03:32:28
|
業界出片速度最快,品質最好,售後服務最佳,價格最優惠, 本站絕不濫竽充數~由下列網址進入 "極品和服美女!光是淫叫聲就能讓你射 114021"   "★w i i 遊 戲 情 報09年最 新情 報都到 齊了★ 114021"   "★p s2 x b360 遊 戲 情 報09年最 新情 報都到 齊了★ 114021"   "看 不 夠 嗎?一 對 一免 費視 訊讓 您絕 對滿 足 114021"   "別家一模一樣的自慰飛機杯賣390元,我們只要230元~ 114021" 另有超夯A片線上看和下載全面免費114021 請在雅虎 搜尋上打『爆爆爽A片免費看 bbs3.x383.com/ds168』查詢網站114021 |
From: 01:46:06 <ww...@62...> - 2003-02-07 17:46:04
|
xml...@li... 您好! 以下深圳一家(噴畫﹐印刷)廣告製作廠的相關服務信息 希望能為你的需求帶來方便﹗ 噴畫服務 各類大小廣告宣傳畫面、海報、戶內外橫額、燈片、廣告展板等。 印刷服務 承印各類畫冊、企業簡介、產品樣本、說明書、招貼畫、包裝盒等。 同樣的質量,香港四分之一的價錢,可送貨到羅湖口岸或香港 詳細了解及合作方法敬請來信查詢! Dear Hong Kong compatriots: Thank you for your enquiries on our product. We are that an advertisement in Shenzhen make the factory. Hope that the information can bring convenience for you! Speciality of our factory: 1. Making of color page by printing 2. Making of color page by spray Including all kinds of paper printing, box, catalogue, poster, outdoor and indoor Banner, etc.. You can visit our home page www.6220610.com for more information. Welcome your quotation inquiry! Shen Zhen Advertising Factory E-mail: ww...@62... Web: http://www.6220610.com/ Fax: +86-0755-2635 8134 ICQ Number: 173161456 Msn Name : ww...@62... QICQ Number: 88680008 Welcome to contact us ! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-13 19:14:53
|
xmlenc 0.24 was just released. Changes: * Added method setEscaping(boolean) to XMLOutputter. Deprecated entityRef(String). * Removed init(Writer,String), setState(XMLOutputter.State) and getDepth() and XMLOutputterStates.INITIAL_STATE. All were deprecated. * Added method getVersion() to XMLOutputter. It returns the version of the xmlenc library. Ernst |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-13 07:59:40
|
xmlenc 0.23 was just released. Changes: * Added constructor XMLOutputter(Writer,encoding). * Added reset(Writer,encoding). Deprecated init(Writer,encoding). * Removed stag(String), etag() and all getInstance() methods. Ernst |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-13 07:38:51
|
> I disagree. I think the <tag attr="value"/> pattern is a real plus. It > shortens the length of the XML file considerably, especially if you use > this form a lot (I do) and if the "tag"s you use it with are long (many > of mine are). Keep in mind that most people will use XMLOutputter to > write to disk, and the time involved in disk writes will far outweigh > the time spent doing some logic to see what type of closing tag is > necessary. You'll have a more efficient outputter if you output shorter > XML, and I know efficiency is a primary design goal here. The following code: startTag("html"); attribute("lang", "en"); pcdata(""); endTag(); will produce: <html lang="en"></html> while this code: startTag("html"); attribute("lang", "en"); endTag(); still produces: <html lang="en"/> So the short form is still supported, but it won't be used when zero-length text is outputted using pcdata("") or whitespace(""). > Anyway, I think that at the level of XMLOutputter you should just output > whatever is sent. Omitting comments or elements if empty should probably > be handled at a higher level (the classes Henri is working on). Agreed. Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-13 07:35:39
|
> I also like the overloaded reset approach. I think reset() with no > arguments sets the member variables for Writer and Encoding to null, > right? In other words, it doesn't leave them as is for potential reuse. > So it requires a call to init() at a later time (useful in the pooling > scenario). Well, not init(Writer,String), but reset(Writer,String). The init method is now replaced with reset. > On a side note, XMLOutputter is a rather lightweight object, right? > Someone might pool the thing for reuse, but I don't think you'd gain the > same kind of benefit as you would from, say, pooling database > connections. I think the more likely reuse scenario would be to write > out several XML files in quick succession, perhaps when a user logs out > or his session times out on the server, or when a client-side program > exits. An XMLOutputter object is rather light, but it initially holds a stack for an element depth of 32. It increases with 100% each time (to 64, 128, 256, etc.) So the object is heavier if ever used with a deep document. I've chosen this approach because if ever one deep document is written, then it is likely that a document with a similar depth is written at a later stage. Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Pete C. <pe...@fi...> - 2003-01-10 22:11:50
|
Hi Ernst, > Example: > > startTag("html"); > attribute("lang", "en"); > pcdata(""); > endTag(); > > Currently (xmlenc 0.21) this would produce the following XML: > > <html lang="en"></html> > > But when VOID_WITHIN_ELEMENT is fully supported, then this would > produce: > > <html lang="en"/> > > Reconsidering this, I think I should not pursue this any further and > remove all evidence I ever did. It's just getting away from simplicity. I disagree. I think the <tag attr="value"/> pattern is a real plus. It shortens the length of the XML file considerably, especially if you use this form a lot (I do) and if the "tag"s you use it with are long (many of mine are). Keep in mind that most people will use XMLOutputter to write to disk, and the time involved in disk writes will far outweigh the time spent doing some logic to see what type of closing tag is necessary. You'll have a more efficient outputter if you output shorter XML, and I know efficiency is a primary design goal here. > The same applies to the short-circuiting when an empty string is > printed. > For example, currently (xmlenc 0.21) the following code: > > startTag("head"); > comment(""); > startTag("title"); > > produces the following XML: > > <head><title> > > instead of the (perhaps expected): > > <head><!----><title> > > I see no good reason to _keep_ the old behaviour. It's again > conflicting with the principle of simplicity. Here I'm fine. If some clown wants to output an empty comment, why not let him? In the past Henri and I have discussed an XML writing mode where empty elements are not written at all. I even put in a few kludge methods in my personal copy of XmlWriter like writeEmptyElementWithText(String tag, String text) and if text is null or "" then nothing is written. This is helpful in conserving file space for things like an optional second line of an address. Anyway, I think that at the level of XMLOutputter you should just output whatever is sent. Omitting comments or elements if empty should probably be handled at a higher level (the classes Henri is working on). I hope I understood your original note, and that this made some sense. Gratefully, Pete Cassetta pe...@fi... ------------------------------------------- Fingertip Software 433 Kitty Hawk Rd., Suite 216 P.O. Box 2487 Universal City, TX 78148 Orders: (800) 209-4063 -or- (210) 659-6832 Support: (210) 659-2532 Fax: (210) 659-8870 http://www.fingertipsoft.com ------------------------------------------- |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-10 21:14:55
|
Hey Pete, > What, exactly, does outputter.reset() do? Will it ever be called > independent of init()? If not, maybe it would be cleaner to instead do: The idea was that a worker thread could call reset() when it's done and then init() when it starts working again. For example when XMLOutputter instances are kept in a pool. > outputter.reset(writer, encoding); > > You could also overload it and have outputter.reset() for cases when you > don't need a different writer or encoding. I guess I'd like to see the > reuse case be done with a single method call if that makes sense, just > so people can't forget the reset() or the init(). I see your point. On the other hand I've got another requirement, and that is that it must be possible to create an XMLOutputter instance that has no Writer associated with it yet. So perhaps we should combine this with your suggestion and have: XMLOutputter() { ... } // State: UNINITIALIZED XMLOutputter(Writer, String) { ... } // State: BEFORE_XML_DECLARATION reset() { ... } // State: UNINITIALIZED reset(Writer, String) { ... } // State: BEFORE_XML_DECLARATION > I think this was a good idea though. I can envision cases when I'll need > to write several XML files at once, and this way I can reuse the > outputter(). (Maybe similar to a database connection or something.) Exactly. I really look forward to retesting the xmlenc performance with this new approach in place! Regards, Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-10 21:14:53
|
Hey, A while ago I've mentioned adding the state VOID_WITHIN_ELEMENT. This state would be entered when for example pcdata("") would be called in the state START_TAG_OPEN. This would make it possible to output a combined start/end tag instead of separate start/end tags. Example: startTag("html"); attribute("lang", "en"); pcdata(""); endTag(); Currently (xmlenc 0.21) this would produce the following XML: <html lang="en"></html> But when VOID_WITHIN_ELEMENT is fully supported, then this would produce: <html lang="en"/> Reconsidering this, I think I should not pursue this any further and remove all evidence I ever did. It's just getting away from simplicity. The same applies to the short-circuiting when an empty string is printed. For example, currently (xmlenc 0.21) the following code: startTag("head"); comment(""); startTag("title"); produces the following XML: <head><title> instead of the (perhaps expected): <head><!----><title> I see no good reason to _keep_ the old behaviour. It's again conflicting with the principle of simplicity. Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-10 21:14:52
|
Just released: xmlenc 0.22. Change log: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xmlenc/xmlenc/CHANGES?rev=HEAD&content-type=text/vnd.viewcvs-markup See: http://xmlenc.sourceforge.net/ Ernst |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-10 21:14:51
|
The suggested (simple) behaviour has been implemented in xmlenc 0.22, released a few hours ago. Ernst On Friday 10 January 2003 09:09, Ernst de Haan wrote: > Hey, > > > A while ago I've mentioned adding the state VOID_WITHIN_ELEMENT. This > state would be entered when for example pcdata("") would be called in the > state START_TAG_OPEN. This would make it possible to output a combined > start/end tag instead of separate start/end tags. > > Example: > > startTag("html"); > attribute("lang", "en"); > pcdata(""); > endTag(); > > Currently (xmlenc 0.21) this would produce the following XML: > > <html lang="en"></html> > > But when VOID_WITHIN_ELEMENT is fully supported, then this would produce: > > <html lang="en"/> > > Reconsidering this, I think I should not pursue this any further and > remove all evidence I ever did. It's just getting away from simplicity. > > The same applies to the short-circuiting when an empty string is printed. > For example, currently (xmlenc 0.21) the following code: > > startTag("head"); > comment(""); > startTag("title"); > > produces the following XML: > > <head><title> > > instead of the (perhaps expected): > > <head><!----><title> > > I see no good reason to _keep_ the old behaviour. It's again conflicting > with the principle of simplicity. > > > Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-10 21:14:48
|
This has been implemented. It will be released in 0.23. Ernst On Friday 10 January 2003 08:40, Ernst de Haan wrote: > Hey Pete, > > > What, exactly, does outputter.reset() do? Will it ever be called > > independent of init()? If not, maybe it would be cleaner to instead do: > > The idea was that a worker thread could call reset() when it's done and > then init() when it starts working again. For example when XMLOutputter > instances are kept in a pool. > > > outputter.reset(writer, encoding); > > > > You could also overload it and have outputter.reset() for cases when > > you don't need a different writer or encoding. I guess I'd like to see > > the reuse case be done with a single method call if that makes sense, > > just so people can't forget the reset() or the init(). > > I see your point. On the other hand I've got another requirement, and > that is that it must be possible to create an XMLOutputter instance that > has no Writer associated with it yet. So perhaps we should combine this > with your suggestion and have: > > XMLOutputter() { ... } // State: UNINITIALIZED > XMLOutputter(Writer, String) { ... } // State: BEFORE_XML_DECLARATION > > reset() { ... } // State: UNINITIALIZED > reset(Writer, String) { ... } // State: BEFORE_XML_DECLARATION > > > I think this was a good idea though. I can envision cases when I'll > > need to write several XML files at once, and this way I can reuse the > > outputter(). (Maybe similar to a database connection or something.) > > Exactly. I really look forward to retesting the xmlenc performance with > this new approach in place! > > Regards, > > > Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Pete C. <pe...@fi...> - 2003-01-10 17:11:50
|
Hi Ernst, > The idea was that a worker thread could call reset() when it's done > and then init() when it starts working again. For example when > XMLOutputter instances are kept in a pool. OK, I didn't think of this. It's a potentially useful scenario. > So perhaps we should combine this with your > suggestion and have: > > XMLOutputter() { ... } // State: UNINITIALIZED > XMLOutputter(Writer, String) { ... } // State: BEFORE_XML_DECLARATION > > reset() { ... } // State: UNINITIALIZED > reset(Writer, String) { ... } // State: BEFORE_XML_DECLARATION I like this. I would normally use the XMLOutputter(Writer, String) form. But the XMLOutputter scenario discussed above would prefer the no-argument constructor. I also like the overloaded reset approach. I think reset() with no arguments sets the member variables for Writer and Encoding to null, right? In other words, it doesn't leave them as is for potential reuse. So it requires a call to init() at a later time (useful in the pooling scenario). On a side note, XMLOutputter is a rather lightweight object, right? Someone might pool the thing for reuse, but I don't think you'd gain the same kind of benefit as you would from, say, pooling database connections. I think the more likely reuse scenario would be to write out several XML files in quick succession, perhaps when a user logs out or his session times out on the server, or when a client-side program exits. Gratefully, Pete Cassetta pe...@fi... ------------------------------------------- Fingertip Software 433 Kitty Hawk Rd., Suite 216 P.O. Box 2487 Universal City, TX 78148 Orders: (800) 209-4063 -or- (210) 659-6832 Support: (210) 659-2532 Fax: (210) 659-8870 http://www.fingertipsoft.com ------------------------------------------- |
From: Pete C. <pe...@fi...> - 2003-01-09 16:40:17
|
Ernst, > The old way of constructing an XMLOutputter object: > > XMLOutputter outputter = XMLOutputter.getInstance(writer, encoding); > > The new way: > > XMLOutputter outputter = new XMLOutputter(); > outputter.init(writer, encoding); > > And when you want to use the outputter for a new Writer: > > outputter.reset(); > outputter.init(writer, encoding); > > What do you think of the new way? What, exactly, does outputter.reset() do? Will it ever be called independent of init()? If not, maybe it would be cleaner to instead do: outputter.reset(writer, encoding); You could also overload it and have outputter.reset() for cases when you don't need a different writer or encoding. I guess I'd like to see the reuse case be done with a single method call if that makes sense, just so people can't forget the reset() or the init(). I think this was a good idea though. I can envision cases when I'll need to write several XML files at once, and this way I can reuse the outputter(). (Maybe similar to a database connection or something.) Gratefully, Pete Cassetta pe...@fi... ------------------------------------------- Fingertip Software 433 Kitty Hawk Rd., Suite 216 P.O. Box 2487 Universal City, TX 78148 Orders: (800) 209-4063 -or- (210) 659-6832 Support: (210) 659-2532 Fax: (210) 659-8870 http://www.fingertipsoft.com ------------------------------------------- |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-09 12:44:46
|
FYI: xmlenc 0.21 was just released. Ernst On Thursday 09 January 2003 08:39, Ernst de Haan wrote: > The new xmlenc 0.21 (not yet released) is going to introduce a new way of > dealing with XMLOutputter instances. The result is that it is possible to > re-use XMLOutputter objects. This should pootentially improve > performance, especially in server-environments. > > The old way of constructing an XMLOutputter object: > > XMLOutputter outputter = XMLOutputter.getInstance(writer, encoding); > > The new way: > > XMLOutputter outputter = new XMLOutputter(); > outputter.init(writer, encoding); > > And when you want to use the outputter for a new Writer: > > outputter.reset(); > outputter.init(writer, encoding); > > What do you think of the new way? > > > Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-09 10:22:28
|
> Between holidays and trying to get as much done as possible before our > (5th) baby comes (due in 4 1/2 weeks), I've let my XML enc/Writer > correspondence slip. Sorry about that. No problemo. Henri and I've been busy as well :) Welcome back. Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-09 10:22:25
|
The new xmlenc 0.21 (not yet released) is going to introduce a new way of dealing with XMLOutputter instances. The result is that it is possible to re-use XMLOutputter objects. This should pootentially improve performance, especially in server-environments. The old way of constructing an XMLOutputter object: XMLOutputter outputter = XMLOutputter.getInstance(writer, encoding); The new way: XMLOutputter outputter = new XMLOutputter(); outputter.init(writer, encoding); And when you want to use the outputter for a new Writer: outputter.reset(); outputter.init(writer, encoding); What do you think of the new way? Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Pete C. <pe...@fi...> - 2003-01-07 18:24:03
|
Hi Guys, Between holidays and trying to get as much done as possible before our (5th) baby comes (due in 4 1/2 weeks), I've let my XML enc/Writer correspondence slip. Sorry about that. I just read everything you two have posted, and I'm quite impressed with what you're up to Henri. My XML writing needs are still quite basic, so I don't have the same motivation as you to get all those new features going. But they will be of great help for many potential users. I'll have to grab the code and get a closer look at it. > Working now. I suspect it has issues, but I think I've tweaked and > murdered Pete's code enough that it seems to work on basic tests. Once things stabilize, I should probably revisit pretty printing. In order to reduce object creation and keep the code simple, you may recall I didn't handle XHTML-style documents nicely (where many nodes contain both text and elements). This should probably be rectified, and doing so may require adding some options to the constructor and/or via a method like setPrettyPrintOptions(). > Writer sw = new StringWriter(); > XmlWriter xw = new XmlEncXmlWriter(sw); > xw = new FormattingXmlWriter(xw).setDateFormat( > new java.text.SimpleDateFormat("yyyy-MM-dd")). > setNumberFormat(new java.text.DecimalFormat("#")); > xw = new EmptyElementXmlWriter(xw). > setEmptyMode(EmptyElementXmlWriter.NULL_EMPTY_MODE); > xw = new PrettyPrinterXmlWriter(xw); A bit messy/complex, but that's the price you pay for flexibility I guess. > [I've made all setXxx methods return their object. Probably breaks the > Bean-ness, but I'm treating this as a play with the method-chaining > viewpoint] > > or they could do: > > XmlWriter xw = XmlIO.prettyPrinter( > XmlIO.emptyElement( XmlIO.NULL_EMPTY_MODE, > XmlIO.formatted( "yyyy-MM-dd", "#", > XmlIO.xmlenc( new StringWriter() ) > ) > ) > ); Well, I for one applaud this breach of the bean rules. This makes the code much more readable. Keep up the great work. I'll try to keep in closer touch. Gratefully, Pete Cassetta pe...@fi... ------------------------------------------- Fingertip Software 433 Kitty Hawk Rd., Suite 216 P.O. Box 2487 Universal City, TX 78148 Orders: (800) 209-4063 -or- (210) 659-6832 Support: (210) 659-2532 Fax: (210) 659-8870 http://www.fingertipsoft.com ------------------------------------------- |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-06 16:39:52
|
> Yep, it works. Any chance of 0.20 too? Stable versions are probably > better to be published at maven. Done. Try fetching: http://xmlenc.sourceforge.net/xmlenc-0.20.jar Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-06 16:37:32
|
Hi Henri, > One thing, have you considered including the version number in the jar > name? > > ie) xmlenc-0.20.jar ? Why? > The Jar's manifest is also supposed to contain version info, but I must > admit that I just let Maven put this in for me. Will add this to the TODO list at sourceforge. Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-06 16:37:30
|
Henri, > > The Jar's manifest is also supposed to contain version info, but I must > > admit that I just let Maven put this in for me. > > Will add this to the TODO list at sourceforge. Done (in HEAD). Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |
From: Ernst de H. <znerd@FreeBSD.org> - 2003-01-06 16:37:29
|
Hey Henri, > proejct.xml I can say: > > I use xmlenc, version 0.20. And it will automatically grab it. Okay. Would it be good enough if I would upload a file to the sourceforge site with each release: http://xmlenc.sourceforge.net/xmlenc-${version}.jar ? If so, then that would solve the issue without having to rename files inside my .tar.gz. > I'd like to get a version of xmlenc up at ibiblio's maven site, which > might help advertise it as a side-effect. While they will accept any > naming scheme, it makes thigns a lot smoother if the naming scheme is > akin to theirs. This sounds like a valid reason to me :-) Ernst -- Ernst de Haan Development Team Leader Wanadoo Nederland B.V. The Lord has truly risen! Merry Christmas and a blessed New Year! |