Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=lwbk3v4copqSYoaI5VSr0JX68ffw5Knq1baJYfn3bWjGL2f3xCPP1nCQzJ7bYHtzYHW7bttu0BjM2rGnTsaEp7/3Zsv4f+9N6gneyxa4UNYMouT636FevFIWS0XGBpNOESV7qK0owiXSzGWjYNObSSjcKx164L7ZdkpuUZpmaOw=
  ;
Message-ID: <20061219145600.22407.qmail@web31709.mail.mud.yahoo.com>
Date: Tue, 19 Dec 2006 06:56:00 -0800 (PST)
From: anita kulshreshtha <a_kulshre@yahoo.com>
Subject: Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
To: dev@geronimo.apache.org, dims@apache.org
In-Reply-To: <19e0530f0612190052t1335632fm67e4906b37d93308@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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