cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Graduating.....
Date Fri, 10 Aug 2007 19:01:54 GMT

From my discussion with Jim, I think the CXF developers kind of take our 
Maven for granted in some senses.   It's setup pretty well (caveat: I'm 
very biased) so you pretty much just type "mvn" and it does the building 
and testing all at once.   There are various flags to turn off things, 
but the default is to do as much testing as it can.

Most likely, the page at:
http://cwiki.apache.org/confluence/display/CXF/Building
and the page at:
http://cwiki.apache.org/confluence/display/CXF/Getting+Involved

need some updating to make a lot of this more clear.   Running mvn runs 
checkstyle, PMD, a bunch of unit tests, and a bunch of system tests 
(some may say too many considering how long it takes to build).   If 
successful, you should be fairly confident that nothing is broken.

That said, the pages also need some additional information such as the 
code style guidelines (we use checkstyle/pmd to enforce things, but it's 
not really documented), how to add unit tests,  some docs around the 
Client/Server test framework for the system tests, etc....   

Anyway, I'm off on vacation till late next week so won't be able to spend 
time on them till then.  I'll log in monday at some point to publish the 
release providing there are no -1 votes or new issues raised by that 
point, but I won't be doing any real work. 

Dan



On Friday 10 August 2007 10:52, Jim Jagielski wrote:
> I also chatted with Dan about advertising better the various
> ways to *test* CXF, even if you aren't *using* it. There are
> many developers who like to plug holes, improve efficiency
> and even add features, even if they don't really use the
> codebase all that much. But for that to happen, there
> needs to be good, active and well-documented testing
> options for them (they won't see that they broke stuff since
> they don't run the code, at least not significantly)...
>
> On Aug 10, 2007, at 10:01 AM, Balaji Ravi wrote:
> > The developers will not come to cxf, it is with the collaboration
> > with different projects that we can invite other developers.
> >
> > We need to look externally to other projects as well as internally
> > within
> > our project.
> >
> > External:
> > What are the projects currently using cxf? Can we ask the
> > developers in this
> > project to participate in the design aspect of cxf? Are there more
> > projects
> > that are potential users of cxf?
> >
> > Internal:
> > Can we publish to other projects some of the feature list that we
> > want to
> > finish with cxf? Can we go actively look at the features of other
> > projects?
> > Maybe we can use the features developed in other projects and
> > integrate with
> > cxf better yet ask other developers to contribute in that way.
> >
> > It is not just the JIRA that we should focus on. We should cross-
> > pollinate
> > design ideas with other projects.
> >
> > - Balaji
> >
> > On 8/8/07, Glen Mazza <glen.mazza@verizon.net> wrote:
> >> Am Dienstag, den 07.08.2007, 21:49 -0400 schrieb Daniel Kulp:
> >>> Jim,
> >>>
> >>> I really appreciate the candid response.   Thanks for that.
> >>>
> >>> So, the question becomes: what can we do to help others get more
> >>
> >> involved
> >>
> >>> in the CXF code?   That question is open to the non-commiters as
> >>> well.
> >>> What can we do to help you?
> >>
> >> Personally speaking, I would very much like to move beyond my usual
> >> grammar checking and coding suggestions.  If people know of simpler
> >> tasks that are rather independent of other people's work, things I
> >> can
> >> do to start moving up the next few steps, emailing me privately or
> >> on this list would be appreciated.  I plan on spending more time
> >> looking at
> >> the JIRA's myself next week.
> >>
> >> (BTW, I will out of town Friday thru Monday, not returning until
> >> Tuesday
> >> morning Wash DC time, so after tomorrow will not be able to
> >> respond to
> >> anything until then.)
> >>
> >>> I was sitting around trying to brainstorm with some folks this
> >>> afternoon
> >>> and thought of one idea (I'll give Debbie credit for this):  is
> >>> there a
> >>> way to mark tasks in Jira with an difficulty level?    If we
> >>> could mark
> >>> some tasks as "Easy" as opposed to "Yea Right", that could make
> >>> it much
> >>> easier for a new person to find something to get their feet wet.
> >>> Jim:
> >>> since you're probably the only one with Jira admin access, is that
> >>> something that can be done?  Add a "Difficulty" or "Complexity"
> >>> attribute with levels like "Unknown, Trivial, Easy, Medium,
> >>> Difficult,
> >>> Yea Right"?   (I know VERY little about what Jira can do.)   If we
> >>> decide this is a good idea, is this something we need to file
> >>> through
> >>> Infrastructure?
> >>
> >> Well, it might not look good for a user to be submitting a patch,
> >> and for us to declare it "difficult" or "complex" or whatever.  I
> >> don't see
> >> this as that important anyway.  As contributors start looking
> >> around JIRA, and also study more, they can start to figure out more
> >> of where they can be of help.
> >>
> >> Also, frequently, it is not just "easy" or "hard"--it is also
> >> "interesting" or "applicable to what I want to focus on", etc.
> >>
> >> Regards,
> >> Glen

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message