On Thu, May 31, 2012 at 8:14 AM, Carol Frampton <[email protected]> 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 TLP. 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 build. 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 that. Greg
