Re: ASF Board Meeting Summary - December 16, 2009
On Dec 17, 2009, at 8:15 AM, Jim Jagielski wrote: The December board meeting took place on the 16th. The following directors were present: Shane Curcuru Doug Cutting Justin Erenkrantz Roy T. Fielding Jim Jagielski Geir Magnusson, Jr. Brett Porter Greg Stein and the following guests/officers were present: Sam Ruby J Aaron Farr Craig L Russell Gavin McDonald All of the received reports to the board were approved. The following reports were not received and are expected next month: Status report for the Apache iBATIS Project Status report for the Apache Santuario Project Status report for the Apache Web Services Project The following resolutions were passed unaminously: A. Establish the Apache Pivot Project (Greg Brown, VP) The PMC is tasked to work with the Branding Cmmt and the Legal Cmmt regarding the use of the name 'Pivot' due to potential conflict. B. Establish the Apache OpenWebBeans Project (Gurkan Erdogdu, VP) Congrats All! Well deserved! --kevan
Re: AW: Removing webbeans-api and atinject-api
On Dec 15, 2009, at 2:58 AM, Mark Struberg wrote: cool! +1 How does the Release process and patching work? Do we have commit rights for e.g. improving the JavaDoc in geronimo-specs? At the moment, any updates would need to be submitted as patches. If there is a lot of activity planned and this presents a problem, let me know and I'll discuss options with the G community... How is the release process working? Are we obliged to release those 2 modules or do we have to send a request to geronimo-dev? Discuss this on dev at geronimo. The geronimo community would be responsible for releasing. --kevan
Re: what about a -M4 release?
On Dec 14, 2009, at 2:40 PM, Gurkan Erdogdu wrote: In the mean time, I will be marrying at next week, all of you are welcome to my wedding ceremony :) Congratulations Gurkan! Would love to attend, but don't think I'll be able to make it... ;-) You've barely given us enough time to arrange the bacherlor's party :D --kevan
Re: Time to move atinject-api over to geronimo?
On Nov 20, 2009, at 8:22 AM, Gurkan Erdogdu wrote: +1. How could we integrate this into geronimo-specs? Kevan, David? Best to start with an email to the geronimo dev list. A Jira and optonally a patch, always helps... --kevan
Re: CDI final draft released
On Nov 11, 2009, at 3:53 AM, Mark Struberg wrote: Hi! Gavin today released the final draft of the CDI specification: http://in.relation.to/Bloggers/JSR299FinalDraftSubmitted Yay... :) So, I'd be interesting in hearing where the community feels they are with respect to implementing the spec. How is progress being documented recorded? What features remain to be implemented, etc. In addition to helping the community, such a list would also help attract new project participants. --kevan
graduation
It's been a while since the community has discussed graduation. What are your current thoughts? I've mentored about all that I can mentor... ; -) From the last time I kicked off the discussion: On Sep 8, 2009, at 11:00 AM, Kevan Miller wrote: IMO, this community displays nearly all of the characteristics that I would look for from a successful Incubator project: you've successfully created several releases while operating in a clear, open, and welcoming manner. All of this while facing some significant challenges as the JSR 299 spec has been an ever shifting target. I'd like to see us moving towards graduation. To start things off, is the community interested in becoming a top-level project? Or would you rather graduate as a sub-project of an existing TLP? I think we're ready. Graduation is going to take a concerted effort by the community. I'm certainly willing to help, but the community is going to need to help drive this. --kevan
Re: [VOTE][Third Try] Release OpenWebBeans 1.0.0-incubating-M3
+1 --kevan On Sep 8, 2009, at 4:41 PM, Gurkan Erdogdu wrote: Hi; This is the OpenWebBeans M3 release [VOTE] process with corrected artifacts. Artifact locations are the same as before. I've staged the releases artifacts here: Plugins repository -- http://people.apache.org/~gerdogdu/staging-repo/OWB/1.0.0-incubating-M3-rc1/plugins/org/apache/openwebbeans Distribution content http://people.apache.org/~gerdogdu/staging-repo/OWB/1.0.0-incubating-M3-rc1/distribution/org/apache/openwebbeans/apache-openwebbeans-distribution/1.0.0-incubating-M3/ SVN Tag (Revision: 812680) http://svn.apache.org/repos/asf/incubator/openwebbeans/tags/openwebbeans-1.0.0-incubating-M3-rc1/ Please verify that this release package is correct and vote for the motion to publish this as a openwebbeans M3 release. All votes are welcome and will be counted. This vote is open for 72 hours. This is my +1 Thanks; /Gurkan
Re: Development Next Steps
On Jun 8, 2009, at 12:53 PM, Gurkan Erdogdu wrote: Hi guys; As you already know, we have succesfully published our M2 version. Altough a spec changes a lot from the last draft version, I think we are on the good track. In the mean time I have sent June board report. In this report I stated one point, from report: NOT : Actually, last draft specification imposes on an implementations that it must be tightly integrated with a Java EE Container's internals , such that integration with an EJB 3.1 Container, Servlet Container, Managed Beans etc. So, we have to work closely on the respective Apache teams to push the implementation. I'd prefer that there was an explicit 'BOARD REPORT' email thread. I have trouble parsing the above. A few things that I think should be mentioned: 1) spec changes have been having a negative impact 2) Gurkan joined the JSR expert group. --kevan
Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
On May 25, 2009, at 11:58 AM, Gurkan Erdogdu wrote: Hey folks; We need some more votes. Until now just Mark and me voted as +1 I'm still unable to build on Mac OS. Everything else looks good. Here's my +1. --kevan
Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
Afraid that I'm currently unable to build. So, I can't fully review...
My build issue seems to be a Mac OS / mvn issue. I'm failing with:
[INFO]
[INFO] Building OpenWebBeans :: WebBeans-API
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /Users/kevan/tmp/owb/openwebbeans-1.0.0-
incubating-M2/webbeans-api/target
[INFO] [remote-resources:process {execution: default}]
[INFO] inceptionYear not specified, defaulting to 2009
[INFO] [resources:resources]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] Copying 4 resources
[INFO] [compiler:compile]
[INFO] Compiling 65 source files to /Users/kevan/tmp/owb/
openwebbeans-1.0.0-incubating-M2/webbeans-api/target/classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Fatal error compiling
Embedded error: Prohibited package name: java.lang
If anyone knows how to avoid this problem, let me know...
Running RAT on the source reveals the following files missing apache
src license headers. These must be fixed. You should be running RAT as
part of a build or as part of the release process...
samples/reservation/src/main/webapp/main.css
webbeans-geronimo/pom.xml
webbeans-jpa/pom.xml
webbeans-jsf/pom.xml
--kevan
Re: [VOTE] Publish OpenWebBeans 1.0.0-incubating-M1
On Feb 2, 2009, at 3:44 PM, Mark Struberg wrote: Some projects will name their release candidates and corresponding votes Or delete the SVN tag and do it again? The artifacts have not been published yet... There is a release:rollback mojo which will do all the pom-renaming back (which is not needed in our case). The tag removal is not implemented yet (because tag-removal is not supported in maven- scm-1.1) and has to be done manually. But this is marked as TODO in the release plugin code, so my guess is that that's the way it _should_ work. btw: I would not use -RC1 but only -M1.1, M1.2, etc because I personally prefer to use the term 'RC' only for release candicates of final versions. I got a little carried away implying that the artifacts would contain the RCx name. Can just be used in the vote/staging directory (unique prefix, etc). Just letting you know how other projects have handle this. It's not uncommon to see a RC5 and higher... I think 1.0 RC1 and a 1.0-M1 RC1 are pretty descriptive and distinct. However, don't really care... As long as the project knows what is being voted on, even if we're having multiple rounds of voting, I'm fine... --kevan
Re: AW: [CANCELED] Publish OpenWebBeans 1.0.0-incubating-M1
On Feb 2, 2009, at 4:08 PM, Mark Struberg wrote: Gurkan, Kevan, should I wait with the SPI implementation as long as you do the release? I'd wait. One way you can handle this type of conflict, is to create a release branch (e.g. svn copy trunk branches/1.0.0-M1) and finalize the release. This allows new development to continue, even if release voting takes a while...). Does require merging of changes, if updates are made to the release branch. Since you don't really plan on supporting the M1 branch, you can delete it after the release vote passes... --kevan
Re: AW: [CANCELED] Publish OpenWebBeans 1.0.0-incubating-M1
On Feb 2, 2009, at 4:39 PM, Mark Struberg wrote: but the release-tag will be on that branch in this case, isn't? So deleting it afterwards is maybe not such a good idea. Imho all releases must have a tag in the repo which exactly matches the released artifacts. But maybe I'm too fussy. I probably left a few things unsaid... The release branch can be deleted, the release tag would be in tags/1.0.0-M1. svn copy trunk/ branches/1.0.0-M1 perform release process (part of the release process will create a tags/1.0.0-M1 tag). The only difference is you're releasing from branches rather than trunk. After vote passes: svn delete branches/1.0.0-M1 (this is optional, but encouraged, since we don't really plan on supporting 1.0.0-M1). --kevan
Re: [VOTE] Publish OpenWebBeans 1.0.0-incubating-M1
On Feb 2, 2009, at 4:42 PM, Mark Struberg wrote: Sorry Kevan, I did not get your opinion. What do you prefer: a) removing the SVN tag and doing the same version again or b) keeping the old tag and simply releasing a new -M1-RC2 or something? a) would be my preference. --kevan
Re: license header in XML files?
On Jan 28, 2009, at 4:28 PM, Mark Struberg wrote: Hi! Should we add a license header in our XML files like beans.xml and test persistence.xml? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- Yes, if the files were generated by the ASF. Here's info about src headers -- http://www.apache.org/legal/src-headers.html --kevan
kevan hands out gold stars
Since I was thinking about this, I thought I'd go ahead and send a note. I think you guys are off to a really good start. You're making a lot of really good progress with the implementation. The release preparation, although potentially delayed for a bit (which is not a bad thing at all), has gone very well. Most importantly, I'm very pleased by the amount of communication that I'm seeing. Keep up the good work! You all deserve a pat on the back this weekend, while reading the updated spec, of course... :-P --kevan
Re: M1-Release Artifacts
On Jan 20, 2009, at 4:18 PM, Gurkan Erdogdu wrote: Hi; I have uploaded the candidate M1-Release artifacts into the http://people.apache.org/~gerdogdu/OWB/M1/ Please have a look at the contents of these artifacts, and if there is an error in artifacts or there is a missing artifact, we can correct all of these problems before the VOTE on the dev@ list. I took a quick look and didn't see any glaring problems. Afraid that I won't have much more time for a few days. Would recommend that you include the maven generated artifacts also... Each artifact should be reviewed. --kevan
Re: additional usage of GIT for experimental features[TCK Related]
On Jan 21, 2009, at 5:50 AM, Mark Struberg wrote: I don't know how TCKs are handled, but I usually require them to be executed and pass before a release is done. And please do not confuse the JBoss TCK implementation with our OpenWebBeans Tck _Integration_. I will only checkin the TCK Integration code and not the TCKs themselfs. The code written by JBoss guys are only referenced via maven dependencies. This is SNAPSHOT version currently [1], but they will have to release a tagged version shortly after the Spec is final. Once the spec goes final, the JCP will make the TCK available. We'd obtain the official TCK from the JCP. The ASF has a JCP site (http://apache.org/jcp/ ), mailing list, and a process for obtaining official TCK's from the JCP. Since the WebBeans TCK is being implemented in the open with an ASL license, we're able to obtain a snapshot of the TCK prior to the spec going final. Until the spec goes final, TCK results are meaningless. We can't make any claims regarding compliance. It is, however, a useful testing tool... [1] so for executing the TCK tests currently one has to also run: $ svn co http://anonsvn.jboss.org/repos/webbeans/tck/trunk tck $ mvn clean install This sounds pretty good to me... --kevan
Re: additional usage of GIT for experimental features
On Jan 20, 2009, at 7:07 AM, Mark Struberg wrote: Hi! As I already tried to expain: it was never ment to use git for productive changes - think about it more like a blog full with code ;) Understood. However, there are other ways of accomplishing this. Which would probably be more acceptable... 1) create an openwebbeans/sandbox in svn 2) generate a patch and post to the jira 3) discuss your intentions/proposed changes (which you've done), and commit them in trunk. The community should be reviewing all changes. It's not necessarily bad to discover disagreements, post-commit. These disagreements can be resolved. At Apache, all committers have earned the necessary karma to be fully trusted. IIUC, this is un-Git like (at least it doesn't match my understanding of the social norms in Git usage). We may be able to work out acceptable usage of Git. I want to be sure we're avoiding private communications about code and some usages of Git might lead to the potential for private conversations. BTW, I'm certainly not implying that this is your (or anybody else's) intent... Back to the issue: how do we cope with the TCK code? Should I check it in to SVN? It will compile, but cannot run due to API incompatibilities between us and RI. But as long as we do not add the module in the parent pom it will at least not break the build. Guess we could add the JBoss snapshot repo to our builds... This would cause problems during releases and as the TCK changes. I will create a Jira and attach the TCK suite via patch in the meantime. Personally, I'd commit the changes I saw Jukka will organise a GIT session on the ApacheCon EU. Maybe we'll find some time there... Sounds good. I'm hoping that I can attend, this year... --kevan
Re: [site] building the site via maven ?
On Jan 19, 2009, at 4:50 AM, Mark Struberg wrote: I'm currently not able to assign OWB-53 to me. Are Jira assignments for OWB handled by PMC only? Try it now. I've added you, Matthias, and me ;-) to the OWB committer's list. --kevan
Re: additional usage of GIT for experimental features
On Jan 16, 2009, at 5:42 PM, Mark Struberg wrote: Hi! The Apache Infrastructure Team offers the possibility to mirror the SVN archive to a GIT repo. I just like to ask if anyone (besides me) is interested in using git for sharing experimental features which are not elaborated enough for being checked in to SVN? If anyone has heard about git, but doesn't have a glue what's behind the development model used with git then you should look at the following google speech from Linus Torvalds: http://www.youtube.com/watch?v=4XpnKHJAok8 To state this clear: this is _not_ about using GIT instead of SVN, but only _additionally_ to share immature features. Hi Mark, So, I confess that I'm not much of a GIT user. I know that there is growing interest in GIT within the ASF and that there are multiple ASF projects which are using GIT, in some form. I don't, however, know how these projects are using GIT. I know that it's possible to use GIT in a private mode. Using GIT on their local machines, creating private branches, making local changes, etc, then committing their changes to SVN. I see absolutely no problem with this type of usage of GIT. However, you are implying that we could use GIT as a means for sharing non-committed code among project members. I have some concerns about this. This could become a form of non-public communication among project members. Non-GIT users would not be able to participate in these communications. This may be very GIT-like usage. However, it's potentially very un-ASF-like communication. I don't know enough to evaluate the validity of my concerns without doing some more research. If you, or anyone else, know specifics about how other ASF projects are using GIT, that would be helpful... --kevan
Re: tabs in sources
On Jan 8, 2009, at 2:25 PM, Mark Struberg wrote: Thanks for seconding this, Kevan ;) I personally would prefer using an already established coding/ checkstyle ruleset like maven or myfaces instead of having our own one. I think myfaces_checks comes very close if we drop the tabs in favour to spaces. Right. I'm not advocating that we *create* one. Just saying that would be good if we had one that we'd agreed to... --kevan
Re: [PATCH] fix for navigation rules in sample 'guess'
On Jan 6, 2009, at 10:00 AM, Mark Struberg wrote: Txs Kevan! I have an active CLA signed for a few maven, scm and openjpa contributions I did, so all rights should be granted already. But I apologize to use Jira in the future for better tracking ;) Cool. ICLA certainly helps/is sufficient. Using Jira patch method is makes it simpler for all involved (e.g. don't have to go searching for an ICLA on file). Certainly appreciate your contributions! Keep 'em coming! ;-) --kevan
december board report?
Have we prepared a December board report? Possible that I've missed it... I may not have my mail sorting rules quite right... --kevan
