Sure! What can I do?
/Linus
2012/1/2 Bob Tarling <[email protected]>
> 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=2903752
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]]
