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

Fernando Nasser fnasser at redhat.com
Fri Dec 14 11:10:42 EST 2007 

Adrian Brock wrote:
> 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.....
> 

The builds can handle source zips as well.  Contrary to this junk OSes 
that you mentioned above, Linux has a working zip ;-)

We just grabbed the tar balls because nobody ever complained before.  We 
can try and standardize on zip tar balls for the future.

We are still way ahead of the non-brew builds that have no source at 
all.  For then, people have to go upstream to grab the sources, which 
they can still do for the -brew builds, the tar ball there is just a nicety.


>> 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.
> 

No, that is and must be a reduced JAR with just the source code to be 
loaded into Eclipse.  We once put a complete upstream source ball there 
and people complained (explained to us how it was used etc).  An 
artifact of the size of the original distribution tar balls which some 
upstream communities fill with JARs and such would make filling the 
local thirdpart a pain.

We have two sources there, for different purposes.  The one in lib is 
for some "JBoss Eclipse Effort" (or whatever Scott calls it), the one 
under 'src' is for re-building the binaries, complete, with everything 
(sometimes with dependency JARs).

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

I don't understand what you mean.

> 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"/>
> 

Only a few non-brew things in the thirdpart repo had the src jar for 
Eclipse.  That has been preserved in the -brew ones.  Not a single one 
has been lost.

If you want that support please ask the developers of that component, we 
will follow suit.


>> 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.
> 

So you do with non-brew builds.  Why have you mixed up the issues then? 
  Leave -brew or non-brew out of it.  It has no connection whatsoever.

>>
>>> 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).
> 

At the contrary: you know _exactly_ what changed, as anything (including 
any patches) used to build is included.  Also, the original repository 
tag is also documented so, as before, one can go and use FishEye or 
whatever in the original source code repo.  Exactly as before.

> 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).
> 

Nobody is preventing you to go to svn.jboss.org.  Where do you thing the 
sources came from?  The tar balls are unaltered svn exports from the tag.


>>> 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.
> 

Who said you can't?  You could not on the days of the undocumented came 
from nowhere binaries that used to be uploaded, without any 
documentation, in the repository.jboss.org.


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

It is named 1.3.4 because the sources were obtained with:

http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/current/concurrent-1.3.4-src.tar.gz

Again, what is the difference w.r.t. to whre it is built?  Anyone that 
grabbed a source tar ball from the upstream community called 
concurrent-1.3.4-src.tar.gz would assume that it is their 1.3.4.  And 
AFAIK it should be.

(We are going to add the exact commands used to download, and the 
commands used to build, like 'ant dist' or whatever is used, to the 
README.txt under 'src', to make it even easier).


>> 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

That depends on the component developers.  We have no blank commit 
accesses.  Some create a tag for us and we use it.  Some just give us a 
patch to fix the problem and promise to include it in a future release 
(many times it is a backported patch).  You will have to argue with each 
of them if you want a tag.  We can just ask.

> * Include a -sources.jar in the artifacts downloaded into thirdparty
> 

Again, wrong kind of source, wrong place.  See above.

We always include the full source tar ball under 'src..  for the Exlipse 
one, we follow the component lead.  They include, we include.  We are 
considering adding it ourselves, but ideally that should be produced 
with the original component build (by 'ant dist' or whatever is used).



>> 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

More information about the jboss-development mailing list