from:"Geir Magnusson Jr ."

If they are only used during the build process, then don't re-distribute
and therefore this issue then seems out of the critical path for 1.1.1
and can be solved for 1.1.1.1.1.1.1.1.1

gier


Matt Hogstrom wrote:
 They are used by XMLBeans during the build process.  I guess we could do
 a one-time generation of the XMLBeans classes but I'd be more
 comfortable with Jencks' input.  If you don't have the schemas you'd
 have to have network connectivity to build I suspect.
 
 Aaron Mulder wrote:
 Can't we just ship without those?  We have pointers to them on our web
 site at http://geronimo.apache.org/schemas.html -- is there any
 additional reason we need them at runtime (e.g. does XMLBeans use the
 actual schema to validate at runtime)?

 Thanks,
 Aaron

 On 8/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
 All,

 For those wondering where the Geronimo 1.1.1 release is at here is a
 quick summary and battle plan.

 John Sisson discovered that we have several DTD and XSDs included in
 our build that are copies of
 Sun's original material.  The copyright in the material seems to
 indicate that we cannot
 redistribute the content.  Unfortunately, as Geir has pointed out,
 that there is no clear way to
 interpret the license and we should manually generate these to stay
 legal and avoid any appearance
 of impropriety.

 The documents in question reside in both the distribution of the
 source as well as the server
 itself.  It appears that other open source and commercial vendors do
 distribute these documents in
 their original form but the ASF does not have a clear indication that
 we can follow this same
 practice.  You can find the documents in
 $G_BUILD_TREE/modules/j2ee-schema/src/* as well as the
 distributions in $G_DIST/schema/* directories.

 The documents are identified in JIRA
 http://issues.apache.org/jira/browse/GERONIMO-2307.

 I'd like to ask anyone that has some spare moments to help out with
 putting these together.
 Basically, you need to refer to the appropriate specification and
 type in the XML exactly like it is
 represented for actual elements and either omit or paraphrase the
 information embedded in comments
 so we do not violate Sun's copyright.

 I know this is frustrating but for their own reasons Sun has imposed
 this unfriendly copyright and
 we need to abide by it.  We are protecting The ASF, Geronimo and our
 users.

 If you are working on a document please update the above JIRA to
 indicate it is partial so others
 can see what remains.  Please check the new schemas into their
 respective replacements.  When the
 replacements are complete we'll build a new distribution and run it
 through a full CTS test to
 validate our work.

 Please also consider working with a partner so you can cross check
 each other's work.

 Thanks in advance for your patience and help with this important issue.

 Also, if others have input into the process that I have missed please
 provide it as well.

 Thanks to John and Geir for discovering and mediating on this issue.

Re: 1.1.1 Status - XSD and DTD issues



Matt Hogstrom wrote:
 Well, the problem is that we distribute the source code for Geronimo out
 of SVN and these would end up being included.  I think that falls into
 the category of redistribution.  Hopefully I'm wrong on that count :)

Right, so why not just take them out of SVN?  I guess it would mean that
you could only build when online, but as we're just trying to find a
simple solution to get 1.1.1 out, I figure that we can do that and
resolve the fundamental issue this creates later.

geir

 
 The remaining question is what about the previous releases?  I would
 expect we're ok going forward and we leave what's out there.  If not I
 think Geronimo, Tomcat and others all have an issue.  Not sure about the
 other projects though.
 
 Geir Magnusson Jr wrote:
 If they are only used during the build process, then don't re-distribute
 and therefore this issue then seems out of the critical path for 1.1.1
 and can be solved for 1.1.1.1.1.1.1.1.1

 gier


 Matt Hogstrom wrote:
 They are used by XMLBeans during the build process.  I guess we could do
 a one-time generation of the XMLBeans classes but I'd be more
 comfortable with Jencks' input.  If you don't have the schemas you'd
 have to have network connectivity to build I suspect.

 Aaron Mulder wrote:
 Can't we just ship without those?  We have pointers to them on our web
 site at http://geronimo.apache.org/schemas.html -- is there any
 additional reason we need them at runtime (e.g. does XMLBeans use the
 actual schema to validate at runtime)?

 Thanks,
 Aaron

 On 8/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
 All,

 For those wondering where the Geronimo 1.1.1 release is at here is a
 quick summary and battle plan.

 John Sisson discovered that we have several DTD and XSDs included in
 our build that are copies of
 Sun's original material.  The copyright in the material seems to
 indicate that we cannot
 redistribute the content.  Unfortunately, as Geir has pointed out,
 that there is no clear way to
 interpret the license and we should manually generate these to stay
 legal and avoid any appearance
 of impropriety.

 The documents in question reside in both the distribution of the
 source as well as the server
 itself.  It appears that other open source and commercial vendors do
 distribute these documents in
 their original form but the ASF does not have a clear indication that
 we can follow this same
 practice.  You can find the documents in
 $G_BUILD_TREE/modules/j2ee-schema/src/* as well as the
 distributions in $G_DIST/schema/* directories.

 The documents are identified in JIRA
 http://issues.apache.org/jira/browse/GERONIMO-2307.

 I'd like to ask anyone that has some spare moments to help out with
 putting these together.
 Basically, you need to refer to the appropriate specification and
 type in the XML exactly like it is
 represented for actual elements and either omit or paraphrase the
 information embedded in comments
 so we do not violate Sun's copyright.

 I know this is frustrating but for their own reasons Sun has imposed
 this unfriendly copyright and
 we need to abide by it.  We are protecting The ASF, Geronimo and our
 users.

 If you are working on a document please update the above JIRA to
 indicate it is partial so others
 can see what remains.  Please check the new schemas into their
 respective replacements.  When the
 replacements are complete we'll build a new distribution and run it
 through a full CTS test to
 validate our work.

 Please also consider working with a partner so you can cross check
 each other's work.

 Thanks in advance for your patience and help with this important
 issue.

 Also, if others have input into the process that I have missed please
 provide it as well.

 Thanks to John and Geir for discovering and mediating on this issue.

Re: 1.1.1 Status - XSD and DTD issues



Matt Hogstrom wrote:
 Heads up...we're using IRC for real-time collaboration on this and will
 post updates to the dev list.  IRC is at irc.freenode.net channel
 #geronimo.

I won't be able to be there.

geir

 
 Right now I'm removing ./modules/j2ee-schema/src/resources/* and
 building to see if these DTDs are required for building in some odd
 way.  Don't work on these just yet.
 
 Matt Hogstrom wrote:
 All,

 For those wondering where the Geronimo 1.1.1 release is at here is a
 quick summary and battle plan.

 John Sisson discovered that we have several DTD and XSDs included in
 our build that are copies of Sun's original material.  The copyright
 in the material seems to indicate that we cannot redistribute the
 content.  Unfortunately, as Geir has pointed out, that there is no
 clear way to interpret the license and we should manually generate
 these to stay legal and avoid any appearance of impropriety.

 The documents in question reside in both the distribution of the
 source as well as the server itself.  It appears that other open
 source and commercial vendors do distribute these documents in their
 original form but the ASF does not have a clear indication that we can
 follow this same practice.  You can find the documents in
 $G_BUILD_TREE/modules/j2ee-schema/src/* as well as the distributions
 in $G_DIST/schema/* directories.

 The documents are identified in JIRA
 http://issues.apache.org/jira/browse/GERONIMO-2307.

 I'd like to ask anyone that has some spare moments to help out with
 putting these together. Basically, you need to refer to the
 appropriate specification and type in the XML exactly like it is
 represented for actual elements and either omit or paraphrase the
 information embedded in comments so we do not violate Sun's copyright.

 I know this is frustrating but for their own reasons Sun has imposed
 this unfriendly copyright and we need to abide by it.  We are
 protecting The ASF, Geronimo and our users.

 If you are working on a document please update the above JIRA to
 indicate it is partial so others can see what remains.  Please check
 the new schemas into their respective replacements.  When the
 replacements are complete we'll build a new distribution and run it
 through a full CTS test to validate our work.

 Please also consider working with a partner so you can cross check
 each other's work.

 Thanks in advance for your patience and help with this important issue.

 Also, if others have input into the process that I have missed please
 provide it as well.

 Thanks to John and Geir for discovering and mediating on this issue.

Re: 1.1.1 Status - XSD and DTD issues

+1

Exactly.  Maybe put a note somewhere saying what schemas were used and
where a user can find them.

geir

David Blevins wrote:
 I personally don't know why we bother to regenerate that tree on every
 build as those schemas are not going to change.  Let's just build them
 once, publish the jars, delete the schemas and be done with it.
 
 -David
 
 On Aug 18, 2006, at 9:45 AM, David Jencks wrote:
 

 On Aug 18, 2006, at 9:22 AM, Geir Magnusson Jr wrote:

 If they are only used during the build process, then don't re-distribute
 and therefore this issue then seems out of the critical path for 1.1.1
 and can be solved for 1.1.1.1.1.1.1.1.1

 They are not needed at runtime, but xmlbeans packs the source schemas
 into the jar with its other binary artifacts.  We might be able to
 prevent their inclusion into our jars, but I don't see how having them
 in svn is not redistribution, so I think we need allowable copies of
 the j2ee 1.4 schemas in our svn.

 thanks
 david jencks

 gier


 Matt Hogstrom wrote:
 They are used by XMLBeans during the build process.  I guess we
 could do
 a one-time generation of the XMLBeans classes but I'd be more
 comfortable with Jencks' input.  If you don't have the schemas you'd
 have to have network connectivity to build I suspect.

 Aaron Mulder wrote:
 Can't we just ship without those?  We have pointers to them on our web
 site at http://geronimo.apache.org/schemas.html -- is there any
 additional reason we need them at runtime (e.g. does XMLBeans use the
 actual schema to validate at runtime)?

 Thanks,
 Aaron

 On 8/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
 All,

 For those wondering where the Geronimo 1.1.1 release is at here is a
 quick summary and battle plan.

 John Sisson discovered that we have several DTD and XSDs included in
 our build that are copies of
 Sun's original material.  The copyright in the material seems to
 indicate that we cannot
 redistribute the content.  Unfortunately, as Geir has pointed out,
 that there is no clear way to
 interpret the license and we should manually generate these to stay
 legal and avoid any appearance
 of impropriety.

 The documents in question reside in both the distribution of the
 source as well as the server
 itself.  It appears that other open source and commercial vendors do
 distribute these documents in
 their original form but the ASF does not have a clear indication that
 we can follow this same
 practice.  You can find the documents in
 $G_BUILD_TREE/modules/j2ee-schema/src/* as well as the
 distributions in $G_DIST/schema/* directories.

 The documents are identified in JIRA
 http://issues.apache.org/jira/browse/GERONIMO-2307.

 I'd like to ask anyone that has some spare moments to help out with
 putting these together.
 Basically, you need to refer to the appropriate specification and
 type in the XML exactly like it is
 represented for actual elements and either omit or paraphrase the
 information embedded in comments
 so we do not violate Sun's copyright.

 I know this is frustrating but for their own reasons Sun has imposed
 this unfriendly copyright and
 we need to abide by it.  We are protecting The ASF, Geronimo and our
 users.

 If you are working on a document please update the above JIRA to
 indicate it is partial so others
 can see what remains.  Please check the new schemas into their
 respective replacements.  When the
 replacements are complete we'll build a new distribution and run it
 through a full CTS test to
 validate our work.

 Please also consider working with a partner so you can cross check
 each other's work.

 Thanks in advance for your patience and help with this important
 issue.

 Also, if others have input into the process that I have missed please
 provide it as well.

 Thanks to John and Geir for discovering and mediating on this issue.

Re: 1.1.1 Status - XSD and DTD issues



Dain Sundstrom wrote:
 On Aug 18, 2006, at 10:01 AM, Geir Magnusson Jr wrote:
 
 Matt Hogstrom wrote:
 Well, the problem is that we distribute the source code for Geronimo out
 of SVN and these would end up being included.  I think that falls into
 the category of redistribution.  Hopefully I'm wrong on that count :)

 Right, so why not just take them out of SVN?  I guess it would mean that
 you could only build when online, but as we're just trying to find a
 simple solution to get 1.1.1 out, I figure that we can do that and
 resolve the fundamental issue this creates later.
 
 As a service to our users, we can simply include a download.[jar|sh|bat]
 in the schema directory that downloads the schemas from sun's website. 
 To protect ourselves from sun's site reorganizations and propensity
 update the schemes, we can first download the list of schemas from
 geronimo.apache.org site.
 
 WDYT?

I think that's a good idea, especially as a quick fix for the problem.

I do wonder how easy it would be to make a set for ourselves.  This
problem is going to repeat itself w/ Java EE 5 and EE 6 (if there is
one).   I've asked that these be distributed in future versions under a
license that works for us - it turns out CDDL doesn't appear to because
it's source (of a sort...) -  I suggested public domain.

Re: 1.1.1 Status - XSD and DTD issues

Might there be a tool that could take the schema jar and produce xsd's
from it's contents?

:D

geir


David Jencks wrote:
 I've uploaded a preliminary version of the proposed schema jar at
 
 people.apache.org/~djencks/geronimo-schema_1.4_spec-1.0-SNAPSHOT.jar
 
 We should be able to remove all the schemas and xmlbeans stuff from
 j2ee-schema module and instead have a geronimo-dependency.xml element to
 pull in the above jar.
 
 In m1 these geronimo-dependency.xml files are generated by our
 dependency plugin, but for m2 you have to write it yourself and put it
 in src/resources2/META-INF/geronimo-dependency.xml
 
 I have some more work to do on the proposed new module to put the
 xmlbeans stuff in a separate profile so the source is not generated each
 time it's run.  I'll open a jira with the new module when I get it
 working better.  I assume this has to go through RTC maybe it can be
 kind of quick since we are basically just changing where we build and
 compile the exact same classes as before.
 
 thanks
 david jencks
 
 
 On Aug 18, 2006, at 10:46 AM, David Jencks wrote:
 

 On Aug 18, 2006, at 10:36 AM, David Blevins wrote:

 I personally don't know why we bother to regenerate that tree on
 every build as those schemas are not going to change.  Let's just
 build them once, publish the jars, delete the schemas and be done
 with it.

 I think this will minimize our legal exposure.  I'll work on a specs
 module for this.  I might need some m2 help, my plan is to use a
 profile so that  using the profile we compile the schemas using
 xmlbeans, letting xmlbeans download the schemas direct from sun, and
 having xmlbeans put the results in appropriate places in src.  We can
 then check the results in by hand.  The normal build can simply
 compile these generated sources.

 We may need another step to put apache headers on the generated code. 
 Some of the generated stuff is binary files, which AFAIK cannot be
 modified to include a header.  I'll probably need help with this part.

 Is everyone OK with putting this into specs?  Any ideas for a better
 place?

 thanks
 david jencks


 -David

 On Aug 18, 2006, at 9:45 AM, David Jencks wrote:


 On Aug 18, 2006, at 9:22 AM, Geir Magnusson Jr wrote:

 If they are only used during the build process, then don't
 re-distribute
 and therefore this issue then seems out of the critical path for 1.1.1
 and can be solved for 1.1.1.1.1.1.1.1.1

 They are not needed at runtime, but xmlbeans packs the source
 schemas into the jar with its other binary artifacts.  We might be
 able to prevent their inclusion into our jars, but I don't see how
 having them in svn is not redistribution, so I think we need
 allowable copies of the j2ee 1.4 schemas in our svn.

 thanks
 david jencks

 gier


 Matt Hogstrom wrote:
 They are used by XMLBeans during the build process.  I guess we
 could do
 a one-time generation of the XMLBeans classes but I'd be more
 comfortable with Jencks' input.  If you don't have the schemas you'd
 have to have network connectivity to build I suspect.

 Aaron Mulder wrote:
 Can't we just ship without those?  We have pointers to them on
 our web
 site at http://geronimo.apache.org/schemas.html -- is there any
 additional reason we need them at runtime (e.g. does XMLBeans use
 the
 actual schema to validate at runtime)?

 Thanks,
 Aaron

 On 8/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
 All,

 For those wondering where the Geronimo 1.1.1 release is at here
 is a
 quick summary and battle plan.

 John Sisson discovered that we have several DTD and XSDs
 included in
 our build that are copies of
 Sun's original material.  The copyright in the material seems to
 indicate that we cannot
 redistribute the content.  Unfortunately, as Geir has pointed out,
 that there is no clear way to
 interpret the license and we should manually generate these to stay
 legal and avoid any appearance
 of impropriety.

 The documents in question reside in both the distribution of the
 source as well as the server
 itself.  It appears that other open source and commercial
 vendors do
 distribute these documents in
 their original form but the ASF does not have a clear indication
 that
 we can follow this same
 practice.  You can find the documents in
 $G_BUILD_TREE/modules/j2ee-schema/src/* as well as the
 distributions in $G_DIST/schema/* directories.

 The documents are identified in JIRA
 http://issues.apache.org/jira/browse/GERONIMO-2307.

 I'd like to ask anyone that has some spare moments to help out with
 putting these together.
 Basically, you need to refer to the appropriate specification and
 type in the XML exactly like it is
 represented for actual elements and either omit or paraphrase the
 information embedded in comments
 so we do not violate Sun's copyright.

 I know this is frustrating but for their own reasons Sun has
 imposed
 this unfriendly copyright and
 we need to abide by it.  We are protecting The ASF, Geronimo and
 our
 users.

 If you

[jira] Commented: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed

2006-08-17 Thread Geir Magnusson Jr (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2307?page=comments#action_12428791
 ] 

Geir Magnusson Jr commented on GERONIMO-2307:
-

following a voice discussion, I've asked formally for Sun to 

a) confirm no problem with typing the schemas in oursleves, and putting in SVN 
and distributions under the Apache license.

b) grant persmission to take their schemas, strip any value add information 
that isn't required for functional or conformance reasons, (such as 
xsd:documentation), put under Apache license, and into SVN and distributions 
- just save us the typing.



 Include appropriate license for the Sun j2ee schema files that are 
 redistributed
 

 Key: GERONIMO-2307
 URL: http://issues.apache.org/jira/browse/GERONIMO-2307
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: buildsystem
Affects Versions: 1.0, 1.1
Reporter: John Sisson
 Assigned To: Geir Magnusson Jr
Priority: Blocker
 Fix For: 1.1.1


 Geronimo redistributes the Sun J2EE schema files for deployment descriptors 
 etc but doesn't appear to include anything in the global license file about 
 it.  
 The following two statement in the copyright text in the schema files  (e.g. 
 http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me:
 * This document and the technology which it describes are distributed under 
 licenses restricting their use, copying, distribution, and decompilation. 
 * No part of this document may be reproduced in any form by any means without 
 prior written authorization of Sun and its licensors, if any.
 Considering the first point, we need to determine what license the files are 
 under.  Seems we need written authorization for the second point.
 The concern regarding copyrights for the schemas came to mind whilst testing 
 the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun 
 license at http://developers.sun.com/license/berkeley_license.html when 
 caching the j2ee schema files (e.g. 
 http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ).
 I can't find anything to confirm that the berkeley license displayed by 
 eclipse is the correct license for the schemas.

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

[jira] Commented: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed

2006-08-17 Thread Geir Magnusson Jr (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2307?page=comments#action_12428806
 ] 

Geir Magnusson Jr commented on GERONIMO-2307:
-

Clearly the documents as is are not appropriate for redistribution, as they say 
no redistribution.

Sun will not allow us to take their documents and snip out their value-add to 
save the typing.

So we should just create these fresh from the spec.

geir


 Include appropriate license for the Sun j2ee schema files that are 
 redistributed
 

 Key: GERONIMO-2307
 URL: http://issues.apache.org/jira/browse/GERONIMO-2307
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: buildsystem
Affects Versions: 1.0, 1.1
Reporter: John Sisson
 Assigned To: Geir Magnusson Jr
Priority: Blocker
 Fix For: 1.1.1


 Geronimo redistributes the Sun J2EE schema files for deployment descriptors 
 etc but doesn't appear to include anything in the global license file about 
 it.  
 The following two statement in the copyright text in the schema files  (e.g. 
 http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me:
 * This document and the technology which it describes are distributed under 
 licenses restricting their use, copying, distribution, and decompilation. 
 * No part of this document may be reproduced in any form by any means without 
 prior written authorization of Sun and its licensors, if any.
 Considering the first point, we need to determine what license the files are 
 under.  Seems we need written authorization for the second point.
 The concern regarding copyrights for the schemas came to mind whilst testing 
 the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun 
 license at http://developers.sun.com/license/berkeley_license.html when 
 caching the j2ee schema files (e.g. 
 http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ).
 I can't find anything to confirm that the berkeley license displayed by 
 eclipse is the correct license for the schemas.

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

Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC

2006-08-14 Thread Geir Magnusson Jr

welcome

Matt Hogstrom wrote:
 The Apache Geronimo PMC would like to let everyone know that Alan
 Cabrera has accepted the invitation to join the Geronimo PMC.  We are
 excited to have Alan assisting with project oversight in addition to his
 technical contributions to Geronimo.
 
 Alan has been active in Geronimo for many years and has helped not only
 to help in Geronimo directly but in related efforts like Ode, Yoko and
 others.
 
 Give it up for Alan :)
 
 The Apache Geronimo PMC

Re: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)

2006-06-14 Thread Geir Magnusson Jr

I agree with this - we'll fix the default in the next rev.  There have
been some good ideas (including mine, I think) and we'll see how they
work in code.

geir


David Blevins wrote:
 Everyone, please read and ACK.
 
 On Jun 14, 2006, at 4:31 PM, John Sisson wrote:
 
 Hiram, I care if a private or commercial entity has control over the
 default option.
 
 I think Hiram does too, he just a read a little too fast.  His thoughts
 are clear though.
 
 On Jun 14, 2006, at 3:55 PM, Hiram Chirino wrote:
 All I'm saying is I don't care if IBM puts up
 http://www.ibm.com/wasce/plugins, I also don't care if you put up a
 http://virtuas.com/geronimo/plugins site.

 Now the default link issue is something else.  Can we point it by
 default at some Apache machines by default?  I'm sure Aaron would not
 mind, would you?
 
 That pretty much sums it up for me.  Aaron seems to agree.  In fact, is
 there anyone out there who doesn't agree?
 
 -David

Re: A bad idea whose time has come to an end

2006-06-14 Thread Geir Magnusson Jr

+1

Alan D. Cabrera wrote:
 The way the specs are currently organized is way too cumbersome and
 confusing.  I propose that we get rid of the root POM for specs and that
 each spec gets its own branches, tags, and trunk, so that each may be
 released independently on its own.
 
 I think that we should do this post v1.1.
 
 Thoughts?
 
 
 Regards,
 Alan

Re: SVN Karma

2006-06-03 Thread Geir Magnusson Jr

done

Matt Hogstrom wrote:
 Yes, thanks...JIRA
 
 Geir Magnusson Jr wrote:
 Do you mean JIRA?

 Matt Hogstrom wrote:
 Geir,

 Can you grant me SVN Karma to add contributors?  Dain is on vacation.

 Thanks

 Matt

JBI TCK

2006-06-02 Thread Geir Magnusson Jr

We finally have it!  Who wants it? :)

geir

Re: SVN Karma

2006-06-02 Thread Geir Magnusson Jr

Do you mean JIRA?

Matt Hogstrom wrote:
 Geir,
 
 Can you grant me SVN Karma to add contributors?  Dain is on vacation.
 
 Thanks
 
 Matt

Re: Moving on from 1.1

2006-05-22 Thread Geir Magnusson Jr


+1

Seems to need some kind of theme music while you are doing it...

geir

Matt Hogstrom wrote:
I would like to make the following changes to the dev tree for 
Geronimo.  Assuming there is concurrence and no objections I would like to:


 move geronimo/trunk to geronimo/branches/oldtrunk
 copy geronimo/branches/1.1 to geronimo/trunk
 Update trunk to version 1.3.  I think 1.3 is a better choice to avoid 
any confusion over our old 1.2


 I'll plan to do this on Wednesday morning at 0300 PT.

 Other thoughts welcome.

 Matt

Re: Moving on from 1.1

2006-05-22 Thread Geir Magnusson Jr

how about deleteing it and put a note somewhere about the rev number so 
someone can go back and get it if they wish, w/o it being received by 
anyone doing a /branch checkout?


geir

Jacek Laskowski wrote:

On 5/22/06, David Jencks [EMAIL PROTECTED] wrote:


I think this would be kind of misleading.  How about 1.2-dead to
indicate that we don't plan to release it?


Much, much better. +1 for 1.2-dead.


david jencks


Jacek

Re: XBean website up

2006-05-17 Thread Geir Magnusson Jr


What is goopen.org?

James Strachan wrote:

Now we've got the confluence - static html in subversion thing all
squared away I've moved the existing XBean site over to Geronimo

http://geronimo.apache.org/xbean/

which is all auto-generated and checked into svn  updated on apache
from the wiki
http://goopen.org/confluence/display/XB

(you can click on the edit page links on the bottom of a page to edit
the pages in the wiki)

There are some useful pages to help get to grips with how the site is
layed out in terms of pages here
http://geronimo.apache.org/xbean/site.html

If folks wanted we could do the same thing with the confluence wiki
content for the geronimo project too; then it can be hosted as static
html at apache

Re: Contributions based on Copyrighted Material

2006-05-17 Thread Geir Magnusson Jr




[EMAIL PROTECTED] wrote:

Dear Developers,

In response to Hernan's call for documentation contributions, I've started
work on a Getting Started XDoc based on the Geronimo Quick Start section of
Aaron Mulder's online book.  However, it occurs to me that because the
original material is copyrighted, this may not be such a good idea.


Not unless Aaron gives you permission, although you should clarify what 
you mean by based on.




At this point, I'm wondering if I shouldn't just start from scratch with
entirely original content.  Any guidance on this would be greatly
appreciated.


Thanks,
Ian

It's better to be hated for who you are
than loved for who you are not

Ian D. Stewart
Appl Dev Analyst-Advisory, DCS Automation
JPMorganChase Global Technology Infrastructure
Phone: (614) 244-2564
Pager: (888) 260-0078

Re: XBean website up

2006-05-17 Thread Geir Magnusson Jr

Oh.  I thought it was to cover in goop, as that API is really 
invasive - it will goopen your codebase...


geir


David Blevins wrote:

Heh, maybe go is James' new Active

I can see it now... GoMQ, GoIO, GoCluster

-David

On May 17, 2006, at 2:37 PM, Geir Magnusson Jr wrote:


What is goopen.org?

James Strachan wrote:

Now we've got the confluence - static html in subversion thing all
squared away I've moved the existing XBean site over to Geronimo
http://geronimo.apache.org/xbean/
which is all auto-generated and checked into svn  updated on apache
from the wiki
http://goopen.org/confluence/display/XB
(you can click on the edit page links on the bottom of a page to edit
the pages in the wiki)
There are some useful pages to help get to grips with how the site is
layed out in terms of pages here
http://geronimo.apache.org/xbean/site.html
If folks wanted we could do the same thing with the confluence wiki
content for the geronimo project too; then it can be hosted as static
html at apache

[Fwd: Re: Please change Open JPA to OpenJPA]

2006-05-09 Thread Geir Magnusson Jr


ROTFL

 Original Message 
Subject: Re: Please change Open JPA to OpenJPA
Date: Tue, 9 May 2006 11:32:53 -0700
From: Dain Sundstrom [EMAIL PROTECTED]
Reply-To: general@incubator.apache.org
To: general@incubator.apache.org
References: 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] [EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED]


On May 9, 2006, at 2:14 AM, Leo Simons wrote:


Riddle:

What would Mr. SVN say if he was written in java?

/me *ducks* and runs around the corner

LSD


I think he would say Gee what should I work on now, since I totally
finished writing SVN like 2 years ago ;)

-dain

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: Re: Please change Open JPA to OpenJPA]

2006-05-09 Thread Geir Magnusson Jr

ooh - sorry - I didn't mean to crosspost  that was just meant for 
dain... I need ot fix Thunderbird's auto completion db...


Geir Magnusson Jr wrote:

ROTFL

 Original Message 
Subject: Re: Please change Open JPA to OpenJPA
Date: Tue, 9 May 2006 11:32:53 -0700
From: Dain Sundstrom [EMAIL PROTECTED]
Reply-To: general@incubator.apache.org
To: general@incubator.apache.org
References: 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] [EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED]


On May 9, 2006, at 2:14 AM, Leo Simons wrote:


Riddle:

What would Mr. SVN say if he was written in java?

/me *ducks* and runs around the corner

LSD


I think he would say Gee what should I work on now, since I totally
finished writing SVN like 2 years ago ;)

-dain

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: hot deployment directory

2006-05-05 Thread Geir Magnusson Jr




Matt Hogstrom wrote:
As Aaron said we have made significant progress in testing againnst our 
test harnesses but there are lingering issues that need to be 
addressed.  Aaron (aka the JIRA magnet) has identified several usability 
and bug issues.  The first release that we put our is stable (DayTrader 
runs in most modes) but we do need to fix the lingering file lock 
problems, files being left behind on deploy, etc.  If you have some time 
Geir we have lots and lots of JIRAs and could use some warm bodies :)




Heh.  I've ordered more Round Tuits. :)

I was just wondering - I had it in my head that it was inflight for 
release, and was surprised with Aaron's suggestion that more work be 
done in 1.1.


I understand now.  Thanks

geir


Matt

Geir Magnusson Jr wrote:



Aaron Mulder wrote:

Please do any work in the 1.1 branch.  Right now 1.2 is in a very
uncertain state.  Though, I suspect the issues will be different in
1.1, so you may want to start by testing the same things there.

IIRC, the hot deployer does not yet check the timestamp of the
deployments in it its directory during startup and compare those to
the timestamps of the current modules to determine whether an existing
file there is the same as ever or a new version was copied in while
the server was down.  That should be doable in 1.1.


I thought 1.1 was done and in testing in prep for release?

geir

Re: hot deployment directory

2006-05-04 Thread Geir Magnusson Jr




Aaron Mulder wrote:

Please do any work in the 1.1 branch.  Right now 1.2 is in a very
uncertain state.  Though, I suspect the issues will be different in
1.1, so you may want to start by testing the same things there.

IIRC, the hot deployer does not yet check the timestamp of the
deployments in it its directory during startup and compare those to
the timestamps of the current modules to determine whether an existing
file there is the same as ever or a new version was copied in while
the server was down.  That should be doable in 1.1.


I thought 1.1 was done and in testing in prep for release?

geir

Re: JavaOne G BOF?

2006-05-03 Thread Geir Magnusson Jr




Jeff Genender wrote:

Anyone know of any Geronimo BOFs at JavaOne this year?  If not, any
interest on getting one together?



Yes - I asked for a slot late and I think we have it.  More as I know it.

geir


I haven't seen or heard of any from our community here.  I think it
would be great to get everyone together and do some form of BOF to
update everyone of where we are at and where we are going.

Thoughts?  Interest?

Jeff

Re: Geronimo Web site structure update

2006-05-03 Thread Geir Magnusson Jr




Aaron Mulder wrote:

On 5/3/06, Hernan Cunico [EMAIL PROTECTED] wrote:
Most of the documentation was uploaded into a JIRA and granted ASF 
license long time ago. I say most
because the last updates have not been yet uploaded. Once we have 
cwiki.apache.org in production the

license should no longer be an issue.


Are you saying that people can't just edit the Wiki without hosing up
the documentation license?  I guess there's not anywhere in the Wiki
edit process that prompts you to grant copyright to the ASF. 


Copyright is never granted to the ASF.  The ASF only asserts a 
collective copyright on the pile of things in a distribution (of 
whatever sort) that in fact have copyright distributed throughout the 
set of contributors.



 Does
this mean we need Jira issues submitted with all documentation changes
so that we can get the license check ticked?


Well, that would be one way if we had a doco system like that. :)

But since we're using the wiki, I think the simplest thing is to have a 
clear terms of contribution somewhere on the wiki, and maybe a link to 
it at the bottom of each page.


Here is some suggested wording :

This wiki has been created for public contribution of material about 
projects of The Apache Software Foundation (the Foundation), a 
Delaware nonprofit corporation classified as a public charity under 
501(c)(3). All contributions intentionally submitted to the Foundation 
on this wiki is considered a Contribution to the Foundation unless 
otherwise noted in the contribution. The terms and conditions that apply 
to your Contributions are defined by either a contributor license 
agreement (CLA) signed by you and/or your employer or, if no such CLA is 
on file at the Foundation, by the terms and conditions of Contributions 
as defined by the Apache License, Version 2.0.


My 0.02

geir



Thanks,
   Aaron


Matt Hogstrom wrote:


 Hernan Cunico wrote:

 I'll try to keep it short but can't help it, I like to write :)

 Aaron Mulder wrote:

 While I grant that the proposed documentation page is sleeker in
 appearance than the current library page, I prefer not to emphasize
 any one source of documentation over the others.  I am not
 recommending that we make the documentation into the table of 
contents

 for my book, nor that we turn it into the index of DeveloperWorks
 articles pertinent to Geronimo, nor that we simply make it a list of
 Geronimo books available at Amazon or Safari.  Yet all of these are
 probably valuable to people looking to get started with Geronimo.


 Where I am going with this idea is to try to get the things more clear
 around the web site and get more people participating in the
 documentation. I am not claiming as mine the documentation that is in
 Confluence, it is the Apache Geronimo's documentation and we ship an
 HTML version with Geronimo.

 Hernan, I don't intend to be rude, but this is the second time you've
 proposed this.  Can you find a way to construct a nice-looking
 documentation page that equally features all the sources of Geronimo
 documentation, instead of turning it into a list of articles you've
 contributed?  I'll be happy to work with you on this if you need help
 populating topics or highlights or blurbs for the documentation other
 than your own.


 I would like to emphasize that I am not proposing to remove any of the
 current content but rather to add more content.  I think it would be
 more organized to have online books, printed books, interviews, etc.
 listed under Library and the documentation listed under
 Documentation.


 If my understanding is correct you are suggesting that articles and
 documentation where the copyright is owned by someone else be put in 
the

 library and content that is ASF copyrighted be in the documentation
 section.  I think the distinction makes sense.  So in your example
 Hernan all the documentation you've provided is owned by the Geronimo
 project and you have granted the copyright to the ASF? I think the
 distinction makes sense.  I very much would like to see a comprehensive
 set of doc owned by the project as that would really improve a user's
 experience.  So long as we provide a prominent place for other people's
 significant work as well I like this idea.


 This is the Geronimo documentation. I have been nearly begging in
 the mailing lists for more people to contribute to the documentation
 and several people have already contributed.  I (I should say we all)
 could really use your help filling up some of the blanks in the
 current confluence based documentation.

 And on the subject of the Confluence documentation, perhaps we (the
 community, I know this is not entirely in Hernan's control) should
 consider revising the page headers.  Right now they tend to include
 something like:

 Added by Tom Smith, last edited by Tom Smith ... (bold) Article
 donated by: Tom Smith

 I don't think that's actually productive.  To be honest, I think it
 probably discourages contributions.  For

Re: Questions about www.geronimoplugins.com site

2006-05-02 Thread Geir Magnusson Jr




Aaron Mulder wrote:

I have to disagree with putting up an ASF option as the default.

Let's say there are 50 plugins produced by Apache and 70 by outsiders.

We have a choice to make the default a repository containing 50
entries, or a repository containing 120 entries.  What makes sense?


Here's a alternative idea...

How about hosting the directory/metadata of plugins at the ASF (or even 
cooler, do something mirrored to avoid the ire of infra when Geronimo is 
ubiquitous) and just have URLs to the plugin locations...?


Then that drives all plug-in authors to come and register them here - 
just send a message to the mail list to have it included...


Then it doesn't matter - you can list plugins under all licenses 
(including proprietary) - and they are hosted where they are hosted, if 
you know what I mean.  No worries about Apache hosting things that 
aren't from the ASF, etc.


geir

Re: Java One - Who will be there?

2006-05-02 Thread Geir Magnusson Jr


I'll be there

Matt Hogstrom wrote:
Thought I'd start a thread to see which of the committers will be a Java 
One.  I seem to remember seeing a note about getting together to discuss 
where we're at and where we're going  but I don't remember seeing a 
whose who in the zoo list.  If your going to JavaOne could you reply 
back to this note?


Matt

Re: Questions about www.geronimoplugins.com site

2006-05-02 Thread Geir Magnusson Jr




Matt Hogstrom wrote:
I am volunteering to research with Infra to find out what it would 
take.  I think we at least need to understand what is possible and not 
simply speculate on it.


Speaking w/ my infra hat, there is a strong aversion to single-sourcing 
resources on ASF infra when they can be mirrored or embedded.


I don't think we'd want to host plugins here unless we could mirror the 
repo.  I'd imagine millions of copies of Geronimo banging away walking 
the repo would irritate someone :)


(Also, remember the joke Don't reboot the JBoss server - Sourceforge is 
down so the schemas won't resolve...)


That's why I suggested changing the model so that there is a simple 
meta-data document that Geronimo the software reads to get info on 
either the plug-in list a set of URLs to plug-in lists...


geir



Per my other e-mail.  I would like to pursue this tack in parallel to 
leaving the www.geronimoplugins.com as a default / find a way to get a 
list from somewhere.


Rodent of Unusual Size wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Davanum Srinivas wrote:

+1 to I do not think we should make the geronimoplugins site the
default and we need an ASF option as the default.


Dims, Matt, are you volunteering to maintain such a
ASF location and a persistent URL for it?
- --
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist  http://Apache-Server.Com/

Millennium hand and shrimp!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRFeWeZrNPMCpn3XdAQKDTQP/aQTjgDQH0mVE4/E9/Tq+8A3O/P1u8asM
WLkLBN6MRcedNJZxEw1JArgVLEEyV7i78mxemefAR1OAfAe8I8qDf9RcAeyaqq5L
Diy7nDiMJbSukGi+MIWj5qXLzLD0KfgWnYlV9wC8HZZkIfF4hLJOxt0QTa7hxM7e
LlYwtP/2j1I=
=/+xG
-END PGP SIGNATURE-

Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire

2006-04-22 Thread Geir Magnusson Jr


Congrats! :)

geir


Geir Magnusson Jr wrote:
In recognition of his contributions and participation in the Apache 
Geronimo community,  the Geronimo PMC is proud to announce the 
committership of Rick McGuire.


Rick has contributed in many places, and is a pleasure to work with, and 
we look forward to his continued involvement as a committer.


Please join us in congratulating Rick.

The Apache Geronimo PMC

Re: [VOTE] 1.1 Code Freeze to start Monday 0600 PT - Ship 1.1 on Cinco De Mayo

2006-04-21 Thread Geir Magnusson Jr


+1

and I agree with Aaron about being flexible about ship date

Any interest in releasing/announcing at JavaOne?

geir


Matt Hogstrom wrote:

All,

I'd like to propose we close 1.1 and start putting the wrapping tape on 
the box.  There have been new features / functions coming in and at some 
point we need to collectively get this one out the door and focus on 
1.2.  So here is the vote to agree to close features and focus on bugs / 
JIRAs so we can complete this one.


[ ] +1 - Close development for 1.1 on Monday 4/24 0600 PT
[ ] 0  - No preference
[ ] -1 - Let's cram as much in as we can

Of course this doesn't mean that we don't fix bugs.

Matt

[announce] Welcome Apache Geronimo's newest committer - Rick McGuire

2006-04-21 Thread Geir Magnusson Jr

In recognition of his contributions and participation in the Apache 
Geronimo community,  the Geronimo PMC is proud to announce the 
committership of Rick McGuire.


Rick has contributed in many places, and is a pleasure to work with, and 
we look forward to his continued involvement as a committer.


Please join us in congratulating Rick.

The Apache Geronimo PMC

Re: ActiveMQ Graduation From Incubator

2006-03-14 Thread Geir Magnusson Jr




Sam Ruby wrote:


What I am unconfortable with is codebases being proposed with a
precondition being placed on where they land.

A sponsor is needed to inject a bit of accountability into the process,
and to reduce the tendency towards the ASF becoming a sourceforge with
lots of abandoned projects.  But that pretty much is the extent of
sponsorship.


The only thing I'd like to add is that I feel that a sponsoring PMC 
should take interest in the mentoring and development of the project it 
sponsored...


geir

Re: Sun copyrights and our rights to include certain files in the repo

2006-03-09 Thread Geir Magnusson Jr

Exactly the right question - the copyright isn't the issue, but the 
license is.


Where did these schemas come from, and what are the listed terms?

geir

Bill Stoddard wrote:

Jacek Laskowski wrote:

2006/3/9, Bill Stoddard [EMAIL PROTECTED]:

Don't change the copyright statements. The only time it is acceptable 
to change copyright statements is when

the copyright holder has assigned copyright ownership to the ASF.


Has it been assigned? If not, my understanding is that we're not
allowed to store them in the repo, either.



That's the wrong question. ASF repositories contain lots of code for 
which the ASF is not the copyright owner. Whether we are allowed to 
store code in our repositories depends on the license terms and 
conditions issued by the copyright holder.  What are the TC's for this 
code? Do we know?


Bill

Re: specs and javadoc question

2006-03-08 Thread Geir Magnusson Jr

if the comments are part of someone else's copyrighted material, and 
it's not under a permissive open source license, please don't copy them.


geir


Bill Dudney wrote:
So I will go ahead and type the comments (I'm more than half way through 
it anyway) and then we can delete them if we need to.


OK?

Jeff or anyone else, who should I go to for official statement? [EMAIL 
PROTECTED]

TTFN,


Bill Dudney
MyFaces - myfaces.apache.org
Wadi - incubator.apache.org/wadi



On Mar 7, 2006, at 4:04 PM, Jeff Genender wrote:




John Sisson wrote:

We shouldn't retype the comments in the XSD just like the javadoc in the
spec.  You are welcome to type your own original comments.


This is debatable for XSDs.  We currently seem to be using a lot of XSDs
verbatim for the SPECs, so we need an official statement on this.



Thanks,

John

Bill Dudney wrote:

Hi All,

I think this must have gotten lost in the traffic over the weekend.

Anyone know if I should/have to retype all the documentation comments
in the XSD?

Thanks,


Bill Dudney
MyFaces - myfaces.apache.org


On Mar 5, 2006, at 6:50 AM, Bill Dudney wrote:


One other question - the documentation comments in the XML schema for
the spec? Should I type in these comments or leave them out?

Thanks,

-bd-

On Mar 3, 2006, at 1:00 PM, Dain Sundstrom wrote:


BTW add a jira for this, so everyone knows you are working on it.

-dain

On Mar 3, 2006, at 10:02 AM, Bill Dudney wrote:


Hi All,

Thanks for the comments.

Dain: Yeah its not copying out of the pdf but simply typing, hardly
feels like original work though so even though I'm not copying, it
sure feels like it. :-)

I'll leave the comments out and post a patch after I get one more
pass over it (~early next week).

TTFN,


Bill Dudney
MyFaces - myfaces.apache.org

On Mar 3, 2006, at 10:43 AM, Dain Sundstrom wrote:


On Mar 3, 2006, at 9:37 AM, David Jencks wrote:


On Mar 3, 2006, at 9:10 AM, Bill Dudney wrote:


Hi All,

I've started getting ready for JSF 1.2 and figured that a good
place for the api jar to land is the uber spec project @ G for
JavaEE 5.

I'm most of the way there for Servlet 2.5 and JSP 2.1 but I was
wondering about javadoc. Does anyone know what the rules are
regarding javadoc in the spec code? I've just been doing a
straight copy/typing of the api and leaving out the javadoc. But
looking back at the Servlet 2.4 and JSP 2.0 spec modules all the
javadoc is there.


No copying only typing is allowed.


I'd like to submit the patch for Servlet 2.5 and JSP 2.1 in the
next week or so. If anyone knows the definitive answer (or since
we are not lawyers as close to definitive as possible:) I'd love
to hear it.


I have not been copying the javadocs into the specs I have worked
on.  I think that our servlet 2.4 and jsp 2.0 specs are copied
from tomcat where they were IIUC donated complete with javadocs
by sun.  I think leaving out the javadoc is the wisest course.


Yes, the javadoc comments are owned by Sun.  If you would like to
write your own *original* javadoc comments, that would be cool,
but not necessary.

-dain

Re: [Vote] Release 1.0.0 of Eclipse Plugin?

2006-02-26 Thread Geir Magnusson Jr


+1


Sachin Patel wrote:
Please vote on the release of the eclipse plugin for Geronimo 1.0.0.  
Keep in mind a update manager patch will be made available to support 
1.0.1 after it is released.


[+1] Release v1.0.0 of the eclipse plugin supporting G 1.0
[-1] Do not release, v1.0.0.

- sachin

Re: Ode Proposal


The Geronimo PMC needs to vote on sponsoring this.

Before you do that, just to start the discussion :

- Why would the Geronimo PMC sponsor this?
- Isn't BPEL a bit far afield from J2EE, which is our charter as a PMC?
- How about bringing it to Agila, which already has a good start on BPEL 
and workflow, and take the best from the Sybase contribution and the 
best from Twister and combine?



Alan D. Cabrera wrote:
Ok.  Here's the proposal http://wiki.apache.org/incubator/OdeProposal.  
Please feel free to comment.


Bill Flood, can you provide us with the list of Sybase developers that 
wish to work on this project?  Can you get the Software Grant paperwork 
faxed in?

Any other ASF committers want to jump in?

We need some more mentors.  Anyone?

This is not meant to stop discussions about this donation, just to start 
the bureaucratic machinery while they take place.



Regards,
Alan




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] XBean donation

Just to tie this up so it won't be left hanging - since Dain has already 
started moving forward with the ip document in incubator and declared 
his intention to commit the code tomorrow ...


My point was that this should have been presented before the vote on the 
dev list (So here's why I want to bring XBean to Geronimo and why it's 
appropriate for Geronimo), rather than it be assumed that everyone is 
familiar with whatever off-list or historical conversations have taken 
place around this.


I'm not against this - I was the one trying to get Dain to bring it back 
to Geronimo last summer when he first took it to Codehaus - but I think 
that the motivations for bringing in  code that is out of main scope of 
the project deserves some illumination.


geir


James Strachan wrote:

On 1 Feb 2006, at 15:53, Geir Magnusson Jr wrote:

I asked a while ago and I think my question was never answered -

why bring XBean into Geronimo?


ActiveMQ, Jetty, OpenEJB, ServiceMix are all using it as an optional 
lightweight kernel for efficient and concise configuration and 
deployment in Spring-ish ways. It is a very useful core piece of technology

and quite a lot of us are pretty excited to work with it in Geronimo

James
---
http://radio.weblogs.com/0112098/

Re: Ode Proposal


Wasn't it offered already to ServiceMix?

I mean, people already voted on accepting the code, so I assume it's 
available somewhere...


geir


[EMAIL PROTECTED] wrote:

Great!

I'm assuming the source won't be available for review unless/until Ode is
accepted as an incubator poddling?


Ian

It's better to be hated for who you are
than loved for who you are not

Ian D. Stewart
Appl Dev Analyst-Advisory, DCS Automation
JPMorganChase Global Technology Infrastructure
Phone: (614) 244-2564
Pager: (888) 260-0078


   
  James Strachan   
  [EMAIL PROTECTED]To:   dev@geronimo.apache.org   
  mail.comcc:   general@incubator.apache.org, servicemix-dev@geronimo.apache.org  
   Subject:  Re: Ode Proposal  
  02/14/2006 10:10 
  AM   
  Please respond to
  dev  
   





On 14 Feb 2006, at 15:03, [EMAIL PROTECTED] wrote:

Allan,

This proposal appears to be gear towards the web services/SOA
community.
Is support for orchestration of non-WS business processes
considered out of
scope for Ode?


No - the code should be reusable for most orchestration needs; even
in cases where there are no pointy brackets involved :).

James
---
http://radio.weblogs.com/0112098/

Re: Ode Proposal

There is a chicken-egg problem here - I'm afraid that would make some 
people unable to look at it.


I can understand not wanting to go through the pain of changing 
namespace until needed, but can it be made available under the Apache 
License (or another open source license of your choosing) for evaluation 
purposes?


While you ponder that, can the evaluation license under which the 
software is currently being offered be placed somewhere so we at least 
know the terms before downloading?


geir

Bill Flood wrote:

The source can be found here:  ftp://ftp.sybase.com/pub/incoming/wcss/bpe/

If the community goes forward with the project, in one form or another, we
are prepared to immediately change the license to the Apache form and modify
the package names spaces as appropriate.

thanks


On 2/14/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:

Wasn't it offered already to ServiceMix?

I mean, people already voted on accepting the code, so I assume it's
available somewhere...

geir


[EMAIL PROTECTED] wrote:

Great!

I'm assuming the source won't be available for review unless/until Ode

is

accepted as an incubator poddling?


Ian

It's better to be hated for who you are
than loved for who you are not

Ian D. Stewart
Appl Dev Analyst-Advisory, DCS Automation
JPMorganChase Global Technology Infrastructure
Phone: (614) 244-2564
Pager: (888) 260-0078



  James Strachan
  [EMAIL PROTECTED]To:

dev@geronimo.apache.org

  mail.comcc:

general@incubator.apache.org, servicemix-dev@geronimo.apache.org

   Subject:  Re: Ode

Proposal

  02/14/2006 10:10
  AM
  Please respond to
  dev





On 14 Feb 2006, at 15:03, [EMAIL PROTECTED] wrote:

Allan,

This proposal appears to be gear towards the web services/SOA
community.
Is support for orchestration of non-WS business processes
considered out of
scope for Ode?

No - the code should be reusable for most orchestration needs; even
in cases where there are no pointy brackets involved :).

James
---
http://radio.weblogs.com/0112098/

Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)

Why not just bring into Agila and work on it in there?

Bill Flood wrote:

Dims,

We heard your plea and have moved the proposal through the incubator as you
suggested. At this point, we are looking for supporters. From the energy
you put behind your posting, we are all hoping you will also be committed to
helping us drive this forward.

We are also reaching out to the Agila folks and anyone else who wishes to
get involved.

http://wiki.apache.org/incubator/OdeProposal

Best,

Bill

On 2/3/06, Davanum Srinivas [EMAIL PROTECTED] wrote:

*IF* that is the objective, then the correct way is to follow the
Apache Incubator process(es) draw up a proposal, name *ALL* the
committers in servicemix who are willing to contribute, add your own
team names, post the proposal to the [EMAIL PROTECTED] mailing list.
Ask for more people to join, Proactively invite other folks (from
Apache and outside Apache as well) to join, seek active support of
exising Apache folks who may be interested in joining a BPEL
implementation. For god's sake just check the list of people who wrote
the original BPEL spec and compare it to the people who work at Apache
on web services related stuff and u will see what i mean.

thanks,
dims

On 2/3/06, Bill Flood [EMAIL PROTECTED] wrote:

The dependency on Axis should be removed. It's the result of a couple

lines

of dead code. BPEL 2.0 is an objective.

The discussion over where the contribution lands is one of the most
important aspects of the process. Too narrow a scope and the project

could

fail to get critical mass, too wide and folks are worried about the

kitchen

sink. If we can find the right balance we will be well served.

We are not hardwired to any one particular approach and welcome

involvement

from all corners. The ServiceMix approach has a few positives - by in

large

they seem to like our contribution and they have critical mass.

On 2/3/06, Davanum Srinivas [EMAIL PROTECTED] wrote:

I was determined to stay of this, but alas! i could resist asking

this:

Would you be ok to having a stand alone project with committers from
servicemix, your team, people from other backgrounds (could be
existing ws committers) working on this code base, bring it up to say
BPEL 2.0 from BPEL1.1, upgrade it to say Axis2 from Axis 1.3
etc.etc...OR are u insisting that this code has to go into servicemix
and nowhere else...

If it is the latter, why? If it is the former, why is there so much

resistance?

As they say, i'll take your answers off the air.

thanks,
dims

On 2/3/06, Bill Flood [EMAIL PROTECTED] wrote:

Dims, I'll take Cory off the hook since he was acting in good faith

behalf of Sybase :-).

As we are learning, there are a variety of ways to work within the

Apache

process as long as the community is supportive. From the Sybase
perspective, we are interested in working with a vibrant community

in a

meaningful way that balances the needs of the community with that of

our

own.

when we first started thinking about the open source path, we looked

Agila and communicated with the developers. While the Agila

developers

were

quite helpful, the project was not open to our contribution and our
assessment was that their existing code line would take substantial

work

bring it up to where we thought we already were.

When we looked at ServiceMix, we found a mature community that not

only

appeared open to a contribution such as ours but one which would

help us

establish a good affinity with the ESB. The Sybase folks working on

this

code line will continue to vigorously support the orchestration

component

and provide help in adjacent areas related to SCA.

At this point, we feel comfortable in our contribution to the

ServiceMix

project based on the positive uptake. Under the rules of

meritocracy,

will work to ensure that the interfaces remain clean and the build

granular

enough to be reused and hope to work with you in the future.

Best Regards,

Bill

---Original Message---
From: Davanum Srinivas [EMAIL PROTECTED]
Subject: Re: Let's rewind!!! (Re: [VOTE] accept donation of a

business

process engine into the ServiceMix project)

Sent: 02 Feb '06 21:12

Cory,

Could you please get James' help and draft a complete proposal?

Please see

http://www.google.com/search?hl=enlr=safe=offq=incubator+proposal+site%3Awiki.apache.orgbtnG=Search

for a list of proposals, their format and their content.

Once the proposal is ready, please post it to [EMAIL PROTECTED]

Also,

please take a peek at the documentation on the
http://incubator.apache.org/ site especially w.r.t to the

incubation

process, what to expect and steps involved.

thanks,
dims

On 2/2/06, cory [EMAIL PROTECTED] wrote:
Hi,

BPEL 1.1 is supported. The code works with Axis 1.3.

Sybase wants this code to be successful within the community

and is

going to work to support it.

Cheers,

-cory

On 2/2/06, Davanum Srinivas [EMAIL

Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)




Bill Flood wrote:

Geir, approaching Agila was our first avenue.  We looked at what they had
and I initiated several conversations about donating to that incubator
project.

We offered a base line upon which to build but there did not seem to be any
uptake although both committers said they were happy to have us come in and
provide coding help on what they already had. 


I don't really know.  I wasn't part of that conversation, although I did 
have a few discussions w/ people after this all started.


I expect that what you just said might have been the problem.  They 
already had a BPEL engine, and it sounds like you were suggesting they 
stop and reboot on your codebase.  After all, they have some users and 
wouldn't want to just drop them.



I was a little mystified.
Jumping in and bringing their stuff up to where we already were seemed
counter productive given the large gap in code maturity and capability so we
passed.

Based on the support we have seen for our contribution from others in Apache
thus far, I have to believe that our impression wasn't just the result of
our inherent subjectivity

I believe we did approach them in good faith and I'm not sure why there was
disinterest in our offer via Agila but here we are.  We left the previous
conversation on good terms.  At this point, my preference would be that the
Agila folks look at the contribution and see if they want to become part of
that larger community for this new baseline.  To me, it's not about
ownership, it's about critical mass in the community to carry something
forward.


How about making a fresh start then...  If the Agila people are 
interested, put out a call for any and all other implementations of BPEL 
that might be donated and build a larger community, mixing the best of 
anything that is donated to get the best BPEL engine and community we can?


In the same way that we built Geronimo from best of breed J2EE-ish OSS 
projects that are out there, I'm sure we could do a similar thing with BPEL.


Maybe do a bake off to help find the best codebase, and have the 
community collaborate around that?  (I'm not sure what that would 
entail, actually...)


Would you be interested in that?

geir

Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)




Bill Flood wrote:

I'm open to what works best.  I think the proposal for Ode is in essence a
fresh starting point for a community.  Sybase just happened to submit some
code, which may or may not be accepted and that we thought was passable.  In
the end, the community has the last say so we welcome that type of open
discussion.


That's why I'm bringing it up here :)

Good luck with it.

geir



On 2/14/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:



Bill Flood wrote:

Geir, approaching Agila was our first avenue.  We looked at what they

had

and I initiated several conversations about donating to that incubator
project.

We offered a base line upon which to build but there did not seem to be

any

uptake although both committers said they were happy to have us come in

and

provide coding help on what they already had.

I don't really know.  I wasn't part of that conversation, although I did
have a few discussions w/ people after this all started.

I expect that what you just said might have been the problem.  They
already had a BPEL engine, and it sounds like you were suggesting they
stop and reboot on your codebase.  After all, they have some users and
wouldn't want to just drop them.


I was a little mystified.
Jumping in and bringing their stuff up to where we already were seemed
counter productive given the large gap in code maturity and capability

so we

passed.

Based on the support we have seen for our contribution from others in

Apache

thus far, I have to believe that our impression wasn't just the result

of

our inherent subjectivity

I believe we did approach them in good faith and I'm not sure why there

was

disinterest in our offer via Agila but here we are.  We left the

previous

conversation on good terms.  At this point, my preference would be that

the

Agila folks look at the contribution and see if they want to become part

of

that larger community for this new baseline.  To me, it's not about
ownership, it's about critical mass in the community to carry something
forward.

How about making a fresh start then...  If the Agila people are
interested, put out a call for any and all other implementations of BPEL
that might be donated and build a larger community, mixing the best of
anything that is donated to get the best BPEL engine and community we can?

In the same way that we built Geronimo from best of breed J2EE-ish OSS
projects that are out there, I'm sure we could do a similar thing with
BPEL.

Maybe do a bake off to help find the best codebase, and have the
community collaborate around that?  (I'm not sure what that would
entail, actually...)

Would you be interested in that?

geir

Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)



Aaron Mulder wrote:

On 2/14/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:

In the same way that we built Geronimo from best of breed J2EE-ish OSS
projects that are out there, I'm sure we could do a similar thing with BPEL.

Maybe do a bake off to help find the best codebase, and have the
community collaborate around that?  (I'm not sure what that would
entail, actually...)


Geir, I don't understand this at all. In different threads you seem
to be simultaneously talking about bringing it to Agila, bringing it
to ServiceMix, having the Geronimo PMC vote on it, and now you're
recommending a bake-off where no one does anything with any code
until the one true way emerges?  


I don't know if you've been following this closely, but originally it 
was suggested that the Sybase engine go to ServiceMix (hence the 
bringing it to ServiceMix part), which would require the vote of the 
Geronimo PMC (which is in fact what James did).


Today, we were introduced to the ODE Proposal, which is a new podling 
proposal that is to be sponsored by the Geronimo PMC (hence my question 
about a vote about that since it would be yet another podling sponsored 
and overseen by the Geronimo PMC, and we hadn't voted on it), and I 
wondered if there was interest/synergy w/ the Agila podling, which is 
already working on an implementation of a BPEL orchestration engine.


I hope that clears up the confusion for the first three elements of the 
above.


As for the bake off, I'm not recommending anything - I was asking if 
it made sense to see what kind of broader community could be assembled 
around this, without presuming the primacy of one codebase - choosing 
the best of what shows up.


If you've been following the whole soap opera for the past week or so, 
you might recall that there was considerable concern from various 
members of the ASF community regarding this subject, with the suggestion 
(from greg) that we should Erase the lines and create a community that 
can work on something with a cooperative atmosphere.


 I won't speculate on your motives,
 but this strikes me as an... unusual approach.

What strikes you as unusual?  Bringing multiple groups together to work 
on a given technology?


My motive is to try and get rid of some of the cloud of bad karma thats 
hanging over this whole discussion because it's the last thing the 
Geronimo project needs right now.  It's also not good for the new people 
that wish to join our community, the Sybasians.  (Sybasers?)   I also 
think that BPEL is an interesting technology and I would like to see a 
community flourish around a great implementation here at the ASF.


What's your motive?



Also, I don't at all agree with your comparison of a BPEL Engine to
Geronimo.  I would compare it to the transaction manager within
Geronimo.  It's a discrete component, and we're not going to take the
best of 20 different projects to make a transaction manager, and I
don't see why we'd do the same to make a BPEL Engine.


Ok. I'll be the first to admit that I'm no expert on BPEL 
implementations, but I certainly wouldn't suggest that we'd try to take 20.


However, could you imagine taking a few and finding the best aspects of 
each?  Are they really that monolithic that you can't find component 
parts that you could blend together to make something better?


What about clustering?  What about management or tooling?  Support for 
different versions of BPEL?  How about service hosting?  Do they have a 
container (like PXE) or can they be used to orchestrate external 
containers (say a mix of services deployed though a heterogeneous 
environment, say w/ Geronimo, Tuscany and Axis+Tomcat (I dunno...), with 
the BPEL engine just deployed into Jetty?




If anything, the JBI container is like Geronimo, and the BPEL Engine
is like the Transaction Manager, and note (everyone) what happened
there.  We didn't create a separate projects for the transaction
manager, we just build a good one in Geronimo and made it
intelligently portable.  



Then, when someone had a fancy to use it in
Spring without the rest of Geronimo, they created Jencks, and now we
have a standalone projects for that purpose and the best of both
worlds, but it was born by putting the code in the container where it
would be used, making it solid and portable there, and building
outward.



Hey - I'm not going to pretend to be an expert on BPEL orchestration 
systems, so I guess I'll take your word for it that it's like a 
monolithic transaction manager.  In the past, I've built production 
workflow systems (not BPEL, more like a JMS-driven SOA) that weren't at 
all monolithic - they got a bit complicated, actually, so that's what's 
driving my understanding of what a full BPEL orchestration system should 
be like.


geir

Re: Migrating to maven 2

this always reminds me of the old jokes about the country that wanted to 
do a  piecemeal switch from wheel on the right cars to wheel on the 
left cars...


David Blevins wrote:

On Feb 14, 2006, at 2:03 PM, Alan D. Cabrera wrote:


On 2/14/2006 3:09 AM, Anders Hessellund Jensen (Trifork) wrote:


I'd like to help migrating to maven 2.

Where to start? I suppose a good start would be to write POM's for 
some of the modules. This should be fairly straightforward, at least 
for modules without complex jelly usage. Should the directory layout 
be configured to maven 1 style in the parent POM?



We've tried to do an uber move and it's never worked.  I recommend 
that we move bits over one at a time.  Maybe we could kill two birds 
with one stone and also perform the breakout that Aaron proposed at 
the same time.




I don't recall us actually trying anything, which is not to subtract 
from your point, just that this the way people have envisioned it 
happening from the get-go.  That's probably not going to be the way it 
happens.


As you say, it's way too much to digest in one big bite and better if we 
start nibbling.



-David

Re: [vote] XBean donation



Aaron Mulder wrote:
How can XBean be out of scope but modules/kernel is not? 


If we're going to switch Geronimo over to XBean, then yes, it's in 
scope.  But the answers to my question never said that.  It was 
ServiceMix and Jetty depends on it or whatever.



XBean is a
better that, including solving a number of problems that we're
currently facing (such as, say, serialized objects).  I'm eager to
start integrating the code.


Fantastic.

Essentially I asked What are we going to do w/ XBean in Geronimo?

That was the answer I was looking for - thanks for just saying it 
plainly and clearly.


Amen.

geir



Aaron

On 2/14/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:

Just to tie this up so it won't be left hanging - since Dain has already
started moving forward with the ip document in incubator and declared
his intention to commit the code tomorrow ...

My point was that this should have been presented before the vote on the
dev list (So here's why I want to bring XBean to Geronimo and why it's
appropriate for Geronimo), rather than it be assumed that everyone is
familiar with whatever off-list or historical conversations have taken
place around this.

I'm not against this - I was the one trying to get Dain to bring it back
to Geronimo last summer when he first took it to Codehaus - but I think
that the motivations for bringing in  code that is out of main scope of
the project deserves some illumination.

geir


James Strachan wrote:

On 1 Feb 2006, at 15:53, Geir Magnusson Jr wrote:

I asked a while ago and I think my question was never answered -

why bring XBean into Geronimo?

ActiveMQ, Jetty, OpenEJB, ServiceMix are all using it as an optional
lightweight kernel for efficient and concise configuration and
deployment in Spring-ish ways. It is a very useful core piece of technology
and quite a lot of us are pretty excited to work with it in Geronimo

James
---
http://radio.weblogs.com/0112098/

Re: [VOTE] accept donation of a business process engine into the ServiceMix project

2006-02-05 Thread Geir Magnusson Jr



James Strachan wrote:
We have received the generous donation of a complete and working BPE 
engine to the ServiceMix project...
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/[EMAIL PROTECTED] 



the contributor has offered to donate to Apache  complete the necessary 
software grants  IP clearance and to work with us on integrating it 
into ServiceMix.


I assume we'd all get to see the code under an Apache License before 
deciding to accept.  How else could we vote it in?


[SNIP]

I'll go out on a limb here :


[X] -1 I object because: ...


... I think that a BPEL engine is something that spans many of the WS 
and SOA oriented projects at the ASF, such as ServiceMix, Tuscany, 
Synapse, Agila, etc...


However, that's not my main reason, because honestly, if I was the only 
one that cared about that, I wouldn't ever attempt to stand in the way 
of people wanting to do cool things.


However, this proposal has sent up far too many red flags, has alienated 
too many people, and is causing too much of a bad feeling in people, for 
ServiceMix, for Geronimo and for the ASF in general.


I'd suggest you make a big effort to cool things down and get a broad 
conversation going, over at [EMAIL PROTECTED], drive to consensus, and 
then regroup and try again.


geir

Re: [VOTE] accept donation of a business process engine into the ServiceMix project

2006-02-03 Thread Geir Magnusson Jr




Rodent of Unusual Size wrote:


This is all hypothetical; I don't know if there *are* people
who'd want to work on it but not ServiceMix, and I have
to take on faith the remarks that there are other packages
that would like a BPEL engine without ServiceMix attached.


I don't think you need much faith to believe that a BPEL engine is 
general purpose.  I think that there are several projects at the ASF 
that have interest and would benefit from participation in such an beastie.


geir

Re: [VOTE] accept donation of a business process engine into the ServiceMix project

2006-02-03 Thread Geir Magnusson Jr


how does that make any sense?

Davanum Srinivas wrote:

Then start the BPEL project under Geronimo. *NOT* under ServiceMix.

-- dims

On 2/3/06, James Strachan [EMAIL PROTECTED] wrote:

On 3 Feb 2006, at 15:08, Rodent of Unusual Size wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Strachan wrote:

Incidentally its worth looking at other projects at Apache like Agila
and various projects on http://ws.apache.org like EWS, Mirae, Muse,
WSRF, TSIK etc which are kinda quiet, some near dormant.

No, it is not worth looking at them, if the intent is to use
them as precedents of a process some are finding objectionable.
Saying, 'They did it so why can't we?' is not appropriate.

I guess I didn't explain myself well there at all Ken sorry. (I'm
full of cold :( ).
I was just trying to say I'd rather see large, successful communities
form first, then if need be parts of the project are split off if
they become so wildly successful by themselves. So I was trying to
show some examples of projects which maybe could have benefited from
starting inside a larger, less granular project/community first
rather than starting small and dwindling then being merged back
together again due to inactivity.

e.g. both Geronimo and Jakarta Commons have a broad range of
components inside them - many of which are reusable by themselves -
in both cases the courser grained projects helped grow a larger more
diverse community IMHO.

James
---
http://radio.weblogs.com/0112098/





--
Davanum Srinivas : http://wso2.com/blogs/

Re: [VOTE] accept donation of a business process engine into the ServiceMix project

2006-02-03 Thread Geir Magnusson Jr




Sanjiva Weerawarana wrote:

Hi James,

We're not sucking in another project. Its a contribution of code  
only. How is this any different than has already happened on  
Geronimo, Agila (twister), Harmony etc?


Geronimo is not an incubating project and hence can bring more stuff in.
The Agila/Twister merger was done thru the incubator (and is still
ongoing and IMO unlikely to complete). Harmony- I'm not sure what you're
referring to (I haven't followed it much).


In harmony we're bringing in donations from people who are contributing 
to our primary mission, creating a fully working implementation of J2SE. 
 That means that implementations of both the VM and the class 
libraries, and that is what is being donated and accepted.



geir

Re: [vote] XBean donation


I asked a while ago and I think my question was never answered -

why bring XBean into Geronimo?

geir


Dain Sundstrom wrote:
The XBean project has voted to donate all of the code located at 
https://svn.codehaus.org/xbean (view with fisheye 
http://cvs.codehaus.org/viewrep/xbean) to Apache Geronimo.  The 
completed IP clearance check list can be found here 
https://svn.codehaus.org/xbean/xbean-ip-clearance.html


[+1/-1/0]  Accept the XBean code donation

-dain

Re: [result] [vote] XBean donation


I was sick and traveling the past few days, so I missed the whole vote.

I'm not necessarily against it, but worried about pointless growth - my 
only question is why bring this in?  It's good code and all, but 
normally we try to draw some line between the existing project's goals 
and what the addition does.


Maybe I missed the discussion before the vote...

geir


Rodent of Unusual Size wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dain Sundstrom wrote:

Vote passed with:

+1 Jeff Genender, Alan Cabrera, Sachin Patel, Dain Sundstrom, David  
Blevins, Andy Piper, Aaron Mulder, Davanum Srinivas, Jacek Laskowski,  
Bruce Snyder, Jason Dillion, Gianny Damour, John Sission, David  
Jencks, James Strachan


No -1s

I'll file the paperwork with the incubator and import later today.


Less than 50 of the committers have voted, but 72 hours
have passed since the vote was called.

Does anyone wish to extend the vote longer?
- --
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist  http://Apache-Server.Com/

Millennium hand and shrimp!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQCVAwUBQ+DcnJrNPMCpn3XdAQI/fQP/dRDczuJf2dKzTTrdnIsY/M9zNaAI7MG0
CRkS4iO8b7aqOzaeNwDt4ZoKGm19jnprHMyC4srqecC6rXi/Kk3VONrWOj7mUY8I
aOqQGwMrgkC8EIK12fKGbBlg7yTojkN3xfgETA4SCDU58W94eh+zQziybqmepJ93
DQiAMXGlJgI=
=Lg5M
-END PGP SIGNATURE-

Re: [VOTE] 1.0.1 Release and the configId issue

What's the timing?  I ask with motivated by the thought that the sooner 
it happens, the fewer people will be affected...


geir


Matt Hogstrom wrote:
There was some discussion on Irc earlier this week about the issue 
related to plans having to be changed due to module versions changing.  
This is clearly going to be a significant issues for customers as they 
will have to re-work all their plans on incremental server changes.  
Although these will most likely be tolerated in the short-term this is a 
serious shortcoming in the current design that needs to be addressed.


During the discussion it was asserted tha given the magnitude of the 
change to the format of the plans and changes to G it was not 
appropriate for make this change in a maintenance release.  The 
collective wisdom was to declare in the release notes this issue and 
give the user guidance with the assurance this is being addressed in 1.1 
(or there abouts).


Since there has been a lot of discussion about this already and it being 
such a significant issue I thought I'd request a vote to see where we 
stand.


[ ] +1 Document issue in release notes and defer fix to 1.1
[ ] 0  Not that important one way or another
[ ] -1 This is an issue that must be resolved in the 1.0.x branch
[ ] Other...provide your reasons.

Re: License issues with commonj

I actually did read the spec and type in the classes once.  (I think it 
was for the timer spec...?)


I believe that if we do that, we have no problems because of the 
copyright notice in the spec.


I've also discussed this issue regarding the lack of any recognizable 
license for their code w/ BEA and IBM, and they have made it very clear 
that they will provide one if needed.


So the question is, type or wait for license?  I say type

geir

David Jencks wrote:
We have a patch with an implementation of the commonj timer spec.  I'd 
like to get this into svn soon.  One issue is straightening out the 
license provisions for the api and implementations.  AFAICT commonj is a 
joint effort of BEA and IBM.


The bea website discussing commonj is:
http://dev2dev.bea.com/wlplatform/commonj/twm.html

After the download links it states:

This specification is being made available on an RF basis (as detailed 
in the Copyright notice of the specification); therefore, BEA does not 
require an implementation license. If you prefer, however, you may 
request a license from BEA to implement the specification.


The specification pdf says:


and earlier:


(sorry about the pictures, I can't figure out how to copy out of a pdf 
otherwise)


There is a link to a zip of source code for the api.  These files 
contain the following license statement:


/* Timer for Application Servers
* Version 1.1
* Licensed Materials - Property of BEA and IBM
*
* © Copyright BEA Systems, Inc. and International Business Machines Corp 
2003-2004. All rights reserved.

*/


My theory about this is that we might not need a license to write our 
own api classes from the javadoc, or to write implementations of the 
api, but that we can't simply check in the existing source code without 
some documentation/grants from IBM and BEA.


Since there are only about 14 classes in the api it would undoubtedly be 
much quicker to simply write out the classes from the javadoc than seek 
documentations/grants.


I assume that a patch to a jira issue containing apache licensed api 
classes, with permission granted to apache for inclusion, supported by 
CLA and CCLA, would also be fine.


My interpretation of the statements about licensing are that we don't 
need a license.  However I'm not at all confident I've interpreted this 
properly.  How can we proceed?


thanks
david jencks

Re: [vote] XBean donation




Alan D. Cabrera wrote:
Because it's a great technology that would make my life easier. 


A Ferrari is great technology that would make my life easier.  :) (Ok, 
it would make it more enjoyable not easier)


 I
encourage you to read the website for more details on the nifty things 
that it does.


I'm sure it does great things.  That wasn't my question.  I'll continue 
this in the other thread on it...


geir




Regards,
Alan

Geir Magnusson Jr wrote, On 2/1/2006 7:53 AM:

I asked a while ago and I think my question was never answered -

why bring XBean into Geronimo?

geir


Dain Sundstrom wrote:

The XBean project has voted to donate all of the code located at 
https://svn.codehaus.org/xbean (view with fisheye 
http://cvs.codehaus.org/viewrep/xbean) to Apache Geronimo.  The 
completed IP clearance check list can be found here 
https://svn.codehaus.org/xbean/xbean-ip-clearance.html


[+1/-1/0]  Accept the XBean code donation

-dain

Re: [VOTE] Documentation in Confluence, MoinMoin, or..

2006-01-24 Thread Geir Magnusson Jr




Jacek Laskowski wrote:

2006/1/23, Geir Magnusson Jr [EMAIL PROTECTED]:

I don't understand - The need for documentation under source control is
important, and we need to find a solution that ensure that is possible.

I think that a documentation system should be a combination of

- reasonably easy to use
- versionable
- able to be used offline
- extractable into an open and transformable format for reuse

Wikis that I've used fail on #2, #3 and #4.


Hi Geir,

Isn't it an issue for the whole Apache org?


Yes, but I don't think a lot of projects do documentation in wiki. 
That's an interesting question to get real data for.



Haven't I seen some emails
about it on [EMAIL PROTECTED] recently? I think it's not only us who
straggle with the issue and I'd be very pleased to have some sort of
Confluence with SVN support so that content could be easily made
offline and committed to a repo *and* the the same time introduce
changes thru Confluence and have them checked into the repo, too.


Yep :)




I'm also curious about how in-code documentation can be integrated, via
something like Doxygen or -ish.


I don't know it at all. Do you have any insights on its features?
Something you know after having worked with it for a while?


I don't know it at all, but I've seen it used for _code_ documentation. 
 I think it would be lousy for general user doc that's not from code.





I realize the clear majority is for Confluence, but these factors should
be considered.


Absolutely! (but shame on me since I had not as I had voted).

Off looking for some information about Doxygen...


geir


--
Jacek Laskowski
http://www.laskowski.org.pl

Re: [VOTE] Documentation in Confluence, MoinMoin, or..

2006-01-23 Thread Geir Magnusson Jr



Jason Dillon wrote:

I think that a documentation system should be a combination of

- reasonably easy to use
- versionable
- able to be used offline
- extractable into an open and transformable format for reuse

Wikis that I've used fail on #2, #3 and #4.


Confluence (as well as other mature wikis) provide #2, and #4 isn't that 
really to achieve.  Most wikis provide some way to version content.


I mean across pages - like how we do tags and branches, so a doco set 
can be associated with a version of G.


  It
happens that Confluence uses Hibernate and versioned entities for this 
not a SCM like SVN or Perforce. Confluence wiki-markup could itself be 
considered that open and transformable format. 


So could anything, I suppose :) I was thinking more along the lines of 
some XML dialect like DocBook - even if it could export, that would be 
cool.


I was thinking about docs the other day - OpenOffice can output DocBook 
(which I'm sure everyone on the planet knew except me...), so there now 
is an offline, WYSIWYG editor that produces a standard format that 
allows transform for various presentation formats.


If you don't like that, 
then you could always write a transformer into that language which you 
do like.


The question that leaps to mind is what keeps me assured that the 
confluence wiki format is stable and not changing?




#3 is the only one that isn't so easy to resolve out of the box.  It is 
possible however, but is lacking in many ways.  For example, you could 
setup a Confluence standalone on whatever your mobile workstation was, 
then import/export spaces.  Its definitely not ideal, but it is possible.


Perhaps someone will write a bidirectional SVN sync, so that you could 
update Confluence wiki-markup in SVN, which would then get picked up in 
Confluence.  While this could be done, there are some issues with 
potential merging conflicts, as the definitive copy of the data is in 
Confluence (from Confluence's perspective), so if a user offline make 
several changes, in addition to online users, there would potentially be 
a window of error.


I keep hoping I have some free time to take this on.  This is the 
canonical detached dataset problem, isn't it?  It seems that marging 
isn't so hard because it is human-readable textual content, so a merge 
process is pretty straightforward in case of collision.




I realize the clear majority is for Confluence, but these factors 
should be considered.


There are several... or many (not sure) of us who are aware of these 
issues.  I've been actively looking at resolving some of them and/or 
finding alternatives which will appease most of the interested parties.


For example, I've got a crude Confluence listener which will persist 
wiki-markup (w/editor id and comments) to SVN.  That gets us closer to a 
#2 that more people can agree on.  Atlassian are cool/reasonable peeps 
so it might be possible to expose the basic versioning/content mechanism 
as a plugin to allow us to completly replace that with a SVN impl... but 
don't hold your breath.


Using SVN as a backing store would go part of the way, as I can then 
setup the Free Local JIRA that those cool peeps at Atlassian would give 
away for single-machine personal use, aim it at my data tree, and let me 
edit away (or a real local WYSIWYG editor...).  Then I can just svn co 
and deal the any merge issues...


geir



--jason

Re: Geronimo Community

2006-01-23 Thread Geir Magnusson Jr




David Jencks wrote:
in my understanding of the apache way, one of the important principles 
is that all decisions happen on the mailing list.  To me, for Geronimo, 
that means that if you are working on a feature more complex than a 
simple bug fix, you describe it in general terms in an email to the dev 
list or in a jira entry.  While I try to follow this I know I often fail 
and would appreciate reminders when I do.


Well, a soft commit-then-review also works, especially when people are 
really good at what they are doing. (like you are)


I think that most of the time, there's no issue, and assuming good faith 
all around, when there is an issue, it's gets resolved easily.  After 
all, that's why we have version control.


I think of it as optimistic locking of sorts.

I think the only risk is the time of the volunteer - if you are going to 
invest a lot of time into something, you might want to make sure that 
everyone will like it if you care about the time investment.




When I don't see this happening, for Geronimo code or for code in 
projects that are supposed to be on the way into incubation as Geronimo 
sub projects, I get worried and wonder how long the project will survive.


Comments?


:x

geir



thanks
david jencks

Re: [VOTE] Documentation in Confluence, MoinMoin, or..

2006-01-22 Thread Geir Magnusson Jr

I don't understand - The need for documentation under source control is 
important, and we need to find a solution that ensure that is possible.


I think that a documentation system should be a combination of

- reasonably easy to use
- versionable
- able to be used offline
- extractable into an open and transformable format for reuse

Wikis that I've used fail on #2, #3 and #4.

I'm also curious about how in-code documentation can be integrated, via 
something like Doxygen or -ish.


I realize the clear majority is for Confluence, but these factors should 
be considered.


[+1] Other (as I think that #2, #3 and #4 aren't realizable w/ current 
proposals... I'd be happy to be wrong...)


geir


Rodent of Unusual Size wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Anyone with an interest in working with the documentation,
either directly or for some sort of postprocessing, please
vote here.  Unless there are problems, this vote will
close in one week, at 14h00 UTC on 27 January 2006.  At
that point, a two-thirds majority will be a clear indicator
of which way to go; any narrower majority will mean
opinions are still too divided.

Working documentation for Apache Geronimo should be kept in

[  ] Confluence
[  ] MoinMoin wiki
[  ] Other (explain)

This does not affect the need for 'solid' or released
documentation to be under source control.  This vote is
only to decide a single collaborative environment for
its development.
- --
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist  http://Apache-Server.Com/

Millennium hand and shrimp!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D
eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y
Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7
48uwYXnlh1c=
=1Dmb
-END PGP SIGNATURE-

Re: Replication using totem protocol

2006-01-22 Thread Geir Magnusson Jr


Catching up :

[EMAIL PROTECTED] wrote:

No.  You license the code to the Apache Software Foundation giving
the foundation the rights to relicense under any license (so the
foundation can upgrade the license as they did with ASL2).  We do ask
that you change the copyrights on the version of the code you give to
the ASF to something like Copyright 2004 The Apache Software
Foundation or its licensors, as applicable.


That _is_ transferring the copyright.


No, it isn't.  You are still the copyright holder of the contributed 
material.  The (c) statement that Dain suggested represents the 
collective copyright of the whole package, which is your original code 
(for which you hold the copyright), and additions from other people (who 
individually hold copyright or share copyright depending on the 
contribution.)


That's why it's or it's licensors, which you would certainly be.



As I told Jeff on the phone, I would definitely considering this if it
turns that evs4j will really be used, but I would rather not grant someone
an unlimited license at the present time. Jeff said we are going to have a
discussion, so we'll know more soon enough.


The Apache License is fairly close to an unlimited license, so if it's 
available under the AL, you are already there.


The only thing different is that you are giving the ASF the ability to 
distribute the collective work under other terms other than the current 
version of the Apache License.


I hope that makes you feel a little more comfortable about things.

geir

Re: CORBA incubation proposal

2006-01-19 Thread Geir Magnusson Jr

When projects start in incubator, yes - anyone on the initial committer 
list is given committer status on the incubating project.  Because 
Geronimo may/is sponsor/ing this as a subproject, when the incubator 
project graduates, all committers become Geronimo committers.


You can see an example of this with ServiceMix (or was it ActiveMQ?) 
All committers were added to Geronimo's ACL for SVN.  I'm not sure why 
because it hasn't graduated, but it's what is going to happen with this 
and the other Geronimo-sponsored incubator podlings if they successfully 
graduate.


geir


Matt Hogstrom wrote:

Alan,

I do have a question about the initial committer list.  Since I'm 
relatively new to Apache my understanding was that commit was based on 
previous work.  Many of the names on the list are new to me so I have 
not had an opportunity to work with them.  Are all the suggested names 
currently committers at Apache?  If not, is this standard practice for 
granting commit and does this mean they are granted commit to the 
entrire Geronimo dev tree?


Thanks for the follow up.

Matt

Rick McGuire wrote:

Alan D. Cabrera wrote:


Here is the incubation proposal

http://wiki.apache.org/incubator/CorbaProposal


I'm interested in assisting with this.  I was wrote the adapter code 
that allowed IBM's WAS CE product to work with the IBM JDK ORB.  This 
required developing a pretty good understanding of how Geronimo hooks 
into the ORB, as well as finding places where hidden assumptions about 
ORB behavior created additional tie-ins to a single implementation.




Does anyone have any comments before we vote on it?

Should this also get sent to the incubator list or do we wait until 
after the vote?


Alex Karasulu and I were talking about it and we both think that it 
might be a good idea to shoot for making this a TLP.  Thoughts?




Regards,
Alan

Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.

2006-01-16 Thread Geir Magnusson Jr




Rodent of Unusual Size wrote:


I believe it is safe to say that Geronimo has been operating
in CTR mode, but I think the specifics and ground rules may
not have been spelt out, or need to be again.  Is this the
way in which the majority wants to continue to proceed?


I believe that most Apache projects are fundamentally CTR.  I can only 
think of one, httpd, that is RTC.  Is that right?


geir

Re: [jira] Created: (GERONIMO-1478) Donation of XBean source

2006-01-16 Thread Geir Magnusson Jr


How do you see this fitting into the scope of Geronimo?

geir

Dain Sundstrom (JIRA) wrote:

Donation of XBean source


 Key: GERONIMO-1478
 URL: http://issues.apache.org/jira/browse/GERONIMO-1478
 Project: Geronimo
Type: New Feature
Reporter: Dain Sundstrom
 Assigned to: Dain Sundstrom 



The XBean project has voted to donate all of the code located at https://svn.codehaus.org/xbean (view with fisheye http://cvs.codehaus.org/viewrep/xbean) to Apache Geronimo.  


XBean is a lightweight server framework which includes a simple kernel for 
managing service lifecycle, a server framework turns the kernel into a sand 
alone server, and several generic services/extensions that augment the simple 
server framework.

The committers to this code base can be seen with the following UNIX command:

svn log https://svn.codehaus.org/xbean | grep r[0-9][0-9]* |  | sed 
s/r[0-9][0-9]* | \(.*\) | .* | .*$/\1/ | sort | uniq

All of the committers have a CLA on file at Apache except Sam Pullara.  Sam has 
faxed the cla but it has not been officially received yet.   The following 
table maps the unix user names to real names:

chirino   Hiram Chirino
dain   Dain Sundstrom
dandiepDaniel Diephouse
dblevinsDavid Blevins
gnt  Guillaume Nodet
jstrachan   James Strachan
jvanzyl   Jason van Zyl
maguro  Alan Cabrera
root -service account-
spullara Sam Pullara

Re: javamail InternetAddress parsing.

2006-01-04 Thread Geir Magnusson Jr




Rick McGuire wrote:
I'm trying to write a fuller implementation of the 
InternetAddress.parseHeader() method for the Geronimo javamail 
implementation.  I've been writing some tests to see how the Sun 
javamail implementation is handling various addresses, and then rolling 
these tests into the Geronimo junit tests for InternetAddress.
While doing this, I ran the existing junit tests against the Sun 
javamail package and discovered that the Sun version failed some of the 
Geronimo unit tests!  Specifically, any of the group address tests in 
InternetAddressTest where the group did not contain a leading phrase did 
not get recognized as a group address.  Thus the tests for :[EMAIL PROTECTED]; 
and :[EMAIL PROTECTED], [EMAIL PROTECTED]; failed when run against the Sun javamail 
version.


It would be fairly simple to fix the Geronimo version to match the Sun 
results and fix the tests as well, but I'm not convinced that either 
version is handling this correctly.  RFC822 specifies that the tag 
phrase before the : in an address is required.  So :[EMAIL PROTECTED]; is 
not a valid group, but group:[EMAIL PROTECTED]' is.  The Geronimo versions 
appears to be incorrect, both in the implementation and the unit test.
However, according the Sun version is parsing :[EMAIL PROTECTED]; as being a 
simple internet address, retaining both the : and ; as part of the 
address.  Strict conformance to RFC822 would consider this to be an 
error rather than a simple address, and I don't believe most mail 
servers would accept that syntax.
So, what should I target here?  Compatibility with the Sun version, or 
conformance to the RFC822 specification?




Nice work.  My preference would be RFC822.  However, I do wonder how 
many people might get bitten by this - that are depending on the broken 
behavior.  Sun's JavaMail has been around for quite a while.  Maybe a 
org.apache.geronimo.be.broken.like.sun property to allow people that 
do depend on it to turn it on?


:)

geir


Rick

Re: javamail InternetAddress parsing.

2006-01-04 Thread Geir Magnusson Jr




Jacek Laskowski wrote:

2006/1/4, Geir Magnusson Jr [EMAIL PROTECTED]:



Nice work.  My preference would be RFC822.  However, I do wonder how
many people might get bitten by this - that are depending on the broken
behavior.  Sun's JavaMail has been around for quite a while.  Maybe a
org.apache.geronimo.be.broken.like.sun property to allow people that
do depend on it to turn it on?



Seriously, that /might/ be helpful, e.g. while migrating apps to Geronimo.



I was dead serious :)

Right now, it appears that we have more people working on JavaMail 
implementation than Sun does.  Granted, theirs is complete, but still. 
This is an area where it would be nice to see an OSS community working, 
and it's darn useful software as well.


*If* Sun's bug is something people depend on, then we wouldn't want to 
make our software unusable by them - we'd also be letting them know 
their apps aren't RFC compliant, and they'd have the option to fix at 
their choosing.


geir

Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]

2006-01-04 Thread Geir Magnusson Jr.


+1

Matt, have you considered using a gmail account until you fix this?


On Jan 3, 2006, at 9:48 AM, Sachin Patel wrote:


forwarding this on behalf of Matt...

- sachin



Begin forwarded message:


From: Matt Hogstrom [EMAIL PROTECTED]
Date: January 3, 2006 9:47:28 AM EST
To: [EMAIL PROTECTED]
Subject: [Fwd: [Vote] 1.0 Release - Do we ship it?]

Can you forward thsi for me?  I'm still getting SPAM errors.  I've  
sent a note to Ken to see if he can help me decipher what's going on.


 Original Message 
Subject: [Vote] 1.0 Release - Do we ship it?
Date: Tue, 03 Jan 2006 09:21:30 -0500
From: Matt Hogstrom [EMAIL PROTECTED]
To: dev@geronimo.apache.org

All,

We have had the last candidate out and available since 12/22.  I  
personally have
had a chance to put the 12/22 build under performance stress and  
I'm satisfied
that the build is stable and runs in a variety of modes using  
DayTrader.


Despite the Christmas Holidays I have seen some traffic related to  
htis release
on the list so some folks have been kicking it around as well.  At  
this time I'd

like to call a vote to release 1.0.

[ ] +1 Release 1.0
[ ] -1 Do not release 1.0 (Reasons included)

Looks like we got through the last remaining significant bugs and  
thansk to all

who worked up to the end to get this release out there.

Matt







--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Release procedure (was Re: [Fwd: [Vote] 1.0 Release - Do we ship it?])

2006-01-04 Thread Geir Magnusson Jr.


my vote was of course with the expectation that it passes the TCK...

This brings up an interesting question, and a novel one since passing  
the TCK is an additional step on our release procedures that most  
projects don't worry about and it is very critical for us.


1) Right now, we vote on releasing a certain rev # in SVN head.  I  
think this is important to continue to do independent of the TCK,  
because it establishes a base of agreement before the heavy lifting  
of TCK passing is done.  (Of course, CI might help ensure that the  
official TCK step is less work/less surprises)


2) We then branch/tag/whatever, produce a binary, and run the TCK.

So now comes the question, what next?  We've learned that offering  
the tested binaries to the public as a release candidate is good -  
people find problems.  So do we do that from now on as a matter of  
course for some time (x days) and then vote on the final release?


That way we all agree to live with whatever bugs were found in the  
release candidate (if there were any found) or decide that they were  
too severe, and we fix and then try again.


Are there alternatives?

geir

On Jan 3, 2006, at 12:35 PM, Alan D. Cabrera wrote:


Date: Tue, 03 Jan 2006 09:21:30 -0500
From: Matt Hogstrom [EMAIL PROTECTED]

All,

We have had the last candidate out and available since 12/22.  I  
personally have
had a chance to put the 12/22 build under performance stress and  
I'm satisfied
that the build is stable and runs in a variety of modes using  
DayTrader.


Despite the Christmas Holidays I have seen some traffic related  
to htis release
on the list so some folks have been kicking it around as well.   
At this time I'd

like to call a vote to release 1.0.

[ ] +1 Release 1.0
[ ] -1 Do not release 1.0 (Reasons included)


Does it pass the TCK?  I will vote no until it does.


Regards,
Alan




--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]

2006-01-04 Thread Geir Magnusson Jr

I'm not sure that's true if changes were made post the initial vote. 
Formally, you want the PMC to vote on what is going to be released, and 
if it changed from the lets do a release to here's the release, we 
want the additional vote to at least protect the release manager - that 
person is then just acting on behalf of the ASF (via the PMCs wishes) 
rather than independently.


See my other post on this subject because it's an interesting problem.

geir

Davanum Srinivas wrote:

Matt,

You have already been authorized to make the release, even this vote
was strictly not necessary. It's you call as to when to make the
actual release binaries and send announcements.

thanks,
dims

On 1/4/06, Matt Hogstrom [EMAIL PROTECTED] wrote:


Thanks to those who have provided their input thus far.  For those who are
interested in casting a vote.  Please take the time to download and test the
server out.

Can someone help out on the process to follow in terms of quorum and time?

Here are the votes so far:

+1
Sachin Patel
Davanum Srinivas
Jeff Genender
Alan Cabrera
David Blevins
David Jencks
Bruce Snyder
Kevan Miller
Dain Sundstrom
Matt Hogstrom
Gianny Damour
John Sisson
Jacek Laskowski

-1
None





--
Davanum Srinivas : http://wso2.com/blogs/

Re: Happy New Year 2006!

2006-01-02 Thread Geir Magnusson Jr.


Happy New Year to you and to all!

geir

On Dec 31, 2005, at 6:40 PM, Jacek Laskowski wrote:


Hi,

It's 2006 in Poland, and it's definitely my pleasure to be the first
who wishes Happy New Year 2006! I wish you all to spend less time in
front of their computers, and if you have to, contribute your time to
Apache Geronimo ;)

Cheers,
Jacek


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Apache mini Geronimo (mini-G)

2005-12-20 Thread Geir Magnusson Jr.


We couldn't call that J2EE then...

On Dec 19, 2005, at 8:41 PM, Aaron Mulder wrote:


In truth, I think we can go further in allowing for a mini-Geronimo.
 For example, right now IIRC the core J2EE configuration contains
OpenEJB, and we could probably break out OpenEJB into a separate
configuration to let you easily configure a server without it.  I
think I've been convinced that more/smaller configurations is the way
to go, though we haven't figured out for sure how granular they should
get.

Thanks,
Aaron

On 12/19/05, Jan Bartel [EMAIL PROTECTED] wrote:

Faisal,

You can use either standalone Tomcat or Jetty containers to give
you web container plus a couple of j2ee frills like jndi, resource
mapping etc etc.

However, if you want to keep within the geronimo idiom, then Erik's
answer re cut-down installation is the way to go.

regards
Jan

Wade Chandler wrote:
--- Faisal Akeel faisal.akeel- 
[EMAIL PROTECTED] wrote:




If you look at the top reason that FireFox more
preferred over Mozilla
suite, this is because its small size and limited
focus feature.
So, Is there way to customize Geronimo to a simple
web container (jetty) and
small foot print database (derby) only, instead of
big J2EE application and
if it possible can anyone provide guide or a demo
example on the wiki web
site.
Some people like mini cooper over big SUV car.




That's what Tomcat is for.

Wade






--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Release 1.0 Status - Release Candidate 20051219 Available for Review

2005-12-20 Thread Geir Magnusson Jr.


Nice job with all this matt.  It cant be easy.

inline...

On Dec 19, 2005, at 3:29 AM, Matt Hogstrom wrote:




That said, as release manager I am officially declaring the release  
closed barring TCK failures or any other serious issues.  Serious  
in my mind means corrupted data or intolerable outcomes.




How much time do you want to have people play with it?  Given the  
rush for the marketing deadline is passed, how about voting for a  
RC that sits for a week for people to play with?  We could even get  
some notice out there on TSS et al to let people find the whoppers if  
there are any left.



That said, the new build is available at http://people.apache.org/ 
~hogstrom/geronimo-1.0  and the file names are:


geronimo-jetty-j2ee-1.0-20051219.zip
geronimo-jetty-j2ee-1.0-20051219.tar.gz
geronimo-jetty-tomcat-1.0-20051219.zip
geronimo-jetty-tomcat-1.0-20051219.tar.gz



What's the idea behind this naming scheme for the zips/tgzs?

geir

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: svn commit: r358103 - /geronimo/site/docs/contributors.html

2005-12-20 Thread Geir Magnusson Jr.


Did you do this by hand, or via the xml source file?

geir

On Dec 20, 2005, at 4:06 PM, [EMAIL PROTECTED] wrote:


Author: kevan
Date: Tue Dec 20 13:06:31 2005
New Revision: 358103

URL: http://svn.apache.org/viewcvs?rev=358103view=rev
Log:
update list of committers

Modified:
geronimo/site/docs/contributors.html

Modified: geronimo/site/docs/contributors.html
URL: http://svn.apache.org/viewcvs/geronimo/site/docs/ 
contributors.html?rev=358103r1=358102r2=358103view=diff
== 


--- geronimo/site/docs/contributors.html (original)
+++ geronimo/site/docs/contributors.html Tue Dec 20 13:06:31 2005
@@ -386,6 +386,18 @@
 tr
 td bgcolor=#a0ddf0 colspan=  
rowspan= valign=top align=left

 font color=#00 size=-1 face=arial,helvetica,sanserif
+Kevan Miller
+/font
+/td
+td bgcolor=#a0ddf0 colspan=  
rowspan= valign=top align=left

+font color=#00 size=-1 face=arial,helvetica,sanserif
+IBM
+/font
+/td
+/tr
+tr
+td bgcolor=#a0ddf0 colspan=  
rowspan= valign=top align=left

+font color=#00 size=-1 face=arial,helvetica,sanserif
 Mark DeLaFranier
 /font
 /td




--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: 1.0 Status: IRC Report

2005-12-19 Thread Geir Magnusson Jr.

I just saw the re-tagging to 1.0.0, as if we know there are problems  
and are setting the stage for 1.0.1.  (There's been no public  
discussion of this as far as I can tell...)


I've never seen anything like this before, doing a 1.0.0 with  
knowledge aforethought about 1.0.1.  If we know there are problems,  
why not get the fixes in there?  I'm not talking about perfection, or  
every feature on every wish list,  but getting confidence over even a  
week of testing would be worth a lot.


Dain was adamant about it, but has so far not explained why it was so  
important to rush this out like this.  I appreciate the stellar  
amount of work going into this, and I'm aware that I'm not doing it,  
but still - is anyone willing to answer why it needs to be pushed out  
on this timetable?


People need to start trusting software that we release, and IMO  
putting out a 1.0 that we know isn't ready doesn't get us closer to  
that goal of community trust.  There's been a little under 2.5 years  
of tremendous passion and energy from many many people that went into  
this.


geir


On Dec 18, 2005, at 6:39 PM, Aaron Mulder wrote:


On 12/18/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

release as what?  rc1 or 1.0?


That was not specifically discussed, but my sense is 1.0 because now
that I look, Matt referred to putting other fixes in 1.0.1.

Thanks,
Aaron


On Dec 18, 2005, at 6:16 PM, Aaron Mulder wrote:


Alan, Matt, and I spoke about the release on IRC.  Matt's thoughts
are:

1. integrate the shell script changes to reduce verbosity. Matt  
thinks

this is important because its a customer's first impression and an
ECHO OFF is fairly trivial (famous last words)
2. Integrate the fixes from JGenender for clustering since this is
such a big thing for users and this was advertised to folks.  The
change looks reasoinalbe...doesn't seem to risk TCK testing and  
if it

doesn't work we're no worse off than we are now
3. (Aaron paraphrasing) Include the simple security patch to reject
logins if web.xml has security settings but the Geronimo plan is not
provided or does not have security settings.  The proposal to change
our Jetty system to use a default realm with no users in it has a
higher risk of breaking something (plus, it's not ready).
4. Tag and cut a set of binaries tonight and start a TCK run

Alan thought we should TCK and release the build that Matt made last
night.  I thought that we should integrate the changes above and TCK
and release that.

At the end of the conversation Matt asked me to summarize the
conversation and said of the 4-step plan above: you can give it  
my +1

and barring core dumps in Java this is it.   I'll build tonight and
ask David Blevins to start the TCK on it.

After that John Sisson pointed out that we have not fixed the  
issue of

spaces in the names of certain files in the documentation.

I'm not totally clear whether Matt wanted more input or whether he's
made his final decision as release manager, but I would assume  
that if

anyone feels strongly that the plan above is a mistake then they
should speak up right away.  :)

Thanks,
Aaron


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]





--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Release 1.0 New Build Available

2005-12-18 Thread Geir Magnusson Jr.

:   c:\matt_spin_121805\geronimo-1.0
Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var\temp
Using JRE_HOME:c:\j2sdk1.4.2_08










--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Release 1.0 New Build Available

2005-12-18 Thread Geir Magnusson Jr.



Why *not* put up an RC that we can release (i.e. distribute for  
people to work with rather than an unofficial candidate that we put  
in some persons directory)?


Can you give a reason why you are against the RC?  1.0 is important  
for the whole project.  It's really a big accomplishment.


geir


On Dec 18, 2005, at 3:25 PM, Dain Sundstrom wrote:


-1 to doing an rc

Lets do 1.0.0 now and 1.0.1 in two weeks.

-dain

On Dec 18, 2005, at 12:16 PM, Geir Magnusson Jr. wrote:


+1

Do an RC and publicize it.  We'll get a surge of interest.  Let  
people beat the tar out of it.  Having a 1.0 would have been a  
nice tie-in to ApacheCon, but that's over now.


Maybe let the RC process run over the holiday season, and hit the  
world with a 1.0 right after New Year as people get back to work,  
recharged, saws sharpened and ready to do new things.  Lets make a  
splash then - go into the New Year on all cylinders...


geir


On Dec 18, 2005, at 2:04 PM, Aaron Mulder wrote:


Another major problem:

If you deploy a WAR with security settings an no geronimo- 
web.xml, all
supposedly secure content is unprotected!  Try deploying this  
with no
plan: http://cvs.apache.org/repository/geronimo/wars/geronimo- 
ldap-demo-1.0-SNAPSHOT.war

and then visiting
http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and  
clicking the

links to secure and forbidden.  Both links work, with no login
prompt.  Instead, IMO, you should get a login prompt and (since no
realm was configured) all logins should fail.

-1 to releasing without the fix.  :)  I'm sorry, this is the stuff
that's supposed to be flushed out during the release candidate
phase.  We never had one since we were trying to get 1.0 out the  
door
in 30 seconds or less, but now we're having one, and I think we  
ought

to use it.  I'd rather release a solid 1.0 in a week instead of a
broken one now.

Aaron

On 12/18/05, Dain Sundstrom [EMAIL PROTECTED] wrote:

-1 to all fixes

We're never going to get this release out at this rate.  Let's list
these as known issues and plan for a 1.0.1 release in two weeks.

-dain

On Dec 18, 2005, at 10:51 AM, Jeff Genender wrote:

Cool...I have a clustering GBean fix...so since we need to  
rebuild I

would like to slide mine in too.

Aaron Mulder wrote:
I'd like to put one more fix in here -- sorry, but I just got  
back to
my internet connection.  Right now if you put a username or  
password
of blank in the database pool portlet, the deployment fails.   
This is
of course required for connections to the embedded Derby  
instance,

and
I have the fix ready.

Thanks,
Aaron

On 12/18/05, Dave Colasurdo [EMAIL PROTECTED] wrote:
Can we also address part 2 (shutdown error) of  
GERONIMO-1371?  It

fails
consistently when issuing a startup followed by a shutdown..
Anyone have any insight here?  If we don't fix it, we should add
this to
the Release notes as a known issue.

BTW, looking through the release notes... I assume Specific  
Issues,
Features and Improvements for Version 1.0 is a list of  
things that

already have been fixed in 1.0.  We may want to make this a bit
clearer.
  Specific Issues, Features and Improvements *fixed* for  
Version

1.0

Hmm.. Should there be a section in the release notes for common
known
issues (JIRAs) or do you feel that a link to JIRA is sufficient?
The
Significant Missing Features section info is much broader and
not at a
JIRA granularity.


Thanks
-Dave-

Dave Colasurdo wrote:

Matt Hogstrom wrote:


Deferring to 1.1
GERONIMO-1371 - Geronimo startup/shutdown issues


Any chance of incorporating part 1 of JIRA 1371?  It is simply
adding an
 @echo off to startup.bat (and a launching new window
message).

While not a functional problem, it sure will make a big
difference as to a user's first impression of geronimo..

Have attached the patch to the JIRA..

Here is the output with the fix:

C:\matt_spin_121805\geronimo-1.0\binstartup
Using GERONIMO_BASE:   c:\matt_spin_121805\geronimo-1.0
Using GERONIMO_HOME:   c:\matt_spin_121805\geronimo-1.0
Using GERONIMO_TMPDIR: c:\matt_spin_121805\geronimo-1.0\var 
\temp

Using JRE_HOME:c:\j2sdk1.4.2_08

Launching Geronimo in a new window


Here is the output Without the fix:

c:\matt_spin_121805\geronimo-1.0\binstartup

c:\matt_spin_121805\geronimo-1.0\binif Windows_NT ==
Windows_NT
setlocal

c:\matt_spin_121805\geronimo-1.0\binset
CURRENT_DIR=c:\matt_spin_121805\geronim
o-1.0\bin

c:\matt_spin_121805\geronimo-1.0\binif not  ==  goto  
gotHome


c:\matt_spin_121805\geronimo-1.0\binset
GERONIMO_HOME=c:\matt_spin_121805\geron
imo-1.0\bin

c:\matt_spin_121805\geronimo-1.0\binif exist
c:\matt_spin_121805\geronimo-1.0\
bin\bin\geronimo.bat goto okHome

c:\matt_spin_121805\geronimo-1.0\bincd ..

c:\matt_spin_121805\geronimo-1.0set
GERONIMO_HOME=c:\matt_spin_121805\geronimo-
1.0

c:\matt_spin_121805\geronimo-1.0cd c:\matt_spin_121805
\geronimo-1.0\bin

C:\matt_spin_121805\geronimo-1.0\binif exist
c:\matt_spin_121805\geronimo-1.0\
bin\geronimo.bat goto

Re: [VOTE] geronimo-1.0 (3rd try)


can we make this an RC1 so people can shake it out a bit?

There seem to be problems being reported even before we have finished  
the vote...


geir


On Dec 15, 2005, at 3:33 PM, David Blevins wrote:

Alright, I repacked the binaries that Jeff created to workaround  
the gbean startup issue.  I have the tck running on them now.


Here are the binaries for review. Please be sure you delete the old  
ones from your system before downloading the new ones.


http://people.apache.org/~dblevins/geronimo-1.0-proposed-final-3/

These versions of these programs where used to create the binaries:

  - tar (GNU tar) 1.15.1
  - Zip 2.3 (November 29th 1999)
  - OpenSSL 0.9.7f 22 Mar 2005
  - gpg (GnuPG) 1.4.1


[ ] +1 Release these binaries provided they pass the J2EE TCK
[ ] -1 Veto the release (provide specific comments)

Let's get this thing out the door!

-David


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

proposal : lets do an RC for a week or so before leaping to the 1.0 ? [Re: [VOTE] geronimo-1.0 (3rd try)]



subject line says it all.  We also need to figure out what to do  
about the press release...


geir

On Dec 16, 2005, at 7:59 AM, Sachin Patel wrote:


Due to amount of problems reported, I too change my vote to a -1.


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: proposal : lets do an RC for a week or so before leaping to the 1.0 ? [Re: [VOTE] geronimo-1.0 (3rd try)]



On Dec 16, 2005, at 2:05 PM, Matt Hogstrom wrote:


Geir,

We need to fix the outstanding issues so here is no argument  
there.  I talked to Jencks this morning and it looks like there is  
an issue with dependencies not working correctly.


the DayTrader issues are not in the application but rather in that  
the web app appears to be initializing before the EJB container is  
initialized and is causing the object not found exeception.  This  
needs to be fixed.  Dave and I are chasing this down today.


Great on both - I had no doubt this would be the case.  What do you  
think we should do as a release plan?




Regarding the press release we've updated the Geronimo web site to  
let folks know that it really isn't out yet.  For the time being I  
see that as being covered although I'm interested in how to do the  
release when its actually ready.  It was unfortunate that the  
release went out when we were clearly not ready.  Thoughts on how  
to address that issue?


Yes.

geir



Matt

Geir Magnusson Jr. wrote:
subject line says it all.  We also need to figure out what to do   
about the press release...

geir
On Dec 16, 2005, at 7:59 AM, Sachin Patel wrote:

Due to amount of problems reported, I too change my vote to a -1.




--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: 1.0 Release Status



On Dec 16, 2005, at 2:48 PM, Matt Hogstrom wrote:


All,

Rather than continue on one of the outstanding release chains its  
appropriate to start a new thread on where we are at and what we  
are doing.


First, the outstanding issues with the release candidates clearly  
show that there are some issues that need to be resolved.


are these Release Candidates in the RCx sense, or candidates for 1.0  
release?



The most significant is the error that is thrown during  
intialization.  It is not, as was previously thought, an issue with  
copying the database files upon initial execution.  It is rather  
associated with a race condition between the web-app being  
initialized and the EJB container reaching an initialized state.   
We are working on this issue and as such all previous release  
candidates should be discarded and ignored for now.  We will track  
down the issues related to initialization as well as the other  
problems reported and put out a new release candidate.


Second, thanks to all that are doing the testing and taking time to  
download and install the images on various operating systems.  We  
very much appreciate your investement of time and interest.  Your  
feedback is noted and will be incorporated where possible.


Here are the outstanding issue that I've noted from the feedback on  
the list:


GERONIMO-1363 - DayTrader still using old geronimo-spec files - fixed
GERONIMO-1371 - Geronimo startup/shutdown issues
GERONIMO-1372 - Exception during startup - TradeEJB
GERONIMO-1375 - Invalid login to console should not produce stack  
trace


If I missed one please let me know.

Regarding the press release I'd like to ask Bruce and Geir to  
tackle that issue.  Can you guys help out there?


It's an interesting problem.  I know the PRC is thinking about it  
too.  I've never seen an OSS project issue a retraction, but that may  
be something worth considering...


geir



Thanks.

Matt



--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: 1.0 Release Status



On Dec 16, 2005, at 5:12 PM, Dave Colasurdo wrote:


Geir Magnusson Jr. wrote:

It's an interesting problem.  I know the PRC is thinking about it   
too.  I've never seen an OSS project issue a retraction, but that  
may  be something worth considering...
The geronimo website properly describes the current situation.  
Let's aim to make Geronimo v1.0 available within the next week and  
issue a new press release (with clarifications) when we complete.


Lets make v1.0 available when it's ready.

No need to draw undue attention to the current situation with a  
retraction press release.


It's more than just about the v1.0 release.

geir

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [VOTE] geronimo-1.0 (3rd try)

2005-12-15 Thread Geir Magnusson Jr.


is this 1.0 or a RC?

On Dec 15, 2005, at 3:33 PM, David Blevins wrote:

Alright, I repacked the binaries that Jeff created to workaround  
the gbean startup issue.  I have the tck running on them now.


Here are the binaries for review. Please be sure you delete the old  
ones from your system before downloading the new ones.


http://people.apache.org/~dblevins/geronimo-1.0-proposed-final-3/

These versions of these programs where used to create the binaries:

  - tar (GNU tar) 1.15.1
  - Zip 2.3 (November 29th 1999)
  - OpenSSL 0.9.7f 22 Mar 2005
  - gpg (GnuPG) 1.4.1


[ ] +1 Release these binaries provided they pass the J2EE TCK
[ ] -1 Veto the release (provide specific comments)

Let's get this thing out the door!

-David


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [Vote] Geronimo V1.0 Release binaries

2005-12-13 Thread Geir Magnusson Jr .


+1 assuming the binaries pass the TCK

On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote:

We are currently going through the final testing phases and have  
the binary images available for review.  These images represent  
what we will be making available to users after we confirm the  
final set of tests.


Please take some time to download a binary and review it for  
completeness.  The  binaries you will be most interested in are:


http://people.apache.org/~dblevins/geronimo-1.0/

geronimo-jetty-j2ee-1.0.tar.gz
geronimo-jetty-j2ee-1.0.zip
geronimo-tomcat-j2ee-1.0.tar.gz
geronimo-tomcat-j2ee-1.0.zip

The .gz files are for *nix platforms and the .zip binaries are for  
Windows.


There are other files in the distribution for your reviewing  
pleasure like source and signature files.


Please post your votes and comments.  Thanks

[ ] +1 Release these binaries
[ ] -1 Veto the release (provide specific comments)

~ Matt



--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [Vote] Geronimo V1.0 Release binaries

2005-12-13 Thread Geir Magnusson Jr.


I assume david is still uploading?  they aren't all there...

On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote:

We are currently going through the final testing phases and have  
the binary images available for review.  These images represent  
what we will be making available to users after we confirm the  
final set of tests.


Please take some time to download a binary and review it for  
completeness.  The  binaries you will be most interested in are:


http://people.apache.org/~dblevins/geronimo-1.0/

geronimo-jetty-j2ee-1.0.tar.gz
geronimo-jetty-j2ee-1.0.zip
geronimo-tomcat-j2ee-1.0.tar.gz
geronimo-tomcat-j2ee-1.0.zip

The .gz files are for *nix platforms and the .zip binaries are for  
Windows.


There are other files in the distribution for your reviewing  
pleasure like source and signature files.


Please post your votes and comments.  Thanks

[ ] +1 Release these binaries
[ ] -1 Veto the release (provide specific comments)

~ Matt



--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

[jira] Closed: (GERONIMO-627) Geronimo Incubator Web Page Must Die!

2005-12-11 Thread Geir Magnusson Jr (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-627?page=all ]
 
Geir Magnusson Jr closed GERONIMO-627:
--

Resolution: Fixed

fixed.  done.  I heart forrest

 Geronimo Incubator Web Page Must Die!
 -

  Key: GERONIMO-627
  URL: http://issues.apache.org/jira/browse/GERONIMO-627
  Project: Geronimo
 Type: Task
 Versions: 1.0-M5
  Environment: n/a
 Reporter: Leonard Norrgard
 Assignee: Geir Magnusson Jr
 Priority: Blocker
  Fix For: 1.0


 The old incubator web page for Geronimo has no reference or indication that 
 Geronimo has moved on from the incubator stage. This leads to visitors 
 thinking the project may have ended, especially given the last news item on 
 display (which is from 2003...).
 http://incubator.apache.org/projects/geronimo.html
 Also the incubator page is the number one Google hit for queries on apache 
 j2ee and apache ejb, so many people will only find the outdated incubator 
 page.
 http://www.google.com/search?q=apache+j2ee
 http://www.google.com/search?q=apache+ejb

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

Re: Using Confluence

2005-12-09 Thread Geir Magnusson Jr.



On Dec 9, 2005, at 3:19 AM, John Sisson wrote:



There are other ways to do documentation that can be exported to  
both PDF and HTML.  These other methods also allow documentaton  
(the manuals) to be edited off-line and stored in svn.




+1 :)

geir

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Does there need to be a default web container?

2005-12-09 Thread Geir Magnusson Jr.


Guarana!

On Dec 9, 2005, at 11:40 AM, Rajith Attapattu wrote:


I feel this debate is like do you like Coke or Pepsi?
People will be more biased about the web container they use most of  
the

time (forget about merits/demerits of each app)

I think it's kind of useless to be arguing about this since both  
tomcat

and jetty is available. So ppl will always choose to modify the config
to have the container they like most.

(This would have been an important debate, if we were going to include
only one (either tomcat or jetty), but since both are included it
doesn't really matter)

Instead we should use the time to put more documentation on how you  
can
change the web container. I think a lot of people will appreciate  
that.


Just my 2 cents

Rajith.

-Original Message-
From: Jeff Genender [mailto:[EMAIL PROTECTED]
Sent: Friday, December 09, 2005 12:54 AM
To: dev@geronimo.apache.org
Subject: Re: Does there need to be a default web container?

Thats a great idea...

Kinda like Google's I'm feeling lucky ;-)

Matt Hogstrom wrote:

[EMAIL PROTECTED]

[EMAIL PROTECTED]
[EMAIL PROTECTED]

In-Reply-To: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1
X-MMS-Smtp-Auth: Authenticated As [EMAIL PROTECTED]
X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1

I think the magic G-ball should be embedded in the installer and let

it make a

random choice for the user :)

The answer is It is decidedly so.

Matt

Jeff Genender wrote:
Then lets agree to disagree.  We should probably take this  
offline if

it

needs to be discussed further.  This is kind of off-topic.

Jeff

Aaron Mulder wrote:


Sorry Jeff, I have to disagree.  If you asked me whether you should
use Tomcat or Jetty, I really couldn't give you an informed answer.
About the best I could say is they both work fine in Geronimo,  
they

do a couple things like virtual hosting slightly differently, and

the

Jetty team is actively involved in Geronimo whereas we pretty much
built the Tomcat integration on our own.  Still, that doesn't give
you much guidance (the last bit there is the only reason I

personally

would have any preference at all).  And I feel like I'm in the

*most*

informed 1% of all possible Geronimo users.

I don't think it's sensible to argue over what average people  
know

or don't know, it's just my feeling that if I can't make a clear
decision for obvious reasons, then I can't ask every user who ever
installs the product to make that same decision.

Thanks,
Aaron

On 12/8/05, Jeff Genender [EMAIL PROTECTED] wrote:


Erin Mulder wrote:


Jeff Genender wrote:


So you think your average Geronimo user will have no idea what a

web

container is?

It's possible.

I asked average user...not whether its possible.  The average

user

will probably be a developer...who has done some degree of

background on
the technologies.  I would hazard to guess there are few people  
who

use

BEA or Websphere and have absolutely no idea what a web container

is.


The developer will likely know what it is.  I have a hard time  
with

equating someone's clickety-click Mom with our average user...its
ridicules, which was really what my previous response was directed
towards.


There are a lot of experienced J2EE developers out there who have

only

ever used full commercial stacks.  Asking them to choose between

two

web
containers is like asking them to choose EJB, MQ and Web Service
implementations.  They may pick Tomcat because they vaguely

recognize
the name, but having to make that choice will add anxiety to  
their

install experience.

I am sorry but I cannot agree here.  I cannot believe there are

many

experienced *J2EE* developers who have no idea what a web

container
is.  That is preposterous.  Are there some?  Sure - but I would  
say

very

few.  However, in servlet 101...of which many of these

un-knowledgable

users would go, surely a mention of a web container, what it is,

and

what they can use (including books, articles, internet), they

should

have a minimal understanding of web containers.


Geronimo is also likely to become popular in academic settings

(both

classroom and self-study) where people will need to install the

server

before they get around to learning what a web container is.

The academic component is such a small microcosm in the grand

scheme of

users, this not even a reason to think its has a major effect of

the

overall user-base.  We should push the direction of Geronimo

towards
what the community wants.  If the community wants Jetty, give  
it to

them. If they want Tomcat, then let them have this.  Let the

community

decide.


Cheers,
Erin






--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: VOTE: release our specs at version 1.0 now


+1 go for it

On Dec 5, 2005, at 1:31 PM, David Jencks wrote:

Lets build version 1.0 of our specs right now, get them in an  
accessible repo, use them for the tck, and when it passes push them  
to m1 and m2 non-snapshot repos.  We will make a best-effort  
attempt to have m1 groupIds of org.apache.geronimo.specs but if  
this causes too many build/tck problems will resort to geronimo- 
specs.  m2 groupId will be o.a.g.specs in any case.


[ ] go for it
[ ] don't care
[ ] no, because.

thanks
david jencks



--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [VOTE] Sponsor OpenEJB to become sub-project of Geronimo


with whom?  Sun?

On Dec 5, 2005, at 2:09 PM, David Blevins wrote:

We'd still like to have them, obviously.  I'm optimistic something  
could be worked out.


-David

On Dec 4, 2005, at 8:21 PM, Geir Magnusson Jr. wrote:

I'm for this, but quick question - what would you do with the  
standalone server distros?  IIRC, you can't distribute anything  
called EJB outside of the full tested container stack as per the  
spec license...


geir

On Dec 3, 2005, at 2:00 AM, David Blevins wrote:

The OpenEJB committers have discussed it and voted to be become a  
Geronimo sub-project.  The incubator proposl is here:


http://wiki.apache.org/incubator/OpenEjbProposal

Please vote if you'd like Geronimo to be the sponsor of OpenEJB  
during incubation


[ ] +1 = I support the move to sponsor OpenEJB during incubation  
as a sub-project of Geronimo

[ ] +0 = I don't mind either way
[ ] -1 = I don't support this move because: ___

+1 from me

--
David




--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]






--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Geronimo Web Site Design


nice!

On Dec 6, 2005, at 6:01 PM, Epiq Geronimo Team wrote:

We have been working on possible web site designs and would like to  
obtain the feedback of the community.   Here are five different  
design types:


http://www.epiqtech.com/corp/products/technology/opensource/ 
apachegeronimoweb.htm


Each of these designs contains distinct elements (bar or tab  
primary navigation, header design, left nav bar type, secondary  
navigation type).  Based on the feedback from the community, we can  
use colors, design options, or items that are good from one design  
in order to create a more refined design based on community feedback.


Best regards,


Epiq Team


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [Vote] 1.0 Branch for Geronimo at Noon EST on 12/7


man, that's short notice...

I'm happy to see the branch, but in general, that's way too short..

On Dec 6, 2005, at 11:41 PM, Matt Hogstrom wrote:

I'd like to get a concensus on branching an official V1.0 branch on  
Wednesday at noon.  It looks like most features are done and we  
need to actively fix (remove) things to get 1.0 out the door.


[ ] +1 Branch at noon
[ ] -1 Don't branch (must provide proposed alternative)



--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [Vote] Alternate Proposal for Branch V1.0 for Geronimo at 23:59 PST 12/7


isn't that still less than 24 hours?

:)
On Dec 7, 2005, at 1:04 AM, Matt Hogstrom wrote:

One more time.  Based on wildly popular feedback.  Here is an  
alternate branching proposal.


[ ] +1 Branch V1.0 at 23:59 PST 12/7
[ ] -1 Defer branching provide proposed alternative

Matt



--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Geronimo BOF at ApacheCon : Tuesday, Dec 13, 2005 - 8:30pm

We have a BOF slot at ApacheCon 2005.  We have 60 minutes, so I'd  
like to see if we can pre-plan what we do and structure it a bit.   
Aaron was interested in presenting something, and I'm sure others are  
as well.


So maybe we do something like 2-3 10 minute slots for formal  
presentations.


I'd really like to try doing Geronimo Lightning Talks.  It would  
work like this :


1) Anyone interested in speaking for 5 (five) minutes on any topic  
related to Geronimo, serious or funny, technical or not, will put  
their name on a slip of paper into a hat.  I'll bring a hat.


2) We choose names at random from the hat, and when your name is  
called, you have 5 minutes to talk, including the time to get to the  
front.


3) At the 5 minute mark, you will leave the front or be manhandled  
off stage by our documentation goons.


You can do this in pairs.  Humor is appreciated.  Any topic is  
welcome, but please have some [tenuous] relationship to Geronimo.


If you aren't used to talking in public, this is a great chance to  
try it.  It's only for 5 minutes, it gets people a chance to know you  
and what you are doing, and it really is an informal, fun setting...


Thoughts?

geir


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: [Vote] Installer: Default Web Container Selection