incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject AW: AW: AW: [MENTORS] Binary Files
Date Fri, 01 Jun 2012 07:33:00 GMT
Ok ... that sounds like a sensible solution ... not pretty, but it should work without breaking
stuff. Think I can sleep better knowing this ;-)


-----Urspr√ľngliche Nachricht-----
Von: Carol Frampton [] 
Gesendet: Donnerstag, 31. Mai 2012 19:53
Betreff: Re: AW: AW: [MENTORS] Binary Files

On 5/31/12 11 :44AM, ""
<> wrote:

>Ok ... but actually using the default version seems to be the better way.
>If the originals are flawed it would be good to file bug-reports with 
>the original project and help them fix those problems.
>If they are simply inconveniancies, I would suggest to implement 
>workarounds ... using patched jars sort of gives me a really bad feeling.
>Especially if you could end up in Classloading version problems since 
>we don't have separate classloaders.
>I read in one of the Adobe developer forums that they didn't publish 
>their changes, because they thought of their code as hackish and crappy 
>... (It was an official Adobe developer stating this).
>If it's extended features, wouldn't it be better to strip that out into 
>a separate jar-file or (if that's not possible) to contribute that 
>It's just because I'm really traumatized with classloading issues I had 
>in the past because of patched jar files ;-)

The are in different packages since they were forked per Bertrand's suggestion.  import org.apache.velocity/batik
-> org.apache.flex.forks.velocity/batik


>-----Urspr√ľngliche Nachricht-----
>Von: Carol Frampton []
>Gesendet: Donnerstag, 31. Mai 2012 16:09
>Betreff: Re: AW: [MENTORS] Binary Files
>On 5/31/12 9 :22AM, ""
><> wrote:
>>"Having a similar setup for Flex would be ok IMO: download binaries 
>>from trusted sources by default, but allow people to supply their own 
>>binaries if they want."
>>It would also make the step of mavenizing a SDK release obsolete. I 
>>would definitely vote for this (If I'm allowed a vote) ;-) I too would 
>>suggest to avoid binary dependencies. The problem is that Adobe 
>>patched quite a lot of Jars so substituting them with the default ones 
>>doesn't seem possible. And Adobe even stated that they will not 
>>publish their changes as the changes are far too ugly to be published.
>I believe you are talking about the velocity, batik and xerces changes.
>The source of all these changes will be in the Flex src kit so the 
>modified jars are build as part of the Flex build.
>>So mabe it is neccesary to distribute some libs in binary form, but I 
>>would assume that it would be better to check if it is actually 
>>nessecary to have patched versions at all ... I would assume that 
>>these patches were needed because of bugs in the third party modules 
>>and are eventually fixed or adobe used them third party libs wrong 
>>(Just an assumption).
>From my brief look at the changes it looks like we added some extended 
>functionality which the devs didn't believe were general purpose enough 
>to be contributed back to Apache.

View raw message