Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: "christofer.dutz@c-ware.de" <christofer.dutz@c-ware.de>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Fri, 1 Jun 2012 09:33:00 +0200
Subject: AW: AW: AW: [MENTORS] Binary Files
Thread-Topic: AW: AW: [MENTORS] Binary Files
Thread-Index: Ac0/VkfRnnU81FuuQo+293sQuu539wAcmYDA
Message-ID: 
 <66E38C42347D6446BF7FCB22C3D3878072CC38EF92@ECCR06PUBLIC.exchange.local>
References: 
 <66E38C42347D6446BF7FCB22C3D3878072CC38EF4E@ECCR06PUBLIC.exchange.local>
 <CBED271F.15BCF%cframpto@adobe.com>
In-Reply-To: <CBED271F.15BCF%cframpto@adobe.com>
Accept-Language: de-DE
Content-Language: de-DE
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Ok ... that sounds like a sensible solution ... not pretty, but it should w=
ork without breaking stuff. Think I can sleep better knowing this ;-)

Chris

-----Urspr=FCngliche Nachricht-----
Von: Carol Frampton [mailto:cframpto@adobe.com]=20
Gesendet: Donnerstag, 31. Mai 2012 19:53
An: flex-dev@incubator.apache.org
Betreff: Re: AW: AW: [MENTORS] Binary Files


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

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

Carol

>
>Chris
>
>
>-----Urspr=FCngliche 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=20
>>from trusted sources by default, but allow people to supply their own=20
>>binaries if they want."
>>
>>It would also make the step of mavenizing a SDK release obsolete. I=20
>>would definitely vote for this (If I'm allowed a vote) ;-) I too would=20
>>suggest to avoid binary dependencies. The problem is that Adobe=20
>>patched quite a lot of Jars so substituting them with the default ones=20
>>doesn't seem possible. And Adobe even stated that they will not=20
>>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=20
>modified jars are build as part of the Flex build.
>
>
>>So mabe it is neccesary to distribute some libs in binary form, but I=20
>>would assume that it would be better to check if it is actually=20
>>nessecary to have patched versions at all ... I would assume that=20
>>these patches were needed because of bugs in the third party modules=20
>>and are eventually fixed or adobe used them third party libs wrong=20
>>(Just an assumption).
>
>From my brief look at the changes it looks like we added some extended=20
>functionality which the devs didn't believe were general purpose enough=20
>to be contributed back to Apache.
>
>Carol
>>
>