geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Date Tue, 19 Dec 2006 17:11:45 GMT
Anecdotal evidence: i spent 4 days to get the builds working and took
me 2 hours to fix the code problems related to the cxfPojoWS.

thanks,
-- dims

On 12/19/06, Donald Woods <drw_web@yahoo.com> wrote:
> 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.
>
> 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?
>
>
> -Donald
>
>
> anita kulshreshtha wrote:
> > 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 <davanum@gmail.com> 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 <a_kulshre@yahoo.com> wrote:
> >>> --- Davanum Srinivas <davanum@gmail.com> 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 <a_kulshre@yahoo.com> 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 <joe.bohn@earthlink.net> 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 <joe.bohn@earthlink.net> 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
> >
> >
>
>
>


-- 
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

Mime
View raw message