* Allowing consumers of XmlFile to disable fsync(2).
* Stop using Unix-specific terminology
* Jesse feels that this would be more natural as a constructor parameter
* Place Javadoc on constructor to make warning visible to callers
Changed all explicit references of the hierarchical driver to use a static
convinience method XStream2.getDefaultDriver() to ensure all XML operations
are using the same driver.
- switched to KxmlDriver (needed for xml 1.1 support)
- updated to create xml v1.1 headers
- updated test to use KXml2Driver explicitly
- updated unit tests to support xml v1.1
* Clean up usages of IOUtils.closeQuietly and related calls predating Java 7.
* Review comments from @oleg-nenashev.
* Noticed another place where try-with-resources would protect against a potential leak.
* Update XStream drive to improve performance in xml serilization/deserialization
According XStream FAQ (http://x-stream.github.io/faq.html#Scalability):
XStream is a generalizing library, it inspects and handles your types on
the fly. Therefore it will normally be slower than a piece of optimized
Java code generated out of a schema. However, it is possible to increase
the performance anyway:
* Write custom converters for those of your types that occur very often in
your XML.
* Keep a configured XStream instance for multiple usage. Creation and
initialization is quite expensive compared to the overhead of XStream
when calling marshall or unmarshal.
* Use Xpp3 or StAX parsers.
So, I decided to move from old Xpp to new Xpp3.
* Change other occurance of XppDriver to Xpp3Driver as well
I'd like to believe that the original reason was because earlier
versions of XStream that we used early on didn't support the methods
that take InputStream as a parameter.
https://www.dev.java.net/svn/hudson/branches/multiple-update-sources
........
r23183 | abayer | 2009-10-25 11:53:17 -0700 (Sun, 25 Oct 2009) | 1 line
First chunk of work towards supporting multiple update centers - infrastructure in place for it, and default update center treated as only one of multiple - have to use slightly modified update-center.json though
........
r23185 | abayer | 2009-10-25 12:25:49 -0700 (Sun, 25 Oct 2009) | 1 line
a number of tweaks - among other things, now works properly with additional update centers defined in hudson.model.UpdateCenter.xml - try using http://andrewbayer.com/images/hello-world/helloWorld-update-center.json as second update center
........
r23245 | abayer | 2009-10-27 13:45:25 -0700 (Tue, 27 Oct 2009) | 1 line
Modified to support existing default update-center.json
........
r23256 | kohsuke | 2009-10-27 18:30:15 -0700 (Tue, 27 Oct 2009) | 7 lines
- moved data binding of update-center.json to UpdateSource.
- moved some of the UpdateSource property into JSON, to improve the user experience when adding an update source.
the user should just type in one URL, and everything else should happen automatically.
- it doesn't make sense for UpdateSource to rely on UpdateCenterConfiguration, since behaviors cannot be
modified per UpdateSource basis. Instead, leaving it in UpdateCenter allows us to maintain backward compatible
behaviors with the existing custom UpdateCenterConfiguration implementation.
........
r23266 | kohsuke | 2009-10-27 19:29:24 -0700 (Tue, 27 Oct 2009) | 1 line
serve id inside JSON.
........
r23279 | kohsuke | 2009-10-28 10:44:00 -0700 (Wed, 28 Oct 2009) | 1 line
Do not special-case "default" ID. Receive hudson.war updates from wherever that provides one.
........
r23280 | kohsuke | 2009-10-28 10:50:57 -0700 (Wed, 28 Oct 2009) | 1 line
formatting change.
........
r23281 | kohsuke | 2009-10-28 11:30:40 -0700 (Wed, 28 Oct 2009) | 1 line
typo
........
r23282 | kohsuke | 2009-10-28 11:45:06 -0700 (Wed, 28 Oct 2009) | 2 lines
- added the UI to remove sites.
- persistence of UpdateSource happens more automatically now.
........
r23283 | kohsuke | 2009-10-28 11:50:04 -0700 (Wed, 28 Oct 2009) | 1 line
UpdateSource -> UpdateSite to align terminology with Eclipse.
........
r23284 | kohsuke | 2009-10-28 11:55:03 -0700 (Wed, 28 Oct 2009) | 5 lines
Actually, for now, just having a programmatic modification to UpdateSite would satisfy the primary use case.
And I'd like to upgrade YUI to a more recent version so that we can use its DataTable for UI. Plus the single update center model encourages the community to bring the code into the Hudson project, which is something we'd like to keep.
So all in all, I'm postponing the UI work.
........
r23286 | kohsuke | 2009-10-28 13:07:19 -0700 (Wed, 28 Oct 2009) | 1 line
Renaming and bug fixes.
........
git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@23326 71c3de6d-444a-0410-be80-ed276b4c234a
Basil Crow