Re: [OT] WebBeans JSR 299
Do you have to be registered with the JCP as a corporation rather than an individual to get that status? On Jul 7, 2006, at 12:34 PM, James Mitchell wrote: I sent in a request to be on the expert group under corporation, since I am incorporated. I would prefer to be a co-rep for Apache, but if that's not possible, then that's cool. -- James Mitchell Software Engineer EdgeTech, Inc. 678.910.8017 - Original Message - From: Matthias Wessendorf [EMAIL PROTECTED] To: dev@shale.apache.org Sent: Thursday, July 06, 2006 4:03 PM Subject: Re: [OT] WebBeans JSR 299 Thanks for heads up, Craig. so James, what should we do? :) I don't want any *wars* b/c a JSP ;) -Matt On 7/6/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 7/6/06, James Mitchell [EMAIL PROTECTED] wrote: Can there be more than one Apache rep? I'd like to participate too (even if just as an Individual). It's up to the spec lead (Gavin King in this particular case) ... but I don't expect he would object to multiple individual participants. As to how the official Apache rep gets selected, best bet would be to post your willingness to do this to the [EMAIL PROTECTED] mailing list (ASF members only to subscribe) to let other JCP-interested folks now of your desire. If there's more than one interested party, we can let Geir help us figure out the process for selecting one. -- James Mitchell Craig On Jul 6, 2006, at 1:23 PM, Craig McClanahan wrote: On 7/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey folks, Is anybody (Craig ;)) going to join this JSR [1]? [1] http://jcp.org/en/jsr/detail?id=299 Yes, I'm going to be the Sun rep on this EG. It would be reasonable for someone to be the Apache rep as well. -- Matthias Wessendorf Craig futher stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf futher stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Proposed Board Report (redirected to correct project dev list)
This looks good to me. Greg On Jul 17, 2006, at 12:57 AM, Craig McClanahan wrote: As part of our transition to an Apache top level project (TLP), we are obligated to submit a report to the ASF Board every month for the first three months, then quarterly thereafter. Here's what I am proposing to send for July, which needs to be forwarded in a couple days. (I'll also create a pmc subdirectory in the repository to archive these things, since there is nothing non-public we need to worry about). Comments? == = Apache Shale Board Report for July 2006 === Overview Per the Apache Board resolution at the June 2006 meeting, Apache Shale was created as a top level project. This is the first of the every month for the first three months status reports to the Board on activities within the project. All of the initial root and infrastructure requests have been completed. We are still de-tangling a few loose ends (wiki and JIRA instance shared with the Struts project), but these are not considered to be urgent. PMC and Committer Changes - None. Current Development Activities -- As the creation of Shale as a TLP was coming to fruition, we had nearly completed a migration to a Maven2 based build environment. This work has been substantially completed, and Shale is now completely M2 based for its build infrastructure. Nightly builds are still currently hosted on my (Craig's) home desktop, but steps are underway to migrate this to a Continuum instance on Apache infrastructure. We have initiated a contest to pick an official logo for the Apache Shale project -- details are at http://wiki.apache.org/shale/LogoContest . The entries so far have ranged from humorous to compelling ... it will be interesting to pick a final winner. Current release activities are focused on a 1.0.3 release, which is still likely to be considered beta quality (due to dependence on unreleased components, plus some outstanding bugs), but which has been requested by some downstream users to avoid their need to depend on snapshots. Submitted by, Craig McClanahan
Re: Source Repository Organization and Release Strategy Thoughts
I like that organization. Keep it as simple as possible and expand on it if needed. Greg On Jul 17, 2006, at 10:11 PM, Wendy Smoak wrote: On 7/16/06, Craig McClanahan [EMAIL PROTECTED] wrote: Before doing so, it's probably worth spending some time figuring out how we want the source repository to be organized ... What do you think? I don't see the need to release things separately right now. Once again we have people asking for a shale-test release, and there have been enough changes in shale-core and shale-clay that it makes sense to go ahead and release the whole thing. For the examples, it seems like we would always want to update them to depend on the latest framework jars, so we might as well just version them together with the framework and release it all at once. Possibly... shale/framework/trunk/ shale/maven/trunk/ shale/sandbox/ The 'framework' directory could be called something else... I'd just as soon have shale/shale/trunk, but Ted says it will confuse viewvc. Sandbox doesn't need trunk/branches/tags, you can just copy sandbox/projectA to sandbox/projectB if you want to try something else. -- Wendy
Re: JSR-299 (Web Beans) Implementation In Shale?
On Jul 27, 2006, at 2:55 PM, Craig McClanahan wrote: What do you think? Are we interested in putting this on our roadmap? (And following up +1s with code? :-) +1. All I know about JSR-299 so far is that it is inspired by Seam. All I know about Seam is what I heard from Gavin's session at JavaOne, and I have to admit it was pretty compelling. Greg
Re: Source Repository Organization and Release Strategy Thoughts
On Jul 29, 2006, at 7:30 PM, Sean Schofield wrote: Is Shale a sourceforge project? http://sourceforge.net/projects/shale Looks like a graphical file mgr for Linux :-) And it appears to be orphaned. At least there's nothing there. Greg
Re: Previous system integration tests now failing?
On Aug 2, 2006, at 12:19 AM, Craig McClanahan wrote: On 8/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: Somewhere in the changes over the last couple of days, the old system integration tests on apps like shale-blank (mvn -Pitest install) have stopped working ... I get an exception from Cargo saying it is not able to create a deployable container. Wendy, does this still work for you? No problems here: Very wierd ... I get an obscure XML parsing error in the log output ... almost like someone is using the wrong XML parser along the way. I've had this happen with unit tests before. I just deleted the surefire plugin stuff from my local maven repo and rebuilt and everything worked. Must've been a bad update. Greg
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
What about just adding shale-petstore as part of shale-goodies? Was that just a thing of getting wires crossed or did you intend for it to be a separate project? Greg On Aug 3, 2006, at 2:26 PM, Sean Schofield wrote: And I just set up a shale-petstore ;-) Do you envision this being more then the petstore app? Also, are we sure we want google as opposed to dev.java.net? I don't know much about the google option. It seems like we can have discussion via a google group. What about distribution of jar files? Sean On 8/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/3/06, Greg Reddin [EMAIL PROTECTED] wrote: +1. I was wanting to figure out what all that google open source stuff was about anyway. But I'm cool with either google or java.net. I just set up shale-goodies for us at Google[1]. Note that you must have a GMail account to log in with for SVN access, but that's already true for a bunch of us. Send me your GMail username and I'll add you in as a project owner. Greg Craig [1] http://code.google.com/p/shale-goodies/ On Aug 3, 2006, at 1:25 PM, Sean Schofield wrote: I'm considering an option that Craig mentioned earlier - moving this to google's new open source area. While I understand the reasons for the tight restrictions that ASF has, it makes it difficult to host a fully functional sample app using several different technologies. On google (and presumably dev.java.net), we can also distribute binaries wither hibernate, etc. That will allow more people to use the app. No matter how easy you make it, some people are just putoff by compiling their own source. I admit, sometimes I fall into this category (if my interest is only casual.) If we do move it, I'd still like some loose integration between shale and this project. This would include links to the shale- petstore from the shale site and referring people on the user list to the shale-petstore when it serves as an appropriate example. Thoughts? Sean On 8/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/3/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote: Most of the images seem to be: GNU Free Documentation License, Version 1.2. What about the text? Any ideas on that? Are you asking about the text on Wikipedia? There's a notice at the bottom of every page: All text is available under the terms of the GNU Free Documentation License. As for whether we can use the text or images, if GFDL is not listed on Cliff's page [1] then I would ask on [EMAIL PROTECTED] I suspect the GNU license for docs will have issues, so asking on legal-discuss would be a good idea. In the mean time, note that the original Blueprints PetStore application (including content and images) is BSD-licensed, so we can use stuff from there. https://blueprints.dev.java.net) Craig [1] http://people.apache.org/~cliffs/3party.html -- Wendy
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
I think I prefer that too. shale.org doesn't appeal to me for some reason I can't really put my finger on. Greg On Aug 4, 2006, at 2:03 PM, James Mitchell wrote: I prefer com.google.shalegoodies Your thoughts? -- James Mitchell 678.910.8017 On Aug 4, 2006, at 11:30 AM, Sean Schofield wrote: Lets think on the package names a bit. OK. What about just org.shale? So for petstore we have org.shale.petstore as the package name with org.shale as the maven group name. Craig Sean
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
I'm cool with that too. It doesn't have to be a web address :-) Greg On Aug 4, 2006, at 2:47 PM, Wendy Smoak wrote: On 8/4/06, Sean Schofield [EMAIL PROTECTED] wrote: The only problem with com.google is if we move it from being hosted on google.com (a distinct possibility at this point.) shale.goodies.petstore ? -- Wendy
Re: Remoting Documentation
Attachment didn't seem to go through. Could you file a ticket? You can send me the file directly I'll still have to open a ticket to commit it. Greg On Aug 8, 2006, at 4:25 PM, David Geary wrote: I've attached an HTML file that documents Shale Remoting. It would be nice if some kind committer could drop it into $SHALE_HOME/ framework/trunk/src/site/xdoc/features-remoting.xml and commit that XML file. I would've given you the XML file directly, but 'mvn site' isn't exactly working for me at the moment. Thanks, david
Re: Confluence Wiki Anyone?
On Aug 8, 2006, at 7:00 PM, Wendy Smoak wrote: The space naming convention would probably give us SHLx___ Do we want to have just one space, and use it like we use Moin, or do we want to push most of the project docs to the wiki? I don't know anything about Confluence so I can't comment on its usability or features, but I *love* the idea of using a wiki for doc. It's so much easier to contribute to. In the second case we might want SHLxDEV for our notes on how to use Maven and Subversion for various things, and another one for docs that get exported and included in the distribution. I'm ok with that so long as we don't make it too hard for people to know where to contribute or look for info. Greg
Re: PROPOSAL Voting For the Logo Contest
On Aug 30, 2006, at 6:26 PM, Sean Schofield wrote: I agree with locking the page down. I don't have any problem with the system as proposed but I think we should add a second round of voting. Lets shorten the initial vote to 7 days. If you miss out on the voting in the first round there's still a second round. That wouldn't bother me. Take the top 5 (weighted) choices of the PMC. If the users top choice is something that is not in the top 5 then substitute the 5th choice for the user's top choice. Then repeat the voting for another 7 days. I dunno. I think maybe the PMC should discuss our course of action if the community's vote is vastly different from our own. We may decide to go with the community's choice instead in an effort to build momentum -- or we may really not like their choice and choose to go with our own. Greg
Re: PROPOSAL Voting For the Logo Contest
On Aug 30, 2006, at 11:19 PM, James Mitchell wrote: One thing that isn't 100% nailed down is the actual voting. Do we want to post our votes to [EMAIL PROTECTED] Or [EMAIL PROTECTED] Or setup a quick web- based poll to keep the votes hidden until the time expires. I think all votes should be to [EMAIL PROTECTED] The purpose of the contest was to get people to subscribe there anyway. I don't have a problem with PMC and community votes going to the same place. I do think we need to keep two separate tallies, but I think if the two groups come up with vastly different results we should seriously consider whether we want to stick to our guns or not. Greg
Re: [PROPOSAL] Migrate Dialog2 Support From Sandbox To Framework
+1 On Sep 28, 2006, at 8:41 PM, Craig McClanahan wrote: The work we've done on the dialog support in the sandbox is showing clear earmarks of success. We can now support 100% of the functionality that actually works in the original implementation, plus have addressed a number of outstanding bug and RFE issues (plus supported a few extra enhancements like programmatic starting of a dialog that were not explicitly mentioned in an issue). I think it is now time to incorporate the results of this effort back into the mainline trunk code. Specifically, I propose to do the following: * Eliminate the original org.apache.shale.dialog (and child packages) code from shale-core. Yes, this is pretty abrupt, but developers who only use the APIs we've exposed for application use will not be affected -- it only impacts those who are using APIs targeted for framework users, and those folks need to be more accomodating about API evolution. * Create new modules under frameworks as follows: - shale-dialog (copied from sandbox shale-dialog2 with package names (etc.) changed from org.apache.shale.dialog2 to org.apache.shale.dialog. - shale-dialog-basic (copied from sandbox shale-dialog2-legacy with packgae names (etc.) changed from org.apache.shale.dialog2.legacy to org.apache.shale.dialog.basic. - shale-dialog-scxml (copied from sandbox shale-dialog2-scxml with package names (etc.) changed from org.apache.shale.dialog2.scxml to org.apache.shale.dialog.scxml. * Update website content in a manner consistent with the refactoring proposal I just sent out. * If we accept the SCXML implementation, start a vote to accept Rahul as a Shale committer. As with the refactoring proposal, I've got some time available starting tomorrow night and through the weekend to devote to these changs, if there are no objections. Thoughts? Craig
Re: Shale-related Tiles 2 issue - solved but not pretty
On Oct 2, 2006, at 6:42 AM, Gregg Leichtman wrote: I solved the problem. I ended up having to wrap all non JSF tags within each tile with verbatim tag pairs. This is definitely far from elegant, but I guess this is necessary until the JSF 1.2 version of MyFaces emerges. I was afraid that would be the solution to your problem. That really sucks. Have you tried using the 1.2 RI? Greg
Re: Shale home page
On Oct 18, 2006, at 5:46 PM, David Geary wrote: If not working on it, I've been thinking about the homepage lately, and it strikes me that I don't really know how to spin Shale. We have so many unrelated features that it's difficult to say Shale is The addition of JPA makes things even murkier. Are we one-stop shopping for JSF? Proving ground for JSF 2.0? I know we're a set of services, but that's a rather bland description. I agree. Until about 4 months ago I only knew very little about JSF. I had not actually written a JSF app. Now, I'm in the middle of writing a pretty significant JSF app and teaching our team of developers how (and why) to use JSF. So I've gone in head first :-) Before I started this adventure I had a difficult time seeing where Shale fit. Now I'm starting to see the plugin points where it makes sense and hopefully we will start integrating Shale into our app in the near future. Maybe it's something like a meta-framework. It's not really a framework as such because JSF is the framework. But it is some missing parts that integrate fairly seamlessly with the JSF framework. Missing parts and added value - things like Clay and Dialog are added value. Things like the core ViewController provide missing pieces to the core JSF framework. Maybe some of the missing pieces should be submitted back as JSRs and we could work ourselves out of a job in that sense. Or maybe not. Maybe they are not as universally applicable as it seems at first glance. Of course as JSR-299 progresses we may find ourselves in a different category. There has been talk of building a JSR-299 implementation when the time is right. Greg
Re: [jira] Reopened: (SHALE-321) Update TilesViewHandler to support new Tiles 2 Snapshot
--- Key: SHALE-321 URL: http://issues.apache.org/struts/browse/SHALE-321 Project: Shale Issue Type: Bug Components: Tiles Affects Versions: 1.0.4-SNAPSHOT, 1.0.5-SNAPSHOT, 1.0.6-SNAPSHOT Reporter: Greg Reddin Assigned To: Greg Reddin Priority: Blocker Fix For: 1.0.4-SNAPSHOT Changes to the Tiles 2 API have broken Tiles support in Shale. We need to modify TilesViewHandler so it will compile. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira
Publishing Snapshots (WAS: [jira] Reopened: (SHALE-321) Update TilesViewHandler to support new Tiles 2 Snapshot)
On Nov 6, 2006, at 3:45 PM, Wendy Smoak wrote: Well, no, since I just published a snapshot. :) IMO, the snapshot repo should always have the latest-- Continuum ought to be publishing a new one every time code is checked in, or at least nightly. On [EMAIL PROTECTED], we've talked about switching to timestamped snapshots, so that other projects could depend on a particular Tiles snapshot, and not necessarily the latest. I saw that discussion, but didn't really have time to digest it. I think there needs to be a way to publish milestone builds. Not a significant milestone like an RC, but more like an incremental milestone. For example, there are big changes being made with Tiles. Along the way, changes happen in chunks. At the end of a chunk applications can migrate to chunk-compatibility. Over time, it allows apps to migrate incrementally as the framework changes and by the end of the revolution, they are up to date. Right now we're in the middle of a change cycle and it doesn't really make sense to update code until this change cycle is complete. So.. what I would like is the ability to publish a dated snapshot, perhaps manually, when a change cycle is complete. I don't see the need to publish a new one with every minute change that happens. It makes more sense to publish one when a series of changes is complete. Greg
Release Status
My project at work is finally in a place where we really need to use Shale :-) The 1.0.3 release does not work out of the box for us because we are using MyFaces 1.1.5 and Shale 1.0.3 depends on MyFaces 1.1.1. Shale 1.0.4-SNAPSHOT does not. So I started looking to see where we stand on publishing a release. I started in the wiki to see the Release plans and there's not one for 1.0.4. However, I did see links to Bylaws and Release Guidelines that don't exist. And I found this: http://wiki.apache.org/shale/ReleaseGuidelines The Bylaws and Release Guidelines seem to be something we need to work out pretty soon - possibly before we release anything else. Am I correct? Getting past that I went to JIRA to see what's to be done before releasing 1.0.4: https://issues.apache.org/struts/secure/IssueNavigator.jspa? reset=truemode=hidesorter/order=DESCsorter/ field=priorityresolution=-1pid=10130fixfor=21740 and there's still quite a list. In addition there's tickets that aren't assigned to a release. So, what has to be done before we can cut a release? If we can narrow it down to a manageable list, I'm willing to help get the release done so we can depend on something besides a snapshot. Greg
Re: Release Status
On Dec 14, 2006, at 3:42 AM, Craig McClanahan wrote: It's just what the POM says, but I don't know how to override it. In 1.1.1 MyFaces used the myfaces groupId and now they use org.apache.myfaces. Because of this Maven doesn't know that my dependency on MyFaces 1.1.5 should override Shale's dependency on 1.1.1. I thought I saw a way somewhere to work around that, but I can't find it now. Yah, dependencies that rename themselves can definitely be a problem :-(. I kiboshed the idea of renaming Commons Digester 1.8's group id for essentially the same issue. The theoretical solution to this is that your downstream dependency (MyFaces in this case) would publish a redirect pom that says any reference to myfaces:myfaces-api now referes to org.apache.myfaces:myfaces-api (and the same for the impl jar), but apparently this is not trivially simple yet with Maven. That's right, the redirect. I'll look that up and see if I can use it while we're working on the next release. Ideally, we should be able to incorporate an arbitrary set of Shale modules into a release, while other modules might be releaseable separtely. Later on, we need to be able to merge something that becomes mature (say, shale-tiles), while also being able to omit something that is -- at that point in time -- undergoing some destabilizing development. I'm hoping our resident Maven/SVN geniuses can help identify viable strategies for executing on these ideals. If not, we might have to go with the alternative of a combined release with different quality grades (which it sounds like Struts2 is going to do). Let me make sure I understand what we have. Please correct any misunderstandings below. shale-master.pom - This is the base POM for the whole project. It inherits from an org.apache parent. We only have to release a new version of this if the information contained in it changes, right (i.e. add new committer, mailing list, svn changes, etc.) And we can release it independently of everything else? shale-parent.pom - The base POM for shale subprojects. It defines the modules, base dependencies, etc. If we release anything (shale- remoting, for example), we also have to release shale-parent, which means we have to release everything, right? I guess one brute force method to release only certain artifacts would be to remove the modules we don't want to release from the parent POM, then replace them after running the release process. Kinda sucks, but it might work. Before we roll a release at work we have to comment out a bunch of SNAPSHOT plugins in the POM that don't really apply to the released artifacts. Greg
Re: Release Status
On Dec 14, 2006, at 8:53 AM, Niall Pemberton wrote: As the shale-tiles module has no dependency on the rest of shale and can be used in a vanilla JSF environment wouldn't it make more sense to move this to the proposed Tiles project? I think the argument for having JSF support in Tiles is different to the one of including support for Struts or any other framework in the Tiles project since JSF is a standard. I've thought about that myself. Shale-Tiles is *just* a ViewHandler. I fear that importing it into the Tiles project might be a mistake for at least a couple of reasons: 1) It sets a bad (IMO) precedent of Tiles providing integration with parent frameworks instead of the frameworks providing integration with Tiles. 2) It may send the message that JSF is a preferred framework for Tiles, and people will start to ask questions about why Tiles doesn't provide Struts integration, etc. I'm more comfortable with Shale-TIles staying here or even moving to MyFaces as an extension than becoming part of the core Tiles framework. That would resolve the potentially confusing issue of having different pieces with different quality labels? It would solve the most immediate problem, but I don't think it addresses the root cause. Shale is made up of a bunch of loosely- coupled components - so much so that, as you pointed out, most of them could live completely independently of one another. But if each one was required to go through the whole release process separately, none of them would ever be released :-) Plus, you also pointed out the issue of compatibility. How can I know if shale-remoting-1.0.4 can live happily alongside shale-dialog-1.0.6? If we could cut a release that includes only selected components we might have this: shale-1.0.4 includes: - shale-core-1.0.4 - shale-remoting-1.0.4 - shale-clay-1.0.4 Then Clay goes into unstable development while dialog-basic stabilizes so we release: shale-1.0.5 includes - shale-core-1.0.5 - shale-remoting-1.0.5 - shale-dialog-basic-1.0.5 But what if I need shale-1.0.5 and I'm using Clay? Which Clay do I use? Is clay-1.0.4 compatible with core-1.0.5? Maybe there's a way for shale-1.0.5 to include shale-clay-1.0.4 with a label of shale- clay-1.0.5. That sounds pretty screwy, but the advantage is that users can know that components with the same version number are compatible. Having an all distro is a good plan IMO - but also making the independent components also available as separate downloads would help communicate that there are pieces available to use on their own and having independent version numbers for them and not precluding the possibility of separate release in the future would seem like a good idea IMO. For projects using maven, of course, this is already possible. I don't know when the last time was I actually downloaded a release package. I just get it by adding a reference in my Maven POM to specific components. To me, this approach is much easier when all the components have the same version number. Greg
Re: Release Status
On Dec 14, 2006, at 9:22 AM, Wendy Smoak wrote: Yes, shale-master is released independently. It has to be released in advance of the framework so we don't have a snapshot as a parent. Oh, I see. When I first looked at it I couldn't find a version number. shale-parent.pom - The base POM for shale subprojects. It defines the modules, base dependencies, etc. If we release anything (shale- remoting, for example), we also have to release shale-parent, which means we have to release everything, right? Right now, the build process is set up to release everything together. It's not a Maven requirement-- consider the Maven plugins, which have a parent pom, yet get released one at a time. Whether to release the framework together or in pieces is just something we need to decide, figure out how to communicate to users, and then adjust the build to match. Sounds like that decision is the next logical step then. If we went with separate releases for each artifact does that just involve removing the modules from the shale-parent POM? What about shipping shale-tiles in a directory other than 'lib' to indicate that it isn't part of the normal distribution? Something like the 'contrib' directory in Struts 1.2 that includes struts-el and struts-faces. I saw something about Struts 2 marking things as experimental. I'm not sure how they are doing that though. Greg
SHALE-335 Resolved?
This issue appears to be fixed in Subversion. https://issues.apache.org/struts/browse/SHALE-335 Is anything holding it up from being resolved? Greg
Re: Release Status
On Dec 14, 2006, at 10:43 AM, Wendy Smoak wrote: For the record, I'm for together. While there are some good arguments for releasing components individually, and it might even be easier from a technical standpoint, I think we'll have problems explaining it to users. (I remember not wanting to announce a new release of the struts-core jar because I couldn't figure out how to word it without making it sound like *all* of Struts 1.3 was ready.) That's the dilemma. Releasing separately is hard for users to figure out. Releasing together means release cycles are longer because a single component is not yet ready. I'd prefer the unified release myself but how would we get past that hurdle? And if all else fails, I'll fall back on the be like Spring argument. :) Sorry, I'm not familiar enough with Spring to know what that means :-) On a related topic, I think if we're going to do the 'tag it, build it, and vote on quality later' thing, it has to be okay to 'skip' version numbers. (Something IIRC Craig and Sean said they were not in favor of.) What's the objection to skipping versions? Greg
Re: Release Status
On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote: In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this weekend once I'm done traveling -- that leaves us with SHALE-61. I dropped the ball on that, and ATM I don't think there is any concrete proposal towards it. It looks like code has been checked in for SHALE-61, but maybe it just needs to be tested? At some point, I'd like to RM a Shale release so I'm aware of all the minutiae. If you guys are OK with it, now is as good a time as any That's funny. I was going to volunteer too :-) Maybe we can tag team it. Greg
Re: Release Status
On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote: In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this weekend once I'm done traveling -- that leaves us with SHALE-61. ... also SHALE-211 [1]. I'm guessing we can close that one. Any objections? Greg [1] https://issues.apache.org/struts/browse/SHALE-211
Re: Release Status
On Dec 15, 2006, at 11:10 AM, Rahul Akolkar wrote: ... also SHALE-211 [1]. I'm guessing we can close that one. Any objections? snip/ Resolve it, at worst it will get re-opened. Its shouldn't affect the release anyway, IMO. Done :-) Greg
Re: Release branch (was Re: Release Status)
Just a question: are you keeping good notes as to what you're doing? I'd like for the details of the process to end up on a wiki page if they are not already there. After reading these messages I have no clue what you are doing :-) Greg On Dec 19, 2006, at 7:49 PM, Rahul Akolkar wrote: On 12/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Sounds like reasonable things to do :-) We even have a staging repo defined in the master pom (thanks Wendy) which we should use for this. By default if the version doesn't end in -SNAPSHOT, the artifacts will end up in http://people.apache.org/builds/shale/m2-staging- repository. snip/ Ah, thats confirmation for one of my questions in the master pom thread. Because each release needs to be staged separately, the entire directory should be moved elsewhere sooner or later. I'd suggest moving it underneath wherever you're staging the assemblies for the vote. snap/ That directory (the staging repo) seems currently empty (has some directories, but they are empty). Maybe I will clean it for good measure before I start with the master pom (if I have the Unix perms). We'll probably move it to the ~ where any assemblies get posted. One other thing... I think we'll need to branch for releases. Continuum [1] is building from the trunk, so changing the version number to a non-snapshot will cause it to build and deploy those jars to the staging repo based on the configuration in the pom. Sounds like we need a 1.0 branch in any case, so this shouldn't be an issue. snip/ OK, if everyone's fine with that, I will create the 1.0 branch (called SHALE_1_0_x unless there are better suggestions) when we get closer to the release (after all 1.0.4-SNAP issues are resolved and the master pom is released etc.) -Rahul [1] http://myfaces.zones.apache.org:8080/continuum/servlet/continuum -- Wendy
Re: Releasing shale master pom
On Dec 19, 2006, at 10:46 PM, Craig McClanahan wrote: The updater should be our long term direction, unless/until the Maven release plugin does all the stuff we need for staging votes. What's missing in the release plugin? Just that there's no way to stage a release? Do we use the release plugin to publish a release? Greg
Re: Release branch (was Re: Release Status)
On Dec 20, 2006, at 2:51 PM, Craig McClanahan wrote: * Since the trunk is being continuously built by Continuum, trying to do our release cutting there (including removing SNAPSHOT from the version numbers) would cause Continuum to publish a release, with the real version number, before we had a chance to vote on it. Hence, we need to branch for the actual release cutting process, and do it there. So the first thing we'd do when we decide to release is - after finishing up business - start a branch for the release. Then we work up the release process in the branch. Once the release is ready and voted on, we cut a tag from the branch and roll the release. Does that sound reasonably close to what you have in mind? :-) * I have a desire to push our further development process to a model where we're doing new feature development only on the trunk, but we maintain active branches for backporting bugfixes and security patches as needed. [...] I've been seeing lots of projects get dinged because they mix bugfixes and feature updates all the time, so you can't get one without the other -- to say nothing about how it stretches out your release cycles (just as we're seeing with 1.0.4 :-). Today's thread on the MyFaces dev list is just one sample of this. I'm definitely in favor of this approach. I've been following the MyFaces discussion. As a MyFaces user I'm stuck in a place where I have to depend on a snapshot simply because our application cannot use any combination of core and tomahawk code I really don't want to get into a situation like that with Shale and it could happen easily. We're like MyFaces in that we have multiple sub-projects that can live independently but have to be able to work together. From a developer perspective, I think setting up a branch whenever you want to work on a new feature when it's not the right time to build it into the next release will help us remove that instinctive pressure to add one more feature, but also satisfy the itch that I want to get my initial work out there shared someplace it can be collaborated on. Yep, I had the first big Tiles refactor on my computer for at least a month before I was able to commit it and that was a sandbox project! I think this would also render moot the decision whether or not to do separate or combined releases. Greg
PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws
The Shale project currently does not have a bylaws document. I propose that we adopt the Struts bylaws[1] as the basis for our own bylaws document and make changes in the following areas: 1. Change all instances of Struts to Shale. 2. Discuss the Subprojects section. Specifically, do we want subprojects to be the unit of release? 3. Discuss the Release Grade section. Are we comfortable with the Struts definition of this section or would we like to refine it? Thanks, Greg [1] http://struts.apache.org/dev/bylaws.html
Re: Release branch (was Re: Release Status)
On Dec 20, 2006, at 7:54 PM, Wendy Smoak wrote: On 12/20/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote: So the first thing we'd do when we decide to release is - after finishing up business - start a branch for the release. Then we work up the release process in the branch. Once the release is ready and voted on, we cut a tag from the branch and roll the release. Does that sound reasonably close to what you have in mind? :-) Yep. Two other notes: Unless we're going to vote twice, the vote comes after tag and roll the release. (It has to exist before we can vote on it. This is related to release staging, where we tag and build the release, then put it somewhere temporarily for examination and the vote.) That makes sense. Greg
Re: [v104] Ready
On 12/31/06, Craig McClanahan [EMAIL PROTECTED] wrote: We had talked earlier about the idea of doing quality rankings on the individual packages separately, so that we'd have a chance to grant a GA quality vote on some remaining portion other than shale-tiles. If we still feel this way, I'd suggest modifying this text to something like this: This is the fourth milestone release of Shale, released to encourage experimentation and gather feedback on usage issues and requested features. A full vote on quality has yet to take place for this release, but will take place later. We plan to vote on the quality of each module separately (where necessary). For example, the shale-tiles module is likely to receive a grade no higher than Beta because it relies on a snapshot of the as-yet unreleased Standalone Tiles package. +1 to the above. Greg
Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]
On 1/15/07, Kailas Lovlekar [EMAIL PROTECTED] wrote: Shale is listed at version 1.1.0 All the pom.xml files show 1.1.0-SNAPSHOT, not sure how 1.0.4 was derived for next release. I believe it's just an iteration. When we got 1.0.4 ready we renamed the trunk to 1.1.0-SNAPSHOT expecting that to be the next major release. That doesn't mean there won't be anymore 1.0.x releases, but I think it means they will take place in the 1.0 branch. Greg
Re: Shale - Release
On 6/22/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? Agreed. I've been meaning (for months) to update the Tiles support and haven't gotten around to it. I'll try to make that a priority. Greg
Re: Shale - Release
On 6/22/07, Rahul Akolkar [EMAIL PROTECTED] wrote: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk I'd be happy with either of the above, perhaps some preference for A. It depends on the workload involved with upgrading to the 1.2 spec. If the load is heavy, A would be better. If it's lighter, B would be better. I wonder how many people are still using 1.1. We are currently still bound to it, but could upgrade without too much work, and probably will as soon as MyFaces 1.2 is released. Greg
Re: [VOTE] Accept the Shale Clay Plugin for Eclipse contribution
On 7/11/07, Wendy Smoak [EMAIL PROTECTED] wrote: [X ] +1 - Let's accept the contribution [ ] -1 - We should not accept it because... Greg
Re: Merging Shale into MyFaces
On 10/20/07, Kito D. Mann [EMAIL PROTECTED] wrote: I sent out an e-mail to the Shale mailing list a week or so ago about the possibility of merging Shale with MyFaces. Development of Shale has become somewhat stale, and I'd rather see MyFaces pickup the pieces than have the code base atrophy The overwhelming consensus for the Shale list is yes (and Craig is no exception). What does the MyFaces PMC think? Wow, my mailing-list mgmt. skills must be worse than I thought :-) How did I totally miss that thread? I'll check the archives. Anyway, I'm in favor of the notion. My only reservation would be that the MyFaces community could become too splintered with JSF extras. Was that discussed in the original thread? Greg
Re: Merging Shale into MyFaces
On 10/21/07, Niall Pemberton [EMAIL PROTECTED] wrote: This is one class[1] and despite what the shale-tiles pom[2] declares, it doesn't relate to/depend on any other parts of shale - just JSF and Tiles. So it could just as easily be moved to the tiles TLP. Having said that, I suggested this a while ago and it was rejected then[3] I think we were opposed to the idea of providing integration support for every framework imaginable in the Tiles project. We might be open to rethink some of that, at least providing some support in subprojects, etc. My objection was that I didn't want to have to include dependencies to umpteen frameworks just to implement an integration class. I would be open to the idea of providing optional (Tiles) subprojects, etc. that self-contained the dependencies, testing, etc. I'm starting to see that such support could fall under the purview of the Tiles project. Greg
Re: Merging Shale into MyFaces
On 10/21/07, Craig McClanahan [EMAIL PROTECTED] wrote: * Tiles Integration See Clay. +0 I'll abstain here and since I don't know much about the Tiles side of things. Let's just say that I think Tiles integration should just work in MyFaces and Shale. Likely relevant for historical Struts1 users who want to stick with JSP as their view technology. I'm not sure how relevant even this is presently. Tiles 2 is so far removed from Struts-Tiles that there would still be a significant learning curve/porting effort. We support the idea of a Struts-Tiles compatibility layer, but to my knowledge, no work has been done to that end. Greg
Re: [release] Last release of Shale?
On Dec 19, 2007 4:32 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: Looks like the two remaining issues are the snapshot version of the shale-master pom, and the Tiles dependency which is on an old snapshot. Shale Tiles does not compile against any release of Tiles 2. Is anyone planning to work on the Tiles integration? snap/ This seems to be on the critical path. Anyone? I'm listening, but having a hard time making time to do the Tiles thing. My work is starting to slow down a bit. Maybe I can jump in and upgrade the Tiles support by the end of the week. Greg
Re: Proposal: Sundown Shale-Tiles
On Jan 2, 2008 6:25 PM, Gregg Leichtman [EMAIL PROTECTED] wrote: Does the MyFaces view handler support JSF 1.2? I'm ashamed to say I don't know what's changed in the ViewHandler API between 1.1 and 1.2. If there are changes I suspect the current view handler from MyFaces or Shale wouldn't be compatible, right? I think I've heard somewhere in MyFaces land that Tomahawk is not 1.2-compliant. I hope someone will chime in and clarify :-) Greg
Re: Proposal: Sundown Shale-Tiles
On Jan 4, 2008 8:40 PM, Gregg Leichtman [EMAIL PROTECTED] wrote: I consider this important, since I use Tiles and I want to and currently am using JSF 1.2, since it resolves the interweaving problem among other things. Granted, I could potentially move to Clay, but I came from Struts and I am familiar with Tiles and it does what I need it to do, especially the latest version. IHMO the current state of Tiles support in MyFaces and Shale acts as a barrier to Tiles adoption under JSF 1.2 which I hope is not intentional. My original intent was to invest effort in getting Tiles to work better with JSF. Then I discovered Facelets and decided my efforts would be largely redundant. I haven't used Clay yet, though I didn't ignore it intentionally, but to me, Facelets does for JSF what Tiles originally did for Struts. That is, it provides an extremely easy-to-use templating and page-building system. Once I got used to Facelets JSP in JSF felt like driving a 1973 Plymouth that gets about 4 mpg gas mileage :-) I do think Tiles could do a lot for JSP in JSF with some TLC, but, again, the work just seems redundant to me. The effort to migrate from Struts-Tiles to Tiles 2 is about the same as learning Facelets. I still love Tiles and I think it has a good future, but the low-hanging fruit has been harvested IMO. Greg
Re: AW: Shale Status
On Feb 6, 2008 4:12 AM, samju [EMAIL PROTECTED] wrote: * Seam similar architecture. Which Shale concepts did Seam implemented? Was Shale created to elaborate JCreator? Seam implements the annotations piece which is also in play for JSF 2.0. I think Seam also implements some of the concepts in the ActionController. I can't remember about the Remoting. Some of the ideas of the Dialog components are also present in Seam, but I don't think they've taken it as far. Greg
Test Failure
When I try to build shale at the root level (i.e. building all subprojects) I get an error trying to build shale-core. It throws a NoClassDefFoundError on ViewExpiredException (see error below). It appears I'm somehow using a JSF 1.1 implementation. How should I go about building with a JSF 1.2? I'm on Mac OSX Tiger so I figured the jdk 1.5 profile would fire. Thanks, Greg Error messages: --- T E S T S --- Running org.apache.shale.util.TokenProcessorTestCase Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.703 sec FAILURE! Running org.apache.shale.util.ConverterHelperTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.094 sec FAILURE! Running org.apache.shale.util.MessagesTestCase Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.135 sec FAILURE! Running org.apache.shale.util.LoadBundleTestCase Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.127 sec FAILURE! Results : Tests in error: testPristine(org.apache.shale.util.TokenProcessorTestCase) testMultiple(org.apache.shale.util.TokenProcessorTestCase) testMessagePropertyOverride(org.apache.shale.util.TokenProcessorTestCase) testMessageFacesConfigBundleOverride(org.apache.shale.util.TokenProcessorTestCase) testMessageDefault(org.apache.shale.util.TokenProcessorTestCase) testNullViewRoot(org.apache.shale.util.ConverterHelperTestCase) testEngish(org.apache.shale.util.MessagesTestCase) testFrench(org.apache.shale.util.MessagesTestCase) testPristine(org.apache.shale.util.MessagesTestCase) testEngish(org.apache.shale.util.LoadBundleTestCase) testFrench(org.apache.shale.util.LoadBundleTestCase) testPristine(org.apache.shale.util.LoadBundleTestCase) Tests run: 12, Failures: 0, Errors: 12, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. One of the surefire reports has this: java.lang.NoClassDefFoundError: javax/faces/application/ViewExpiredException at org.apache.shale.test.mock.lifecycle.MockLifecycle.init(MockLifecycle.java:52) at org.apache.shale.test.mock.lifecycle.MockLifecycleFactory.init(MockLifecycleFactory.java:45) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at javax.faces.FactoryFinder.newFactoryInstance(FactoryFinder.java:138) at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:107) at org.apache.shale.test.base.AbstractJsfTestCase.setUp(AbstractJsfTestCase.java:125) at org.apache.shale.util.TokenProcessorTestCase.setUp(TokenProcessorTestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
Re: Test Failure
On Wed, Feb 20, 2008 at 4:37 PM, Greg Reddin [EMAIL PROTECTED] wrote: When I try to build shale at the root level (i.e. building all subprojects) I get an error trying to build shale-core. It throws a NoClassDefFoundError on ViewExpiredException (see error below). It appears I'm somehow using a JSF 1.1 implementation. How should I go about building with a JSF 1.2? I'm on Mac OSX Tiger so I figured the jdk 1.5 profile would fire. I can't build the 1_0_x tree either. The validator test fails because it seems to not be loading TestBundle.properties for whatever reason. Has anybody experienced that issue? testMessage(org.apache.shale.validator.converter.AbstractConverterTestCase) Time elapsed: 0.179 sec FAILURE! junit.framework.ComparisonFailure: expected:Custom Long Error Message but was:???errors.long??? at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.shale.validator.converter.AbstractConverterTestCase.testMessage(AbstractConverterTestCase.java:110) Thanks, Greg
[ANNOUNCE] New Shale PMC Chair
In its meeting yesterday the Apache Board of Directors unanimously approved a resolution naming Gary VanMatre the new chair of the Apache Shale Project Management Committee. Please join us in congratulating Gary for this new role. In addition we would like to publicly thank Craig McClanahan for his service to this project and his invaluable contribution to the Java web application development community. We are endlessly grateful to him for his role in defining the JavaServer Faces framework and, more specifically, in birthing the Shale project. It is no small loss to this community that his work has made it difficult for him to be as involved as he once was. At his own request, Craig is now an emeritus member of the Shale PMC. Thank you, Greg Reddin Apache Shale PMC Member
Re: Removing Tiles
On Wed, Feb 20, 2008 at 2:04 PM, Wendy Smoak [EMAIL PROTECTED] wrote: On Wed, Feb 20, 2008 at 12:01 PM, Greg Reddin [EMAIL PROTECTED] wrote: To get rid of the Tiles modules do you think it is sufficient to simply remove the references from the POM or should we delete or move the svn tree as well? Move the svn tree (do we have a sandbox?) and remove the module from the top level pom. The assemblies will also need to be fixed as they will be expecting to find the source code, website, etc. I think I have removed all dependencies and references to Tiles in the source code, documentation, examples, and assemblies - except where the references are still relevant. I'd love for somebody to give everything a whirl and ensure it works. Please reopen SHALE-483 if you find a problem. Thanks, Greg Just comment on the JIRA issue with what you've done so far, and someone else can jump in to fix the rest. :) -- Wendy
1.0.5 Release
I've fixed the build problems in the 1_0_X branch and completed the extraction of the Tiles integration component. There are two Clay-related tickets still posted to 1.0.5 [1] that don't seem critical to me. I'd like to volunteer to be the RM for a 1.0.5 release if everybody else is on board. I'm not a fast-mover and I'm not sure what my schedule will be but I would like to do it so I can understand the process. I'll start by reading up on the release process on the wiki and we can take it from there. Let me know if you have any objections to this direction. Thanks, Greg [1] https://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10130fixfor=21751
Re: 1.0.5 Release
Can someone doublecheck these two wiki pages and let me know if they are out of date? Will I be ok using these as a guide? I noticed there is no release plan page for 1.0.4. Was that intentional and/or should I create one for 1.0.5? http://wiki.apache.org/shale/ReleaseGuidelines http://wiki.apache.org/shale/ReleaseProcess Thanks, Greg
Re: [OT] Re: @SHALE-442
We got the mail three times - at least I did :-) On Tue, Apr 1, 2008 at 1:37 AM, Torsten Krah [EMAIL PROTECTED] wrote: Something off-topic, i'll wrote the mail 3 times now and 2 got not delivered because the list produces invalid mail headers (it inserts a reply-to header instead of replacing the existing one, in the end the mail gots 2 of them which is not valid). As for that specific problem I have no idea what to do about it. Sorry. http://shale.apache.org/mail-lists.html does not tell me whos responsible and where should i mail this problem to, can anyone help? You can try [EMAIL PROTECTED], but I'm not sure who that will go to. Hopefully somebody else on this list will know how to address your problem. I'm glad you didn't just machine gun the send button though :-) Greg
Re: @SHALE-442
On Mon, Mar 31, 2008 at 5:24 PM, Torsten Krah [EMAIL PROTECTED] wrote: I want to fix this bug 442 and want to ask some question here about doing that, if thats ok, i'll hope so. This is definitely the right place to discuss such fixes. I'll fixed the decorator not to apply shales validator renderer if the renderer family matches the ajax stuff, which let them work again. However this seams not the ultimate approach to me because there are so many different familys and renderers which should not be decorated, that i'll have to code everytime they change. At first glance, I don't think it's a good idea to hardcode a set of renderer families that will not apply like that. The root of the problem is that you can't have both the validator and ajax renderers and the combination is a valid one. So it seems like we need to rethink (maybe) the way we handle the validator renderers. Right now I don't have a better answer for you. Greg
[VOTE] Release Shale Master POM Version 3
This is the formal vote for the new Shale master POM version 3. I would appreciate a thorough review of these artifacts since I am a release manager newbie :-) You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom and approve of it -1 if you found a flaw or potential problem with the new master pom Thanks, Greg [1] http://people.apache.org/builds/shale/m2-staging-repository/org/apache/shale/shale-master/3/
Re: [VOTE] Release Shale Master POM Version 3
I would like to cancel this vote and go ahead and implement the changes outlined by Rahul that will keep the site from redeploying when the master-pom is released. You can track progress in SHALE-487: https://issues.apache.org/struts/browse/SHALE-487 Any objections? Greg On Fri, Apr 11, 2008 at 11:29 AM, Greg Reddin [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:59 AM, Greg Reddin [EMAIL PROTECTED] wrote: Please vote +1 if you reviewed the new master pom and approve of it -1 if you found a flaw or potential problem with the new master pom I'll add my +1 as well. Just a note: I'm leaving town tomorrow morning and won't be available to do more work on this until probably Wednesday. If y'all are anxious to get things out there someone can go ahead and complete the process for the master POM, but if you do please update the wiki page I created [1] so future RM's can have an exact list of what needs to be done to publish a release. Otherwise I'll get back on it sometime Wednesday or so. Thanks, Greg [1] http://wiki.apache.org/shale/ReleasePlan105
Re: Master pom changes (was: Release Shale Master POM Version 3)
On Fri, Apr 18, 2008 at 6:58 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: I was hoping to just redo it. It has not been sync'ed yet so I'll just svn rm the tag and the artifacts on the staging repo and to it over. In case anyone's wondering, I'm still planning to continue the release process. I was going to get back on it this week, but I've decided to wait until the svn issues are resolved. In the meantime, when I can find time I will track down the further changes needed to the master pom. Thanks, Greg
Re: Master pom changes (was: Release Shale Master POM Version 3)
On Fri, May 2, 2008 at 10:42 AM, Paul Spencer [EMAIL PROTECTED] wrote: Greg, Thank you for the update. For clarification, what are you artifacts are you planning on releasing in the near future. We are going to try to do a 1.0.5 release of the entire framework. But there are a few changes that need to be made to the master pom first. So the plan is: 1) Bring the master pom up to date and release it. 2) Release 1.0.5 of all framework components. Then I will start looking at getting 1.1.0 up to snuff for a release. Greg
Re: Master pom changes (was: Release Shale Master POM Version 3)
On Fri, May 2, 2008 at 2:02 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: I think the master pom is mostly ready for a vote (unless you're having issues with the build due to any particular now-locked-down plugin that you weren't having before). No issues. I was just trying to decide whether to go ahead and move all the plugins to the latest versions or just release it as it is and do that later. Depending on how much time I can find this weekend I may go ahead and push for a release as it is now. Thanks, Greg
[VOTE] Release Shale Master POM Version 3
This is the formal vote for the new Shale master POM version 3. The former vote for the same version was cancelled due to problems in the POM. The POM was corrected and the release process was re-executed since the previous release had not been copied to the main repository. You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom and approve of it -1 if you found a flaw or potential problem with the new master pom Thanks, Greg [1] http://people.apache.org/builds/shale/m2-staging-repository/org/apache/shale/shale-master/3/
Re: m2 gpg plugin (was Re: Update of ReleasePlan105 by GregReddin)
On Mon, May 12, 2008 at 11:18 AM, Rahul Akolkar [EMAIL PROTECTED] wrote: Its sometimes tedious to figure out why certain things are not happening in the m2 build, but I think it'll be worthwhile spending some time trying to fix this -- it will be a lot of work if you have to manually sign the artifacts in the framework release(s). True, I didn't think about that. I'll look into it. I saw something somewhere about the GPG plugin. I'm sure I can figure out how to add that goal to the release process. Greg
Re: [VOTE] Release Shale Master POM Version 3
On Mon, May 12, 2008 at 10:48 AM, Greg Reddin [EMAIL PROTECTED] wrote: Please vote +1 if you reviewed the new master pom and approve of it -1 if you found a flaw or potential problem with the new master pom Here's my +1. Anybody else care to vote on this one? Greg
Re: [VOTE] Release Shale Master POM Version 3
On Sat, May 17, 2008 at 11:44 AM, Wendy Smoak [EMAIL PROTECTED] wrote: (I'm having trouble actually building Shale (test failures, problems in the Tiger module, missing Cargo dependency?) but I see no reason to hold up the master pom release.) Is that occurring when building the trunk or the 1_0_X branch? I think I've fixed all the problems in the 1.0 branch, but I haven't looked at the trunk yet. Greg
[RESULT] [VOTE] Release Shale Master POM Version 3
The vote has passed with three binding +1s and no -1s. I will complete the release process today and hopefully start on a 1.0.5 framework release. Thanks, Greg On Mon, May 19, 2008 at 9:03 AM, Greg Reddin [EMAIL PROTECTED] wrote: On Sat, May 17, 2008 at 11:44 AM, Wendy Smoak [EMAIL PROTECTED] wrote: (I'm having trouble actually building Shale (test failures, problems in the Tiger module, missing Cargo dependency?) but I see no reason to hold up the master pom release.) Is that occurring when building the trunk or the 1_0_X branch? I think I've fixed all the problems in the 1.0 branch, but I haven't looked at the trunk yet. Greg
Release Status
Just an update on the status of Release 1.0.5. I am unable to get the apps to build unless I use the jsfri12 profile. Using MyFaces doesn't seem to pull in all the needed Servlet/JSP dependencies. We are back a version on MyFaces. I'll try to upgrade that and see if it helps. If not, I can include the dependencies explicitly, but if it ever worked, why not now? Using jsfri (for JSF 1.1) it cannot find jsp-api-1.2 on ibiblio or java.net (no matter which java.net repo I use). There's another missing dep here declared transitively by the jsf-api. I think it's jstl. The other profile is jsfee5. I haven't tried that one yet. Hopefully I'll get these resolved soon. Please advise if you have any suggestions. Thanks, Greg
Re: svn commit: r661427 - /shale/framework/branches/SHALE_1_0_X/KEYS
On Thu, May 29, 2008 at 1:43 PM, Wendy Smoak [EMAIL PROTECTED] wrote: I see that this is on a branch, is there also one on trunk? There should be only one KEYS file for Shale, which is then published at http://www.apache.org/dist/shale Therre is a file on trunk and my key was already added there. Should I remove the one under the branch? Greg
1.0.5 Release Notes
I just checked in a release notes document for the upcoming 1.0.5 release. Please let me know if you'd like changes to be made to it before I proceed. Thanks, Greg
[VOTE] Release Shale 1.0.5
A set of artifacts for Shale 1.0.5 is now ready. Please review the artifacts mentioned below and vote accordingly. Since this is my first time as release manager I wouldn't be surprised if something is missing or if I've included things that shouldn't be included, so I'd appreciate as thorough a review as you have time for. In particular I see a lot of Maven artifacts and zip files that were not included in previous releases so I wonder if they are meant to be release (the *test* artifacts for example). (1) The repository has been tagged here: http://svn.apache.org/repos/asf/shale/framework/tags/SHALE_1_0_5/ (2) The Maven artifacts are staged here: http://people.apache.org/builds/shale/shale-1.0.5/m2-staging-repository/ org.apache.shale.extras:mailreader-jpa:1.0.5 org.apache.shale:shale-application:1.0.5 org.apache.shale:shale-apps-parent:1.0.5 org.apache.shale:shale-blank:1.0.5 org.apache.shale:shale-clay-usecases:1.0.5 org.apache.shale:shale-clay:1.0.5 org.apache.shale:shale-core:1.0.5 org.apache.shale:shale-dialog-basic:1.0.5 org.apache.shale:shale-dialog-scxml:1.0.5 org.apache.shale:shale-dialog:1.0.5 org.apache.shale:shale-mailreader-jpa:1.0.5 org.apache.shale:shale-mailreader:1.0.5 org.apache.shale:shale-parent:1.0.5 org.apache.shale:shale-remoting:1.0.5 org.apache.shale:shale-spring:1.0.5 org.apache.shale:shale-sql-browser:1.0.5 org.apache.shale:shale-test-core:1.0.5 org.apache.shale:shale-test-dialog-basic:1.0.5 org.apache.shale:shale-test-dialog-scxml:1.0.5 org.apache.shale:shale-test-tiger:1.0.5 org.apache.shale:shale-blank:1.0.5 org.apache.shale:shale-test-view:1.0.5 org.apache.shale:shale-tiger:1.0.5 org.apache.shale:shale-usecases:1.0.5 org.apache.shale:shale-validator:1.0.5 org.apache.shale:shale-view:1.0.5 (3) The release artifacts are available here: http://people.apache.org/builds/shale/shale-1.0.5/dist/ mailreader-jpa-1.0.5.zip shale-blank-1.0.5.zip shale-clay-usecases-1.0.5.zip shale-framework-1.0.5.zip shale-mailreader-1.0.5.zip shale-mailreader-jpa-1.0.5.zip shale-sql-browser-1.0.5.zip shale-test-core-1.0.5.zip shale-test-dialog-basic-1.0.5.zip shale-test-dialog-scxml-1.0.5.zip shale-test-tiger-1.0.5.zip shale-test-view-1.0.5.zip shale-usecases-1.0.5.zip (4) The release notes are here, for ready reference: http://people.apache.org/~greddin/release-notes-1.0.5.html (5) Vote Please review these artifacts, signatures and checksums, and vote whether we should release them as Apache Shale version 1.0.5. --8 [ ] +1 (Binding) for PMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released A quality vote (per module, where necessary) will be held later on if this passes. Thank you!! Greg
Re: [VOTE] Release Shale 1.0.5
On Wed, Jun 4, 2008 at 10:00 AM, Paul Spencer [EMAIL PROTECTED] wrote: -1 The copyright date in the notice file is 2007 instead of 2008 Aside from the copyright date, noted above, I only verified that notice.txt, manifest.mf and license.txt existed I'll have a look at that. The artifact where built using JDK 1.5.0_13. Should they be built using 1.4? Hmm, I didn't think about that. You're probably right, at least everything except the Tiger stuff. Rahul, did you use 1.4 to build the non-Tiger artifacts for 1.0.4? Thanks for checking. I figured there's little chance this first hack would be the final one :-) Greg
[VOTE] [Modified] Release Shale 1.0.5
This is a resubmit of the Shale 1.0.5 release vote. (Sorry for the delayed posting). I've modified the set of artifacts to the list below. (1) The repository has been tagged here (I did not modify the tag): http://svn.apache.org/repos/asf/shale/framework/tags/SHALE_1_0_5/ (2) The Maven artifacts are staged here: http://people.apache.org/builds/shale/shale-1.0.5/m2-staging-repository/ org.apache.shale.extras:mailreader-jpa:1.0.5 org.apache.shale:shale-application:1.0.5 org.apache.shale:shale-apps-parent:1.0.5 org.apache.shale:shale-blank:1.0.5 org.apache.shale:shale-clay-usecases:1.0.5 org.apache.shale:shale-clay:1.0.5 org.apache.shale:shale-core:1.0.5 org.apache.shale:shale-dialog-basic:1.0.5 org.apache.shale:shale-dialog-scxml:1.0.5 org.apache.shale:shale-dialog:1.0.5 org.apache.shale:shale-mailreader-jpa:1.0.5 org.apache.shale:shale-mailreader:1.0.5 org.apache.shale:shale-parent:1.0.5 org.apache.shale:shale-remoting:1.0.5 org.apache.shale:shale-spring:1.0.5 org.apache.shale:shale-sql-browser:1.0.5 org.apache.shale:shale-blank:1.0.5 org.apache.shale:shale-tiger:1.0.5 org.apache.shale:shale-usecases:1.0.5 org.apache.shale:shale-validator:1.0.5 org.apache.shale:shale-view:1.0.5 (3) The release artifacts are available here: http://people.apache.org/builds/shale/shale-1.0.5/dist/ mailreader-jpa-1.0.5.zip shale-blank-1.0.5.zip shale-clay-usecases-1.0.5.zip shale-framework-1.0.5.zip shale-mailreader-1.0.5.zip shale-mailreader-jpa-1.0.5.zip shale-sql-browser-1.0.5.zip shale-usecases-1.0.5.zip (4) The release notes are here, for ready reference: http://people.apache.org/~greddin/release-notes-1.0.5.html (5) Vote Please review these artifacts, signatures and checksums, and vote whether we should release them as Apache Shale version 1.0.5. --8 [ ] +1 Release these artifacts as Shale 1.0.5 [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released A quality vote (per module, where necessary) will be held later on if this passes. Thank you!! Greg
Re: [VOTE] [Modified] Release Shale 1.0.5
On Sat, Jun 7, 2008 at 10:44 PM, Greg Reddin [EMAIL PROTECTED] wrote: --8 [X] +1 Release these artifacts as Shale 1.0.5 [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released Here's my vote. Greg PS. I will be out of town Wednesday thru Monday. If the vote passes I will likely have to wait till I get back to finish the release. I'm not exactly sure what all I need to do to push the release artifacts to the mirrors. (I think I understand the Maven artifacts). Can someone direct me to some doc and/or instructions?
Re: [VOTE] [Modified] Release Shale 1.0.5
On Mon, Jun 16, 2008 at 10:12 AM, Gary VanMatre [EMAIL PROTECTED] wrote: +1 Release these artifacts as Shale 1.0.5 Assuming Rahul's +1 from the previous vote thread still holds the vote passes and Shale 1.0.5 is ready to be released. As soon as I can find the time I will complete the release process. Thanks, Greg
Re: [VOTE] [Modified] Release Shale 1.0.5
On Wed, Jun 25, 2008 at 11:39 AM, Paul Spencer [EMAIL PROTECTED] wrote: Great! I have not been able to test the current 1.0.5 release. Assuming the issues I brought up in the prior 1.0.5 have been resolved, I would +1 this release. IIRC your objections were related to a 2007 copyright date. The team decided that it wasn't a big enough issue to hold up the release. Do you disagree? Greg
Re: [VOTE] [Modified] Release Shale 1.0.5
On Wed, Jun 25, 2008 at 2:37 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: Absolutely. All aboard, let 'er sail :-) Sorry for disappearing for a few weeks. I have just copied the dist artifacts to the dist directory and the Maven artifacts to the Maven dist directory. I'll update the site tomorrow. Then we can announce I guess? Thanks, Greg
Re: Shale 1.05
On Fri, Aug 29, 2008 at 11:11 PM, Kito D. Mann [EMAIL PROTECTED] wrote: So, I see that the download link on the Shale home page actually points to 1.05, so that part is at least complete :-). I think the site and maven artifacts still need to be pushed out, though... That's right. THe site is really the only thing remaining and the reason why no announcement has been made. The artifacts are in production other than that. I will try to get back on the wagon this week. Thanks, Greg
Re: Shale Test
On Mon, Sep 29, 2008 at 6:22 PM, Kito Mann [EMAIL PROTECTED] wrote: That's fine, but I don't really see _anyone_ driving releases :-). What's the problem with letting Shale Test move somewhere else? The problem, though, is that Shale Test is part of a project that has stagnated. So, even if Shale Test moves forward, it's difficult to get traction if the whole project is perceived as stale. Do you see what I'm saying? If there are so many people out there who want to help move Shale Test forward, then we would love for them to step up and start contributing. Look at it this way: I use Shale in at least one project at work, so I have a vested interest in it continuing to work. Now a whole bunch of people from Project Foo think Shale needs to move forward and that it can move forward better over at Project Foo. But I've never seen code from the folks at Project Foo. I don't know their attitudes or development styles. I don't know how they work with others. I don't know if they will release it under a license I am comfortable with. How can I agree in good faith to just hand over the management of Shale to Project Foo when I don't know these things? We are commissioned by the ASF to manage the Shale project. You could make a decent argument that we have not done a very good job of managing the project. But we cannot recommend to the ASF in good faith that the best direction for the project is to send it to somebody else who we don't know. So that brings us back to this: If people think Shale Test needs to move forward then I would cordially and sincerely invite them to come join the dev list and start submitting patches. Point me to the patches that have not been responded to. Point me to the questions and requests that are not being answered. When I see that I can begin to give credibility to your argument that Shale would be better managed elsewhere. Just so I am clear: the motive of this post is not to be dramatic or troll or anything like that. I want to see Shale move forward too. If the best thing is for it to move elsewhere, then I will be the first to vote for that. But I can't trust who I don't know. Send those folks over here and let's engage in some discussion and get some stuff done. Thanks, Greg
Re: [ANNOUNCEMENT] New Shale Committer: Paul Spencer
Welcome, Paul! Glad to have you here. Greg On Thu, Oct 2, 2008 at 10:31 PM, Gary VanMatre [EMAIL PROTECTED] wrote: Please join me in welcoming Paul Spencer as the newest Shale committer. Paul has been very supportive of the Shale community over the past year. Paul is also a member of the MyFaces project. Welcome, Paul!
Re: Shale test status
On Mon, Oct 20, 2008 at 10:49 AM, Gary VanMatre [EMAIL PROTECTED] wrote: I'd rather see the Shale community grow this library and the Shale project. However, if the communities feel that the only way we can find volunteers to contribute to its ongoing growth (seems a bit snobbish) is to move to MyFaces, then so be it. +1. I'm not saying I'm dead set against a MyFaces merger. If that's the best thing for the Shale project, then let's go do it. But I would much rather see efforts to grow the Shale community, rather than take one node that has a lot of interest and move it somewhere else. I don't think we've really explored the options that involve keeping all of Shale here. As to Simon's argument that Shale Test is linked exclusively to JSF, I think that applies to the whole framework. We can't work towards a JSF 2 version of the other components without having a JSF 2 codebase to link to. So if Test is being held back by that dependency then so is the rest of the project. Greg
Re: Shale test status
On Wed, Oct 22, 2008 at 10:45 AM, Simon Lessard [EMAIL PROTECTED] wrote: If the base test classes don't get moved to MyFaces, then we're more or less condemning MyFaces API to wait for RI to be released so that Shale-test can depend on it to be updated to 2.0 API, or forcing MyFaces API to redevelop the base test classes, or release versions without running unit tests on the API. I'm trying to make sure I understand the issue so please bear with me. If shale-test depends on 2.0 RI and 2.0 RI is not yet released, then shale-test cannot be upgraded, no matter where it lives, correct? If so, then a JSF 2.0 development branch could be created (either in Shale or MyFaces) so work can be done on a 2.0 version of shale-test. That development branch could depend on a snapshot of JSF 2.0 (whether the snapshot is MyFaces or something else) while it is in development. Once there is a release of the 2.0 API anywhere, then shale-test can be released, then MyFaces, once passing all tests, can be released. Have I identified the situation correctly? If so, then I can see how it would be more convenient for the MyFaces community for shale-test to live there. But it could further isolate the Shale community by moving a vibrant part of Shale out. I would rather see more cooperation occur. If we get enough folks to commit to Shale (even just test) then Shale releases don't have to be such a backlog. I don't think MyFaces are the only people relying on or benefitting from shale-test so it might not be a good idea to tie shale-test releases into MyFaces. Greg
[Announce] Call For Papers opens for ApacheCon US 2009
If you have only 30 seconds to read this; Join us in celebrating the ASF's 10th Anniversary at ApacheCon! The Call for Papers is now open for ApacheCon US 2009, taking place 2-6 November in Oakland, California. Proposals are being accepted at http://us.apachecon.com/c/acus2009/cfp/ and can be revised at anytime until the submissions closing deadline of 28 February 2009. In addition, sponsorship opportunities for both ApacheCon EU 2009/Amsterdam and ApacheCon US 2009/Oakland are available. Please contact Delia Frees at [EMAIL PROTECTED] for further information. Please, read on... *** ApacheCon Celebrates the ASF's 10th Anniversary in Oakland, California, 2-6 November 2009 Call for Papers Opens for ApacheCon US 2009 The Apache Software Foundation (ASF) invites submissions to its official user and developer conference, taking place 2-6 November 2009 at the Oakland Convention Center and Marriott Hotel. ApacheCon serves as a forum for showcasing the ASF's latest projects, members, and community initiatives. Offering unparalleled educational opportunities, ApacheCon's presentations, hands-on trainings, and sessions address key technology, development, business/community, and licensing issues in Open Source. The wide range of activities offered at ApacheCon promotes the exchange of ideas amongst ASF Members, committers, innovators, developers, vendors, and users interested in the future of Open Source technology. The conference program includes peer-reviewed sessions, trainings/workshops, and select invited keynote presentations and speakers. Conference Themes and Topics Building on ten years of success, ApacheCon returns to the Bay Area for the 10th anniversary of the Apache Software Foundation. Comprising some of the most active and recognized developers in the Open Source community, ApacheCon provides an influential platform for dialogue between Open Source developers and users, traversing a wide range of ideas, expertise, and personalities. ApacheCon welcomes submissions across many fields, geographic locations, and areas of development. The breadth of the Apache community lends itself to conference content that is somewhat loosely-structured, with common themes of interest addressing groundbreaking technologies and emerging trends, best practices (from development to deployment), case studies and lessons learned (tips, tools, and tricks). In addition, ApacheCon will continue to offer its highly popular, two-day intensive trainings; certifications of completion will be distributed to those who fulfill all the training requirements. Topics appropriate for submission are manifold, and may include but are not restricted to: Apache HTTP server (installation, configuration, migration, and more); ASF-wide projects (including Lucene, Hadoop, Jackrabbit, and Maven); Scripting languages and dynamic content (such as Java, Perl, Python, Ruby, XSL, and PHP); Security and e-commerce (performance tuning, load balancing and high availability); New technologies (including broader initiatives such as Web Services and Web 2.0); ASF-Incubated projects (such as Sling, UIMA, and Shindig); and Business/Community issues (Open Source driven business models, open development, enterprise adoption, and more). Submission Guidelines Submissions must include; – Session title - Speaker name - Speaker biography - Session description - Format and duration - Audience expertise level Full details are available online on the CFP page at [WWW] http://us.apachecon.com/c/acus2009/cfp/ Types of Presentations; - Trainings/Workshops - General Sessions - Case Studies/Industry Profiles - Corporate Showcases Demonstrations - Fast Feather (short) sessions - Birds of a Feather discussions - Invited Keynotes/Panels/Speakers Pre-Conference Trainings/Workshops Held on the first two days of the conference (2-3 November 2009), ApacheCon trainings are available at a registration fee beyond the regular conference fee. Proposals may be submitted for half-day (3 hours), full-day (6 hours), or two-day (12 hours) training sessions. These proposed tutorials should be aimed at providing in-depth, hands-on development experience or related continuing education. Training submissions are welcome at beginner, intermediate, and expert levels. General Sessions include presentations on practical development applications, insight into high-interest projects, best practices and key advances, overcoming implementation challenges, and industry innovations. Especially welcome are submissions that extend participants' understanding the role of ASF projects and their influence on the Open Source community at large. General Sessions are scheduled for 50 minutes and are accessible to all conference delegates. Case Study/Industry Profile Practitioners are invited to submit presentations that focus on how implementing particular ASF technologies led to improved products/solutions, service offerings, changes in work practices, among other successes. Proposals
Re: [1.1.0] Testing of Shale-Core fails due to missing ViewExpiredException
On Tue, Dec 9, 2008 at 6:20 AM, Paul Spencer [EMAIL PROTECTED] wrote: I am building Shale 1.1.0-SNAPSHOT with JDK 1.5.0_16-b06-284. The test on Shale-Core are failing with the following error: testPristine(org.apache.shale.util.TokenProcessorTestCase) Time elapsed: 0.038 sec ERROR! java.lang.NoClassDefFoundError: javax/faces/application/ViewExpiredException at org.apache.shale.test.mock.lifecycle.MockLifecycle.init(MockLifecycle.java:52) at org.apache.shale.test.mock.lifecycle.MockLifecycleFactory.init(MockLifecycleFactory.java:45) The test for Shale-Core uses JSF 1.1. I suspect that Shale-Test is expecting a JSF 1.2 implementation and failing since 1.1 is used. Ideas? I don't have an answer for you but I will verify that I experience the same problem. Greg
[Travel Assistance] Applications for ApacheCon EU 2009 - Now Open
The Travel Assistance Committee is now accepting applications for those wanting to attend ApacheCon EU 2009 between the 23rd and 27th March 2009 in Amsterdam. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon EU 2009 who need some financial support in order to get there. There are very few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF or open source in general. Financial assistance is available for travel, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in the United States or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon EU of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the online application form. Time is very tight for this event, so applications are open now and will end on the 4th February 2009 - to give enough time for travel arrangements to be made. Good luck to all those that apply. Regards, The Travel Assistance Committee --
Registration for ApacheCon Europe 2009 is now open!
ApacheCon EU 2009 registration is now open! 23-27 March -- Mövenpick Hotel, Amsterdam, Netherlands http://www.eu.apachecon.com/ Registration for ApacheCon Europe 2009 is now open - act before early bird prices expire 6 February. Remember to book a room at the Mövenpick and use the Registration Code: Special package attendees for the conference registration, and get 150 Euros off your full conference registration. Lower Costs - Thanks to new VAT tax laws, our prices this year are 19% lower than last year in Europe! We've also negotiated a Mövenpick rate of a maximum of 155 Euros per night for attendees in our room block. Quick Links: http://xrl.us/aceu09sp See the schedule http://xrl.us/aceu09hp Get your hotel room http://xrl.us/aceu09rp Register for the conference Other important notes: - Geeks for Geeks is a new mini-track where we can feature advanced technical content from project committers. And our Hackathon on Monday and Tuesday is open to all attendees - be sure to check it off in your registration. - The Call for Papers for ApacheCon US 2009, held 2-6 November 2009 in Oakland, CA, is open through 28 February, so get your submissions in now. This ApacheCon will feature special events with some of the ASF's original founders in celebration of the 10th anniversary of The Apache Software Foundation. http://www.us.apachecon.com/c/acus2009/ - Interested in sponsoring the ApacheCon conferences? There are plenty of sponsor packages available - please contact Delia Frees at de...@apachecon.com for further information. == ApacheCon EU 2008: A week of Open Source at it's best! Hackathon - open to all! | Geeks for Geeks | Lunchtime Sessions In-Depth Trainings | Multi-Track Sessions | BOFs | Business Panel Lightning Talks | Receptions | Fast Feather Track | Expo... and more! - Shane Curcuru, on behalf of Noirin Shirley, Conference Lead, and the whole ApacheCon Europe 2009 Team http://www.eu.apachecon.com/ 23-27 March -- Amsterdam, Netherlands
[ANNOUNCE] Apache Shale To Move To the Attic
This is a heads up for the Shale user community that the Shale PMC has voted to move the project to the Attic. This means that the Shale developers (more formally its Project Management Committee) have voted to retire Shale and move the responsibility for its oversight over to the Attic project. The MyFaces community has expressed interest in continuing development of the Shale-Test module and the Shale PMC will work with MyFaces to migrate this piece of the codebase.. Look for further announcements to that regard in the near future. You can read more about the Apache Attic at http://attic.apache.org. You can follow the progress of the move at https://issues.apache.org/jira/browse/ATTIC-2 if you so wish. On behalf of the Apache Shale PMC, Thanks! Greg Reddin
