Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState

[Donald Woods]

This is a very sad state of affairs, as we are spending more time getting this convoluted maven build to work than writing code, just as many have pointed out and I'm sure will cause jdillon and anyone doing CTS testing ulcers.

-Donald


anita kulshreshtha wrote:

Is it not time to split the Geronimo 2.0 build into separate maven-plugin, modules, applications, configs and assembly build steps??? We are using multiple groupIds, so why not split up the builds for each unique groupId?

Dims,
   Yes, it is not straightforward to do an offline build.. This is what
many of us do:
1. If starting from an empty repo do a full online build. Delete
modules, configs and assemblies directory from .m2 repo. Do an offline
build of these items (sometimes car plugin).
2. After an svn update, build the files that changed from their
respective modules directory online. This will download any new jars.
Delete the modules, configs, and assemblies from .m2 repo and do an
offline full build.
    Not pretty but works.. I started using this after my local classes
went missing..
    I have been looking at the code to figure out why the
incompatibility was not caught by the compatibility test in
GBeanDataTest. Does anyone know?

Thanks
Anita

--- Davanum Srinivas <[EMAIL PROTECTED]> wrote:

Anita,

Try this when you have some time.

1. Remove your .m2
2. "mvn install" from root.
3. cd to testsuite and run "mvn -N install"
4. cd to itests and run "mvn -N install"
5. cd to cxfPojoWS and run "mvn -o install"

It's impossible to execute 5 with "-o" flag as the project needs to
download cxf stuff from the remote repo. since you can't use the "-o"
flag it will pick up the remote jar for geronimo-kernel. If you
search
all the sub directories after running 5, you will see 2 jars for
geronimo-kernel, one built locally and one from the remote repo.
Basically you are dead in the water. After this, you will have to
replace the remote jar with the local jar and re-run "mvn install" to
actually run the test.

So basically "The only way to make sure that the local jars/cars are
used is to do an offile build" is not possible.

thanks,
dims

On 12/18/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:

--- Davanum Srinivas <[EMAIL PROTECTED]> wrote:

Anita,

Anyone who builds geronimo from scratch is likely to into into
problem. We can't really tell people they can't use the jars they
build themselves on their boxes and have to use the published
SNAPSHOT
jars.

  We do not tell people that they have to use the published jars.

It is

clear from this error that maven is still downloading jars from a
remote repo instead of using the ones that were built locally. The

only

way to make sure that the local jars/cars are used is to do an

offile

build.

Thanks
Anita

So i think we need to fix it.
Just imagine that you are trying

to fix a bug in Geronimo kernel for shipping to your customer,

but

the
code does not have a serial version uid and the compiled jar is

hence

unusable...not a pretty picture. I don't think we have to "worry"
about compatibility especially as right now if 2 jars built from

same

svn revision by 2 different people on different JDK's/JDK

versions on

different boxes, you can't mix the jars. So there is no
"compatibility" right now :(

Anyway my specific problem was because of lack of the UID in
GBeanOperation and i checked in a patch for it (487759).

thanks,
dims

On 12/16/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:

Dims, Joe, and Prasad
    I wish I had seen this coming.. The compatibility of

GBeanInfo

was

broken for 4 days (Dec 10th - Dec 14), while we discussed

whether

we

should maintain this compatibility. In a perfect world it would

not

have mattered.. But sometimes Maven does not use locally built
SNAPSHOTs in online build mode (some of the reasons for this

are

known). Once the SNAPSHOTs published during this time, are

overwritten,

this problem should go way. At least that is my thinking...

Please

correct me if I am on wrong track.

Thanks
Anita

--- Joe Bohn <[EMAIL PROTECTED]> wrote:

Prasad,

I'm hitting this particular problem in trunk (but I have hit

similar

problems in 2.0-M1).  I actually was trying to recreate the

problem

today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I

didn't

hit

the problem but I hit it with the first attempt on trunk.

As I

mentioned, the second build attempt corrected the problem.

Joe


Prasad Kashyap wrote:

I was able to build G successfully on a RedHat machine.

I started with a completely clean repo (rm -rf

.m2/repository).

I did an 'svn up' of my 2.0-M1 directory. I had done a

fresh

checkout

of these files last night.

The entire tree built successfully with a

-Dmaven.test.skip=true.

I verified that both jetty and tomcat binaries run fine.

I used the console to successfully deploy jsp-examples app

on

both

binaries.

Cheers
Prasad

On 12/15/06, Joe Bohn <[EMAIL PROTECTED]> wrote:

This might be the sporadic problem after all.  I just

rebuilt

again

without any changes (still rev 487523) and the problem

doesn't

exist

with the new images.

Here's what I did this time:
- mvn clean
- from my local repo remove o/a/g/modules, configs,

assemblies,

and

applications rather than removing the entire local repo.
- mvn -Dstage=bootstrap
   - still failed in the geronimo-jetty6 SecurityTest

(yes, I

know

I

should have skipped the tests but I wanted to see if the

failure/restart

was in any way related to the failures)
- mvn -Dstage=bootstrap -Dmaven.test.skip=true

-Dmaven.itest.skip=true

- mvn -Dstage=assemble -Dmaven.test.skip=true

-Dmaven.itest.skip=true

Joe



Joe Bohn wrote:

This is happening in trunk rev 487523.   I'm not sure it

is

the

same

problem I reported earlier .. in fact I think it may be

different and

possibly related to the serialized UID change made

earlier

today.

I was keeping careful track of what I did in case I hit

the

problem

that

I'm mentioned in other threads with the GBeanInfo object

Here's what I did:
- mvn clean
- completely remove my local repository.
- mvn -Dstage=bootstrap
  - this failed in modules/geronimo-jetty6 test case for

SecurityTest

... expecting a 500 returned instead of a 404 that was

returned.

- mvn -Dstage=bootstrap -Dmaven.test.skip=true

-Dmaven.itest.skip=true

- mvn -Dstage=assemble -Dmaven.test.skip=true

-Dmaven.itest.skip=true

I then extracted the zip images created and began

hitting

this

error

=== message truncated ===


__________________________________________________
Do You Yahoo!?

Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

smime.p7s
Description: S/MIME Cryptographic Signature