Oops - sorry about my strange numbering sequence. I moved things around but forget to renumber.
The guy who most recently reported a problem may well want to use our next dev release to try and load his project. Should we not try and get (3) in as a stop-gap solution till we have something better? Regards Bob On 2 January 2012 15:54, Linus Tolke Tigris <[email protected]> wrote: > Hello Bob! > > Generally I think that we should avoid implementing or including functions > that are already part of the jre distributions. I have had serious thoughts > on removing log4j in favor of the new (in jre1.4?) logging api. If this was > the only consideration alternatives 3) and 4) are the way forward. > > There are other considerations, as you point out. Specifically the time > constraint. > > I suggest that we set the ambition to alternative 3). If we, when we get > closer to the next stable release, have not yet managed to solve this, we > could make a quick fix to implement alternative 1. > > /Linus > > > 2012/1/2 Bob Tarling <[email protected]> > >> We have a historical issue with the 1.3 to 1.4 conversion giving errors >> on large files >> >> Most recently issue 6383 has been reported ( >> http://argouml.tigris.org/issues/show_bug.cgi?id=6383) >> >> We have previous issues 3992, 4188, 5188 >> >> I've discovered replacing Suns default xalan processor with an old >> version of Saxon resolves this problem. >> >> How should we move forward on this? >> >> Options I see. >> >> 3) Fix the stylesheets so that they work with xalan >> >> The obvious favourite choice but I think if we understood the issue we >> would have done this already. >> >> 1) Distribute Saxon B and continue to use this for XSLT processing >> >> Simplest option. >> >> Disadvantage is lack of support. Saxon has dropped some functionality >> that we are using from their latest releases. This is from their website. >> >> Saxon-HE does not offer all the capabilities that were present in >> Saxon-B. Most notably, support for Saxon extension functions and other >> extensions was dropped, as was the capability for writing extension >> functions that rely on dynamic loading of Java or .NET code (a new facility >> for "integrated extension functions" is however available). Users whose >> code relies on these features of Saxon-B should either purchase the >> Professional Edition product or stick with Saxon-B: the latest release of >> Saxon-B is 9.1.0.8, and although there are no plans to develop it further >> or maintain it, it will remain available indefinitely. >> >> 2) Fix the stylesheets so that they are compatible with Saxon HE and >> distribute that. >> >> At least we are now fully supported but we have more work to do in some >> complex stylesheets and still need to distribute Saxon. I'm not sure if the >> xslt extensions used can be replaced easily with standard xslt. >> >> 4) Drop the UML1.3 to UML1.4 conversion from the standard ArgoUML >> distribution and move it to an optional module. >> >> If a user tries to load a 1.3 file then they would be prompted to >> download and install this module. >> >> Advantage - smaller footprint for core ArgoUML with Saxon only in the >> module download. >> >> Disadvantage - another module to maintain. >> >> >> Any thoughts....? >> > > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2903733 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
