Responses and updates!
On Sun, Jul 7, 2013 at 6:42 AM, kristian <m.krist...@web.de> wrote:
> it turns out to be to error prone to keep things consistent over time. there
> are gems. specifications and bin files to be deleted and they need to be
> hardcoded for clean up. so better leave the gems installed :)
That seems fine to me. We did not bother uninstalling in the old build
either, except to ensure we had the right versions installed at
certain times.
On Sun, Jul 7, 2013 at 7:47 AM, kristian <m.krist...@web.de> wrote:
> @headius could you push joda-timezones-2012j which is needed for
> core/pom.xml even though it will not be packed with the shade-plugin but
> needed to populate the Constants.java correctly.
I'm still waiting to hear if we can use the joda-time groupId for
joda-timezones, and I don't have push rights anywhere for org.jruby at
the moment. I could push it under com.headius, but ideally I'd prefer
to just push as the final groupId we're going to use. If we don't get
access to push under joda-time groupId by tomorrow, I'll figure
something out.
On Sun, Jul 7, 2013 at 8:58 AM, Hirotsugu Asari <asari.r...@gmail.com> wrote:
> I see that tzdata.version gets reset (and subsequent builds fail, due to the
> issue that you raise above). So I feel that we are *almost* there.
>
> But 2012j is distributed with joda-time. Is it possible to convince maven
> that we don't need that artifact under certain circumstances?
Yeah, ideally if we don't want to update timezones, everything should
fall back to joda-time without any dependency on timezones at all.
I think it would probably be ok if we wanted to ship more recent
timezone data as *standard*, though. Stephen Colbourne replied to my
tzdata email saying it's very common that people want more frequent
timezone data updates, so I think many others are choosing too (or
would choose to) ship up-to-date timezone data. I can't think of any
reason why shipping the most current tzdata *always* would be the
wrong thing to do.
What do you think, Hiro?
UPDATES
I have pushed unsafe-mock and coro-mock under com.headius and they
appear to have propagated. I was able to build this morning with
everything fetching remotely (I think). I've pushed changes to master
that remove the binaries from localrepo and use the release versions.
Today I will look at getting yecht prepared for pushing as a maven
artifact, but I will need to figure out push rights for org.jruby. It
would definitely be simpler if everything were under sonatype instead
of codehaus, so I will talk to Tom about that this week. I'm right in
thinking it shouldn't have any visible impact on users, right?
Moving to sonatype would also mean we've got all our snapshots in the
same place, which is obviously a good thing.
I will ping Remi Forax about jsr292-mock again. He's pretty
anti-maven, but perhaps he'd be willing to let us set up a groupId and
handle pushing the current versions via sonatype.
I set up a pom.xml for yydebug in gh/jruby/jay project and modified
dependencies to point at the new ID org.jruby.jay-yydebug. Once we
push it we can remove this as well.
If we get jay-yydebug, yecht, and jsr292-mock artifacts pushed, there
will be no binary dependencies left in our repository (yay!). That
will be a big success in my book. The requireTest jar should get built
as a submodule of test; I'll look into that today as well.
Once all deps are scrubbed, I'm gong to consider the main build part
of the maven migration complete. Here's a new coarse-grained list of
to-do's:
* dist artifacts. Maybe Tom can help us come up with a list of
everything we need to produce.
* spec/test cleanup. I'm still thinking maybe these all go under test,
but I'm not sure yet. Getting remote repo stuff set up as modules
pulled down for integration testing might be pretty slick. The
following test suites could all be sourced remotely: MRI tests (out of
our fork), RubySpec (out of RubySpec repo...we'd go back to committing
spec changes there), library tests (we don't run e.g. rake or rubygems
tests, but we could/should).
* Running integration tests (.rb tests) via Maven. I'm on the fence as
to the value of this, but if it just involves using the rake maven
plugin to launch the same targets we run normally, it could be a win.
Then CI etc could run a single maven target to build, bootstrap, unit
test and integration test JRuby.
* Missing test targets from ant build. Things like int/jit/aot for
unit tests, reflected invoker mode, thread pool mode. I want to wipe
out all ant test targets, but don't want to lose these profiles.
* Anything else in ant that we're not doing yet in maven or rake.
As always, post to the list if you have any issues with the new build.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
