Thanks, but I'm still not sure I'll change anything in VFS. I prefer having both the source and binary archives built in the same project. With the change to the Apache pom the source archive is built in the parent and the binary is built in the dist project. As we also discussed, it may be possible to get the assembly plugin to work correctly in Maven 3. If that happens I will gladly remove the dist project and move building the binary distribution to the parent project and let the source distribution be constructed as you describe here.
The real topic of this thread though, is what to include in the binary distribution archive. I'm planning on including the source and javadoc jar in VFS since it doesn't appear the community wants to set guidelines for all of commons. Ralph On Nov 23, 2010, at 6:48 AM, Brian Fox wrote: > Ralph, > We made the change to easily allow projects to select the tar.gz & zip > source distribution now and it's being staged for a vote today: > http://svn.apache.org/viewvc?view=revision&revision=1038139 > > Once this is released and you update to the new Apache pom, you can > select the tar.gz assembly simply by adding this property: > <sourceReleaseAssemblyDescriptor>source-release-zip-tar</sourceReleaseAssemblyDescriptor> > > Then you can get rid of the duplicated assembly.xml setup we added at > ApacheCon and the associated assembly plugin config. > > > On Thu, Nov 18, 2010 at 7:20 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >> On 11/18/10 10:27 AM, Mark Thomas wrote: >>> >>> On 18/11/2010 15:11, Ralph Goers wrote: >>>> >>>> It would be good to have a definitive position on this. >>> >>> The definitive ASF position is: >>> - the ASF releases source code >>> - the src release should contain everything needed to build >>> - binary releases are optional >>> - binary releases, if provided, should be derivable from the src release >> >> +1 - and the actual release is what we put on dist/. >> Traditionally we have provided both source and binary distributions there, >> archived as gzipped tars and zip files. >> >> We have never had hard rules on what is required in Commons releases other >> than the above (and NOTICE, LICENSE and headers stuff) and I am -1 on adding >> them now. I don't even think we should *require* maven artifacts; though >> RMs are encouraged to publish them or ask others to help. Again, the actual >> release is the zips and tarballs available on the download pages. And in >> fact the source is what is actually being released - the binaries are a >> convenience for users. >>> >>> (I know - the above list misses out a bunch of stuff) >>> >>>> The VFS build includes the javadoc and source jars in the distribution >>>> zip, even though there is a separate source distribution zip (the source >>>> distribution is complete while the source jar is only suitable for use by >>>> an >>>> IDE). I'm close to doing another release attempt and would like to know if >>>> I >>>> need to change that before I do it. >>> >>> Projects are free to impose additional restrictions on themselves if >>> they wish. >>> >>> From an ASF perspective you are fine. >>> >>> From a Commons perspective, ENOCLUE. In your shoes, and in the absence >>> of a documented Commons policy on exactly what should and should not be >>> in a binary distribution, I'd go with whatever you think is best and if >>> folks don't like it they are free to provide patches for the next release. >> >> It is up to the RM what additional jars to put into the binary release. >> Obviously, the RM should listen to the community. Since it is dead easy to >> include javadoc and sources jars in maven-generated releases, and some users >> seem to like them, I personally include them for the releases that I cut. >> >> Phil >>> >>> Mark >>> >>>> >>>> Ralph >>>> >>>> >>>> On Nov 18, 2010, at 3:37 AM, Phil Steitz wrote: >>>> >>>>> On 11/18/10 5:04 AM, sebb wrote: >>>>>> >>>>>> On 18 November 2010 07:22, Oliver Heger<oliver.he...@oliver-heger.de> >>>>>> wrote: >>>>>>> >>>>>>> Build works fine with JDK 1.5 on Windows 7. Artifacts look good. >>>>>>> >>>>>>> The only nitpick I found is that the binary distribution does not >>>>>>> contain >>>>>>> the source and Javadocs jar. >>>>>> >>>>>> That's deliberate. >>>>>> >>>>>> It contains the Javadocs as individual files, so including the javadoc >>>>>> jar is just wasted space, and if users want the source they can >>>>>> download the source archive. >>>>>> >>>>>> As far as I was aware, the source and javadocs jars are intended for >>>>>> Maven distribution only >>>>> >>>>> >>>>> Personally I am fine not including these jars; but IIUC the reason >>>>> people started including them a couple of years back was to make it easier >>>>> for users using IDEs that make use of them. >>>>> >>>>> Not voting yet because I have not tested the release yet. >>>>> >>>>> Phil >>>>>> >>>>>>> So +1. >>>>>> >>>>>> Thanks. >>>>>> >>>>>>> Oliver >>>>>>> >>>>>>> Am 17.11.2010 02:27, schrieb sebb: >>>>>>>> >>>>>>>> This is a vote to release Apache Commons NET 2.2 based on RC3. >>>>>>>> >>>>>>>> Changes since RC1 are: >>>>>>>> - drop unnecessary jars from binary archive >>>>>>>> - include RELEASE-NOTES in binary and source archives >>>>>>>> >>>>>>>> [ ] +1 release it >>>>>>>> [ ] +0 go ahead I don't care >>>>>>>> [ ] -1 no, do not release it because... >>>>>>>> >>>>>>>> tag: >>>>>>>> http://svn.apache.org/repos/asf/commons/proper/net/tags/NET_2_2_RC3/ >>>>>>>> >>>>>>>> site: http://people.apache.org/~sebb/NET_2_2_RC3/ >>>>>>>> >>>>>>>> Archives (Maven and non-Maven) have been uploaded to: >>>>>>>> >>>>>>>> >>>>>>>> https://repository.apache.org/content/repositories/orgapachecommons-011/ >>>>>>>> >>>>>>>> Vote will remain open for at least 72 hours. >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
