I think I'll add another standard descriptor to the default bundle, and then projects can opt for the tar.gz simply by setting a property. I'm hesitant to start causing all projects to generate two copies of the source archives by default, since many of them seem happy with just a zip.
On Thu, Nov 4, 2010 at 2:28 PM, Henning Schmiedehausen <[email protected]> wrote: > That makes lots of sense to standardize. > > So, if we standardize, IMHO we should standardize on provide both. It > really is only a single line in the default assembly. No big deal. > > -h > > > > On Thu, Nov 4, 2010 at 12:59, Brian Fox <[email protected]> wrote: >>>> >>>> We need both zips and tars of the sources for the actual release (what we >>>> push to dist/). >> >>> Brian wants to know why. It certainly isn't mandated by the board. >> >> That gets me into trouble a lot of times. "Because we always have done >> it that way" is my favorite opportunity to ask why. You guys are >> certainly free to make tar.gz's if you want and I have nothing to say >> about it. However here's why I ask: >> >> We've tried to setup a standard profile in the apache pom that will >> meet the basic requirements for any Apache project using Maven to meet >> the things like LICENSE/NOTICE and signed source archives. So far, the >> zip has been sufficient for all the projects using it. I can't see any >> value in duplicating the source archive as a tar.gz because as I >> mentioned, it shouldn't normally have binaries and therefore the >> permissions are irrelevant. Since it's unlikely we would want to >> enable this for all projects, it means you would have to extend the >> profile in a way that causes you to diverge from the norm and it will >> make it harder to consume standard changes down the road. (in fact >> most of the troubles we've seen getting vfs released were related to >> undoing the legacy profile and using the standard one). >> >> So I wonder why a tar.gz sourceball is needed and is it worth it to >> diverge just for that. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
