incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Reddin <>
Subject Re: [MENTORS] Binary Files
Date Thu, 31 May 2012 18:54:58 GMT
On Thu, May 31, 2012 at 8:14 AM, Carol Frampton <> wrote:
> 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.  Their
> source kits contains lots of dependent jars.  Can we leave the
> velocity/batik structure as is in our source kit, including those jars, or
> do we have to "fix" them by removing all their dependent jars and download
> 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 can
> 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