Ok folks...the branching off of 1.7 is coming very soon, and I think
one of the biggest ticket items we need to do before then is reorg the
codebase like we want to see it in the future. Failing to do this
before branching will massively complicated merging changes back.
I have a few proposals.
Any thoughts on migrating to Gradle rather than Maven? This should give
better tools for capturing the complexity of the existing ant build while
still having all the benefits you're after from Maven.
I reckon it would also give a better migration path than Maven: it should
be possible to port
On Sun, Jun 23, 2013 at 6:09 PM, Charles Oliver Nutter
head...@headius.comwrote:
* Mavenizing.
hey - I am more than happy to help with that task if help is needed ;)
- christian
Hi Charlie,
Mavenizing is a good idea. It is IDE friendly. (Probably Gradlizing as
well)
When JRuby will be mavenized, is it possible to divide into sub modules?
and, for some users, make it customizable?
For example, Ruboto cuts down unnecessary packages from JRuby and make it
small to fit in
On Sun, Jun 23, 2013 at 12:28 PM, Daniel Marcotte dmarco...@gmail.com wrote:
Any thoughts on migrating to Gradle rather than Maven? This should give
better tools for capturing the complexity of the existing ant build while
still having all the benefits you're after from Maven.
Gradle is a
On Sun, Jun 23, 2013 at 1:37 PM, kristian m.krist...@web.de wrote:
* Mavenizing.
hey - I am more than happy to help with that task if help is needed ;)
We welcome any help :-) I think we really want to do this in master
*before* branching, since it will mean structural changes that
complicate
On Sun, Jun 23, 2013 at 2:03 PM, Yoko Harada yoko...@gmail.com wrote:
When JRuby will be mavenized, is it possible to divide into sub modules?
and, for some users, make it customizable?
For example, Ruboto cuts down unnecessary packages from JRuby and make it
small to fit in the devices.
As
On Sun, Jun 23, 2013 at 12:09 PM, Charles Oliver Nutter
head...@headius.com wrote:
* Remove C ext support to an external repository and gem
I have pushed a no_cext branch that removes all direct references to C
ext stuff from src, build/test, dist, and so on. Everything looks
clean (and it feels
Hey Kristian,
Let me know if you need help with this, that does sound like a big task,
and I think I can help for that.
Regards,
Sébastien.
Le 23/06/2013 19:37, kristian a écrit :
On Sun, Jun 23, 2013 at 6:09 PM, Charles Oliver Nutter
head...@headius.com mailto:head...@headius.com wrote:
Thanks for laying out the Maven case, Charlie. Totally resonates on all
fronts. I'll be looking for places I can help with the effort.
On Sun, Jun 23, 2013 at 12:31 PM, Charles Oliver Nutter head...@headius.com
wrote:
On Sun, Jun 23, 2013 at 12:28 PM, Daniel Marcotte dmarco...@gmail.com
On Sun, Jun 23, 2013 at 8:42 PM, Charles Oliver Nutter
head...@headius.comwrote:
On Sun, Jun 23, 2013 at 1:37 PM, kristian m.krist...@web.de wrote:
* Mavenizing.
hey - I am more than happy to help with that task if help is needed ;)
We welcome any help :-) I think we really want to do this
On Sun, Jun 23, 2013 at 4:33 PM, kristian m.krist...@web.de wrote:
A quick list, scanning build_lib...
Already being published to Maven for releases (but not snapshots):
bytelist
invokebinder
jcodings
jffi
jnr-constants
jnr-enxio
jnr-ffi
jnr-netdb
jnr-posix
jnr-unixsocket
jnr-x86asm
json was incorporated into 1.9.3 as a standard library. We copy it in when
we need to update it, but it is not currently upgradable as a gem (we
always see our stdlib copy).
- Charlie (mobile)
On Jun 23, 2013 5:24 PM, Yoko Harada yoko...@gmail.com wrote:
Thanks for explaining in detail.
On
On Sun, Jun 23, 2013 at 6:37 PM, Charles Oliver Nutter
head...@headius.comwrote:
json was incorporated into 1.9.3 as a standard library. We copy it in when
we need to update it, but it is not currently upgradable as a gem (we
always see our stdlib copy).
Wow, sorry for my ignorance.
Now, I
14 matches
Mail list logo
