On Wed, 2013-06-12 at 16:00 -0400, Gary Gregory wrote: > On Wed, Jun 12, 2013 at 3:46 PM, Oleg Kalnichevski <[email protected]> wrote: > > > On Wed, 2013-06-12 at 11:49 -0400, Gary Gregory wrote: > > > On Wed, Jun 12, 2013 at 11:30 AM, Oleg Kalnichevski <[email protected] > > >wrote: > > > > > > > On Wed, 2013-06-12 at 11:21 -0400, Gary Gregory wrote: > > > > > On Wed, Jun 12, 2013 at 11:15 AM, Oleg Kalnichevski < > > [email protected] > > > > >wrote: > > > > > > > > > > > On Wed, 2013-06-12 at 11:10 -0400, Gary Gregory wrote: > > > > > > > Can I step back a second and ask why we are not sharing a > > > > checkstyle.xml > > > > > > > file, for example, the way we do it in Log4j 2, which is also a > > > > > > > multi-module project? > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > That is the whole point of publishing module: to make it re-usable > > as a > > > > > > binary artifact by all HC projects. > > > > > > > > > > > > > > > > I understand the point of it, but it sure seems more complicated that > > > > just > > > > > having a file sitting in the root directory. > > > > > > > > > > > > > In the root directory of what exactly? We now have 4 (or maybe even > > > > more) instances of hc-stylecheck.xml sitting around in various > > > > directories. > > > > > > > > > > Ah, I just looked at the directory layout of log4j2 vs. httpcomponents > > and > > > I see that both projects have a different approach to laying out modules. > > > > > > Log4j2 puts the 'project file' at the root and the submodules in > > > subdirectories. > > > > > > Gary > > > > > > > Gary, > > > > Obviously this approach works well for a group of modules that share the > > same release cycle. In HC land we have three components with different > > release cycles which makes our situation considerably more complex. > > > > Check. FWIW, I've always found the current release model unclear. I do not > feed I can guarantee that core 4.2.x works with client 4.2.y or other > combinations. The only thing I can be guaranteed is that the stack works as > defined by the deps in the POMs. > > For me at least, I'd be happy to link to a httpcomponents-all 4.3, get > all-in-one jar and be done with it, > > But hey, that's just me :) > > Gary >
HC stable branches are not meant to have any public visible changes are meant for bug fixes only. Likewise stable releases should never depend on releases from a development branch. Everything in this life has pros and cons. Big über all-in-one jars make some things easier and others more difficult like management of transitive dependencies. Same goes for one release cycle for distinct group of components. One release cycle basically means that while core components undergo a lot of changes, client components cannot be released with a lower, more stable version, and vice versa. All comes with a price. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
