It's very easy to create one, but I think we should focus on small high quality
simple to use modules and let third parties provide assemblies. I think most
of us will feel better about providing solutions that explicitly declare the
modules used. This gives maintainers a more precise target. Keeping an uber
jar also gets more and more difficult to maintain with each new module release.
For example with superfly-css I change modules all the time and I'm planning on
adding a lot of new ones. If I also add a uber module I have to maintain that
as well. That's not my main concern though. I think an uber jar / module can
easily cause headaches. It's the opposite of allowing JDK 9 or osgi manage
dependencies and corresponding contexts. The less indirection the better.
Cheers,
Ole
On 01/25/2016 06:38 PM, Gary Gregory wrote:
If you decide to break up math into modules, I encourage you to also
provide an all-in-one jar.
Gary
On Jan 25, 2016 4:22 PM, "Ole Ersoy" <ole.er...@gmail.com> wrote:
Also if each module is very simple and isolated alphas, betas, etc. matter
less (If at all). Most devs releasing to npm rely on semver only.
Cheers,
Ole
On 01/25/2016 02:27 PM, Gary Gregory wrote:
On Jan 25, 2016 10:11 AM, "Emmanuel Bourg" <ebo...@apache.org> wrote:
Le 25/01/2016 18:52, Gilles a écrit :
AFAICT, the real issue is one of policy: Commons is supposed to be
stable,
stable, stable and stable (IIUC).
And CM is far from being mature as a programming project, when
considering
design and scope, and not only the quality of its results and
performance
(which are both good in many cases).
So stability (as in using JDK 5 only) is not a good perspective (surely
not
developers and probably not for users either IMO).
If this does not change, what's the point indeed?
I hope that a motivation behind the TLP isn't to break the compatibility
on every release, otherwise this will quickly turn into a nightmare for
the users. Bouncycastle plays this game and it isn't really fun to follow
:(
WRT compatibility, the only thing that matters is not creating jar hell
for
users. You can break compatibility if you change package and maven
coordinates. It's up to the project to create enough alphas and betas to
get to a stable public API before a release. That's just basic project
management IMO. Anything less will leave a lot users unhappy.
Gary
Emmanuel Bourg
---------------------------------------------------------------------
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
