Kernel module wip WARNING

[alesj]

OK, I think a WARNING here should be enough.
Despite this:

Fair warning is a message to the dev-list with a title that has block capitals
and an explanation of what people need to do to get the correct behaviour.

:-)

With regard to this:
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=131977

Till Wednesday evening (in the worst case Thursday), I'll be committing code that won't be fully tested. One laptop scare over the weekend was enough.
But that doesn't mean it will break any other tests or be out of synch with other MC subprojects.

I'll post here when done, field injection finished and fully tested.

[adrian.brock]

"alesj" wrote:
OK, I think a WARNING here should be enough.
Despite this:

Fair warning is a message to the dev-list with a title that has block capitals
and an explanation of what people need to do to get the correct behaviour.

:-)

I was talking about changes that effect the appserver
(like your removing of part of the api without replacement :-).

[adrian.brock]

"alesj" wrote:
OK, I think a WARNING here should be enough.
Despite this:

Fair warning is a message to the dev-list with a title that has block capitals
and an explanation of what people need to do to get the correct behaviour.

:-)

With regard to this:
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=131977

Till Wednesday evening (in the worst case Thursday), I'll be committing code that won't be fully tested. One laptop scare over the weekend was enough.
But that doesn't mean it will break any other tests or be out of synch with other MC subprojects.

I'll post here when done, field injection finished and fully tested.

You were wrong. You've updated the snapshots which means I can't work.

* Origianlly I couldn't do a proper release of the MC projects because you'd changed
them in an incompatible way from what I'd tested

* I managed to put together a snapshots-temp in the old repository
that didn't have your changes.

* You've now updated the kernel project snapshots which means I'm compiling
over your changes while I'm working on the deployers

I'm now stuck and there's a bug I need to fix in the deployers

We either
* release your stuff
* roll it back
* I compile over your stuff (but don't deliver it) and **hope** it really is backward
compatible in terms of testing/runtime for the deployers
* or I sit twiddling my thumbs until your stuff is ready later this week

The purpose of "mvn install" is so you can install it in your local repository
without having to publish unfinished work to everybody else until it is ready.

I'm going to try option 3. But please be more careful in future.

I'd be able to get a lot more work done if I wasn't continually dodging and wading through
problems of other people's making. :-)

[alesj]

The purpose of "mvn install" is so you can install it in your local repository
without having to publish unfinished work to everybody else until it is ready.

Sure, but once I commit something, and my stuff depends on a snapshot that is in my local repo, I guess you'll complain if this snapshot isn't also in the jboss repo?

I'd be able to get a lot more work done if I wasn't continually dodging and wading through problems of other people's making. :-)

It's called 'have a little faith in the work of others'. :-)

In the perfect world two things would be better for you not to have to 'dodge and wade'.
1) people wouldn't make mistakes
2) laptops wouldn't crash
;-)

[adrian.brock]

"alesj" wrote:

It's called 'have a little faith in the work of others'. :-)

"Faith can move mountains" but you have to careful about where you move them to. :-)

[adrian.brock]

"alesj" wrote:

The purpose of "mvn install" is so you can install it in your local repository
without having to publish unfinished work to everybody else until it is ready.

Sure, but once I commit something, and my stuff depends on a snapshot that is in my local repo, I guess you'll complain if this snapshot isn't also in the jboss repo?

I'm complaining because I can't work from a release since you stomped all over it
with changes "just as" I was about to do it.

My workaround was to use a "snapshot of a snapshot"
(snapshot-temp :-), but now you've even stomped over that.

I can't wait until the end of this week when this farce can end.

[adrian.brock]

Its even worse than that.

The jboss-mdr snapshot you released yesterday depends on the old
jboss-reflect-2.0.0.Beta11

Looks like I going to be wasting most of this evening trying to fix poms again.

[alesj]

The jboss-mdr snapshot you released yesterday depends on the old
jboss-reflect-2.0.0.Beta11

MDR change was a small bug fix.
If it helps, you can revert it.
I know where to find it and fix it again.

So, even though Reflection didn't have any impact on my MDR change, I should move this dependency to snapshot in MDR?

[adrian.brock]

"alesj" wrote:

The jboss-mdr snapshot you released yesterday depends on the old
jboss-reflect-2.0.0.Beta11

MDR change was a small bug fix.
If it helps, you can revert it.
I know where to find it and fix it again.

So, even though Reflection didn't have any impact on my MDR change, I should move this dependency to snapshot in MDR?

The way the poms are currently setup is broken. The reflection dependency
is coming from jbossxb. But if you remove that, then it comes from mdr.
That's what I'm fixing now.

In general you don't have to update to the snapshot unless it is really dependent
on the change.

But as a matter of policy, we should be updating the poms regularly to run
over the latest *stable* releases we expect to support. Otherwise we'll never
find problems when people change things inconsiderately :-)

[adrian.brock]

I'm back to a working build at least upto the deployers.
I haven't done reliance or OSGi.

The fix is basically to exclude JBossXB from choosing the version of jboss-reflect

I've updated all the snapshots so they are using consistent versions.
You can update the microcontainer project as much as you want.

BUT PLEASE DON"T MODIFY IT IN A WAY THAT BREAKS BACKWARDS COMPATIBILITY.

I still haven't verified whether it is actually backwards compatible yet,
but then the JBossAS all config isn't booting for me currently. :-(

[slaboure]

Ales,

You should receive a special price for being "Brocked" on pretty much a daily basis! I admire your calm! ;)

Special present for you Ales: Friday night, at a pub, Adrian told me that he enjoyed "brocking" you but that I shouldn't read too much into this is as he thinks you are actually doing a great job. Coming from Adrian, that's a great compliment.

Onward,


Sacha

[adrian.brock]

Ales,

You should receive a special price for being "Brocked" on pretty much a daily basis! I admire your calm! ;)

Special present for you Ales: Friday night, at a pub, Adrian told me that he enjoyed "brocking" you but that I shouldn't read too much into this is as he thinks you are actually doing a great job. Coming from Adrian, that's a great compliment.

Onward,


Sacha

Now you've let the secret out the bag, how I am I supposed to get Ales
to do what I want him to do? :-)

It's true 99.9% of what Ales does is brilliant. (There's some bits even
I don't understand, which may or may not be a good thing :-)

It's just that I found the other 0.1% all in one go while pushing for CR1 releases. ;-)

P.S. I plan to handover most of the MC projects to Ales once 2.0.0.GA is out.
So I'll be "working for him" after that. What goes around comes around. ;-)