Ok ... that sounds like a sensible solution ... not pretty, but it should work without breaking stuff. Think I can sleep better knowing this ;-)
Chris -----Ursprüngliche Nachricht----- Von: Carol Frampton [mailto:[email protected]] Gesendet: Donnerstag, 31. Mai 2012 19:53 An: [email protected] Betreff: Re: AW: AW: [MENTORS] Binary Files On 5/31/12 11 :44AM, "[email protected]" <[email protected]> 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:[email protected]] >Gesendet: Donnerstag, 31. Mai 2012 16:09 >An: [email protected] >Betreff: Re: AW: [MENTORS] Binary Files > > > >On 5/31/12 9 :22AM, "[email protected]" ><[email protected]> 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 >> >
