Re: [Proposal] NoNameYet : Link Error - please use this link
On Feb 3, 2008, at 2:05 PM, Meeraj Kunnumpurath wrote: Paul, The fork on Tuscany was not instigated by BEA. Of the three committers who decided to leave Tuscany, due to technical differences and otherwise, only Jim Marino was employed by BEA. Myself and Jeremy Boynes were independent committers, though, Jeremy was employed by IBM and leading the development effort when they started on Tuscany. Leading is a bit strong as I always viewed it as a community project. Apart from that I'll second Meeraj here in saying that the fork was not instigated by BEA but sprang from our individual frustrations. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yoko project wind down
On Jan 9, 2008, at 8:24 PM, Alan D. Cabrera wrote: As you all know Yoko is being assimilated into CXF and Geronimo. Both PMCs understand that they are responsible for the provenance of the contributions that are being brought in. My question is about what remains to be done on the *incubator* side. Here's what's on my to-do list: - Update the status page notifying the reader that the project has been wound down and where to find it. This will include the vote. - Shutdown the mailing list but keep the archives - Make SVN r/o - Remove the wiki pages after they have been moved. It's my understanding that it is ASF tradition to keep the userids around. Is there anything else? Migrate any remaining JIRAs? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Field of use constraint on OSOA license?
There is an updated license here: http://www.osoa.org/xmlns/sca/1.0/license.txt and I've attached a copy of the text below. To my layman's understanding that seems OK but it would be good to have official blessing. Thanks Janet for getting this through. -- Jeremy On Jan 7, 2008, at 3:56 PM, Janet Campbell wrote: Yes, my understanding is that the new version of the license has now been posted. Janet Campbell Phone: +1.613.224.9461, x.229 (GMT -5) Fax: +1.613.224.5172 [EMAIL PROTECTED] -Original Message- From: Oisin Hurley [mailto:[EMAIL PROTECTED] Sent: Friday, December 21, 2007 5:36 AM To: Janet Campbell Cc: general@incubator.apache.org; 'Legal Discuss' Subject: Re: Field of use constraint on OSOA license? On 20 Dec 2007, at 20:50, Janet Campbell wrote: We have been in touch with the OSOA folks and the license restriction referred to below has now been removed. Thanks for pushing that through, Janet. Have you secured the new license text, and has it been posted on the OSOA site do you know? best regards Oisin License for the Service Component Architecture JavaDoc, Interface Definition files and XSD files. The Service Component Architecture JavaDoc, Interface Definition files, and XSD files are being provided by the copyright holders under the following license. By using and/or copying this work, you agree that you have read, understood and will comply with the following terms and conditions: Permission to copy, display, make derivative works of, and distribute the Service Component Architecture JavaDoc, Interface Definition Files and XSD files (the Artifacts) in any medium without fee or royalty is hereby granted, provided that you include the following on ALL copies of the Artifacts, or portions thereof, that you make: 1. A link or URL to the Artifacts at this location: http://www.osoa.org/display/Main/Service+Component+Architecture +Specifications 2. The full text of this copyright notice as shown in the Artifacts. THE ARTIFACTS ARE PROVIDED AS IS, AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE ARTIFACTS AND THE IMPLEMENTATION OF THEIR CONTENTS, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT OR TITLE. THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE ARTIFACTS. The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Service Component Architecture Specification or its contents without specific, written prior permission. Title to copyright in the Service Component Architecture Specification and the JavaDoc, Interface Definition Files and XSD Files will at all times remain with the Authors. No other rights are granted by implication, estoppel or otherwise. Revision level 1.1, last updated on 2007/11/19 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Podling status files, was: Graduate FtpServer
On Dec 13, 2007, at 5:46 AM, Niclas Hedhman wrote:
On Wednesday 12 December 2007 19:45, Niall Pemberton wrote:
I couldn't see a STATUS file in svn
You have mention this for the Yoko project as well, and I start to
wonder who
of us two has misunderstood what the so called status file is.
http://incubator.apache.org/guides/sites.html says that the status
file is
the http://incubator.apache.org/projects/{podlingname}.html and is
what I
have always thought of it being.
You make a claim that a second one is required in
http://svn.apache.org/repos/asf/incubator/{podlingname}/STATUS or
equivalent,
like has been done for Tuscany.
http://svn.apache.org/repos/asf/incubator/tuscany/STATUS
Can someone authorative clarify the situation for me?
Not authoritative, but when I set this up for Tuscany the thought was:
* the one on the incubator site reflected incubation status and would
stay with the incubator
* the one in svn reflected project status and would move with the
project on graduation
During incubation there would be a lot of overlap, but there would
also be other information for the respective audiences (for example,
some projects include the one from svn in distros).
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] RAT to enter incubator
On Oct 30, 2007, at 10:03 PM, Robert Burrell Donkin wrote: --8-- --- [ ] +1 Allow RAT to enter incubator, sponsored by IPMC [ ] +0 [ ] -0 [ ] -1 Do no allow RAT to enter incubator -- - +1 (non-binding) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Tuscany as a top level project
On Oct 13, 2007, at 10:07 PM, Noel J. Bergman wrote: Ant, Are there any issues that should be pointed out, such as the (hopefully) mechanical licensing header issue in stdcxx, or community diversity, which at least in part is measuring independence from corporate backing (a popular thread this past month)? It seems that the latter should be well in hand, but I'll not assume. :-) Noel I've expressed some concern before about diversity and independence [1]. At the time, 11 out of 12 members proposed for the TLP's PMC worked for a single organization. Since then, a couple more people have been added but the ratio is still 13 out of 16. Yes, there are 3 organizations represented but control still lies with one bloc. The project has voted in 19 new committers, but 12 of those work for the same organization as above. Many have dropped out - at this time there are only 2 committers active[2] who don't work for that organization, compared to 11 who do. Neither of the two independents are active in the core project areas of Java SCA or SDO (they are committing to the C++ implementation or to DAS). Taking a quick sample of the mailing list, the only contributors to the discussion thread on Graduation, which I would assume would have been a hot topic, were from the vendor. I think more work is needed to reduce the dependency on and influence by a single corporate. -- Jeremy [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/ 200710.mbox/[EMAIL PROTECTED] [2] commit in the last 3 months - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Tuscany as a top level project
On Oct 15, 2007, at 8:02 PM, Paul Fremantle wrote: Jeremy Neither of the two independents are active in the core project areas of Java SCA or SDO (they are committing to the C++ implementation or to DAS). Is it stated somewhere that the Java SCA/SDO components are core compared to C++ and DAS? s/core/most active/ I still find it odd that Tuscany is aiming for graduation when in the two most active sections of the project there are no active independents. Taking a quick sample of the mailing list, the only contributors to the discussion thread on Graduation, which I would assume would have been a hot topic, were from the vendor. I remember contributing to discussion on Graduation. Maybe you don't count me? I know I'm an ex-corporate but then so are you! I was thinking primarily of people who were on the TLP PMC proposal. But yes, you and Matthew did help draft that proposal. As the diversity sub-thread was taken to the private list (which is kind of ironic in itself) there may also have been some discussion there I missed as well. As a mentor you are much closer to the project than I am - why do you think Tuscany is ready to graduate with such a skewed PMC and committer base? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Field of use constraint on OSOA license?
On Sep 30, 2007, at 11:30 AM, Niclas Hedhman wrote: On Sunday 30 September 2007 01:53, Jeremy Boynes wrote: The recent Tuscany distribution contains XSDs licensed under the OSOA license[1] which contains the following: Permission to copy, make derivative works of, and distribute the Service Component Architecture JavaDoc, Interface Definition Files and XSD files in any medium without fee or royalty as part of a compliant implementation of the Service Component Architecture Specification is hereby granted. Is the restriction to a compliant implementation a field of use constraint that Tuscany project should be concerned about? Perhaps it is more of a matter for the legal-discuss@ list than here... This has come up there before but I have not seen a resolution. I cc'ed them on this reply. But, I agree with Roland that this is not FoU restrictions. I find the formulation a bit odd, but think the intent is to ensure that the spec doesn't evolve beyond the control of OSOA. Especially since it mentions Permission to ... make derivative works of ... Interface Definition Files. This is the point that concerns me. As I read it, users are only permitted to copy, make derivative works of, and distribute these items as part of a compliant implementation. FoU may be the wrong term, but that clause is imposing restrictions on users that go beyond the Apache License as they are constrained to a compliant implementation. This seems the same issue we had with libraries from JSRs and which led to the creation of our own XSDs and API files in Geronimo so that we could provide them under the AL (back in the days before Sun's were available under CDDL). Tuscany already has an AL version of the APIs so this would only affect the XSDs. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Field of use constraint on OSOA license?
The recent Tuscany distribution contains XSDs licensed under the OSOA license[1] which contains the following: Permission to copy, make derivative works of, and distribute the Service Component Architecture JavaDoc, Interface Definition Files and XSD files in any medium without fee or royalty as part of a compliant implementation of the Service Component Architecture Specification is hereby granted. Is the restriction to a compliant implementation a field of use constraint that Tuscany project should be concerned about? -- Jeremy [1] http://www.osoa.org/xmlns/sca/1.0/license.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [WITHDRAWN] Approve release of SCA specification APIs by Tuscany project
On Mar 23, 2007, at 7:34 AM, Noel J. Bergman wrote: Jeremy Boynes wrote: Dims has asked to see some progress on the Tuscany community front. I have taken these artifacts down for now. Jeremy, on this and the Tuscany SCA Java kernel, what is your take on the effect of the release vis-a-vis community, and on the Tuscany community in general? Dims has a thread on community reconciliation so I'll limit this to the effect of these releases. In r1.0 of the SCA spec there were some significant, incompatible changes in the Java APIs compared to the r0.95 version of the spec. We have an independent version of the classes for those APIs in the project (to my knowledge there is no compiled version available yet from the spec group). The community did an extensive review of our version against the draft spec and voted to release our version. There was some concern over what version number we would assign. Personally, I think having a version of the APIs from the spec as Java code under AL rather than text in a PDF is a very valuable resource for the general community. Short of finding a discrepancy with the published spec, this is a stable artifact. For the kernel, we had discussed doing a release of the kernel in early Jan and there was general agreement on that[1]. However, there were some subsequent changes in the programming models in the spec and the implementation needed to be changed to match. That was quite disruptive and delayed the release until early March. Personally, I think having a release available that allows people to write components against the revised programming models and then run them in Tuscany will encourage them to try it out, give us feedback, and offer them an easy way to contribute to the community. I hope this leads to more independent developers. We knew the kernel changes would be disruptive and discussed creating a branch to provide a stable base for developing extensions and plugins[2]. This didn't work very well, leading to frustration in the community. Shortly after a wiki page appeared to capture requirements[3] which initially looked like a product feature/priority matrix (page revision 5 for example), followed by a proposal for an alternative release in March with different functionality from the release already in progress[4]. Shortly after another branch was created to support stabilization for that alternative but since then there has been no discussion about actually performing a release from it. Personally, I think the presence of that branch and the substantial new development that has gone on there has not acted as a release valve but has been very divisive in the community. -- Jeremy [1] http://thread.gmane.org/ gmane.comp.apache.webservices.tuscany.devel/12250 [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13075.html [3] http://cwiki.apache.org/confluence/display/TUSCANY/Feature+areas +and+what+folks+are+working+on [4] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13643.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[WITHDRAWN] Approve release of SCA specification APIs by Tuscany project
Dims has asked to see some progress on the Tuscany community front. I have taken these artifacts down for now. -- Jeremy On Mar 12, 2007, at 11:59 PM, Jeremy Boynes wrote: The Tuscany community recently voted to release version 1.0- incubating of our implementation of the API classes for the OSOA specification V1.0: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/ [EMAIL PROTECTED] The source archives and RAT reports can be found at: http://people.apache.org/~jboynes/sca-api-r1.0-1.0-incubating and the binary in the Maven repo at: http://people.apache.org/repo/m2-incubating-repository/org/osoa/ sca-api-r1.0/1.0-incubating Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[WITHDRAWN] Approve release of Apache Tuscany SCA Java Kernel 2.0-alpha-incubating
Dims has asked to see some progress on the Tuscany community front. I have taken these artifacts down for now. -- Jeremy On Mar 13, 2007, at 12:11 AM, Jeremy Boynes wrote: The Tuscany community recently voted to release version 2.0-alpha- incubating of the Kernel for SCA Java. [VOTE] to release the kernel modules http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/ [EMAIL PROTECTED] [VOTE] to release an amended version of the sample code http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/ [EMAIL PROTECTED] For this release we have transitioned away from a single distribution to a number of separate modules that can be released separately. The first of these are the kernel and runtime modules voted on here which provide a baseline (alpha) version for development of other modules. The source distributions for these can be found here: http://people.apache.org/~jboynes/kernel-2.0-alpha-incubating/ http://people.apache.org/~jboynes/runtime-2.0-alpha-incubating/ along with a binary assembly for a standalone runtime installation. The project artifacts are also available through the Maven repo. For full details, please see the links in the original [VOTE] thread. We would like to ask the IPMC to approve this release. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release of Apache Tuscany SCA Java Kernel 2.0-alpha-incubating
Another vote that may have been lost in the flood. So far a +1 from robert. Thanks -- Jeremy On Mar 14, 2007, at 3:33 PM, robert burrell donkin wrote: On 3/14/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 13, 2007, at 6:53 PM, Jeremy Boynes wrote: On Mar 13, 2007, at 3:46 PM, robert burrell donkin wrote: the source and binary kernel releases look identical zip errors in jars unpackaged from kernel-2.0-alpha- incubating.zip: * core/src/test/resources/deployables/sample-calculator.jar * core/src/test/resources/repository/sample-calculator.jar has there been some sort of mix up? There was. When I uploaded the src archives to the staging area I left -src out of the name and then started the vote thread with links in it. Luciano pointed this out but rather than rename the files and break the links I just hard linked them on the website. There is no binary distro for the kernel there as it is basically just a set of libraries - the binary versions are meant to be distributed through the Maven repo. I will remove the misnamed files. The two jars you mentioned are just used during testing and I don't believe the test actually unpacks them at all. I used zip -rlq to create the zip on OSX so the LF-CRLF conversion may have corrupted them (but if we don't unpack them during the build that would not have been caught). I will redo the zip file using export --native- eol and zip without the -l. Sorry for the confusion. I have done this and there is a new version of the kernel source zip here: http://people.apache.org/~jboynes/kernel-2.0-alpha-incubating/ kernel-2.0-alpha-incubating-src.zip +1 notes and comments - (non-binding suggestions and recommendations) consider including the name of the project (apache-tuscany) within the release name. not only is this good geurilla advertising but it also gives a measure of legal redress against bogus artifacts with the same name. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release of SCA specification APIs by Tuscany project
This may have been lost in the flood of other release mails - so far was have +1's from Robert and Dims but still need a third. Thanks Jeremy On Mar 18, 2007, at 11:12 AM, Davanum Srinivas wrote: +1 On 3/18/07, robert burrell donkin [EMAIL PROTECTED] wrote: On 3/16/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 15, 2007, at 5:07 PM, Jeremy Boynes wrote: On Mar 15, 2007, at 3:49 PM, robert burrell donkin wrote: On 3/13/07, Jeremy Boynes [EMAIL PROTECTED] wrote: The Tuscany community recently voted to release version 1.0- incubating of our implementation of the API classes for the OSOA specification V1.0: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/ 200703.mbox/% [EMAIL PROTECTED] The source archives and RAT reports can be found at: http://people.apache.org/~jboynes/sca-api-r1.0-1.0- incubating and the binary in the Maven repo at: http://people.apache.org/repo/m2-incubating-repository/ org/osoa/ sca-api-r1.0/1.0-incubating ok except for the signature issue major issues == gpg --verify sca-api-r1.0-1.0-incubating.jar.asc sca-api- r1.0-1.0- incubating.jar gpg: Signature made Sun Mar 4 01:53:25 2007 GMT using DSA key ID 11007026 gpg: BAD signature from Jeremy Boynes [EMAIL PROTECTED] MD5 sums look right I added the profile (r518844), redeployed all the artifacts and replaced the source distributions to include the change. Due to a issue with the gpg plugin I signed the POM in the repo manually. Hopefully, that takes care of this one :-) +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incentive for Graduation
On Mar 18, 2007, at 4:08 AM, Niclas Hedhman wrote: Irregardless of that, the IPMC could stipulate that releases are final stepping stones towards graduation, and require an active and diverse community to allow for releases. After all, it is the Incubator that does the release (legally) and not the podling. Personally, I think it makes sense. I could also see good argument to allow for one or two 'early releases' which don't require this. SO the setup is a huge deterrent to get cozy in the Incubator, not too different from the human incubator, where the baby will try to stay on, and the mother's body will starve it of the resources to force a birth ;o) Those 'early' releases could perhaps be source-only with some latitude for existing open source projects. That's a deterrent for commercial entities but supports the goal of building the podling's developer community. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany, was: Incentive for Graduation
Tuscany has issues though. When you look at active committers (at least one commit in the last 3 months) it is a different picture: 14 from IBM and 3 from elsewhere (83%). Worse, there are modules where no non-IBM committer has ever been active (e.g. Java/SDO, Java/DAS, C+ +/*). -- Jeremy On Mar 17, 2007, at 6:27 PM, Davanum Srinivas wrote: Ant, No, question is not about tuscancy. It's a general question as the situation can arise in the future where someone is trying to game the system. thanks, dims On 3/17/07, ant elder [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] On 3/17/07, Davanum Srinivas [EMAIL PROTECTED] wrote: Niclas, Here the scenario is a project with all committers from one employer and regular releases. Are you talking about Tuscany still? Not all the Tuscany committers are from the one employer. There's 25 committers now, only 16 of those from the main employer which makes it 64%. ...ant -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Difference between Maven repository and dist directory
On Mar 16, 2007, at 8:42 AM, Craig McClanahan wrote: Is everyone in ASF willing to be comfortable with the ASF stamp of approval on a project that might still be in the process of vetting code provenance, or still checking licenses, but chooses to do an incubating release anyway? As Dims, said Hell No! As a user, I want to be able to trust the IP provence of anything from Apache and I trust that the IPMC would *never* approve anything that they were not sure was clean, no matter what a podling voted. As a committer/release manager, I want the assurance that I have legal protection for anything I upload through the approved process. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Disclaimer location
On Mar 15, 2007, at 4:03 PM, Cliff Schmidt wrote: On 3/15/07, robert burrell donkin [EMAIL PROTECTED] wrote: the latest advice on best practice from cliff is that a separate DISCLAIMER.txt is preferred to including the incubator disclaimer in the NOTICE.txt. the reason is that the NOTICE.txt has legal implications so it's best to restrict the contents. incubator policy asks that the DISCLAIMER is distributed but this isn't something we require by downstream. IMHO this isn't important enough to consider re-rolling. Just to clarify, I haven't advocated for a file necessarily named DISCLAIMER.txt just for the incubator disclaimer. I don't recall if/what the Incubator PMC policy is on that. I do remember when we started the disclaimer thing (almost four years ago), we were just adding it to the top of the README. Either case seems reasonable to me (with my Incubator PMC hat on) unless we have a stated policy specifying exactly one thing. Otherwise, Robert's comment about my advice on the NOTICE file is correct. The NOTICE file should only be used for attributions and other notices required to be included by some third-party license or as required by http://apache.org/legal/src-headers.html#notice. Isn't it something that should be propagated downstream? The purpose of the disclaimer is to notify users that the podling isn't a fully- endorsed Apache project and the reasons behind that don't go away just because someone else re-licenses the jar. The legal implication around the NOTICE is that the attributions it contains are retained and by adding the disclaimer in there we ensure that it will be. __ Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release of SCA specification APIs by Tuscany project
On Mar 15, 2007, at 3:49 PM, robert burrell donkin wrote: On 3/13/07, Jeremy Boynes [EMAIL PROTECTED] wrote: The Tuscany community recently voted to release version 1.0- incubating of our implementation of the API classes for the OSOA specification V1.0: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/% [EMAIL PROTECTED] The source archives and RAT reports can be found at: http://people.apache.org/~jboynes/sca-api-r1.0-1.0-incubating and the binary in the Maven repo at: http://people.apache.org/repo/m2-incubating-repository/org/osoa/ sca-api-r1.0/1.0-incubating ok except for the signature issue major issues == gpg --verify sca-api-r1.0-1.0-incubating.jar.asc sca-api-r1.0-1.0- incubating.jar gpg: Signature made Sun Mar 4 01:53:25 2007 GMT using DSA key ID 11007026 gpg: BAD signature from Jeremy Boynes [EMAIL PROTECTED] MD5 sums look right There appears to be a bug in the gpg plugin for mvn. When I did this release I used gpg:sign as a goal on the command line and that consistently generates invalid keys for all except the last artifact (in this case the JavaDoc) even in the local repo. When I did the kernel modules I added a profile to the build which includes gpg:sign and for those all artifacts seem to have valid signatures. Rather than resign the deployed artifacts (just in case there is something squiffy going on), I'll pull them down, add a profile to the pom and then redeploy them. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release of SCA specification APIs by Tuscany project
On Mar 15, 2007, at 5:43 PM, Daniel Kulp wrote: On Thursday 15 March 2007 20:07, Jeremy Boynes wrote: There appears to be a bug in the gpg plugin for mvn. When I did this release I used gpg:sign as a goal on the command line and that consistently generates invalid keys for all except the last artifact (in this case the JavaDoc) even in the local repo. When I did the kernel modules I added a profile to the build which includes gpg:sign and for those all artifacts seem to have valid signatures. Rather than resign the deployed artifacts (just in case there is something squiffy going on), I'll pull them down, add a profile to the pom and then redeploy them. I don't think there's a way to get the gpg:sign stuff to work outside of a profile and have it install/deploy correctly. You MIGHT be able to get it to work on the command line via: mvn verify gpg:sign install:install deploy:deploy Basically, gpg:sign will sign the artifacts that are attached to the lifecycle at the point in the lifecycle that it runs. (default is verify phase)install/deploy then deploys those things. It you tried it with: mvn package gpg:sign deploy that won't work. The package will run a lifecycle up to package, then run gpg:sign signing those artifacts, but the deploy would then start another complete lifecycle which would rebuild the jars causing the signature to be invalid. The pom doesn't change in the second build which is why that sig is OK. I'll try and update the gpg docs tomorrow. This seems counter-intuitive - is there some reason why mvn can't merge goals into one lifecycle (specifically when the plugin is just attaching and not forking another one)? Guess this discussion should be moved to [EMAIL PROTECTED] :-) BTW the sig on the POM is also borked but that might be because the pom is being regenerated. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Should we treat incubator releases differently to normal releases
ONE: Should Incubator tarballs go in the normal place (and thus mirrors). [X] +1 [ ] -1 TWO: Should there be an Incubator maven repository. [ ] +1 [X] -1 On Mar 15, 2007, at 6:49 PM, Craig McClanahan wrote: If we accept this argument, then we naturally need a place where the incubating releases can be retrieved from; hence, the m2-incubating repository. If we do not accept this argument, then AFAICT we are basically making the incubating projects cannot do releases policy inoperative. Podlings cannot do Releases because they are not Projects established by the Board. However, the artifacts produced by them are voted on and approved by the Incubator PMC and hence are official Releases by the Incubator Project and hence by the ASF. This is essential if the artifacts and their authors are to receive any legal protection though being product of or actions by the Foundation. As these are official Releases by the Incubator Project then I think they should go through the normal distribution channels as used by other TLPs. There are already enough indicators for users that these are incubating work (distribution location, file name, prominent disclaimer in content and on website). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release of SCA specification APIs by Tuscany project
On Mar 15, 2007, at 5:07 PM, Jeremy Boynes wrote: On Mar 15, 2007, at 3:49 PM, robert burrell donkin wrote: On 3/13/07, Jeremy Boynes [EMAIL PROTECTED] wrote: The Tuscany community recently voted to release version 1.0- incubating of our implementation of the API classes for the OSOA specification V1.0: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/ 200703.mbox/% [EMAIL PROTECTED] The source archives and RAT reports can be found at: http://people.apache.org/~jboynes/sca-api-r1.0-1.0-incubating and the binary in the Maven repo at: http://people.apache.org/repo/m2-incubating-repository/org/osoa/ sca-api-r1.0/1.0-incubating ok except for the signature issue major issues == gpg --verify sca-api-r1.0-1.0-incubating.jar.asc sca-api-r1.0-1.0- incubating.jar gpg: Signature made Sun Mar 4 01:53:25 2007 GMT using DSA key ID 11007026 gpg: BAD signature from Jeremy Boynes [EMAIL PROTECTED] MD5 sums look right I added the profile (r518844), redeployed all the artifacts and replaced the source distributions to include the change. Due to a issue with the gpg plugin I signed the POM in the repo manually. Hopefully, that takes care of this one :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incentive for Graduation
On Mar 15, 2007, at 7:59 PM, Davanum Srinivas wrote: Frank Question, Would your vote be the same if you thought Tuscany would graduate very soon? Yes, my vote has nothing to do with Tuscany. I'm actually pretty ambivalent about the result and was voting more for consistency across TLPs than any other reason. My opinion is that the dist/ incubator location, the file name, and the disclaimer everywhere give users more than adequate notice that a project is incubating and that more is just a bit of overkill but short of being asked to VOTE on it I'll go with the flow. The primary issue for me in Craig's reply was whether stuff generated by podlings gets any legal protection from the ASF. If it doesn't, then there's no difference between my uploading stuff to dist/ incubator or the incubating repo or to some random server. If the Release is not an action by the Foundation then I personally (and potentially my employer if I had one) would be liable and that's rather unnerving. In other words, what's the incentive for a project (full of committers from one employer) to push for diversity/graduation? I think in that situation (e.g. Tuscany) the employer has its own motivations for graduation and generally wants that to happen as quickly as possible - no additional incentive is required. The challenge is in getting them to understand what is required, especially the necessity of losing control through diversity - i.e. no single company or entity that is vital to the success of the project. The ultimate incentive I think though should be more stick than carrot. If a project doesn't start acting like an Apache one, and exhausts its Mentors' energy to mentor, then it should simply be Terminated. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing posts in archives
On Mar 14, 2007, at 10:57 AM, Martin Sebor wrote: Thanks! There is also the less severe problem with ezmlm stripping attachments from some posts (see INFRA-1194). So far I haven't been able to identify what causes them to be removed. Does anyone have any ideas? Just from observation e.g. submitting a patch as x.diff seems to get stripped but x.txt does not. Don't know if ezmlm is keying on extension or mime-type and haven't looked at what my mailer is doing. I assume it's anti-viral/anti-image-spam (for which I am very grateful). -- Jeremy https://issues.apache.org/jira/browse/INFRA-1194 Martin Justin Erenkrantz wrote: On 3/13/07, Martin Sebor [EMAIL PROTECTED] wrote: I'm wondering if anyone else has noticed the problem noted in INFRA-1185 (https://issues.apache.org/jira/browse/INFRA-1185), namely that not all posts appear in our browsable archives. Weird. I tossed the mod_mbox index for that month and recreated them. Those messages appear now. Thanks for pointing this out! As an aside, if it persists, we may switch away from SDBM to BDB. But, that'll mean a little bit of downtime for the archive as we recreate all of the indexes. Finally, I'm very much against archives that allow people to spam via web pages. Ugh! -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing posts in archives
Thanks - it does. FWIW my mailer sends .diff as application/octet-stream and .txt as text/plain On Mar 14, 2007, at 11:13 AM, Justin Erenkrantz wrote: On 3/14/07, Martin Sebor [EMAIL PROTECTED] wrote: Thanks! There is also the less severe problem with ezmlm stripping attachments from some posts (see INFRA-1194). So far I haven't been able to identify what causes them to be removed. Does anyone have any ideas? https://issues.apache.org/jira/browse/INFRA-1194 I just replied to that issue with the contents of ezmlm's mimeremove file. HTH. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release of Apache Tuscany SCA Java Kernel 2.0-alpha-incubating
On Mar 14, 2007, at 3:33 PM, robert burrell donkin wrote: On 3/14/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 13, 2007, at 6:53 PM, Jeremy Boynes wrote: On Mar 13, 2007, at 3:46 PM, robert burrell donkin wrote: the source and binary kernel releases look identical zip errors in jars unpackaged from kernel-2.0-alpha- incubating.zip: * core/src/test/resources/deployables/sample-calculator.jar * core/src/test/resources/repository/sample-calculator.jar has there been some sort of mix up? There was. When I uploaded the src archives to the staging area I left -src out of the name and then started the vote thread with links in it. Luciano pointed this out but rather than rename the files and break the links I just hard linked them on the website. There is no binary distro for the kernel there as it is basically just a set of libraries - the binary versions are meant to be distributed through the Maven repo. I will remove the misnamed files. The two jars you mentioned are just used during testing and I don't believe the test actually unpacks them at all. I used zip -rlq to create the zip on OSX so the LF-CRLF conversion may have corrupted them (but if we don't unpack them during the build that would not have been caught). I will redo the zip file using export --native- eol and zip without the -l. Sorry for the confusion. I have done this and there is a new version of the kernel source zip here: http://people.apache.org/~jboynes/kernel-2.0-alpha-incubating/ kernel-2.0-alpha-incubating-src.zip +1 notes and comments - (non-binding suggestions and recommendations) consider including the name of the project (apache-tuscany) within the release name. not only is this good geurilla advertising but it also gives a measure of legal redress against bogus artifacts with the same name. Thanks. Would there be any issue with just doing that when I move the distribution artifacts to the final dist location (people.a.o/dist/ incubator at least for now) i.e. mv kernel-2.0-alpha-incubating-src.zip apache-tuscany-kernel- alpha-2.0-incubating-src.zip I can do that this time for those and we can work on the Maven artifactIds for next time. Again, thanks for looking this over. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Approve release of SCA specification APIs by Tuscany project
The Tuscany community recently voted to release version 1.0- incubating of our implementation of the API classes for the OSOA specification V1.0: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/% [EMAIL PROTECTED] The source archives and RAT reports can be found at: http://people.apache.org/~jboynes/sca-api-r1.0-1.0-incubating and the binary in the Maven repo at: http://people.apache.org/repo/m2-incubating-repository/org/osoa/ sca-api-r1.0/1.0-incubating Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Approve release of Apache Tuscany SCA Java Kernel 2.0-alpha-incubating
The Tuscany community recently voted to release version 2.0-alpha- incubating of the Kernel for SCA Java. [VOTE] to release the kernel modules http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/% [EMAIL PROTECTED] [VOTE] to release an amended version of the sample code http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/% [EMAIL PROTECTED] For this release we have transitioned away from a single distribution to a number of separate modules that can be released separately. The first of these are the kernel and runtime modules voted on here which provide a baseline (alpha) version for development of other modules. The source distributions for these can be found here: http://people.apache.org/~jboynes/kernel-2.0-alpha-incubating/ http://people.apache.org/~jboynes/runtime-2.0-alpha-incubating/ along with a binary assembly for a standalone runtime installation. The project artifacts are also available through the Maven repo. For full details, please see the links in the original [VOTE] thread. We would like to ask the IPMC to approve this release. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release of Apache Tuscany SCA Java Kernel 2.0-alpha-incubating
On Mar 13, 2007, at 3:46 PM, robert burrell donkin wrote: the source and binary kernel releases look identical zip errors in jars unpackaged from kernel-2.0-alpha-incubating.zip: * core/src/test/resources/deployables/sample-calculator.jar * core/src/test/resources/repository/sample-calculator.jar has there been some sort of mix up? There was. When I uploaded the src archives to the staging area I left -src out of the name and then started the vote thread with links in it. Luciano pointed this out but rather than rename the files and break the links I just hard linked them on the website. There is no binary distro for the kernel there as it is basically just a set of libraries - the binary versions are meant to be distributed through the Maven repo. I will remove the misnamed files. The two jars you mentioned are just used during testing and I don't believe the test actually unpacks them at all. I used zip -rlq to create the zip on OSX so the LF-CRLF conversion may have corrupted them (but if we don't unpack them during the build that would not have been caught). I will redo the zip file using export --native-eol and zip without the -l. Sorry for the confusion. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release of Apache Tuscany SCA Java Kernel 2.0-alpha-incubating
On Mar 13, 2007, at 6:53 PM, Jeremy Boynes wrote: On Mar 13, 2007, at 3:46 PM, robert burrell donkin wrote: the source and binary kernel releases look identical zip errors in jars unpackaged from kernel-2.0-alpha-incubating.zip: * core/src/test/resources/deployables/sample-calculator.jar * core/src/test/resources/repository/sample-calculator.jar has there been some sort of mix up? There was. When I uploaded the src archives to the staging area I left -src out of the name and then started the vote thread with links in it. Luciano pointed this out but rather than rename the files and break the links I just hard linked them on the website. There is no binary distro for the kernel there as it is basically just a set of libraries - the binary versions are meant to be distributed through the Maven repo. I will remove the misnamed files. The two jars you mentioned are just used during testing and I don't believe the test actually unpacks them at all. I used zip -rlq to create the zip on OSX so the LF-CRLF conversion may have corrupted them (but if we don't unpack them during the build that would not have been caught). I will redo the zip file using export --native- eol and zip without the -l. Sorry for the confusion. I have done this and there is a new version of the kernel source zip here: http://people.apache.org/~jboynes/kernel-2.0-alpha-incubating/ kernel-2.0-alpha-incubating-src.zip Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Ratify Tuscany vote to release build dependencies
Passed with +1s from dims, jim, and pzf and no -1s Thank you. -- Jeremy On Feb 26, 2007, at 2:36 PM, Jeremy Boynes wrote: Resending as a [VOTE] thread as this one seems to be rambling ... -- Forwarded message -- From: Jeremy Boynes [EMAIL PROTECTED] Date: Feb 25, 2007 6:34 AM Subject: Ratify Tuscany vote to release build dependencies To: general@incubator.apache.org The vote below was held in the Tuscany podling to release two artifacts that are used by other modules during the build process; they are a podling-wide parent pom and configuration data for code checking. There are four +1's from the PPMC but no binding votes and we would like to ask the IPMC to approve the release. -- Jeremy Begin forwarded message: From: Jeremy Boynes [EMAIL PROTECTED] Date: February 25, 2007 6:14:15 AM PST To: tuscany-dev@ws.apache.org Subject: [RESULT] Release updated parent pom and buildtools Reply-To: tuscany-dev@ws.apache.org Passed with +1's from jboynes, jmarino, isilval, rineholt and no -1's I'll ask the IPMC to ratify this. -- Jeremy On Feb 21, 2007, at 6:34 PM, Jeremy Boynes wrote: The parent pom and buildtools were recently updated and as these are used by all other modules I think we should formally release them. These are distributed through the maven repo rather than as a end-user distribution. Please vote to approve the release content: parent-pom [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/2 [binary] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/2-incubating/ [rat]http://people.apache.org/~jboynes/rat/parent-2.rat buildtools [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/2 [binary] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/2-incubating/ [rat]http://people.apache.org/~jboynes/rat/buildtools-2.rat Here's my +1 Given the recent discussion on [EMAIL PROTECTED] about crypto issues around Bouncy Castle, I would point out that these artifacts are not impacted by the export issue. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ratify Tuscany vote to release build dependencies
Thanks Jim. We have two votes for this - could another IPMC member please take a look (these are small files) so we can start on the main part of our next release. Thanks -- Jeremy On Feb 28, 2007, at 12:16 PM, Jim Jagielski wrote: +1 On Feb 27, 2007, at 10:15 PM, Davanum Srinivas wrote: +1 from me. -- dims On 2/26/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Resending as a [VOTE] thread as this one seems to be rambling ... -- Forwarded message -- From: Jeremy Boynes [EMAIL PROTECTED] Date: Feb 25, 2007 6:34 AM Subject: Ratify Tuscany vote to release build dependencies To: general@incubator.apache.org The vote below was held in the Tuscany podling to release two artifacts that are used by other modules during the build process; they are a podling-wide parent pom and configuration data for code checking. There are four +1's from the PPMC but no binding votes and we would like to ask the IPMC to approve the release. -- Jeremy Begin forwarded message: From: Jeremy Boynes [EMAIL PROTECTED] Date: February 25, 2007 6:14:15 AM PST To: tuscany-dev@ws.apache.org Subject: [RESULT] Release updated parent pom and buildtools Reply-To: tuscany-dev@ws.apache.org Passed with +1's from jboynes, jmarino, isilval, rineholt and no -1's I'll ask the IPMC to ratify this. -- Jeremy On Feb 21, 2007, at 6:34 PM, Jeremy Boynes wrote: The parent pom and buildtools were recently updated and as these are used by all other modules I think we should formally release them. These are distributed through the maven repo rather than as a end-user distribution. Please vote to approve the release content: parent-pom [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/2 [binary] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/2-incubating/ [rat]http://people.apache.org/~jboynes/rat/parent-2.rat buildtools [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/2 [binary] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/2-incubating/ [rat]http://people.apache.org/~jboynes/rat/buildtools-2.rat Here's my +1 Given the recent discussion on [EMAIL PROTECTED] about crypto issues around Bouncy Castle, I would point out that these artifacts are not impacted by the export issue. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ratify Tuscany vote to release build dependencies
Thanks Dims. We still need two more votes for approval - would a couple of other IPMC members be able to take a quick look? Thanks -- Jeremy On Feb 27, 2007, at 7:15 PM, Davanum Srinivas wrote: +1 from me. -- dims On 2/26/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Resending as a [VOTE] thread as this one seems to be rambling ... -- Forwarded message -- From: Jeremy Boynes [EMAIL PROTECTED] Date: Feb 25, 2007 6:34 AM Subject: Ratify Tuscany vote to release build dependencies To: general@incubator.apache.org The vote below was held in the Tuscany podling to release two artifacts that are used by other modules during the build process; they are a podling-wide parent pom and configuration data for code checking. There are four +1's from the PPMC but no binding votes and we would like to ask the IPMC to approve the release. -- Jeremy Begin forwarded message: From: Jeremy Boynes [EMAIL PROTECTED] Date: February 25, 2007 6:14:15 AM PST To: tuscany-dev@ws.apache.org Subject: [RESULT] Release updated parent pom and buildtools Reply-To: tuscany-dev@ws.apache.org Passed with +1's from jboynes, jmarino, isilval, rineholt and no -1's I'll ask the IPMC to ratify this. -- Jeremy On Feb 21, 2007, at 6:34 PM, Jeremy Boynes wrote: The parent pom and buildtools were recently updated and as these are used by all other modules I think we should formally release them. These are distributed through the maven repo rather than as a end-user distribution. Please vote to approve the release content: parent-pom [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/2 [binary] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/2-incubating/ [rat]http://people.apache.org/~jboynes/rat/parent-2.rat buildtools [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/2 [binary] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/2-incubating/ [rat]http://people.apache.org/~jboynes/rat/buildtools-2.rat Here's my +1 Given the recent discussion on [EMAIL PROTECTED] about crypto issues around Bouncy Castle, I would point out that these artifacts are not impacted by the export issue. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Ratify Tuscany vote to release build dependencies
Resending as a [VOTE] thread as this one seems to be rambling ... -- Forwarded message -- From: Jeremy Boynes [EMAIL PROTECTED] Date: Feb 25, 2007 6:34 AM Subject: Ratify Tuscany vote to release build dependencies To: general@incubator.apache.org The vote below was held in the Tuscany podling to release two artifacts that are used by other modules during the build process; they are a podling-wide parent pom and configuration data for code checking. There are four +1's from the PPMC but no binding votes and we would like to ask the IPMC to approve the release. -- Jeremy Begin forwarded message: From: Jeremy Boynes [EMAIL PROTECTED] Date: February 25, 2007 6:14:15 AM PST To: tuscany-dev@ws.apache.org Subject: [RESULT] Release updated parent pom and buildtools Reply-To: tuscany-dev@ws.apache.org Passed with +1's from jboynes, jmarino, isilval, rineholt and no -1's I'll ask the IPMC to ratify this. -- Jeremy On Feb 21, 2007, at 6:34 PM, Jeremy Boynes wrote: The parent pom and buildtools were recently updated and as these are used by all other modules I think we should formally release them. These are distributed through the maven repo rather than as a end-user distribution. Please vote to approve the release content: parent-pom [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/2 [binary] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/2-incubating/ [rat]http://people.apache.org/~jboynes/rat/parent-2.rat buildtools [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/2 [binary] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/2-incubating/ [rat]http://people.apache.org/~jboynes/rat/buildtools-2.rat Here's my +1 Given the recent discussion on [EMAIL PROTECTED] about crypto issues around Bouncy Castle, I would point out that these artifacts are not impacted by the export issue. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ratify Tuscany vote to release build dependencies
The vote below was held in the Tuscany podling to release two artifacts that are used by other modules during the build process; they are a podling-wide parent pom and configuration data for code checking. There are four +1's from the PPMC but no binding votes and we would like to ask the IPMC to approve the release. -- Jeremy Begin forwarded message: From: Jeremy Boynes [EMAIL PROTECTED] Date: February 25, 2007 6:14:15 AM PST To: tuscany-dev@ws.apache.org Subject: [RESULT] Release updated parent pom and buildtools Reply-To: tuscany-dev@ws.apache.org Passed with +1's from jboynes, jmarino, isilval, rineholt and no -1's I'll ask the IPMC to ratify this. -- Jeremy On Feb 21, 2007, at 6:34 PM, Jeremy Boynes wrote: The parent pom and buildtools were recently updated and as these are used by all other modules I think we should formally release them. These are distributed through the maven repo rather than as a end-user distribution. Please vote to approve the release content: parent-pom [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/pom/parent/2 [binary] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/parent/2-incubating/ [rat]http://people.apache.org/~jboynes/rat/parent-2.rat buildtools [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java/buildtools/2 [binary] http://people.apache.org/repo/m2-incubating-repository/ org/apache/tuscany/buildtools/2-incubating/ [rat]http://people.apache.org/~jboynes/rat/buildtools-2.rat Here's my +1 Given the recent discussion on [EMAIL PROTECTED] about crypto issues around Bouncy Castle, I would point out that these artifacts are not impacted by the export issue. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany is still a podling ...
On Feb 25, 2007, at 7:18 AM, Niclas Hedhman wrote: On Sunday 25 February 2007 22:34, Jeremy Boynes wrote: The vote below was held in the Tuscany podling to release two artifacts that are used by other modules during the build process; they are a podling-wide parent pom and configuration data for code checking. There are four +1's from the PPMC but no binding votes and we would like to ask the IPMC to approve the release. Can someone explain to me why http://ws.apache.org/ lists Tuscany as a su-project of WS, as well as the mailling lists are @ws.apache.org, yet the project is not graduated??? When the project was proposed, it was sponsored by the WS-PMC and entered incubation. IIRC, at the time mailing lists were typically associated with the sponsoring PMC and so were created under ws (AIUI this policy has subsequently changed). I believe the legal issues and such for the podling have been resolved [1] but I also believe that community issues are such that the podling is not yet ready to graduate. When I responded to the veto on the codedump, I got the impression (this is serious) that Tuscany had graduated, hence not really an Incubator issue anymore... I vetoed the codedump for two main reasons. The first is that the IP clearance process is not being followed: there is no record of the code here http://incubator.apache.org/ip-clearance/index.html and there has been no vote by the Tuscany PPMC or Incubator PMC to accept the code. The second is that there has been *no* discussion about this contribution in the community. One of the community issues Tuscany has is dominance by a single vendor and the way this contribution is being handled is symptomatic of that. I think both of these reasons are relevant to the Incubator, although responsibility for fixing them lies first with the podling. From a technical perspective, I think this contribution could make a useful addition to Tuscany. Is it only me that feels that something is not standard around here?? And it goes for a couple of others as well; Woden, TSIK Synapse. Woden is still incubating, TSIK was withdrawn and Synapse has graduated. -- Jeremy [1] http://incubator.apache.org/projects/tuscany.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BouncyCastle export for Tuscany
On Feb 20, 2007, at 5:47 PM, Noel J. Bergman wrote: Jeremy Boynes wrote: I went through the process and attached is a patch for the site to include Tuscany in the matrix. AIUI though these should be applied/sent by a Officer which I would assume in our case would the IPMC Chair. Since Roy actively has his hand in that space, I'll wait for some feedback before doing so. After discussion on legal-discuss it does not look like we need an export notification for this. We are still working on resolving the IDEA patent issue. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS]Incubator podling mvn pom files...
On Feb 22, 2007, at 2:08 AM, Daniel Kulp wrote: NOTE: Both (1) and (2) can be taken care of by having the org.apache:apache:3 artifact as the parent.Should that be a requirement? (Actually, should there be an incubator parent that lives in the middle?) I made a start on such a pom: http://svn.apache.org/repos/asf/incubator/public/trunk/pom/pom.xml -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS]Incubator podling mvn pom files...
If we end up switching to the main repos, then I think the pom would be fairly empty as the values in apache:3 would be reusable. I still think it is worth having as it ties the podling back to the offical project that is doing the releases. If we keep as we are, the repository, pluginRepository and distributionManagement sections would be the main overrides. The other sections (like site and project URLs) would be podling specific. -- Jeremy On Feb 22, 2007, at 9:29 AM, Daniel Kulp wrote: On Thursday 22 February 2007 06:14, Trustin Lee wrote: Hi, 2007-02-22 (목), 05:08 -0500, Daniel Kulp 쓰시길: While looking at the Trinidad stuff, I had some thoughts about requirements around pom files for Apache stuff and what requirements should be imposed. There are several things in a pom file that could affect how things appear when someone takes a dependency on an Apache project. Thus, we need to make sure these things are correct: 1) organization element: Somewhere up the heirarchy, we need to have: organization nameThe Apache Software Foundation/name urlhttp://www.apache.org//url /organization Shouldn't we specify http://incubator.apache.org/ for incubator project to state it's an incubator project? snip/ I agree with the idea on extending a parent POM generally, but org.apache:apache-incubator might be more reasonable for the projects under incubation. I guess the question is: What would be different in the incubator pom from the apache:3 version? Possibilities: 1) url, but not really the organization.url as that's the URL for ASF, which is correct. 2) Deployment repository (m2-incubating-repository)- however, with the discussion started by Roy, that may be going away. Thus, potentially no difference. 3) Mailing list - [EMAIL PROTECTED] I'd say once the IPMC gets #2 settled (good luck, I think this discussion comes up every 6 months), we could modify the one Jeremy created and get it out there for use. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany diversity, was: Incubator Board Report, February 2007
On Feb 19, 2007, at 1:14 PM, Yoav Shapira wrote: == Tuscany == iPMC Reviewers: dims, jerenkrantz, yoavs, jukka, twl, noel Tuscany provides infrastructure for developing service-oriented applications based on the OSOA specifications for Service Component Architecture (SCA) and Service Data Objects (SDO). Since our last report Tuscany has voted in one new committer, Simon Laws, but community diversity remains an issue with most contributors working for a single company. snip * noel: Are there any specific steps being taken to improve diversity? Didn't see this question on the wiki. There are some significant activities going on: * presentation on Tuscany/SCA at TSSS by minority project members * collaboration with other SDO implementations on a (SDO) community test suite * collaboration with an independent group interested in DAS for C++ all of which have the potential to attract unaligned contributors. Of the active committers (i.e. have committed since 1/1/07), 14 work for the dominant vendor compared to 3 who do not. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BouncyCastle export for Tuscany
On Feb 19, 2007, at 11:28 PM, James M Snell wrote: All of the instructions can be found at [1]. Just step through that and it shouldn't take too long. As far as I understand, each project is responsible for it's own notifications. - James [1] http://www.apache.org/dev/crypto.html Thanks. I went through the process and attached is a patch for the site to include Tuscany in the matrix. I ran the XSL and the generated mail looked OK. AIUI though these should be applied/sent by a Officer which I would assume in our case would the IPMC Chair. I couldn't find any indication on the JXTA site whether they have filed an export notice for their dependency on Bouncy Castle - Meeraj is going to ping their project list to find out. Thanks -- Jeremy https://svn.apache.org/repos/asf/infrastructure/site/trunk/xdocs/ licenses/exports Index: index.xml === --- index.xml (revision 509799) +++ index.xml (working copy) @@ -390,6 +390,30 @@ /Version /Product /Project + + Project href=http://incubator.apache.org/tuscany; + NameApache Tuscany Project/Name + ContactNameJeremy Boynes/Name/Contact + Product +NameApache Tuscany SCA Java Runtime/Name +Version + Namestrunk/Names + ECCN5D002/ECCN + ControlledSource href=http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/; +ManufacturerASF/Manufacturer +WhyDesigned for use with encryption library/Why + /ControlledSource + ControlledSource href=http://download.jxta.org/build/release/jse/2.4.1/jxta-src-2.4.1.tar.gz; +ManufacturerJXTA/Manufacturer +WhyDesigned for use with encryption library/Why + /ControlledSource + ControlledSource href=http://www.bouncycastle.org/download/bcprov-jdk14-124.tar.gz; +ManufacturerBouncy Castle/Manufacturer +WhyGeneral-purpose encryption library for Java 1.4.x used by JXTA/Why + /ControlledSource +/Version + /Product + /Project /eccnmatrix /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: podling BIS notifications
What we actually have in svn is a mvn pom which references jxta and bouncycastle: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/ services/discovery/jxta/pom.xml The bouncycastle reference is there because jxta needs it; there is no direct reference from our code. My assumption is the same as Roy's in that this makes the Tuscany module 5D002. During development we publish unstable snapshots to the mvn repo at http://people.apache.org/repo/m2-snapshot-repository/ This would include the jxta module in binary form but would not include binaries for jxta or bouncycastle themselves. Being conservative though, my guess would be that this still meets the criteria for first notification as we are distributing code that uses a 5D002 item through a public server (people.apache.org). Apart from this one module though, Tuscany itself does not have a dependency on a 5D002 item. We do include that module by default in one distribution which would presumably make that distribution 5D002 (when we release it, we have not done so yet). However, there are other distributions that do not include it and do not rely on it. Are there any issues with not classifying those, or should we be conservative and notify for all? -- Jeremy On Feb 20, 2007, at 9:22 PM, Roy T. Fielding wrote: BIS notices have to be made if a product contains encryption functionality controlled by the EAR's 5D002 classification, or is specifically designed to make use of a 5D002 classified item (as would the case if the source code contains calls to OpenSSL or JCE interfaces), or if any released package contains any other product that is classified as 5D002 (as it would if the Bouncy Castle jar was included in a release package). A conservative read of the EAR would indicate that JXTA depending on Bouncy Castle makes JXTA 5D002, so if Tuscany is specifically designed to use JXTA then it would also be 5D002. (The same sad fate applies to Apache httpd 2.x modules as well, apparently, even if they aren't designed to make use of the SSL components.) Hence, the podling should bring it to the attention of the IPMC when a release vote is made, and the IPMC chair should be the one to edit the exports page and send the appropriate message to the BIS *prior* to the release being published. Noel can delegate that if he wants, but whoever has the hat needs to be kept aware of the situation. The notice only needs to be sent once per product when it is first considered for release and later only if the product's encryption functionality changes. We don't know exactly where the line needs to be drawn, since the BIS has been very lenient or very overloaded in the past and never (to my knowledge) taken us to task for doing it wrong. Or maybe we always did it right. Nevertheless, the EAR is the law as far as the ASF is concerned, and has to be obeyed even if we think the law is confusing and pointless. My guess is that ongoing development of source code bits within subversion qualifies as an open conference, just like our mailing lists, and thus not subject to the export controls. It is only when the bits appear in functioning product form that the encryption controls apply (it is the encryption *functionality* that is controlled, so says the regulations, since everyone knows that encryption itself is not a secret technology). *shrug* But being proactive on the notice is always better than being reactive to government agents. Note, however, that if anyone commits something like the OpenSSL or Bouncy Castle source code and/or binaries, which are products in and of themselves, to the subversion instance, then the PMC must file an export notice for the subversion area even if no ASF product has been released yet. That is because distributing third-party products from a public web server is the same as exporting them. Personally, I think it is wrong for projects to commit code to subversion unless it is intended to be maintained as source, but I know that some real projects at the ASF are too lazy to write build scripts and instead use our subversion instance as a binary distribution medium. As far as timing goes, the notice should be sent as soon as it becomes clear that the product will eventually contain code that is designed for a given 5D002 product (i.e., anything that uses encryption for purposes other than mere authentication). Preferably, before that code is committed to subversion. The real benefit of having the exports page (aside from answering the FAQ) is that we now have a single source link to provide to the BIS that is independent of the product names and release versions, and so we can easily send the notice once, before any chance of an export occurs, and not worry about it later. Note: For those wondering about history, we submitted the equivalent of BIS notices for the Apache HTTP Server a long time ago when the ASF first began, and then again when the regulations changed, and
BouncyCastle export for Tuscany, was: [Vote] Abdera v0.2.2
On Feb 17, 2007, at 5:27 PM, James M Snell wrote: I've gone ahead and filed the export notification and updated the ASF exports page [1]. I also added an appropriate notification to the distributions README. [1] http://www.apache.org/licenses/exports/ In Tuscany our next release will have a dependency on JXTA which has one on BouncyCastle so I believe we will need to do this as well. I couldn't see anything on that page about how to file the notification - what did you need to do and who is authorized to do this on behalf of the ASF? Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to bring code to Apache?
The important part here is not to validate the process but the provenance of the code being contributed. It does not matter whether the code was developed in an open or closed manner, by one individual or by many, what we have a responsibility to establish is that the code can legally be contributed to the ASF. Unlike an employer, the ASF has no initial rights to any code; those are granted to it through the ICLA when the code is contributed. We operate on an ongoing assumption that the committer abides by the ICLA and does actually have the rights to contribute that code. However, for any body of code we (the ASF) should have the ability to ask the committer to reconfirm this, especially if there is increased potential that the IP for the code is not owned solely by them (as would be the case if it was developed by multiple people or for an employer outside a CCLA). AIUI, that is the role of the IP Clearance process: to obtain that confirmation. The openness of the development process used is only relevant here to the extent that it exposes the provenance of the code - an open process allows us to backtrack and see who created the code and owns the IP. It's much more of an issue for the receiving PMC in gauging the health of the community. I'd suggest changing that part to something like the important part is whether anyone else may own any of the code, for example if it was developed with other people or as part of your job -- Jeremy On Nov 3, 2006, at 2:09 PM, Henri Yandell wrote: On 11/3/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: Henri Yandell wrote: [snip] Any thoughts on the below? [snip] the important part is that the code was developed outside of the ASF SVN repository and the ASF public mailing lists. I struggle with what that really means. Code is technically developed in IDEs on people's machines, not on mailing lists. Agreed - to the point that I used the text on the documentation page rather than trying to paraphrase it. The other phrase I've heard is: Created using the ASF development process If I create a new file for an ASF project it's developed on my machine and subsequently committed to the project or posted as a patch. So for sometime the new file was outside the ASF SVN repository and not visible on a public mailing list. What really makes something developed inside the ASF? - intention to contribute to a project? Definitely not. - JIRA entry created before the file is created? Not important. - discussion in mailing list before the file is created? Openness is a lot of it - so this is often a good example of openness. - creating the file in a local SVN copy from the ASF SVN? I think this can be a warning sign. If a large 'svn add' commit is done, then it's a warning sign to ask whether the change was developed openly. The barracks-lawyer (aka pain in the arse) in me looks at the documentation and thinks What if it was on a public asf mailing list, was by people with asf clas but didn't use the svn repos?. I think getting the answer for that would not be worth the small effort required to file an ip clearance - but if the style was to have an external svn and then slowly bring pieces over, it might be worth figuring it out. Biggest question here would be 'why not the asf svn?'. Another case that is interesting is 'the big rewrite' style of commit. If someone works on the next version of their project on their own and then code dumps a lot of changes in, that also seems like it's going to need IP clearance. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CCLAs for Tuscany code, was: Ratify Tuscany PPMC vote to release SDO for Java M2 artifacts
On Oct 28, 2006, at 12:46 PM, robert burrell donkin wrote: On 10/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Oct 28, 2006, at 6:59 AM, robert burrell donkin wrote: the status file is worrying: there are two CCLAs pending. please confirm that this is either an oversight or that these CCLAs are not pertinent to this material. The CCLAs are pertinent and were sent to Jim on 2005-12-28 as recorded here: http://incubator.apache.org/projects/tuscany.html I was waiting for an ack from Jim before updating the SVN STATUS file and lost track of the issue. If he could ack this here I'd think we'd be OK (and I'll update the file as well). there are notes in the software grant records about contributions by BEA and IBM related to 'Tuscany' codebase for SCA, SDO and DAS. is this the code in question? Yes. Thanks for checking, I'll update the status file to reflect this. I'll use 2005-12-28 for the date unless there's something to indicate differently. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CCLAs for Tuscany code, was: Ratify Tuscany PPMC vote to release SDO for Java M2 artifacts
On Oct 28, 2006, at 6:59 AM, robert burrell donkin wrote: the status file is worrying: there are two CCLAs pending. please confirm that this is either an oversight or that these CCLAs are not pertinent to this material. The CCLAs are pertinent and were sent to Jim on 2005-12-28 as recorded here: http://incubator.apache.org/projects/tuscany.html I was waiting for an ack from Jim before updating the SVN STATUS file and lost track of the issue. If he could ack this here I'd think we'd be OK (and I'll update the file as well). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Ratify Tuscany PPMC vote to release project pom and buildtools artifacts
Passed with binding +1's from rdonkin, geirm, dims and non-binding +1 from matezw Thank you everyone. -- Jeremy On Oct 15, 2006, at 6:34 PM, Jeremy Boynes wrote: The Tuscany PPMC has voted to release a parent pom and buildtools jar that are dependencies for a forthcoming M2 release. These would be made available through the m2-incubating-repository to allow end users to build source distributions of that release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. Vote thread (with links to artifacts and aRAT results): http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/ [EMAIL PROTECTED] Vote result: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/ [EMAIL PROTECTED] -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Ratify Tuscany PPMC vote to release project pom and buildtools artifacts
The Tuscany PPMC has voted to release a parent pom and buildtools jar that are dependencies for a forthcoming M2 release. These would be made available through the m2-incubating-repository to allow end users to build source distributions of that release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. Vote thread (with links to artifacts and aRAT results): http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/% [EMAIL PROTECTED] Vote result: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/% [EMAIL PROTECTED] -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Requirements
On Oct 13, 2006, at 6:28 AM, robert burrell donkin wrote: On 10/12/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Other than wait for Robert's scanning tool? :-) no need to wait: get the source (http://code.google.com/p/arat/) and run the RAT against the source distribution (i'll improved binary will come later). the output is very unfriendly but what do you expect from aRAT ;-) We're using it - thanks for putting it together, I've found it helpful. I was including the result of the run in the [VOTE] thread e.g. http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/% [EMAIL PROTECTED] -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Requirements
On Oct 12, 2006, at 8:13 AM, Noel J. Bergman wrote: The Mentors can and should engage the community on best practices. When the Incubator PMC is presented with a release to approve, we ought to focus on actual requirements, such as: Licensing Notification Signing (if we choose to enforce this) ... I would say that the IPMC should focus on the process the podling used to prepare the release. Oversight from the Mentors or other IPMC members on the PPMC should mean that by time the release is presented to the IPMC the requirements already have been met. This not only ensures that the release content meets the ASF requirements but also that the PPMC members know what is involved. The IPMC still needs to review the actual release but to some degree they should be able to rely on the votes from the Mentors. Ideally the Mentors would be able to vote based on their review at the PPMC stage. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Requirements
On Oct 12, 2006, at 3:09 PM, Noel J. Bergman wrote: Jeremy Boynes wrote: Noel J. Bergman wrote: The Mentors can and should engage the community on best practices. When the Incubator PMC is presented with a release to approve, we ought to focus on actual requirements, such as: Licensing Notification Signing (if we choose to enforce this) ... I would say that the IPMC should focus on the process the podling used to prepare the release. Oversight from the Mentors or other IPMC members on the PPMC should mean that by time the release is presented to the IPMC the requirements already have been met. Your predicate has not been met in far too many cases, and the Incubator PMC has the obligation to make sure that the requirements (summarized above) have been met. I realize, I think that's an area we can improve :-) This not only ensures that the release content meets the ASF requirements but also that the PPMC members know what is involved. How can we help change things so that this is the case? Other than wait for Robert's scanning tool? :-) The biggest help IMO would be what you said in the original post: Mentors can and should engage the community on best practices. One thing that is almost certain to be new for a podling is the ASF release process and requirements. Best practice in this case is how to make sure that a release meets them. This is one area where active participation by existing ASF people is of direct benefit; if they are Mentors or others with IPMC votes that also helps the IPMC fulfill its obligations as their involvement in the process of producing the release can provide valuable background information. By involvement I mean from an oversight/mentoring perspective, actual execution should be done by the podling community as they will be the ones responsible after graduation. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
source audit tool?
I would like to use this as part of the run-up for Tuscany's next release. Did you check this in somewhere and if so where? If not, can I have a copy I can run locally? Thanks -- Jeremy On Sep 14, 2006, at 2:31 PM, robert burrell donkin wrote: i have a basic tool that i've been running against the source releases recently. it's simple but helps to track down some basic issues. no documentation. would this tool be useful for podlings (mentors and release managers in particular)? if so, would it be appropriate to check the source in somewhere in the incubator public tree? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RELEASES] any interest in a source audit tool?
On Sep 14, 2006, at 2:40 PM, Daniel Kulp wrote: I would suggest it go into: https://svn.apache.org/repos/private/committers/tools/ as it would be applicable for non-incubator projects as well. Unless there's something special, how about a public tree? A podling it's own right? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing to release an incubator POM
On Sep 9, 2006, at 5:48 AM, Jason van Zyl wrote: On 8 Sep 06, at 10:36 PM 8 Sep 06, Wendy Smoak wrote: On 9/8/06, Jeremy Boynes [EMAIL PROTECTED] wrote: This artifact would need to released by the Incubator PMC so that it can be made freely available via ibiblio. The latest version is in SVN at https://svn.apache.org/repos/asf/incubator/public/trunk/pom/pom.xml and if there are no issues with doing this I would like to formally tag it and request a vote by the IPMC. Any comments before I do so? What about using 'incubator' or 'incubator-parent' for the artifactId (instead of just 'parent')? incubator would probably be the best I have no strong preference, this just seemed tautological as the groupId is already org.apache.incubator Other examples are the top-level 'apache' pom,(which you might want to define as this pom's parent, if only to show the project hierarchy,) I thought it was better not to do this as this pom is intended to be used as a parent by podlings which do not have official Apache project status. Maintaining a distinct hierarchy seemed clearer. With this in mind, how about podling-parent for the artifactId? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing to release an incubator POM
On Sep 9, 2006, at 10:12 AM, Craig L Russell wrote: Hi Jeremy, On Sep 9, 2006, at 8:53 AM, Jeremy Boynes wrote: On Sep 8, 2006, at 7:23 PM, Craig L Russell wrote: Hi Jeremy, Thanks for doing this. I think it's great for podlings to get a leg up. I'd like to understand where this POM is documented so that podlings can use and understand it. Just a link to the incubator web page that tells podlings what they need to do to use it would let me see how it is intended to be used, and to refer podlings to it. I would suggest the projects page: http://incubator.apache.org/guides/projects.html This page doesn't appear to have any information on how to use the POM you are setting up. No, not yet - that was the suggestion on where it would go. There's some work needed (for example, I don't think that page is even linked to off the nav) in addition to just documenting it. As a jump start, what a podling would need to do is add a section to their maven pom like: project ... parent groupIdorg.apache.incubator/groupId artifactIdpodling-parent/artifact version1/version /parent ... rest of podling's original pom ... /project Their project would then inherit settings from this POM in the normal Maven way, the interesting ones being: * the location of the download repositories for podlings (snapshot and incubator) * the location of the upload repositories for the podlings (snapshot and incubator) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Preparing to release an incubator POM
As discussed recently I have created a Maven2 POM that is meant to capture current Incubator policy for podlings. For example, this defines the location of the Maven repositories where they should release artifacts to. This allows a podling to inherit from this POM and avoid the need to provide (and maintain) their own versions of these definition. This artifact would need to released by the Incubator PMC so that it can be made freely available via ibiblio. The latest version is in SVN at https://svn.apache.org/repos/asf/incubator/public/trunk/pom/pom.xml and if there are no issues with doing this I would like to formally tag it and request a vote by the IPMC. Any comments before I do so? Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Lightning Talks at ApacheCon US?
On Sep 6, 2006, at 7:59 AM, Justin Erenkrantz wrote: On 9/6/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Justin Erenkrantz wrote: Our initial idea was to have short (15-min?) talks about as many podlings as we can fit in to the timeslot. Tell us what the project is about, who is involved, why I should download it, etc, etc. You've got 15 minutes to convince a room full of Apache folks to contribute to your project. Go forth. 15 minutes is way too long. If you can't digest it to 5 minutes their eyes have glazed over, if they aren't excited enough to dig into the project by then you failed to persuade :) If we have enough podlings to fill 2 hours with a bunch of 5 minute slots, sure - I don't think that'll be the case though. But, we can compress the time available to the podling as more folks sign up. If only one podling signs up, they get 2 hours to talk. =) So there's an incentive to hang back :-) I would be interested in doing 5 minutes on Tuscany -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator POM as parent for podlings
Thanks Jason. I added this to svn in public/trunk/pom with a 1- SNAPSHOT version. As you say, small errors could be problematic so I would appreciate if it could be reviewed. If it's OK and after we vote is it just a matter of using the release plugin to tag/publish it? Thanks -- Jeremy On Sep 3, 2006, at 10:41 AM, Jason van Zyl wrote: On 1 Sep 06, at 1:03 PM 1 Sep 06, Jeremy Boynes wrote: Any other thoughts on this? Any objection to checking it in to incubator SVN? I think it's a good idea because a lot of the common information can be collected, made consistent and that's a good thing. One policy that Maven follows is the vote on releases of these POMs because small, inadvertent errors can have serious repercussions. You just have to take some care and treat new versions of the POM as you do any other release and do it consistently in a reproducible way. So for our POMs for Maven and the one we keep for the ASF we have the typical trunk/tags and try to do proper releases. So what's released with a whole numbers like 1,2,3,...,N is what you try to reference most of the time but in dire need you can reference a SNAPSHOT which would be in trunk. Be glad to help setting this up. Thanks for creating this! Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator POM as parent for podlings
Any other thoughts on this? Any objection to checking it in to incubator SVN? Thanks -- Jeremy On Aug 30, 2006, at 3:45 PM, Jeremy Boynes wrote: The Maven project maintains a POM that can be used as a parent by other ASF projects http://svn.apache.org/repos/asf/maven/pom/trunk/asf/pom.xml I think it would help if we had a similar thing for the incubator that podlings can use - for example, defining the distribution repo to be the incubator one. I took a swag at modifying the one above for the incubator - see below. -- Jeremy ?xml version=1.0 encoding=UTF-8? !-- * 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. -- !-- Shared parent for Incubator projects and podlings. Version: $Rev$ $Date$ -- project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdorg.apache.incubator/groupId artifactIdparent/artifactId version1-SNAPSHOT/version packagingpom/packaging nameThe Apache Incubator/name description The Incubator project is the entry path into The Apache Software Foundation (ASF) for projects and codebases wishing to become part of the Foundation's efforts. All code donations from external organisations and existing external projects wishing to join Apache enter through the Incubator. /description licenses license nameThe Apache Software License, Version 2.0/name urlhttp://www.apache.org/licenses/LICENSE-2.0.txt/url distributionrepo/distribution /license /licenses organization nameApache Software Foundation/name urlhttp://www.apache.org//url /organization urlhttp://incubator.apache.org//url repositories repository idapache.snapshots/id nameApache Snapshot Repository/name urlhttp://people.apache.org/repo/m2-snapshot- repository/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository repository idapache.incubator/id nameApache Incubator Repository/name urlhttp://people.apache.org/repo/m2-incubating- repository//url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository /repositories distributionManagement !-- Site omitted - each podling must provide their own -- repository idapache.incubator/id nameApache Incubator Repository/name urlscp://people.apache.org/www/people.apache.org/repo/ m2-incubating-repository/url /repository snapshotRepository idapache.snapshots/id nameApache Snapshot Repository/name urlscp://people.apache.org/www/people.apache.org/repo/ m2-snapshot-repository/url /snapshotRepository /distributionManagement mailingLists mailingList nameApache Incubator Genera; List/name subscribe[EMAIL PROTECTED]/ subscribe unsubscribe[EMAIL PROTECTED]/ unsubscribe postgeneral@incubator.apache.org/post archivehttp://mail-archives.apache.org/mod_mbox/ incubator-general//archive /mailingList /mailingLists /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 repo for incubating project releases?
On Jul 29, 2006, at 10:03 PM, Andrus Adamchik wrote: On Jul 30, 2006, at 12:41 AM, Craig McClanahan wrote: There are (at least) two scenarios where I believe there is legitimate cause for concern with the way Maven does things: * You can declare a dependency on a particular groupId/artifactId combination *without* specifying a version number. The meaning is something along the lines of take the latest version you know about. Thus, you could unknowingly be declaring a dependency on an incubating project if incubating is only present in the version number. This can be alleviated by requiring that incubating be part of the group or artifact identifier, which I think would be a really good idea. AFAIK the version still has to be set explicitly in the parent POM. It certainly fails for me when I remove the version tag from the dependencies. Maven gurus please correct me if I'm wrong. (I think only Maven *plugin* versions can be omitted??) That is my understanding as well. It does leave a loophole where someone purely using a plugin may not be aware that the project is incubating but I would expect that if they had reached the level of using the plugin they would also be using other artifacts from the project that would be clearly marked. This would be avoided though if we placed the artifacts in a different repository (as they would have to explicitly specify the incubator pluginRepository). * The harder problem is that Maven2 does transitive dependency identification. If you declare an explicit dependency on module A, which itself has a dependency on incubating module B, you're not going to know that you are depending on incubating code unless you are very careful about analyzing the entire set of POMs for all your dependencies (or you generate the website and analyze the dependency report that is produced there). That was the case that I described. My understanding is that the roots of the policy requiring to include a clear indication that the code is incubating is to alert the users of the differences between Apache software and incubating Apache software. AFAIK having a separate repository would not achieve this as the repository definition would also be extracted from the first level dependency's POM - in other words the transitive dependency would automatically be downloaded from the incubator repository with no action taken by the user. So my earlier point was that if Maven downloads a transitive dependency that is third or higher degree from the root, users either do not know that they got anything Apache at all (so no unintended misrepresentation of the incubating code takes place), of if they do - they will clearly see the incubating suffix in the Maven log or local repo directory name, or the jar file name, or any other number of ways. Therefore having x.x-incubating in the version number seems sufficient. Perhaps it would suffice to make it ASF policy that no official project should have a dependency on a incubating one (or such a dependency would be scoped as provided so that the user would have to explicitly include it). Outside the ASF we have very little control over what people do with the artifacts, although we might ask them to preserve the incubating status. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] any volunteers?
On Jul 30, 2006, at 3:15 AM, robert burrell donkin wrote: http://incubator.apache.org/guides/releasemanagement.html is really just an outline. lot of work required. I had an itch to help with this one. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of Incubating Project Names without mentioning Incubator?
On Jul 14, 2006, at 2:30 PM, Martin van den Bemt wrote: Would probably also be a good idea to fix the tuscany page itself..It mentions that it is in the incubator, but the page title and header is Apache Tuscany.. The branding page says that a podling must be referred to as Apache Podling-Name and I think this is consistent with that. A quick poll of podling websites shows this to be the norm. http://incubator.apache.org/guides/branding.html We are planning to redo the site based on feedback at ApacheConEU that it basically sucked and as part of that should make a couple of other changes to address recommendations on the branding page (such as using the longer disclaimer and the incubator logo). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PPMC list for Tuscany
After the recent discussion on the New Committers thread, I'd like to ask someone to create a private/ppmc list for Tuscany. I opened a Jira for this a while ago http://issues.apache.org/jira/browse/INFRA-839 and someone who shall remain nameless volunteered to do it but hasn't quite got around to it yet. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] CeltiXfire Project
Sanjiva Weerawarana wrote: In any case, the framework part seems just like what JBI impls like ServiceMix are doing and what JBI alternates like SCA (Tuscany) are doing. Since James is a mentor of this maybe he can explain the relationship (or lack thereof) between Celtixfire and ServiceMix. It would be great if Jeremy (or some other Tuscanite) could explain how this relates to Tuscany as well. Dan Kulp has been involved in Tuscany for a while working on both the SCA core and contributing a binding implementation that integrates with Celtix. There are samples in Tuscany that illustrate how to use it and at our JavaOne BOF we showed SCA assembly being used to switch Celtix between web-service (specifically SOAP over HTTP) and XML over JMS bindings (with Celtix using ActiveMQ under the cover). We also have a webservice binding using Axis2 (and we used to have an Axis1 version as well). Given Dan's participation I would expect integration with Celtix to continue - we support other bindings so, for example, I can see how Celtix/Yoko integration may help with CORBA. Of course, other participants have an interest in Axis so I would expect that to continue as well. One challenge we face for web-services in general though is support for the add-in specs for things such as security, transactions, reliable messaging and so on. I see from the proposal that CeltiXfire is already using WSS4J - is there going to be more collaboration between the communities in these areas? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New committers
Justin Erenkrantz wrote: I think the initial decision was that a PPMC was not necessary as the code was just going to be imported into the MyFaces project. Therefore, the MyFaces PMC is responsible for executing the duties that a PPMC would normally do. Perhaps we need to clarify these types of situations. What have we done for mod_ftp, for example? My glance at the status page says that there isn't a PPMC either. So, I'd guess [EMAIL PROTECTED] would control adding new committers to it. I guess... Anyone else have an opinion? Any other examples? -- justin For Derby we had a PPMC which was useful for personnel discussions. On graduation responsbility was transferred to the DB PMC. On Tuscany we don't have a PPMC or other private forum - we've added committers so far based on adhoc discussions. I think that is problematic as it provides no visibility to either the Incubator or WebServices PMCs on how those decisions are being made. I think it would be a good idea for every podling to have such a forum so that the committers involved can become familiar with Apache's way and so that the IPMC can perform its oversight role. This also provides new committers with exposure to PMC responsibilities which is valuable if the podling graduates into an existing project and essential if it exits as a TLP. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project templates
robert burrell donkin wrote: On 6/7/06, Paul Fremantle [EMAIL PROTECTED] wrote: I will try to get a template based on Maven 1.x ready for ApacheCon It probably makes far more sense to make that Maven 2.x. both would be best a lot of projects are still maven 1. what would be great is a maven 2 ready maven 1 build as well as a maven 2 build. Paul's focus may be M1 as I think Synapse/Axis are using it. Tuscany is using M2 so if Paul wants to work on M1 I'm willing to come up with a similar template for M2 (I would propose as an archetype mojo). Would this be an appropriate thing to check into incubator SVN, and if so where? incubator/public/trunk/template/maven[12] ? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Request to release (revised) Tuscany M1
On 6/1/06, Cliff Schmidt [EMAIL PROTECTED] wrote: yes -- it's true that the policy is still only proposed and that the proposed policy allows for a transition/evaluation period to see the impact of some of the requirements. I would not suggest that you remove something from the release just because it's under the NPL. However, you should make sure the license is copied into or referenced in the LICENSE file. Thanks - we'll update the NOTICE/LICENSE files to reflect NPL and continue with the release. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Request to release (revised) Tuscany M1
On 5/25/06, Jeremy Boynes [EMAIL PROTECTED] wrote: We voted on tuscany-dev on a revised version that addresses the issues Robert raised below and the results can be viewed at http://article.gmane.org/gmane.comp.apache.webservices.tuscany.devel/3403 We would like to request approval from the Incubator PMC to release this new version. The candidate distribution can be found at http://people.apache.org/~jsdelfino/test-incubating-M1/ Passed with +1's from dims, jim, pzf, stoddard, jstrachan and no -1's. Thanks to everyone for reviewing and voting. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
STATUS files in podling release
On 5/27/06, Jim Jagielski [EMAIL PROTECTED] wrote: Is STATUS appropriate to be bundled in the release? I had the same question relating to the Tuscany release. In general I don't think it should as STATUS reflects the state of the project rather than the code being distributed and technical matters can be covered in some form of release notes (e.g. README). However, during incubation, the state of the podling is more likely to be a material factor for potential users so I would suggest that requiring it to be included should be part of incubator policy. If others agree I'll volunteer to update the incubator site to reflect that. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Request to release (revised) Tuscany M1
We voted on tuscany-dev on a revised version that addresses the issues Robert raised below and the results can be viewed at http://article.gmane.org/gmane.comp.apache.webservices.tuscany.devel/3403 We would like to request approval from the Incubator PMC to release this new version. The candidate distribution can be found at http://people.apache.org/~jsdelfino/test-incubating-M1/ Thanks -- Jeremy On 5/22/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: robert burrell donkin wrote: On 5/19/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi! I have initiated a vote on tuscany-dev@ws.apache.org to publish a release of Tuscany. The vote email thread is available there: http://article.gmane.org/gmane.comp.apache.webservices.tuscany.devel/3259 We have read the Apache release guidelines and the incubator release policy, but this is the first time that we are doing an incubation release so I would appreciate if you could take a look at the distributions at http://people.apache.org/~jsdelfino/test-incubating-M1/http://people.apache.org/%7Ejsdelfino/test-incubating-M1/, give us feedback and let us know if we need to fix anything. (non-binding) a few little nits (nothing serious, more FYI for next time): 1 there are some encoding issues down at the bottom of the LICENSE.txt. they don't effect the meaning. 2 STATUS seems like it might be a little outdated re:PENDING ISSUES. might be good to list M1 in the release status 3 MANIFEST files lack a Implementation-Vendor-Id and so are not fully complient. it's conventional to use 'org.apache'. one slightly more serious point: 4 the tuscany jar's don't contain NOTICE files. all distributed artifacts *must* contain these LICENSE and NOTICE files. if these jars don't contain these files then they cannot be released via the apache jar repository (which is mirrored to the maven repository on ibiblio). read http://www.apache.org/dev/release.html. it's traditional to include LICENSE and NOTICE files within META-INF (but that's not mandatory). http://jakarta.apache.org/commons/releases/prepare.html contains maven 1 snippets. but overall not bad :-) - robert Robert, Thanks for your feedback. I fixed the issues you reported (see JIRA http://issues.apache.org/jira/browse/TUSCANY-414) and uploaded the updated files to http://people.apache.org/~jsdelfino/test-incubating-M1/. I also started a new vote on tuscany-dev@ws.apache.org to publish the updated distribution. The vote email thread is available there: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200605.mbox/[EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (INCUBATOR-8) Incubate Tuscany SOA project
[ http://issues.apache.org/jira/browse/INCUBATOR-8?page=all ] Jeremy Boynes updated INCUBATOR-8: -- Attachment: tuscany-java-contrib.jar Contribution of Java implementation by BEA and IBM as covered by CCLA Incubate Tuscany SOA project Key: INCUBATOR-8 URL: http://issues.apache.org/jira/browse/INCUBATOR-8 Project: Incubator Type: Wish Reporter: Kenneth Tam Attachments: Tuscany-apache-proposal.tar.gz, tuscany-cpp.tar.gz, tuscany-java-contrib.jar, tuscany_cpp.tar.gz Placeholder for materials related to Tuscany SOA incubator proposal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [RESULT] (Re: [PROPOSAL] Incubate Tuscany SOA Project)
Davanum Srinivas wrote: Folks, The WS-PMC has voted to accept the re-written Tuscany proposal with 11 +1 votes (and zero -1/+0/-0 votes) Thanks, dims Dims Great, thank you! I have updated the proposal on the wiki to reflect this result and to change sponsor from the Incubator to the WS PMC. My understanding is that once we get an ack from the Incubator we should be good to go. If that's right, is there anything we can do to help with the next steps? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SOA Project
[EMAIL PROTECTED] wrote:
I would like to offer development help on the proposed Tuscany SOA project.
Great - welcome aboard.
From the Tuscany proposal, I would be interested in helping with the
following technology areas:
* integration with Axis2 policy implementations for security,
transactions, reliable messaging
Before we can do that we need to upgrade from Axis1 to Axis2 itself. If
you look in the snapshot we posted to JIRA at
http://issues.apache.org/jira/browse/INCUBATOR-8 then the Axis
integration is in the runtime/binding.axis module. I would suggest
having a look at the code there first
The intent is to support multiple binding implementations so we can
either modify this module or add a new one e.g. binding.axis2
* support heterogeneous components written in C/C++, BPEL, PHP
and other languages
The container integration is split between two modules: runtime/core
which is meant to be applicable to all and runtime/container.${type} for
a specific type. As you can see, container.java is fairly basic.
Sebastien has had some thoughts on integrating a BPEL engine, I've been
thinking about integrating with the C++ implementation - were these the
ones you had in mind or another language all together?
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubate Tuscany SOA Project
Roy T.Fielding wrote: No, the proposal is all about SOA. What you are saying is that the *actual plan* is about SCA. What I am saying is that the proposal needs to match the actual plan, preferably a plan that is actionable, rather than a statement of how happy the SOA community may someday be. I think everyone understands that now, yet nobody has updated the wiki. There's no rush, I guess, but I do want to be clear that an e-mail exchange is not the same as recording a mission statement that people outside the proposal authors will understand. I held off making changes as I thought discussing a moving target would be confusing. I have now updated the proposal on the wiki expanding the Rationale section to indicate that we will be implementing the SCA specifications starting from an initial contribution. I've not seen anything from the WS PMC but if they do decide to sponsor Tuscany I will update the wiki to reflect that change. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubate Tuscany SOA Project
Paul Fremantle wrote: Now - can someone give me an idea of how open the model is? In other words are the specifications behind Tuscany open to being modified? Will they be submitted to a standards body and in what timeframe? It would be good to know that Apache and in particular the committers can have input into the model and not just write code to a fixed specification that has no way for committers to improve except if they work for one of the publishing companies. The specifications themselves are not final and are open for suggestions and improvements. Facilitating this was one reason they have been held back from submission to a standards body at this time though the intention is to do so in the future. When? Well, when they're ready. On the other hand, Tuscany is not a reference implementation of the specifications, constrained by the functionality they define. As an open and independent community we are free to develop the features and function we think most important. Portability and interoperability, as provided by the specifications, are naturally very important and I think our implementation will reflect that; however, innovation, flexibility and responsiveness to users' needs are equally important and we have the opportunity to provide those as well. There are many things that we've thought of doing that are not covered by the specifications; some of those are in the proposal, others aren't. Implementing them, along with other people's new ideas, is one way in which we hope to build the developer community. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Incubate Tuscany SOA Project
communities (including Apache and Eclipse). No ties to other Apache products: As described in the Alignment section, this framework already has ties to many Apache products. The initial codebase is already licensed under the Apache License 2.0. A fascination with the Apache brand: The committers are intent on developing a strong open source community around frameworks that treat SOA-centric design in a first-class manner. We believe that the Apache Software Foundation's emphasis on community development makes it the most suitable choice for such a project. 1. Scope of the subprojects The initial contributors envision an active community of related projects sharing a common model for SOA applications but targeting specific technical areas of that model. Tuscany will be seeded with several projects based on donated material (see the next section): * an assembly model defining a mechanism for composing SOA applications * a Java implementation running on top of Tomcat and Axis * a Java implementation of SDO2 and a data access subsystem * a C++ implementation running on top of Apache HTTPD and Axis C++ * a C++ implementation of SDO2 To assist in community building the committers have identified several key technology areas that will allow new contributors to actively engage in the project. These include: * transition web service integration to Axis2 * integration with Axis2 policy implementations for security, transactions, reliable messaging * support heterogeneous components written in C/C++, BPEL, PHP and other languages * support callbacks, allowing a component to call back to the service that invoked it * support asynchronous calls using JMS * support typesafe SDOs in the C++ implementation of SDO2 These initial projects are intended merely as starting points and should not be taken as bounding the scope of the Tuscany project as a whole. Some other potential projects may include: * Integration with existing development frameworks (such as JEE5/EJB3 or Spring). * Integration with rich middleware frameworks (such as Celtix). * Frameworks for providing service-oriented data access to a variety of existing resources. * Richer tooling support for SOA-based applications, especially in the areas of services composition, monitoring and policy administration. 2. Identify the initial source from which the subprojects are to be populated A group of vendors are developing a set of specifications relating to the design and composition of systems using SOA. In progress versions are available at: * [WWW] http://dev2dev.bea.com/pub/a/2005/11/sca.html * [WWW] http://www.ibm.com/developerworks/library/specification/ws-sca/ * [WWW] http://www.iona.com/devcenter/sca/ * [WWW] http://oracle.com/technology/webservices/sca * [WWW] https://www.sdn.sap.com/ * [WWW] http://www.sybase.com/sca The initial contributors have been developing a Java and C++ code base (already licensed under the Apache License 2.0) which implements aspects of these specifications, and intend to donate it to Apache. A snapshot of this code has been uploaded to JIRA and is is available at: * [WWW] http://issues.apache.org/jira/browse/INCUBATOR-8 Although the Tuscany project expects to bootstrap using these materials and in the case of specifications, to provide feedback that will be incorporated into their ongoing development, we expect the open source community to take the project in new directions not envisioned by them. 3. Identify the ASF resources to be created 3.1 mailing list(s) * tuscany-ppmc * tuscany-dev * tuscany-commits * tuscany-user 3.2 Subversion repository * [WWW] https://svn.apache.org/repos/asf/incubator/tuscany 3.3 Jira * Tuscany (TUSCANY) 4. Identify the initial set of committers: * Jeremy Boynes * Frank Budinsky * Jean-Sebastien Delfino * Mike Edwards * Padmapriya Illindala * Jim Marino * Geir Magnusson Jr. * Eddie O'Neil * Radu Preotiuc-Pietro * Rick Rineholt * Pete Robbins * Michael Rowley * Edward Slattery * Ken Tam * Alexandre Vasseur * Kevin Williams 5. Identify Apache sponsoring individual We request that the Apache Incubator PMC sponsor Tuscany as an incubating project, with the eventual goal of graduation as a TLP. The initial contributors feel the scope of the project doesn't clearly overlap with any existing TLP, and is broad enough to justify eventual TLP status. Champion:Geir Magnusson Jr. Mentors: Sam Ruby Davanum Srinivas (Dims) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (INCUBATOR-8) Incubate Tuscany SOA project
[ http://issues.apache.org/jira/browse/INCUBATOR-8?page=all ] Jeremy Boynes updated INCUBATOR-8: -- Attachment: Tuscany-apache-proposal.tar.gz Example of seed code for Java implementation - actual contribution to be uploaded on acceptance of proposal accompanied by formal software grant Incubate Tuscany SOA project Key: INCUBATOR-8 URL: http://issues.apache.org/jira/browse/INCUBATOR-8 Project: Incubator Type: Wish Reporter: Kenneth Tam Attachments: Tuscany-apache-proposal.tar.gz Placeholder for materials related to Tuscany SOA incubator proposal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubate Tuscany SOA Project
Davanum Srinivas wrote: speaking for myself, we'd be glad to make tuscany part of the WS family. If you wish, we can have a vote on the PMC list. just let us know. thx, dims On 11/30/05, Kenneth Tam [EMAIL PROTECTED] wrote: Hi Noel, (I worked with Jeremy on the proposal, and this seems like a good place to chime in) If by merge, you mean consolidate the projects organizationally, we debated approaching e.g. the WS PMC with this first but decided that it ultimately make more sense to just come to the incubator and have the discussion here. As Ken said, we are very open to becoming part of the WS family especially given the substantial role WS plays in SOA. If the WS PMC votes to sponsor us I think I can speak for all and say we would welcome it. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question- [PROPOSAL] Incubate Tuscany SOA Project
Changshin Lee wrote: Quick question - Is the project going to be a JBI (JSR 208) implementation? The design of the code we are contributing is intended to support multiple container models. At this time there is an implementation of a very simple Java container but some experiments have been done integrating others, including Spring. There is no reason why we could not integrate a JBI container, perhaps ServiceMix or Celtix. The intention is to allow users to choose the programming model and language most appropriate for their application - we need to be able to do that to support the wide range of existing components that are out there. Basically, while implementating JBI itself is not a primary objective, integrating with an implementation would be an option. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP Clearance Process For Extensions To Existing Apache Code bases
robert burrell donkin wrote: i've done some digging around and think that the software grant applies to a specific, concrete instance of the source. this will typically be examplared by a tarballed source artifact checked into subversion. am i right and is the incubator the right place to check in this artifact (and if so, where)? Another alternative would be to attach the archive to a JIRA/Bugzilla issue associated with the target project. This allows it to be staged before hitting svn. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Graduate Derby as sub-project of Apache DB
Jean T. Anderson wrote: Brian McCallister wrote: On Jul 26, 2005, at 11:21 AM, Jeremy Boynes wrote: So what happens now? :-) Logistical details that come to mind are: * adding Derby committers to the DB PMC - I assume a vote on who to add takes place on the DB PMC list, is this in progess? yes. Cannot comment on the rest =) I'm happy to take care of web site updates on Jeremy's list below. Brian, can we move forward with graduation-related work, such as requesting that infrastructure move derby's svn repo and committer karmas from infrastructure to db? Or are we waiting for some other loop to close first? I believe we are waiting for the conclusion of the vote by the DB PMC. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Derby as sub-project of Apache DB
Niclas Hedhman wrote: Has the Derby project engaged suitable DB PMC members as committers and PPMC members, to enhance oversight and increase cross-pollination ?? (Sorry if this has been mentioned before, but I have not followed the details of Derby.) DB PMC members have been with Derby from the start and have actively been involved in its incubation. Derby has cross pollinated with other Apache projects such as Geronimo and JDO (also under incubation by the DB PMC). THe last time the issue of graduation was raised the primary concern was that the project lacked a diversity of committers having added only one from outside IBM. Since then we have added one independent, three from Sun and continue see a diversity on the dev and user lists that should lead to even more committers in the near future. I believe Derby has demonstrated Apache's community values and is ready to graduate. +1 -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Derby from the incubator
Brian Behlendorf wrote: It's not so much dissonance as an exception. In an incubating project, the developers are usually new to the ASF, and skipped the meritocracy step by virtue of association with the project before it entered Apache (here's the list of committers). Therefore it's reasonable to ask the incubating project to prove that not only can they write code, but they can build an active multi-participant community. If there really is still just one outside committer, then in my opinion the community has not yet passed that test; and rather than coding, those who care about that project should be advocating its existance to others, giving presentations at conferences, getting the middleware projects to support it as a peer to mysql and postgres, that sort of thing - all in the name of getting more outside involvement. The irony here is that there is a steady increase in the size of the user community - both existing Cloudscape users converting over and new users looking for alternatives. This is demonstrated in the traffic on both the dev and user lists. This is actually not limited to incubator projects - we've had issues before with projects whose committership was overwhelmingly from one employer. The issue wasn't the employer corrupting the decisions of the employees so much as the employees communicating privately with each other because they could, leaving out other developers; it also meant they were not incented to reduce the learning curve on the code or document internals, which would have increased outside involvement. The solution there is to slow down the pace of coding and do more community development, and ask why are there so few other developers?. Even if the project is widely, you should ask why are so few users of this software interested in becoming developers?. One factor, I believe, is that this is mature technology that just works. My company embeds Derby in our product offering and, to date, we have not needed any changes from the engine itself and have been able to work with the documentation already provided by the project. We have been involved in peripheral projects - integration between Derby and Geronimo, connector support in TranQL, porting sample applications to it (such as XPetstore), and more. However, all the work there has been in other projects. Similarly we have seen involvement from Sun who were very quick to add Derby support to their appserver and whose people remain as active participants on the lists. Again this meant changes in their product and they did not need anything new from the project. As usage increases we are seeing requests for new features and bugfixes and are seeing more people step up to develop them. This will lead to the increase in the committer base. If you look at the community now, we do not see the warning signs Brian mentions above. The committers are acting independently, they just happen to work for the same employer. That remains the main concern of the IPMC and the project needs to work to address it. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Derby from the incubator
Brian McCallister wrote: Derby depends on nothing else at Apache (except ant for its build), and is depended on by nothing else at Apache. Let's not forget that the Derby codebase extends back to the dim dark distant days of the 1990's before many of the ASF's Java projects even existed. Moreover the project needs to limit the number of external dependencies so that it remains easy to embed, which is still a design goal. As for use by other projects, most are database agnostic and can use Derby through the JDBC API. We use it in Geronimo to provide database services to applications and may extend that to internal data at some point. Craig has said JDO is using it and I believe Torque now supports Derby data bindongs as well. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby page updated
The changes to the Derby page have made it. Thanks everyone. -- Jeremy Garrett Rooney wrote: Otis Gospodnetic wrote: How long ago did you do that? svn up used to work a week or so ago. This was on March 26th. svn up should still work, it'll just take up to 4 hours before that data is synced over to ajax, the machine currently serving up the apache.org sites. If it's not getting synced over within 4 hours or so you should mention it to infrastructure@ and have someone look into it. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is graduation subject to veto?
Noel J. Bergman wrote: Roy T. Fielding wrote: Er, just a vote -- there is no veto for this type of decision. Actually, althought it has never been necessary to address so far, I do recall discussion of a -1 veto option graduation. Yes, it is a policy decision, but it effects importing code under the auspices of the Foundation, and it isn't unreasonable to have a higher bar. There are some graduation criteria, such as licensing or IP issues, that are clearly objective and for those a veto option would be appropriate. I would trust, though, that we would never obtain concensus should any such issue exist. Other criteria, for example the diversity of the community, are more subjective. Simple consensus seems more appropriate. Citing the recent Derby discussion, Roy voted against with clear issues that have been resolved; however, the issue with community is far muddier. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Derby from the incubator
Noel J. Bergman wrote: Actually, I agree with you, and others have expressed the same concern, although without casting a vote. Adding new Committers is probably the #1 issue facing the Derby project, which has otherwise performed excellently to date. As even Jeremy pointed out, were IBM to withdraw (however unlikely) from Derby, it would be a serious blow. I also pointed out that there is a scale of impact. Derby is not alone in this; picking on no-one in particular, Logging would also be impacted if Ceki withdrew. Likelihood and community reaction are factors that should be considered. I have great respect for everyone involved in the Derby project, but I don't believe that special consideration should be given. That is a slipperly slope, which would cause other projects to either ask for the same special consideration or cry foul about favoritism. I don't believe Derby is seeking, or even wants, special consideration - just a realistic evaluation of the situation. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Derby from the incubator
Jim Jagielski wrote: I vote -0. Ideally, a more diverse group of contributors would alleviate concerns, or at least some plan of action, post-graduation, which would address those concerns. There is a plan in place to do this which would continue after graduation. There are currently several people working on contributions including Shreyas Kaushik, Tomohito Nakayama, Bernd Ruehlicke, Mamta Satoor, and others. Hopefully one or more will become committers soon, but I think it would be irresponsible to rush such a vote simply to aid graduation. We are in the process of adding items to the project todo list that are less tied to the internals making it easier for people to find areas where they can start to contribute to the project. There are several people, including Brian and Geir, eager to get their hands on something. I think this bodes well for diversity in the longer term. Finally, IBM has clearly demonstrated that they are willing to let their people work on features/fixes as determined by the project. For example, there have been several changes already that break compatibility with DB2 and people have been very forthcoming with information on how Cloudscape was changed to become DB2 like and how those changes can be undone if desired; that information would have been hard to find just from the code alone. So although most committers do work for one company, there is a demonstrated diversity of behaviour that should be considered. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Derby page updated
I updated the page and was waiting for site regeneration but thought I would give it a go. With the infrastructure changes is minotaur still the right host to use? -- Jeremy Original Message Subject: Re: [VOTE] Graduate Derby from the incubator Date: Mon, 28 Mar 2005 21:13:26 -0800 From: Jeremy Boynes [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Roy T.Fielding wrote: The incubator site uses Forrest, not Maven; most people just edit the content under site-author and let someone else generate the real site. True to form, I updated the content, added the project specific goals and am leaving for someone else to generate the real site. Please let me know if there are other areas that need to be addressed. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby page updated
David Crossley wrote: Garrett Rooney wrote: I believe a 'svn up' needs to be run by someone on minutaur (perhaps in /www/incubator.apache.org?), then you need to wait for the sync job to copy the results over to the current web server (ajax?). Thanks for clarifying. I just did that 'svn up' so now we need to wait for the rsync to ajax. This quarter's report to the board for Infrastucture shows that the rsync happens every 4 hours. Thank you both. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Prepping for Derby graduation vote
As that one committer I am also comfortable discussing this. The user community is growing continuously and is very diverse. The developer community, while not as diverse as we would like, has demonstrated that it is following its charter (found at http://incubator.apache.org/derby/ ), is operating independently of the main employer, and is following Apache guidelines and method. The committers have already committed (sorry) to growing the developer base and have discussed approaches that will encourage that. I would be willing to commit to the I-PMC and/or DB-PMC that we will continue that process after leaving the incubator. I would also point out that the number of database-internals wonks with the time or even the contractual ability to work on an open source database project is limited; for example, anyone with hard-core SQL query optimization experience is probably employed by a vendor somewhere. To overcome this, we are reexamining the roadmap so that there is less focus on database internals and more on integration and management. How this plays out will depend on the user community and what they want to see implemented, and the diversity there can only help. There are several people actively contributing already and I expect to see more as time goes on. I do not think that the Derby community is ready at this time to become a TLP. However, I do believe we should discuss leaving the incubator heading for the DB project. -- Jeremy Brian McCallister wrote: DB PMC Hat On: I'm quite comfortable discussing this. One committer has been added while in incubation, and there are a couple more people under consideration. The user and developer community has grown, even if the committer distribution is worrisome. Very much worth talking about, though! -Brian On Mar 15, 2005, at 7:09 PM, Rodent of Unusual Size wrote: Considering the recent discussion about diverse communities and such, this may appear ill-timed. However.. I'd like to open the discussion about Derby graduating from the incubator. The project has accomplished all of its stated goals save for the acquisition of several additional committers. I attest that the project is being operated according to the Apache guidelines and method, and that the community has adopted them and taken them to heart. Since Derby isn't heading for a TLP position (unless someone wants to open that particular ball for some reason), I think they've demonstrated the viability and sustainability. I would support its graduation IFF the DB project took on, as a specific priority, building the developer base. (I.e., taking an active role in the project and not just accepting Derby and letting it continue as it has.) Does anyone think this discussion is premature? -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where, oh where has my Agila gone ? Where, oh where ...
Joey Smith wrote: Sorry if you've already answered this, but how, exactly, do we subscribe to these lists? send an email to [EMAIL PROTECTED] and acknowledge the reply - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is HSQLDB compatible with ASF license?
Clinton Begin wrote: Hi all, I love Derby, but for unit testing it's just too slow. We used to use HSQLDB before iBATIS joined ASF, but I switched to Derby it because I wasn't sure if HSQLDB was compatible with the ASF license. Thoughts? Axion? http://incubator.apache.org/projects/axion.html -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is HSQLDB compatible with ASF license?
Clinton Begin wrote: Hmmm... I'm a bit worried about the status of Axion. It's last update was well over a year ago and has no status updates at all. So is this an implicit no, HSQLDB is not compatible? Not meant that way - just offering an alternative. IIRC hsqldb is BSD licensed which I believe would be compatible given suitable entries in a NOTICE file. http://cvs.sourceforge.net/viewcvs.py/hsqldb/hsqldb/doc/hsqldb_lic.txt?rev=1.1view=auto -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JDO] Project Name
Niclas Hedhman wrote: On Wednesday 08 December 2004 21:29, Brian McCallister wrote: As there are no JDO lists (yet, just asked for them), I'll bring one concern I have up here, which is the name. Apache Jay Dee Objects is really cool: Let me think of Jack Daniels :o) Apache Jade ? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Agila] assigning tasks to groups of users
[EMAIL PROTECTED] wrote: On 8 Nov 2004, at 18:53, Jeremy Boynes wrote: I think we may be in violent agreement here :-) I think we should add some type of collective entity, I just hesitate to call it a Group as that tends to be associated with a specific model ( a relatively static set of users and other groups). Call it Assignee or something and allow for more dynamic models :-) Cool; I'll submit a patch. Assignee sounds a bit vague; how about Workgroup, Role or Team? That kind of leaves out the poor old individual user but I agree Assignee is a weak name - better than ThingToAssignTheTaskTo I guess although that could be refactored later :-) Given those, Role would be my choice although that tends to get overloaded as well. I have seen Role used by a few different business communities so it may fit their world view well. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Agila] assigning tasks to groups of users
[EMAIL PROTECTED] wrote:
On 8 Nov 2004, at 15:58, Jeremy Boynes wrote:
[EMAIL PROTECTED] wrote:
Its very common with people workflow to assign a task to a group of
users (or a role) rather than assigning it to a specific individual
user. Then a user sees a list of all available tasks they could
perform - they then grab one ('locking it') and then execute the task
or releasing it back into the pool if they don't want to complete the
task.
Right now Agila uses a single UserID for assigning tasks. Unless I'm
missing something, it looks like Agila needs some kind of 'role' or
'group' entity so that users can grab tasks rather than a workflow
just assigning it directly to them. Or am I missing something subtle
here?
I think there was a design trade off here around how that list of
users would be determined.
One option is that when task is being generated, the actor resolution
process pre-calculates the list of users and assigns tasks to all of
them. When one of them completes their task, then all other
assignments are marked 'already-completed-by-another-user'. This means
the expansion process, which can be very expensive, is only done once.
It also means that there is a permanent audit trail of all tasks that
have been assigned to a user, whether they were the one who did them
or not. The downside, of course, is that a lot of assignments may be
generated and not used.
Agreed.
Its often better to just assign a task to a group and then let a user
grab a task - again the same audit trail can be kept, but it can result
in just 2 simple database operations rather than lots for large groups.
In these situations the resulting number of users is often small making
for a very manageable set. The set is also defined by some correlation
id associated with the activity and so can be handled by two simple
database operations.
The other option is to assign the task to a group deferring expansion
until a task list is displayed. The set of tasks returned is then
calculated based on the union of all groups to which the user belongs.
If there are more views of the list than there are assignments then
this may be a more expensive solution.
Agreed - though its the more common approach on all the systems I've
worked on in the past. e.g. folks often want to search the available
tasks by role/group.
Typically a users group membership is not that great (only a few groups)
and the groups in which a user belongs does not change that often, so
its common to be able to cache this around for a while, so the query of
all tasks for 1..N groups is usually pretty cheap.
Funny - I have seen systems collapse under such load even with caching
(the cost of a cache miss was too high when dealing with hundreds of
thousands of users).
The audit trail is also more expensive as you have to record the list
of tasks that was calculated from the group membership expansion.
I don't quite follow. So long as you've an audit trail of tasks to
groups and users to groups, you're OK right?
You have to generate audit events for the tasks that were displayed as a
result of the expansion. In the pre-calculated one you have specific
unique task-ids that can be logged. In the dynamic one you have to be
able to reconstruct the user/group hierarchy as it was at the time of
display. This involves an effective dating mechanism for users/groups
(which you would probably have anyway) plus way of making that data
available to the auditor.
In certain business scenarios (especially HR, Finance or Health) the
group membership rules can be quite complex. For example, something
simple sounding like get approval for my expense report could
involve calculations to determine which managers have approval
authority based on the employee, the value of the report, the date of
the report, who default approvers (such as HR) are, and so forth.
That sounds more like an approval workflow rather than just a group of
users. i.e. if it requires complex logic to figure out what a group is,
then its more about a step in the workflow chooses which users should
get what tasks.
It depends on how you view actor resolution. Yes, the rules for it can
be scripted by an analyst in the workflow itself (or in a reusable
sub-flow). Alternatively they can be managed by more specialized systems
such as a rules engine. Yes, you can have an activity encapsulate such
an agent, but I was trying to avoid having to write low-level iteration
code (e.g. to loop over a number of assignees) in the workflow model
itself - it just doesn't fir with what I see an analyst doing.
The group feature I'm more keen on is where you have groups of people
doing similar roles who compete for tasks, taking tasks and completing
them while avoiding dual work.
This is certainly one model. Another is what I was describing as the
call-center model where work is more directed - it is the software that
determines what task to perform next and people often have
Re: Checking in Software Granted Code to Jetspeed CVS
Noel J. Bergman wrote: David Sean Taylor wrote: Attached is the filled form that you sent me on June 26. Thank you. :-) Sorry for the delay. I have checked in the form and your instance of it, as you can see from CVS. When we rebuild the site, they will appear on the website as well. I take it from the form that you are aware of work-for-hire issues, and have either verified that you do not need for Gluecode to submit a Corporate CLA or are in the process of having one submitted. We have already submitted a Software Grant for this work; Geir has soft and hard copies. A more general CCLA is in process. -- Jeremy CTO, Gluecode Software Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[STATUS] Apache Geronimo Project
Status report from the Geronimo PPMC * The project status file (/home/cvs/incubator-geronimo/STATUS) is up to date. * Geir Magnusson is preparing a response to the JBoss letter for approval by the ASF Board. It concludes that there is no validity to the claims. * Legal arrangements have been made to provide non-Members with access to the J2EE TCK. Certification testing will be starting imminently. * No response has been received from Sun on the use of J2EE Schema documents and hence the project will keep these in its CVS as other projects do. If the matter is raised by Sun then they will be removed immediately. * All code in the project has been converted to ASL 2.0 * Jacek Laskowski has been added as a committer Within the next period (3 months) we expect to: o Exit the incubator o Release alpha and beta versions o Progress with J2EE certification testing -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Status Report for Geronimo
Apologies for the last minute update. Status report for the Incubator Geronimo Project * is the STATUS file up to date? (also post link) Yes /home/cvs/incubator/site/projects/geronimo.cwiki * any legal, cross-project or personal issues that still need to be addressed? A serious legal issue was raised by JBoss Group LLC in a letter dated 10/31/2003. This issue has been thoroughly investigated and the conclusion of the community is that the issues raised in the letter are unfounded. A question has arisen whether it is permissible to include XML Schema documents for J2EE deployment descriptors in CVS. We have raised the issue with Sun and are awaiting a response. * what has been done for incubation since the last report? The establishment of a PPMC has aided the organization of the project. Added Gianny D'Amour as committer. The community voted to keep the name Geronimo The ASF has become a J2EE licensee, allowing us to start the certification process. * plans and expectations for the next period? To start testing with the J2EE TCK. To work with the Incubator PMC to provide an interim release allowing people to use Geronimo without building from source making it available to a larger community. To address any remaining issues before applying to leave the Incubator. * any recommendations for how incubation could run more smoothly for you? The establishment of the PPMC has been a great help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
