On 21 January 2014 16:28, Gary Gregory <garydgreg...@gmail.com> wrote: > On Tue, Jan 21, 2014 at 11:10 AM, sebb <seb...@gmail.com> wrote: > >> On 21 January 2014 03:21, Gary Gregory <garydgreg...@gmail.com> wrote: >> > On Thu, Jan 16, 2014 at 7:49 PM, Gary Gregory <garydgreg...@gmail.com >> >wrote: >> > >> >> Sebb, >> >> >> >> Please modify the POMs and whatever else as you see fit. >> >> >> >> It sure would be nice to release 2.1. >> >> >> > >> > Sebb, >> > >> > When do you think you'll be able to put time in? The multi-module stuff >> is >> > daunting. I just RM'd a release of HttpCommons HttpClient and it would >> not >> > have been possible without the wiki docs. >> >> I have done some work on this.I can fix up the poms so that the >> Commons "release" profile works. >> > > Thank you. > > >> And it looks like the distribution module is not really needed. The >> assembly plugin can be run from the top level pom. >> >> I'm wondering whether VFS really needs to use multiple modules at all. >> > > Probably not. > > >> >> The examples could certainly be merged into the main module, > > > I imagine they would then end up in the test jar. >
Not necessarily; that depends on how the pom is set up and where the code is moved. I don't think it makes sense to put examples in the test jar. The example sources can be usefully included in the binary archive. Whether there is any need for example binaries depends on whether the examples actually work as is. For example, the Net examples can be run directly from the command-line. >> and the >> distribution module is not really needed. >> That just leaves the sandbox module. >> >> Does the sandbox module have any use as part of the proper component? >> > > These are works in progress or works that depend on jars with third party > incompatible licensing. Or perhaps works that are hard to test. > > It does not seem to be included in any releases - it is only present in SVN. >> > > Right. > > >> Would it be better as an actual sandbox component? >> > > Depending on the licensing issue, they could be folded in the test jar. The test jar should be for unit tests only. > >> Or if the classes are useful, perhaps they should be merged into core? >> > > As noted above it depends on what to do with code that depends on a third > party jar that has an incompatible license. The Java code is ASL 2 IIRC so > the issue is whether it is OK to distribute code that depends on a third > party jar which may have an incompatible license. Depends. It is possible to provide code to link to GPL code, so long as downloading the GPL code is optional. The component must be usable without the GPL code, i.e. it can depend on it for optional functions only. And of course the GPL code must not be distributed in releases. So it ought to be OK to flag those jars as "provided" However: is there anything in the Sandbox that warrants the extra work to include the code in a release? AFAICT, the code has not yet been included in any existing releases. > Gary > >> >> Note that Commons Net does not use modules, but does release its >> examples separately, if that was still required. >> >> > Thank you, >> > Gary >> > >> > >> > >> >> >> >> Gary >> >> >> >> >> >> On Thu, Jan 16, 2014 at 7:22 PM, sebb <seb...@gmail.com> wrote: >> >> >> >>> At present, the VFS poms use the "apache-release" profile from the >> >>> Apache pom, and override some bits of it that don't suit Commons. >> >>> >> >>> However, this is also done by the Commons parent pom which provides >> >>> its own "release" profile. >> >>> >> >>> This is not ideal as VFS uses a different process for releasing code >> >>> from all other Commons components. >> >>> >> >>> VFS is a multi-module project, which makes it a bit trickier to deal >> >>> with assemblies etc. >> >>> >> >>> However as far as I can tell, it is relatively simple to fix VFS. >> >>> >> >>> Change VFS parent pom to disable the assembly plugin for itself and >> >>> all inheriting poms >> >>> >> >>> Change VFS distribution pom to re-enable the assembly plugin and >> >>> change the profile "apache-release" to "release" >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>> >> >>> >> >> >> >> >> >> -- >> >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> >> Java Persistence with Hibernate, Second Edition< >> http://www.manning.com/bauer3/> >> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> >> Spring Batch in Action <http://www.manning.com/templier/> >> >> Blog: http://garygregory.wordpress.com >> >> Home: http://garygregory.com/ >> >> Tweet! http://twitter.com/GaryGregory >> >> >> > >> > >> > >> > -- >> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> > Java Persistence with Hibernate, Second Edition< >> http://www.manning.com/bauer3/> >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> > Spring Batch in Action <http://www.manning.com/templier/> >> > Blog: http://garygregory.wordpress.com >> > Home: http://garygregory.com/ >> > Tweet! http://twitter.com/GaryGregory >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
