[jboss-dev] Re: [Fwd: Re: [JBoss JIRA] Commented: (JBAS-5072) Fix null pointer exception when getting keys, values, or entry's in the ConcurrentHashmap]

Fri Dec 14 10:34:04 EST 2007

On Fri, 2007-12-14 at 10:16 -0500, Fernando Nasser wrote:
> Adrian Brock wrote:
> > Look, you're missing the whole point of the 
> > jboss.org/EAP seperation.
> > 
> > Average Joe Developer (not Redhat) that wants to fix a bug
> > isn't going to know about CP releases or have access to the QA
> > department.
> > 
> > His procedure is to create update1, see that JBossXB needs
> > to be tested and if he wants to test it himself, he
> > downloads JBossXB and runs its testsuite.
> > 
> 
> What prevents him to do this?  He has the sources (doesn't even need to 
> go look for it in the upstream repository, the source tar ball 

tar is broken/non-existant on Windows, Solaris, etc.....

> is in the 
> src subdirectory of the thirdpart repo as well).

It should be in jboss-xxx/thirdparty/project/lib/project-sources.jar
not in some repository.

1) If you know the complicated jboss build system then maybe
you know about repository.jboss.com?

2) If you're using Eclipse or some other ide, the source
should be viewable inside the ide.

e.g. Eclipse .classpath:

<classpathentry kind="lib"
path="/thirdparty/jboss/common/lib/jboss-common.jar"
sourcepath="/thirdparty/jboss/common/lib/jboss-common-sources.jar"/>

> So he can do the above as always.

But this is irrelevant to this issue. The source for the tests
and the test build script are not in the source archive anyway.
You have to go back to the tag to reproduce the tests.

> 
> 
> > That we do more than this for EAP is a different issue.
> > 
> 
> Ah, but here is where the symbiosis exist.  Both sides by themselves 
> have limited testing capabilities, but when they join forces we can have 
> rock solid open source software.
> 
> By QAing the produced libraries, the EAp project does some level of 
> testing that could not be done by the "Average Joe Developer".  On the 
> other hand, by exposing to the world the -brew builds in the community 
> branches as well, it gets exposed to real time situations that QA can't 
> reproduce.
> 
> As the fixes flow from both sides, based on both test paradigms, the 
> software evolves to greater stability.
> 

I'm not interested in that here, as nice as you make it sound. ;-)

A source tarball or some Redhat cvs repository is no
good if I want to know what changes went into the release
(or more usually who changed a particular line and why).

The history for this is on svn.jboss.org not in a source tarball
that is unattributable without unnecessary searching and cross
referencing (assuming you even know how to do those steps).

> 
> > When JBoss is developed by only Redhat employees I'll agree
> > with you. Since hopefully that is never going to happen
> > we need to remove all this "Redhat internal procedure"
> > from the open source project.
> > 
> 
> "Internal" is having builds done in people's machines, which I can't 
> reproduce.   When we tried to reproduce the binaries used in JBoss AS 
> some time ago, we found out that we did not know what the sources where, 
> which patches had been applied and so one (ask Ryan).

No, that's people not doing things properly.

If I can't reproduce something from the tag then the tags 
and releases are worthless.

How about the original 1.3.4-brew release of concurrent.jar
was actually 1.3.3? Same issue, same problem. :-)

> 
> Now people can reproduce any -brew build they want, all info is 
> available (we are working on improving even further the contents of the 
> thirdparty repo to make it even easier).  Using the machines in the RH 
> intranet is as unaccessible as your laptop is the the rest of us.  It 
> does not make any difference where it is built  --  having the sources 
> and info to reproduce is all that matters for Open Source.

The issue is how does a developer fix something in a thirdparty library
or trace a problem in a thirdparty library.

The minimum for me to make brew work in the OS project is:

* Tag svn.jboss.org with the version you used for the brew binary
* Include a -sources.jar in the artifacts downloaded into thirdparty

> 
> This said, some folks from the MEAD project are preparing our publicly 
> accessible version of Brew, called Koji.  This is the same process that 
> the Fedora community followed and the community there is really happy 
> with their setup.
> 
> Regards,
> Fernando
> 
> 
> > On Fri, 2007-12-14 at 09:10 -0500, Fernando Nasser wrote:
> >> Adrian Brock wrote:
> >>> Copying to the main dev-list.
> >>>
> >>> Yes, you can change it. But ideally you should test it first.
> >>> i.e. checkout the jbossxb 1.0.0SP1 tag 
> >>> and modfiy the build to use update1
> >>>
> >>> That's what compatiblity means. ;-)
> >>>
> >> Who has to do that is the JBoss XB developer, not Jay, as they may have 
> >> the proper testing procedure.  Alternatively, he can let it go through a 
> >> complete QA cycle first, inside a CP release, if he feels confident the 
> >> changes are absolutely backwards compatible.
> >>
> >>
> >>> This clearly wasn't done for the brew release
> >>> since there's no maven release for that.
> >> The product line is not using update1.  When it does, it will be based 
> >> on the opinions of the developers that work on the product and it will 
> >> be fully tested by the QA department (and jbossxb developers if that is 
> >> deemed necessary).
> >>
> >>> Which is another reason why brew is bad.
> >>>
> >> So, contrary to what you say, the -brew versions are much safer than 
> >> binaries that have not been properly QAed.
> >>
> >> Furthermore, adding <compatible> lines or not is a developers procedure, 
> >> has NOTHING to do with how it was built.
> >>
> >>> http://repository.jboss.com/maven2/oswego-concurrent/concurrent/
> >>>
> >>> On Wed, 2007-12-12 at 16:41 -0500, Jay Howell wrote:
> >>>> Hey Adrian,
> >>>> I've made a new version of the concurren 
> >>>> lib(https://svn.jboss.org/repos/repository.jboss.org/oswego-concurrent/1.3.4-jboss-update1) 
> >>>> , and I've changed my build-thirdparty.xml file, but I also need to add 
> >>>> an entry in the jbossxb(component-info.xml) to establish compatibility.  
> >>>> The current version that is current in branch 4.2 for jbossxb is 
> >>>> 1.0.0.SP1.  My question is, Do I need to make a new version of jbossxb, 
> >>>> or can I check the compatibility changes in for 1.3.4-jboss-update1into 
> >>>> jbossxb 1.0.0SP1?  I see that the entry that put the compatibility entry 
> >>>> in for 1.3.4-jboss(1.0.0.GA_CP01-brew) was just added to that version 
> >>>> and a new version(directory) was not added.  I can easily either make a 
> >>>> new version(called ???) or I can just change the version that's there.
> >>>>
> >>>> Thanks, Jay:)
> >>>> email message attachment (Re: [JBoss JIRA] Commented: (JBAS-5072) Fix
> >>>> null pointer exception when getting keys, values, or entry's in the
> >>>> ConcurrentHashmap)
> >>>>> -------- Forwarded Message --------
> >>>>> From: Jay Howell <jhowell at redhat.com>
> >>>>> To: Adrian <abrock at redhat.com>
> >>>>> Subject: Re: [JBoss JIRA] Commented: (JBAS-5072) Fix null pointer
> >>>>> exception when getting keys, values, or entry's in the
> >>>>> ConcurrentHashmap
> >>>>> Date: Wed, 12 Dec 2007 15:04:59 -0500
> >>>>>
> >> _______________________________________________
> >> jboss-development mailing list
> >> jboss-development at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx