incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carol Frampton <cfram...@adobe.com>
Subject Re: AW: AW: [MENTORS] Binary Files
Date Thu, 31 May 2012 17:53:24 GMT


On 5/31/12 11 :44AM, "christofer.dutz@c-ware.de"
<christofer.dutz@c-ware.de> 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
>functionality?
>
>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

Carol

>
>Chris
>
>
>-----Urspr√ľngliche Nachricht-----
>Von: Carol Frampton [mailto:cframpto@adobe.com]
>Gesendet: Donnerstag, 31. Mai 2012 16:09
>An: flex-dev@incubator.apache.org
>Betreff: Re: AW: [MENTORS] Binary Files
>
>
>
>On 5/31/12 9 :22AM, "christofer.dutz@c-ware.de"
><christofer.dutz@c-ware.de> 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.
>
>Carol
>>
>


Mime
View raw message