As I see it, the problem with the experimental branch is that we haven't yet "flipped" the configuration so that everything is based on a HierarchicalConfiguration nor have we gotten rid of the attribute splitting stuff. The reloading is mostly a problem with how CombinedConfiguration works - having the combination point into the trees of the various configurations makes reloading a nightmare.
As for 2.0 - I first need to finish the VFS release so we can release 1.7. I'm not happy with the way I have to generate release notes but I haven't had time to create a plugin to do it correctly, primarily because the changes plugin wasn't designed to allow another plugin to make use of its functionality. Ralph On Feb 16, 2011, at 11:04 PM, Oliver Heger wrote: > Am 17.02.2011 02:10, schrieb Ralph Goers: >> Thanks. But I have a larger issue. >> >> We have been doing performance testing and the synchronization in >> AbstractFileConfiguration, DynamicCombinedConfiguration, and >> MultiFileHierarchicalConfiguration are showing up as predominant hot spots. >> These would be easy to fix if I could use java.util.concurrent but, of >> course, that would require an upgrade to Java 5. The experimental branch has >> a minimum version of Java 5 but it is nowhere near ready for a release. I'm >> wondering when the right time to upgrade would be? 1.8? >> >> Ralph >> > > This is really a good question. AFAIK other Commons components switched to > Java 1.5 only in a major release, but given the current situation with end of > support for older JDKs, it may be worth starting a new discussion. > > OTOH I would not have a major problem with switching to Java 1.5, doing some > slight API improvements by introducing generics etc., and calling this > version 2.0. (Maybe we have then again a discussion whether package names > must be changed.) > > I am not very happy with the experimental branch, too. If time permits, I > would like to start something new in the sandbox from scratch to overcome > some of the problems in our current design (e.g. the tight coupling of the > reloading mechanism which causes these synchronization problems). > > Oliver > >> On Feb 16, 2011, at 1:48 PM, Jörg Schaible wrote: >> >>> Hi Oliver, >>> >>> Oliver Heger wrote: >>> >>>> Am 16.02.2011 22:05, schrieb Rahul Akolkar: >>>>> On Wed, Feb 16, 2011 at 3:45 PM, Oliver Heger >>>>> <oliver.he...@oliver-heger.de> wrote: >>>>>> Am 15.02.2011 21:23, schrieb Oliver Heger: >>>>>>> >>>>>>> Am 10.02.2011 13:09, schrieb sebb: >>>>>>>> >>>>> <snip/> >>>>>>>> >>>>>>>> FYI: >>>>>>>> >>>>>>>> Note that the Commons Parent POM was changed some while ago to add >>>>>>>> profiles java-1.4, java-1.3 etc. which change the Java version used >>>>>>>> for compile and test without needing to change the JVM used to run >>>>>>>> Maven itself. >>>>>>>> >>>>>>>> See >>>>>>>> >>>>>>>> http://commons.apache.org/commons-parent- >>> pom.html#Testing_with_different_Java_versions >>>>>>>> >>>>>>> >>>>>>> Thanks for the pointer. I will try to exclude the affected classes if >>>>>>> the profile for Java 1.4 is active. >>>>>>> >>>>>> >>>>>> Just an update: I have added a profile which excludes the problematic >>>>>> classes when building under JDK 1.4. With the current version of the pom >>>>>> it is possible to run the following command successfully: >>>>>> >>>>>> mvn clean package -Pjava-1.4 >>>>>> >>>>>> However, what does not work is the following: If you first build without >>>>>> the profile (using Java 1.5+), you cannot simply run >>>>>> >>>>>> mvn test -Pjava-1.4 >>>>>> >>>>>> (i.e. simply running tests without compiling). Test execution is aborted >>>>>> immediately with a bad class version error, although I excluded the >>>>>> classes in the configuration of the surefire plug-in. No idea why this >>>>>> is the case. >>>>>> >>>>> <snap/> >>>>> >>>>> The sources are already compiled using the higher JDK by then (and mvn >>>>> test won't clean that compile run). >>>>> >>>>> -Rahul >>>>> >>>> Yes, but I hoped that the excluded classes would not be loaded at all, >>>> so it would not be a problem that they have been compiled on a higher >>>> JDK. But obviously surefire works in a different way. >>> >>> You did not exclude the .class files and forgot the anonymous classes ... >>> ;-) >>> >>> Fixed, tests succeed. >>> >>> - Jörg >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
