incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carol Frampton <>
Subject Re: [MENTORS] Binary Files
Date Thu, 31 May 2012 19:36:50 GMT

Thank you for taking the time to look into this.

Alex and I talked this morning and we agree with you.  We will take the
jars out of our velocity and batik sources.  While we are not yet using
maven we will have an ant target that will go fetch all the jars needed to
build.  We are already doing that with many of the jars we use.

We're using very old versions of both velocity and batik (but the newer
versions I looked at seem to be doing it the same way).  Going forward we
need consider fixing the current situation or, it most likely will become
a non-issue when we switch to the Falcon compiler.


On 5/31/12 2 :54PM, "Greg Reddin" <> wrote:

>On Thu, May 31, 2012 at 8:14 AM, Carol Frampton <>
>> Sorry to keep asking the same question but I don't think I've gotten an
>> answer yet.  We just forked velocity/batik from their source kits.
>> source kits contains lots of dependent jars.  Can we leave the
>> velocity/batik structure as is in our source kit, including those jars,
>> do we have to "fix" them by removing all their dependent jars and
>> them as part of our build?  It seems sort of silly to have their source
>> but then have to download their source kit to extract those jars.
>I put some time into this and you're right. The Velocity project does
>not release a source-only build of the Velocity Engine. They have one
>distribution, which is labeled "Binaries and Sources". The distro
>includes all the JAR files as you mentioned above. However, if you dig
>deeper and download the sub-projects you'll see there's a separate
>source package for some of them: Velocity-Tools, for example. If you
>expand this package you'll see it does not contain any binary
>artifacts (that I could find).
>The Batik story is similar. The source distribution contains the JAR
>files you mentioned.
>My opinion is that these projects are not following accepted Apache
>practice. For an example of a project doing it right (IMO) download
>the Struts 2.3.4 source build. It contains three jars - all in test
>directories, all used for testing purposes. It's a Maven-based build
>so the Maven build will download all the dependencies (or, as Bertrand
>alluded to, you can download and host them yourself).
>So I feel we're in a bit of a quandary. We're doing some things that
>are not best practice. We're forking another project instead of
>extending it. It just so happens that the projects we're forking are
>also not following best practice. I feel we will have a difficult time
>getting a release through the Incubator with these JARs in it. I feel
>like these established Apache projects would also have a hard time
>getting a release through the Incubator - that's why the Incubator
>exists - to catch and fix these issues before promoting a project to
>So do we "fork it and fix it" or just fork it and try to push it
>through? I'm not sure if I can answer that question.
>> If even the binary kit can't contain dependent jars that means that you
>> can't run Flex "out of the box".  With our current setup it means you'd
>> have to have ant installed and run a target to download the dependent
>> jars.  Do you know of another Apache project that has to do this so I
>> take a look at it?
>Again, the Struts project requires you to have Maven installed to run
>the build. You can then either provide all the needed dependencies or
>let Maven grab them from the central repository. I haven't checked,
>but I'd assume even the HTTPD project has similar requirements.
>Certainly you'd have to have a C compiler and build tools installed.
>But with most C-based projects I've built from source you had to
>actually build and install the dependencies before you could run the
>Sorry I don't have a good answer for you, but I think the "right"
>answer is to list these JARs as dependencies and download them as part
>of the build. The question is whether we can get away with the easier
>path of leaving the forks as they are. I don't know the answer to

View raw message