I think I'll tend towards agreeing with Jochen here, rather get half the modules out early than fight ourselves with versioning workarounds if the rest of the modules are not ready for prime time.
However I see concerns of selective "part releases" and reproducible builds, so I would do this using Maven profiles - the release profile can have a smaller <modules> set. I then think all the modules that appear in the src release should also go to Nexus as binaries, even if they are more exotic "internal" modules. I would not mess around with selective deployment as it is a recipe for maintenance nightmare and manual mistakes. It only gets tricky if the leftover modules get a release cycle of their own. It is OK if the -bin release don't have all modules, that is more of a convenience of jars that are useful out of the box. I've been thinking for Commons RDF it would make sense to have a bin with the commons-rdf-api.jar and commons-rdf-simple.jar as they have no external dependencies - the remaining Integration modules require a large set of deps and mostly useful through Maven. (OSGi folks might still like the extra jars as they are bundles) On 25 Nov 2016 11:47 am, "Jochen Wiedmann" <jochen.wiedm...@gmail.com> wrote: > Hi, Gary, > > > I humbly disagree on your response to Gilles questions. In more detail: > > > a. Is it OK if the official release does not contain (5) and (6)? > [Rationale is that it would allow to make changes without > bothering about compatibility with _unintended_ uses.] > > A release is a release, because it fulfills the typical requirements > (ASL licensed, source first, binary is for convenience only, > LICENSE.txt, and NOTICE.txt, etc.) > and, most importantly, because the PMC endorses it as such. > > I can't think of any reason, why the PMC should refuse a release, if > it fulfills the requirement, just because the source release can be > used to build four jars only, and not six. At least, I'd be glad to > vote +1 in such a case. > > That being said, and having had the experience of a multi-module > project (Apache RAT) in the past, I strongly recommend that RNG > > - abstains from full releases (all six jar files) and > - starts by pushing out single jar files by default (in whatever order > seems to make sense). (Possibly more than one at once, okay.) > > Otherwise, I have learned that the hurdle to push out a release can > become overwhelming, and leads to deferring releases endlessly. Forget > "release early, release often". > > Besides, you'd have to maintain varying build scripts, or even worse: > Create individual build scripts, depending on what is being released. > Not, what I would like to see in a project of mine. > > b. If so, is it still OK to provide JARs for them via the web site > (but not upload them to Nexus)? > > For all practical purposes, Nexus is more important nowadays for > distributing binary jars, than the ASF web site. The source archives > are another story, of course, as they constitute the actual release. > Those *must* be available from the web site. > > > c. Is it OK that the modules have different versions (reflecting > the perceived status of development)? > [This is related to the "commons-rng-sampling" issue of the > post with subject "Ralease policy for version < 1".] > > If they are successfully voted upon: Why not? > > Jochen > > > On Thu, Nov 24, 2016 at 7:01 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > Preface: This thread, the questions it contains, as well as other recent > > emails in general feels like the result of the normal learning curve one > > must go through when dealing with a Maven multi-module project. This is > > time well-spent IMO as most non-trivial (>1 jar) projects are > multi-module > > projects. > > > > Now for the meat: > > > > Strictly speaking, Apache Commons (and all Apache projects) release > sources > > as the official release artifacts on Apache "dist" servers. Any binary > > files we provide are a convenience whether on Apache servers or Maven > > Central. > > > > That means that ALL sources for a component (Apache Commons RNG in this > > case) must be released in the -src ZIPs and GZs. I'd like to hear a good > > reason not to do that. If a module is not ready for prime time, then I > > suppose it could either be excluded or packaged in an module and package > > with an appropriate artifact ID and name (like .ea/-early-access or > > .experimental/-experimental). > > > > It makes the most sense if the -bin version of a component contains the > > result of building what is in all of the -src ZIP/GZ. > > > > So that would be a "no" to (a). > > > > "[Rationale is that it would allow to make changes without > > bothering about compatibility with _unintended_ uses.]" > > > > You should make it clear which module you guaranteed binary > compatibility. > > For example, in Log4j 2 we do our utmost to keep the API module 100% BC. > > For all other modules (there are a few), we make no such guarantee but > also > > try not to make our user's life difficult. > > > > I cannot imagine that you'd want to provide 100% BC for a performance > > measurement or examples module. It seems obvious to me, but you might as > > well state it front if you think there could be room for confusion. > > > > For (b), that's a recipe for confusion and guaranteed questions on the ML > > or bug reports in JIRA. Especially when it is easier to release to Nexus > > than it is manually copying files around SVN (or writing a script to do > so). > > > > For (c), that's another recipe for confusion. Apache Commons is special > in > > the sense that it is ONE Apache project that releases COMPONENTS like > > Apache Commons IO, Apache Commons Lang and so on. When a component is > > released, all modules it contains come along for the ride. Anything else > is > > going to be a mess IMO. > > > > A 1.0 release is not only the first release but it is also a MAJOR > release, > > setting the public APIs in stone for 1.x. Breaking BC in a public API > means > > a major version change, a package change, and matching artifact ID > change. > > That's how we avoid jar hell. > > > > Noe that you get to define what public means BTW, this and that module > but > > not this other one. Even within a module you can make it clear what APIs > > are public by "hidding" private APIs in specially named packages (IIRC, > > Eclipse uses ".internal." for example). > > > > If you really want to push to a 1.0 and some of the code is not ready, > you > > can do that but you really should move that code to "I'm an experiment" > > package. Then when that code is ready, you can release a 2.0 version with > > the new shiny code in a public package. Or you could COPY it to to the > > public package in a 1.x release, YMMV. It may seem like I am > contradicting > > myself but there are many ways to do this and play nice by BC rules. > > > > I hope this helps! > > > > Gary > > > > On Thu, Nov 24, 2016 at 6:05 AM, Gilles <gil...@harfang.homelinux.org> > > wrote: > > > >> Hi. > >> > >> The "Commons RNG" component (in the "Apache Commons" sense), > >> consists of the following modules (in the "maven" sense) that > >> provide Java code: > >> (1) commons-rng-client-api > >> (2) commons-rng-core > >> (3) commons-rng-simple > >> (4) commons-rng-sampling > >> (5) commons-rng-jmh > >> (6) commons-rng-examples > >> > >> One could see the RNG low-level "library" as composed of (1), > >> (2) and (3). > >> (4) is higher-level; it depends solely on the "UniformRandomProvider" > >> interface defined in (1). > >> (5) does not provide any functionality to application developers. > >> (6) contains working code that is either of interest to "Commons > >> RNG" contributors (for running the "stress" tests) or currently, > >> fairly trivial (and not recommended) examples of use of the > >> "library". > >> > >> Questions: > >> > >> a. Is it OK if the official release does not contain (5) and (6)? > >> [Rationale is that it would allow to make changes without > >> bothering about compatibility with _unintended_ uses.] > >> b. If so, is it still OK to provide JARs for them via the web site > >> (but not upload them to Nexus)? > >> c. Is it OK that the modules have different versions (reflecting > >> the perceived status of development)? > >> [This is related to the "commons-rng-sampling" issue of the > >> post with subject "Ralease policy for version < 1".] > >> > >> > >> --------------------------------------------------------------------- > >> 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 > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > > > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > > JUnit in Action, Second Edition > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > > > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > > Spring Batch in Action > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > > > -- > The next time you hear: "Don't reinvent the wheel!" > > http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/ > evolution-of-the-wheel-300x85.jpg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
