Re: [ANNOUNCEMENT] Apache Geronimo v3.0-beta-1 Released!

[Bill Stoddard]

Congratulations!


On 11/16/11 9:32 AM, Kevan Miller wrote:

Great work everyone!

There's also been a press release from the ASF.

--kevan
On Nov 15, 2011, at 10:22 PM, Rex Wang wrote:


The Apache Geronimo project is very glad to announce the release of Apache 
Geronimo v3.0-beta-1 server. It is the first open source solution other than RI 
that implements both the Java EE 6.0 Full profile and Web profile 
specifications.

This release has passed 100% of SUN's Java Enterprise Edition 6.0 Full Profile 
and Web Profile Certification Test Suites, and includes a great many new 
features, improvements, bug fixes.

Further more, Geronimo v3.0-beta-1 has transformed its kernel based on OSGi 
technology, so it natively supports OSGi programming model and new technologies 
in the OSGi enterprise marketplace, including:
- OSGi Blueprint Bundle
- OSGi Web Application Bundle (WAB)
- Enterprise Bundle Application (EBA).

Please see the detail information in the release notes: 
http://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-3.0-beta-1/RELEASE_NOTES-3.0-beta-1.txt

A couple highlights are:
Support SUN's Java Enterprise Edition 6.0 Full Profile specification:
- Servlet 3.0
- JSP 2.2
- JSTL 1.2
- JSF 2.0
- EL 2.2
- EJB 3.1
- JPA 2.0
- JTA 1.1
- JTS 1.0
- JDBC 3.0
- JNDI 1.2
- JMS 1.1
- JMX 1.2
- JACC 1.4
- JASS 1.0
- JASPIC 1.0
- JAX-WS 2.2
- JAX-RPC 1.1
- JAX-RS
- JAXR 1.0
- JAXB 2.2
- JAXP 1.3
- SAAJ 1.3
- Java Mail 1.4
- DI 1.0
- Bean Validation 1.0
- Common Annotations 1.0
- CDI and DI 1.0
- Debugging support for other languages 1.0
- Managed Beans 1.0
- Interceptors 1.1.

For details about Full Profile specifications, please visit Java EE 
specifications website.

Support OSGi Core Specification v4.3 and part of Enterprise Specification v4.2, 
including:
- Configuration Admin Service Specification
- Blueprint Container Specification
- Web Applications Specification
- JNDI Services Specification
- JPA service Specification
- JMX Management Model Specification.

For details about OSGi specifications, please visit OSGi Alliance website.

You can download the source jar and binary assemblies from 
http://geronimo.apache.org/apache-geronimo-v30-beta-1-release.html

The geronimo-tomcat7-javaee6-3.0-beta-1 assembly has passed the Java Enterprise 
Edition 6.0 Full Profile Certification Test Suite.
And the geronimo-tomcat7-javaee6-web-3.0-beta-1 assembly has  passed Java 
Enterprise Edition 6.0 Web Profile Certification Test Suite.

Thanks very much to various ASF partner projects that we include, e.g. Apache 
Tomcat, OpenJPA, OpenEJB, ActiveMQ, MyFaces, OpenWebBeans, Axis2, Aries etc.
And also a big THANK YOU to all committers and contributors for this release!  
Great work everyone!



Rex Wang,

Apache Geronimo Project

2011-11-15

Re: New server release process checklist

[Bill Stoddard]

On 11/30/10 3:35 AM, Rex Wang wrote:

Hi all,

I just wrote a checklist for the things I did during 2.1.7 release:
https://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.7+Release+Process

This contains all the key points of the new release process.

I also adjust the old process page to make it clear:
https://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+Release+Process

Hope this help for the following release managers..

regards,

--
Lei Wang (Rex)
rwonly AT apache.org 


Very good writeup!  Thanks for this.

Bill

Re: [RESULT] Release Geronimo 2.1.7 (2nd try)

[Bill Stoddard]

On 11/29/10 8:39 PM, Rex Wang wrote:


The vote to release 2.1.7 passes with 7 "+1" votes and no 0 or -1 
votes.  Voting +1 were


Rex Wang
Kevan Miller
Forrest Xia
Rick McGuire
Shawn Jiang
Ashish Jain
Rick McGuire

The artifacts will be promoted today and the download links updated 
accordingly.


Thanks all for the review.

-Rex

Congratulations Geronimo team!  Nice job!

Bill




--
Lei Wang (Rex)
rwonly AT apache.org 

Re: Problem building custom activemq for geronimo 2.1

[Bill Stoddard]

On 11/19/10 8:30 AM, Rick McGuire wrote:

On 11/19/2010 8:20 AM, Ashish Jain wrote:
Somehow I am again seeing some intermittent failures at times 
RoundRobinDispatchPolicyTest will fail and at times 
Spring2XmlNamesapceWithoutRemoteSchemaTest  is failing. This seems to 
be a very unpredictable behavior.


This suggests that activemq 4.1.2 build is quite unstable. I think it 
is better to use 4.1.2 as is and defer JIRA 5700 for 2.1.7 release.
Perhaps it makes sense to start working on an activemq upgrade for a 
2.1.8 release immediately after shipping 2.1.7 so it has time to be 
shaken out.  It's looking like we're going to have a tough time 
maintaining this now quite old activemq version.


Rick


+1





On Fri, Nov 19, 2010 at 3:47 PM, Ashish Jain > wrote:


Thanks Rex and Ivan!

My build runs successfully on linux now only change is I have to
disable the test DemandForwardingBridgeTest. I have applied the
patch as suggested in readme.txt 4.1.2-G20100308.README.TXT and
build runs successfully now. I have used sun java 1.5.0_13 and
maven 2.0.9. Now I am will apply the patch on GERONIMO-5700 and
will post my results.

--Ashish


On Fri, Nov 19, 2010 at 2:45 PM, Ivan mailto:xhh...@gmail.com>> wrote:

Those cases failed intermittently,  guess there is a time slot
somewhere. I will suggest to go ahead to apply the patch in
GERONIMO-5700, and try it with a full TCK first.

2010/11/19 Rex Wang mailto:rwo...@gmail.com>>

I encountered the same problem when only built
activemq-4.1.2 tag (without any of our patches).

I think we can comment our the test from the build
(activemq-4.1.2 had already commented out a lot of its
tests...)

-Rex

2010/11/18 Ashish Jain mailto:ashja...@gmail.com>>

Hi ALL,


I am working on GERONIMO-5700 which requires to add
new patches to geronimo custom activemq-core.
Somehow I am not able to build this following the
instructions in ""

2.1\repository\org\apache\activemq\4.1.2-G20100308.README.TXT"".


Till now I have NOT applied any new patches and using
the original ones as listed in
4.1.2-G20100308.README.TXT. I have tried
in Windows Xp SP3 and RHEL5 with a mix of Sun java5
and Sun java6. I do not have access to MACOS so donno
if the
build runs successfully in that.

Thanks
Ashish




-- Lei Wang (Rex)
rwonly AT apache.org 




-- Ivan

Re: [RESULT][VOTE] Geronimo 3.0-M1 release - 3rd attempt

[Bill Stoddard]

On 6/18/10 7:57 AM, Rick McGuire wrote:
The Vote passes with 4.5 +1 votes and no 0 or -1 votes.  Voting for 
the release were


Rick McGuire
Jarek Gawor
Kevan Woods
Donald Wood
Joe Bohn

Thank you for the time spent reviewing this.  The release artifacts 
will be promoted and made available for download ASAP.


Rick


Hi, Rick.
Couple of comments...

There's a problem with the names of the install packages.   Check out 
the link to the tomcat7 image on this page:

http://geronimo.apache.org/apache-geronimo-v30-m1-release.html

That link tries to download this file:
http://www.apache.org/dist/geronimo/3.0-M1/geronimo-tomcat7-javaee6-3.0.M1-bin.tar.gz

Actual name is:
http://www.apache.org/dist/geronimo/3.0-M1/geronimo-tomcat7-javaee6-3.0-M1-bin.tar.gz

Maybe a good idea to work up an announcement letter when GEP and sample 
apps are ready.


Bill


On 6/9/2010 4:13 PM, Rick McGuire wrote:
A new 3.0-M1 release candidate is ready for review.  The LICENSE 
problem has been corrected and the missed testsuite updates that 
Jarek noticed have been included.


See the JIRA issues here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315090&styleName=Text&projectId=10220 



Staged to

https://repository.apache.org/content/repositories/orgapachegeronimo-046/ 



The main artifacts up for vote are the source release archives

https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.zip 

https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.tar.gz 



If you vote you should at least examine these and make sure something 
plausible builds from them.


The voting will be open a minimum of 72 hours.

[  ] +1 about time to push this out the door
[  ]  0 no opinion
[  ] -1 not this one  (please explain why)

Rick

Re: [Discussion] How to display help informations on the Console

[Bill Stoddard]

On 6/14/10 10:01 AM, Donald Woods wrote:

#1-3 are good usability improvements.

Can we use Dojo for #4-6?  Seems hover help would be the best option, as
adding an example beside/below every field could require a lot of screen
area and doesn't cover the cases for links (like
Start/Stop/Restart/Delete).  Also, the portlet help page should
include the same text as the hoover help (which should be the same
resource strings), plus additional help text if needed.

#7 requires us to stop reorganizing the User Docs and would mean we
couldn't rename pages.  If we go this route, we should include a hidden
comment on each doc page with a reference back to the portlet that has a
link to it, so we know not to rename the page unless the portlet link is
updated too.
   


Connecting the documentation and console will be expensive to maintain.

As a general principle, I would suggest carefully weighing the 
'opportunity cost' of adding new features to the server that require 
on-going maintenance.  Each added feature that requires on-going 
maintenance takes time away from other potentially more important work.  
Over time as more 'on-going' maintenance requirements accumulate, the 
development team spends more and more effort to just tending to the 
maintenance; less time is spent on innovation and keeping current with 
technology trends.


Bill

Re: jconsole instructions

[Bill Stoddard]

On 5/11/10 1:48 PM, David Jencks wrote:
Every time I use jconsole I have to spend a long time trying to figure 
out how to connect to geronimo.  Not sure if its in the wiki but maybe 
if its on the dev list I'll be able to find instructions again.

Google's your friend :-)

This often works for me:
- go to the WebSphere Community Edition doc page: 
http://publib.boulder.ibm.com/wasce/Front_en.html0
- Select the version of CE (roughly equivalent to the G version) you're 
interested in.

- type jconsole in the google search box

The guys that develop the CE doc also develop a lot of the Geronimo doc; 
good deal of cross pollination happens.


Bill

Re: Geronimo 2.1.5 Release Status

[Bill Stoddard]

On 2/25/10 2:38 AM, Rex Wang wrote:

Hi all,

I make a summary of the current G 2.1.5 release status in 
http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.5+Release+Status

Feel free to update it if you have more information.

To do list and questions:
(1) Tomcat
Wait 6.0.25 release?


Tomcat 6.0.25 vote failed; stability issues cited.  Expect tomcat dev to 
move to release 6.0.26 once the issues are resolved.


Bill

Re: Geronimo 2.1.5 Release Status

[Bill Stoddard]

On 2/25/10 2:38 AM, Rex Wang wrote:

Hi all,

I make a summary of the current G 2.1.5 release status in 
http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.5+Release+Status

Feel free to update it if you have more information.

To do list and questions:
(1) Tomcat
Wait 6.0.25 release?

6.0.25 vote is happening now on d...@tomcat.

Bill

Re: [VOTE] geronimo 2.2 release (2nd try)

[Bill Stoddard]

Lin Sun wrote:

+1 able to start, stop the server, visited admin console and verified
a few link function okay.

Thanks for pulling together this release David.  I visited the jira
list, it contains hundreds of items!

  
Indeed, that's an impressive list!  Lots of good stuff in this release. 
Congrats!


Bill

Re: Welcome "Delos" Xuan Dai as a new committer

[Bill Stoddard]

Kevan Miller wrote:


On Jul 20, 2009, at 11:42 AM, Donald Woods wrote:

I would like to welcome Delos aboard, as he recently accepted the 
Geronimo PMC invitation to become a committer.  His account was 
created last week (delos), so you should start seeing some commits 
from him as soon as we finish granting him karma.


Congrats Delos!

You should be all set, karma-wise. Look forward to your contributions!

--kevan

Congratulations Delos!

Bill

Re: Possible for G to directly consume a Tomcat server config w/o changes?

[Bill Stoddard]

Lin Sun wrote:

One quick way would be allow users to start a tomcat server from a
geronimo tomcat javaee5 assembly  or little G tomcat assembly(say
geronimo.sh start tomcatOnly=true).   It is possible to just launch
the tomcat server, and read the configuration files (conf/server.xml,
etc) and start a tomcat server from a geronimo tomcat assembly, by
using the Catalina.java provided by tomcat.   But this server/app
would have no relationship with geronimo, other than using the jars
provided by the geronimo tomcat assembly.   The deployed app would be
tracked only by tomcat, and not by geronimo.   We should be able to
achieve this without adding any new jars.

If we need more than that, I can for seen the following issues that
need investigation -
1. We'll have to provide better server integration with tomcat and be
able to read the server configuration from tomcat's server
configuration files, along with using config.xml configurations.
  
This would be an absolute minimal requirement.  Would this be really 
difficult?



2. We'll have to migrate user's app automatically for the user, when
the user's app is a bit complicated that contains any need to require
a geronimo-web.xml

  
This is where things get more interesting lots of permutations and 
edge cases to consider.

Lin

On Mon, May 18, 2009 at 3:49 PM, Bill Stoddard  wrote:
  

I know G can't consume tomcat configs today, but is this a feature that
could be developed for G 2.2?

Say I have an application successfully deployed and running under Tomcat..
 wouldn't it be nice if I were able to drop the tomcat server config into a
Geronimo-Tomcat assembly, start the server, deploy the app and be up and
running in seconds.  I'm talking about a seamless, zero effort/zero touch
migration from Tomcat to a Geronimo-Tomcat assembly.  Is it possible?  If
not, what simplifying assumptions could be made to 'mostly' achieve a
zero-touch migration?
What are the primary challenges with consuming a tomcat config unchanged
with a G-Tomcat assembly?  Same Q's apply for Jetty... what's 'doable'
with-in reason?

Thanks,
Bill




  

Possible for G to directly consume a Tomcat server config w/o changes?

[Bill Stoddard]

I know G can't consume tomcat configs today, but is this a feature that 
could be developed for G 2.2?


Say I have an application successfully deployed and running under 
Tomcat..  wouldn't it be nice if I were able to drop the tomcat server 
config into a Geronimo-Tomcat assembly, start the server, deploy the app 
and be up and running in seconds.  I'm talking about a seamless, zero 
effort/zero touch migration from Tomcat to a Geronimo-Tomcat assembly.  
Is it possible?  If not, what simplifying assumptions could be made to 
'mostly' achieve a zero-touch migration? 

What are the primary challenges with consuming a tomcat config unchanged 
with a G-Tomcat assembly?  Same Q's apply for Jetty... what's 'doable' 
with-in reason?


Thanks,
Bill

Re: Thinking about a 2.2 release

[Bill Stoddard]

David Jencks wrote:


On Apr 15, 2009, at 10:42 PM, David Jencks wrote:


I've been assuming that the classloader work Gianny and I have been 
working on in my sandbox would get into 2.2.  At the moment I think I 
have the classloader framework more or less working and I'm going 
through the plugins working on setting up the required jar 
dependencies.  Only some of them can be derived from maven 
dependencies.  This is turning out to be a somewhat slow process.


I finally got the server to run with the one-classloader-per-jar 
setup.  After struggling with this for a couple of weeks and seeing 
the difficultly of correctly configuring classloaders I don't  think 
we should put this into 2.2.  For one thing classloading seems to be 
pretty slow: it takes about 55 seconds to start the jetty-jee5 server.


55 seconds to start... that's really bad  in comparison to the server 
today. The full Tomcat JEE5 assembly on my MBP will start in something 
like 20 seconds.. a minimal assembly under 10 seconds.  I've been seeing 
reports that JBoss 5 is slow and bloated compared to earlier releases... 
seems to be the natural evolution of app servers. 

Is the performane hit related to the design (classloader per jar) or 
something in how the design is implemented?


Bill

Re: [ANNOUNCE] Availability of Geronimo 2.1.4

[Bill Stoddard]

Joe Bohn wrote:


The Apache Geronimo project is pleased to announce the available of 
Apache Geronimo v2.1.4 server. This is primarily a maintenance release.


Among the updates and fixes included in the release are several 
security fixes for vulnerabilities in the administration console. 
Details of the security vulnerabilities fixed in this release can be 
found in the Security Report:

http://geronimo.apache.org/21x-security-report.html
Other fixes and enhancements are listed in the Release Notes:
http://cwiki.apache.org/confluence/display/GMOxDOC21/RELEASE-NOTES-2.1.4.TXT 



Visit the Downloads page for details on downloading Apache Geronimo 
v2.1.4 server assemblies:

http://geronimo.apache.org/downloads.html

A big THANK YOU to all that contributed to this release!  Great work 
everyone!


Joe


Congratulations!

Download statistics

[Bill Stoddard]

Poking through the apache.org logs, I see a large number of downloads of 
jar files from this directory:


http://www.apache.org/dist/geronimo/eclipse/updates/features/

Given the large number of downloads, I suspect these are being driven by 
automation.  Are these downloads being driven by G builds?


Bill

Re: G download stats

[Bill Stoddard]

Kevan Miller wrote:


On Jan 12, 2009, at 2:40 PM, Bill Stoddard wrote:

I'm sure most of you know about Vadim's Apache stats project for 
tracking download statistics for the verious Apache projects:


http://people.apache.org/~vgritsenko/stats/index.html 
<http://people.apache.org/%7Evgritsenko/stats/index.html>


A fun little project but exceedingly difficult (not to mention time 
consuming) for Vadim to dig into the details of each project in order 
to present project stats with finer details.


Just out of curiosity, I did some Ruby hacking to modify Vadim's 
apache log mining script to filter out Geronimo project data with 
finer resolution.  Here are the results:


http://people.apache.org/~stoddard/stats/data/ 
<http://people.apache.org/%7Estoddard/stats/data/>


BTW, if I understand what you are counting, then these statistics only 
represent some fraction of the actual downloads (i.e. the downloads 
from http://www.apache.org/dist/geronimo/ 
<http://www.apache.org/dist/geronimo/2.1.3/geronimo-tomcat6-javaee5-2.1.3-bin.zip> ) 
Downloads from the various Apache mirrors would not be counted... 
Wondering if hits to the mirroring system 
(e.g. http://www.apache.org/dyn/closer.cgi/geronimo/ ) would yield a 
more accurate statistic.


--kevan 
These stats include downloads redirected to the mirrors.   I do count 
the redirects for download artifacts by closer.cgi.   As expected, I 
have no way to determine if a redirect was successful... very possible 
some fractions of hits are duplicates (i.e., a mirror failed and the 
client came back for another mirror).


Bill

G download stats

[Bill Stoddard]

I'm sure most of you know about Vadim's Apache stats project for 
tracking download statistics for the verious Apache projects:


http://people.apache.org/~vgritsenko/stats/index.html

A fun little project but exceedingly difficult (not to mention time 
consuming) for Vadim to dig into the details of each project in order to 
present project stats with finer details.


Just out of curiosity, I did some Ruby hacking to modify Vadim's apache 
log mining script to filter out Geronimo project data with finer 
resolution.  Here are the results:


http://people.apache.org/~stoddard/stats/data/

I'll not bother commenting or summarizing on the different results 
because it's exciting in exactly the same way as watching paint dry.


The one item that might need a bit of explaining is the reference to 
'206W', so I'll cover that briefly...  A 'successful' reply to an HTTP 
Range request is a status '206'  response (see RFC 2616 if you want to 
know about range requests).   So the '206' in 206W refers to a 
successful reply to a Range request.  The 'W' means 'weighted' more 
on 'W' in a bit.


An example... if the size of a file to download is 100M, a client can 
make 10 range requests, each requesting a different 10MB segment of the 
file.  There are various reasons why a client might issue a range 
request (PDF, acrobat and similar viewers, high bandwidth but very low 
latency connections between the server and client and so forth. reason 
is not important to this explanation... ).  Each of the 10 Range 
requests will create a 206 reply entry in the web server's log file.  
So... if we are counting downloads of that 100MB file, it would be 
incorrect to count each 206 reply as a download.  The 'w', which stand 
for weighted... in this case, the '206W' download count would be '1'.  
The 10 206 replies are equivalent to 1 download of the 100 MB file.


fyi...

Bill

[Fwd: [Urgent] Please help promote ApacheCon video streaming!]

[bill stoddard]

--- Begin Message ---
Hi,

please help promote the ApacheCon live video streaming by forwarding
the email below to your PMC user and dev mailing lists, ASAP!

Thank you
Lars Eilebrecht

-

Subject: ApacheCon live video streaming available; keynotes and Apache 101 are 
free


Can't make ApacheCon this week in New Orleans?  You can still watch all 
the keynotes, Apache 101 sessions, and system administration track in 
live video streams:

   http://streaming.linux-magazin.de/en/program_apacheconus08.htm?ann

Keynotes and the Apache 101 lunchtime sessions are free; the full 
sysadmin track, including httpd performance, security, and server stack 
administration talks are available for a fee.

Keynotes include:
- David Recordon, Six Apart  (Wednesday 09:30)
   "Learning from Apache to create Open Specifications"

- Shahani Markus Weerawarana, Ph.D.  (Thursday 11:30)
   "Standing on the Shoulders of Giants"

- Sam Ramji, Microsoft  (Friday 11:30)
   "struct.new("future", :open, :microsoft)"


   Reminder: New Orleans is CST or UTC/GMT -6 hours.


Advance notice: ApacheCon EU 2009 returns to Amsterdam, 23-27 March.  We 
had a great response to our CFP and look forward to announcing the 
schedule in the next month.

---

-- 
Lars Eilebrecht  -  V.P., Conference Planning
[EMAIL PROTECTED]  -  http://www.us.apachecon.com



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


--- End Message ---

Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration

[bill stoddard]

Joe Bohn wrote:



Any ideas on PHP and if this would be another potential area for 
integration?

Python



Joe


Bill

Re: Geronimo 2.1&2.2 Documentation

[bill stoddard]

Joe Bohn wrote:

Hi Rhonda,

We're glad that you would like to help with the documentation. Before 
you can be given contributor access you must first file an ICLA 
(Individual Contributor License Agreement) with the Apache Software 
Foundation.  I just checked and I don't see a record of an ICLA on 
file for you yet.  Please let us know when it is filed and once 
verified we can grant you contributor access to the wiki.


You can find the form and information on how to submit it at this URL:
http://www.apache.org/licenses/


Hi Rhoda,
Here is the link to the ICLA pdf:
http://www.apache.org/licenses/icla.pdf

You can submit the form electronically by printing, filling out, 
signing, then scanning it.  Send the scanned and signed form to:


secretary at apache dot org
legal-archive at apache dot org

It will probably take about a week (maybe a bit more due to the upcoming 
labor day holiday) for the ICLA to be recorded by the secretary.


Bill

Re: apache httpd and geronimo -- newbie

[bill stoddard]

whitewaterbug wrote:

Mod_JK might give the right way to do this.

If httpd does certificate-based client side authentication using SSL, then
does mod_JK pass the certificate along to geronimo so it can use it for
application level authorization?

I think the whole certificate would still need to be sent over mod_JK
because sometimes authorizations are dependent on the content in the
certificate.

  

mod_headers should do what you need:

http://httpd.apache.org/docs/2.2/mod/mod_headers.html#header

mod_ssl sets (or can be configured to set) SSL per-request envars that 
can then be read by mod_headers.  Configure mod_headers to package the 
contents of the SSL envar into an HTTP header field on the request 
forwarded to the Geronimo instance.


Bill

Re: apache httpd and geronimo -- newbie

[bill stoddard]

whitewaterbug wrote:

Is it possible to have apache HTTPd run as the web server and geronimo run as
the application server? 
  
Yep, it's possible. Jason already pointed to the doc that works with 
Apache httpd 2.0. 


My suggestion is to use Apache 2.2 with mod_proxy and mod_proxy_http:

http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

You would want to use a basic 'Reverse Proxy' configuration.

Bill

Re: Documentation of new 2.2 features in current wiki?

[bill stoddard]

Been watching this conversation with interest... since the discussion 
has lagged, thought I'd throw a bit more fuel on the fire to completely 
burn down the topic. So here's what I see...


1) Developers need a 'low friction' place to document new content
The process needs to be dirt simple... go to wiki page 'foo', add page, 
add documentation to the page, done. Predictable, same process 
everytime, no need for the developers to figure out where it needs to go 
in the final doc tree (what is the final doc tree anyway), no need for 
the developer to necessarily even understand the project's overall 
documentation structure.  Developers need a place to just catch the 
essential facts, and move on.  Uncertainty of the developer about where 
to write the doc, or how to format it, or anything will increase the 
probability the developer will just conclude writing anything is just 
not worth the effort.  Lower barriers to entry... make easy for 
developers to capture their ideas, leave the organization to someone who 
likes to do that sort of work.


I've heard a couple of ideas here... Jarek suggested creating new 
content under a temp space. Joe said "I suggest that we create new 
content for 2.2 under this page for now: 
http://cwiki.apache.org/GMOxDOC22/what-changed-in-22.html ".  David's 
'clearly tagging new doc with a version statement' is a variation of the 
above.  Sounds reasonable to me, and unless I misread any of the 
replies, I think this meets the developer's requirements and I don't 
think it is on conflict with Rebekah's proposal. 


2) On going maintenance of the doc
David's primary concern (which I share) is that what ever process we 
adopt for G documentation should lend itself to being maintained.  If 
all we have are developers maintaining documentation, then our doc 
structure will 'trend to' being flat and unorganized because that 
requires the least maintenance.  If all we have is developers 
maintaining the documentation, I also agree with David's conclusion that 
we should maintain a single documentation tree and tag new doc with a 
clear version statement.  However. if I've not misread any emails,  
I think Rebekah is volunteering (with help from her colleagues)  to 
maintain the structure of our documentation, and create a new doc tree 
for each release of G (or a least when it make sense to create a new doc 
tree. The idea that she is volunteering to maintain the structure for 
the development team is the essential point... not the specific 
decisions about the exact nature of the structure of the final 
documentation).


3) Documentation structure...
If Rebekah can maintain the doc structure she has proposed going forward 
while also enabling the developers to easily create new doc for new 
features, then I am a strong +1 to following her lead. 


Conclusion:
We have someone showing up in the community to start what is essentially 
an Apache Geronimo documentation project tuned to the needs of the 
development community but offloading a lot of the 'chore' of maintaining 
the doc structure from the development community.  What's not to like 
here? .. let's make sure that the basic needs of the development 
community are met then let's get out of her way and let her contribute.


BTW, +1 for the 'single document' (infocenter? what's that?) approach.  
I strongly dislike the 'users' vs 'developers' bifurcation; the two are 
indistinguishable in the Geronimo community.



Bill


Joe Bohn wrote:


Hi Rebekah,

I just posted a note about a new space that I created for the 2.2 
documentation.  The new space was really created just to get things 
moving for 2.2.  It was not a statement of what the final structure 
should be ... so please feel free to continue to explore this area and 
receive comments.


I personally haven't had a chance to consider the alternatives you 
presented below.  However, my inclination is to keep the current 
structure "as is" unless there are obvious problems with the 
organization and there are resources willing to invest the time and 
effort to change things.  Can you provide some more information on 
what is driving the changes that you are proposing?


Thanks,
Joe



wei zhang wrote:

Hi there,

This is Rebekah and I've been reading through the documentation with 
my colleagues for a while. I think we can keep the current version of 
the documentation and create another space for v2.2, because there 
will be users who may want to track the previous information. 
Regarding the organization of information, we have worked out new 
documentation structures based on the 2.1 info using two different 
appraches: one is pretty much book based, keeping some of the current 
look&feel; the other is info center based. If we are going to create 
a new space for v2.2, we can take either approach. As long as the 
structure is ready, people can take topics they are interested in and 
write up the content.
 
If you have any ideas or comments on the proposed structures,

Re: broken 2.1.1 download link

[bill stoddard]

bill stoddard wrote:

The G 2.1.1 download link on this page is broken:
   http://geronimo.apache.org/downloads.html

Here's the link:
   http://geronimo.apache.org/apache-geronimo-v211-release.html

Bill


fixed!

broken 2.1.1 download link

[bill stoddard]

The G 2.1.1 download link on this page is broken:
   http://geronimo.apache.org/downloads.html

Here's the link:
   http://geronimo.apache.org/apache-geronimo-v211-release.html

Bill

[jira] Updated: (GERONIMO-3264) Results of WebKing Accessibility Testing of Geronimo 2.0 M3

[Bill Stoddard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Stoddard updated GERONIMO-3264:


Attachment: GeronimoConsoleAccessibilityTesting.zip

> Results of WebKing Accessibility Testing of Geronimo 2.0 M3
> ---
>
> Key: GERONIMO-3264
> URL: https://issues.apache.org/jira/browse/GERONIMO-3264
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0-M3
> Environment: all
>Reporter: Bill Stoddard
>Priority: Minor
> Fix For: Wish List
>
> Attachments: GeronimoConsoleAccessibilityTesting.zip
>
>
> What is accessibility? All your questions are answered here:
> http://www.w3.org/WAI/intro/accessibility.php
> A colleague did some accessibility testing of the G 2.0 admin console with 
> WebKing.   The results of that testing are attached. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3264) Results of WebKing Accessibility Testing of Geronimo 2.0 M3

[Bill Stoddard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Stoddard updated GERONIMO-3264:


Attachment: (was: GeronimoConsoleAccessibilityTesting.zip)

> Results of WebKing Accessibility Testing of Geronimo 2.0 M3
> ---
>
> Key: GERONIMO-3264
> URL: https://issues.apache.org/jira/browse/GERONIMO-3264
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0-M3
> Environment: all
>Reporter: Bill Stoddard
>Priority: Minor
> Fix For: Wish List
>
> Attachments: GeronimoConsoleAccessibilityTesting.zip
>
>
> What is accessibility? All your questions are answered here:
> http://www.w3.org/WAI/intro/accessibility.php
> A colleague did some accessibility testing of the G 2.0 admin console with 
> WebKing.   The results of that testing are attached. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3264) Results of WebKing Accessibility Testing of Geronimo 2.0 M3

[Bill Stoddard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Stoddard updated GERONIMO-3264:


Attachment: GeronimoConsoleAccessibilityTesting.zip

one more time...

> Results of WebKing Accessibility Testing of Geronimo 2.0 M3
> ---
>
> Key: GERONIMO-3264
> URL: https://issues.apache.org/jira/browse/GERONIMO-3264
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0-M3
> Environment: all
>Reporter: Bill Stoddard
>Priority: Minor
> Fix For: Wish List
>
> Attachments: GeronimoConsoleAccessibilityTesting.zip
>
>
> What is accessibility? All your questions are answered here:
> http://www.w3.org/WAI/intro/accessibility.php
> A colleague did some accessibility testing of the G 2.0 admin console with 
> WebKing.   The results of that testing are attached. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3264) Results of WebKing Accessibility Testing of Geronimo 2.0 M3

[Bill Stoddard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Stoddard updated GERONIMO-3264:


Attachment: (was: GeronimoConsoleAccessibilityTesting.zip)

> Results of WebKing Accessibility Testing of Geronimo 2.0 M3
> ---
>
> Key: GERONIMO-3264
> URL: https://issues.apache.org/jira/browse/GERONIMO-3264
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0-M3
> Environment: all
>Reporter: Bill Stoddard
>Priority: Minor
> Fix For: Wish List
>
>
> What is accessibility? All your questions are answered here:
> http://www.w3.org/WAI/intro/accessibility.php
> A colleague did some accessibility testing of the G 2.0 admin console with 
> WebKing.   The results of that testing are attached. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3264) Results of WebKing Accessibility Testing of Geronimo 2.0 M3

[Bill Stoddard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Stoddard updated GERONIMO-3264:


Attachment: GeronimoConsoleAccessibilityTesting.zip

> Results of WebKing Accessibility Testing of Geronimo 2.0 M3
> ---
>
> Key: GERONIMO-3264
> URL: https://issues.apache.org/jira/browse/GERONIMO-3264
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0-M3
> Environment: all
>Reporter: Bill Stoddard
>Priority: Minor
> Fix For: Wish List
>
>
> What is accessibility? All your questions are answered here:
> http://www.w3.org/WAI/intro/accessibility.php
> A colleague did some accessibility testing of the G 2.0 admin console with 
> WebKing.   The results of that testing are attached. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3264) Results of WebKing Accessibility Testing of Geronimo 2.0 M3

[Bill Stoddard (JIRA)]

Results of WebKing Accessibility Testing of Geronimo 2.0 M3
---

 Key: GERONIMO-3264
 URL: https://issues.apache.org/jira/browse/GERONIMO-3264
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: console
Affects Versions: 2.0-M3
 Environment: all
Reporter: Bill Stoddard
Priority: Minor
 Fix For: Wish List


What is accessibility? All your questions are answered here:
http://www.w3.org/WAI/intro/accessibility.php

A colleague did some accessibility testing of the G 2.0 admin console with 
WebKing.   The results of that testing are attached. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Release Notes for 2.0-M2 - EJB content

[Bill Stoddard]

David Blevins wrote:


On Jan 26, 2007, at 5:46 AM, Dave Colasurdo wrote:


Thanks... Have made the updates...

Is there anything that should be added to the limitations section?


One of the things I mentioned in another email is that MDBs are 
completely untested and should be assumed non-functional.



  Do we fully support EJB 3.0?


:)

-David


The answer probably depends on the definition of 'fully'. :)

Bill

Re: svn commit: r486169 - in /geronimo/server/trunk: ./ configs/jetty6/ configs/tomcat6/ modules/geronimo-web-2.5-builder/ modules/geronimo-web-2.5-builder/repository/ modules/geronimo-web-2.5-builder

[Bill Stoddard]

Jason Dillon wrote:

Why was this added?

The use of module local repositories is a temporary HACK that I added 
to add artifacts which only existed in m1 repositories... so that the 
build could be free of repos with a legacy layout.


And that's the problem with hacks.  Sometimes hacks are necessary (or 
not?), but if they are not clearly identified as such, they tend to 
propagate through out the code base.


Bill

Re: Geronimo v1.2 documentation - Summary of changes

[Bill Stoddard]

Hernan Cunico wrote:

Hi All,
For this release I would like to ask you guys to throw a line or two 
listing the areas your worked on that represent new or improved features.
In the past I used to dig into the JIRAs but that took forever and 
always felt I was missing a lot. So, this time it would be great to 
hear it "directly from the horse's mouth". ;-)


Let's try consolidate in this thread a list with all the new features, 
updates and improvements.


Thanks in advance.

Cheers!
Hernan

This is a good idea.  The Apache HTTP Server maintains a file named 
"CHANGES" in the top level of each server branch in SVN for this 
purpose.  Check it out here:


http://www.apache.org/dist/httpd/CHANGES_2.2

When a developer commits an interesting change (from an Apache HTTPD 
user's perspective), he will check in a quick description in CHANGES at 
the same time.   Apache HTTPD users know to check out the CHANGES files 
to get a quick rundown on a new release.  This is a practice worthy of 
emulating, in my biased humble opinion :-)


Notes:
- CHANGES grows as a stack, with newer stuff at the beginning of the file
- Security fixes are prefixed with the word "SECURITY:"   Tracking 
security fixes in the CHANGES file with this simple convention 
eliminates an amazing number of user questions.


Bill

[jira] Commented: (GERONIMO-2348) Tomcat ConnectorGBean does not handle attribute values properly

[Bill Stoddard (JIRA)]

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

Bill Stoddard commented on GERONIMO-2348:
-

Why is the patch to http11protocol required?   The code being patched in tomcat 
simply sets the default values for these attributes; is the original 
(unpatched) code actually causing a problem?  I would be concerned if that's 
the case because I believe tomcat (w/o Apache Geronimo) allows these values to 
be overridden (user configurable) and tomcat does not have a problem with the 
defaults being set.  This part of the patch just doesn't seem right to me.


> Tomcat ConnectorGBean does not handle attribute values properly
> ---
>
> Key: GERONIMO-2348
> URL: http://issues.apache.org/jira/browse/GERONIMO-2348
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.0, 1.1, 1.1.1
> Environment: Win XP, Geronimo Tomcat 1.1.1-SNAPSHOT
>Reporter: Vamsavardhana Reddy
> Assigned To: Vamsavardhana Reddy
> Fix For: 1.1.2, 1.1.x, 1.2
>
> Attachments: GERONIMO-2348.patch, http11protocol.patch
>
>
> Tomcat ConnectorGBean does not handle the following attributes properly.
>   1.  hostLookupEnabled
>   2.  redirectPort
>   3.  maxSavePostSize
>   4.  useBodyEncodingForURI
> There may be other attributes that are not handled properly as well.  So, far 
> I have confirmed the above list.  I will continue investigation and update 
> the list.
> A similar problem GERONIMO-2343 is observed and fixed by Krishnakumar B.  And 
> the fix is also similar.

-- 
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: 1.1.1 - Ready or not ? Soliciting input

[Bill Stoddard]

Kevan Miller wrote:


SECURITY

http://issues.apache.org/jira/browse/GERONIMO-2294
- For a security realm with multiple login modules, we do not handle
the JAAS Control Flags correctly (e.g. we do not call the login
modules using the correct logic).  Code to reproduce available. Alan
had claimed a predecessor to this issue; I'm not sure if he's planning
on working on this one.


Does this problem allow unauthorized/unauthenticated access to secured 
resources? If not, then I wouldn't categorize it as a BLOCKER.




http://issues.apache.org/jira/browse/GERONIMO-2295
- For a web app, if the security url-patterns don't exactly match the
servlet-mapping url-patterns, we apply no security at all.  Code to
reproduce available.  Alan has claimed this issue.


That certainly seems like a must-fix BLOCKER to me...


I agree. While not in the same class as a remote root exploit, this is still potentially very serious (I say 
'potentially' because I don't know the precise details of the defect).


Bill

Re: svn commit: r427120 - /geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java

[Bill Stoddard]

Aaron Mulder wrote:

Hurray!

Thanks,
   Aaron

On 7/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: jsisson
Date: Mon Jul 31 07:08:13 2006
New Revision: 427120

URL: http://svn.apache.org/viewvc?rev=427120&view=rev
Log:
GERONIMO-1996 Fix cleanup of configurations when Errors occur.  
Previously an Error such as a  java.lang.ExceptionInInitializerError 
during Serialization during deployment leaves files in the repository 
and possibly leaves things in a state where you cannot undeploy.


Modified:

geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java 



Modified: 
geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java 

URL: 
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java?rev=427120&r1=427119&r2=427120&view=diff 

== 

--- 
geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java 
(original)
+++ 
geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java 
Mon Jul 31 07:08:13 2006

@@ -301,6 +301,7 @@
 // It's our responsibility to close this context, once 
we're done with it...
 DeploymentContext context = 
builder.buildConfiguration(inPlace, configID, plan, module, stores, 
artifactResolver, store);

 List configurations = new ArrayList();
+boolean configsCleanupRequired = false;
 configurations.add(context.getConfigurationData());
 configurations.addAll(context.getAdditionalDeployment());

@@ -334,23 +335,31 @@
 notifyWatchers(deployedURIs);
 return deployedURIs;
 } else {
-cleanupConfigurations(configurations);
+configsCleanupRequired = true;
 return Collections.EMPTY_LIST;
 }


Is this correct?

Bill

Re: 1.1 Release Voting Results - 1.1 is approved

[Bill Stoddard]

Matt Hogstrom wrote:
I tallied the votes so far and have 5 +1 Votes from the PMC and 1 +0.  4 
PMC members did not vote.


11 Commiters voted +1 and there was 1 +0.  7 Committers did not vote.

It appears that 1.1 has been voted a release !!


Congratulations!!

Bill

Re: Where did the 1.1 branch go?!?!

[Bill Stoddard]

David Jencks wrote:


On Jun 15, 2006, at 10:31 AM, Bill Stoddard wrote:


David Blevins wrote:


Comment from the peanut gallery...
It is extremely poor form to modify 'tagged' releases. Once a 
release is tagged in SVN, it should not be changed, ever.

We don't update tags.

That's good.

1.1 should not have been tagged until after the vote to release 1.1 
passed. FWIW.

It's been our tradition to insist the releases are built from the tag.


1.1 is tagged. What happens if the 1.1 release vote fails because of a 
show stopper bug?


IIRC this happened repeatedly with 1.0.  We deleted the tags/1.0 and 
made a new one, using, IIRC, svn cp.


As I mentioned in another post, I don't have a big problem with this 
since you don't lose any history by doing this, unlike cvs where moving 
tags destroys history.  It does make the history a bit hard to find 
however, and we might consider using "maven  build numbers" such as 
tags/1.1.1-3 for the third try to release an acceptable 1.1.1.  I'd 
rather continue as we have been, deleting and recreating tags.  I'm open 
to argument however :-)


svn solves the history problem, however if your constantly changing the contents of the 1.1 tag (by deleting 
and recreating the tag) then how are AG users to know that they have the official AG 1.1 release? Why not 
eliminate the opportunity for users to get different versions of what they believe to be the "true" 1.1?


I've seen this problem solved in a couple of ways. Apache HTTP Server takes the view that "version numbers are 
cheap".  A release is tagged and if it proves buggy, the bug is fixed and a new version number is assigned. 
Many tagged versions never make it to "generally available" status. Other projects create tags like 1.1-rc3. 
rc3 may very well become the generally available "1.1" release.  I am sure there are other ways to solve the 
problem.


All that said, I am just sharing my experience from working on other open source projects over the years. Do 
what you think is right and have fun ;-)


Bill

Re: Where did the 1.1 branch go?!?!

[Bill Stoddard]

David Blevins wrote:


Comment from the peanut gallery...
It is extremely poor form to modify 'tagged' releases. Once a release 
is tagged in SVN, it should not be changed, ever.


We don't update tags.

That's good.



1.1 should not have been tagged until after the vote to release 1.1 
passed. FWIW.


It's been our tradition to insist the releases are built from the tag.


1.1 is tagged. What happens if the 1.1 release vote fails because of a show 
stopper bug?

Bill

Re: Where did the 1.1 branch go?!?!

[Bill Stoddard]

Jay D. McHugh wrote:

Aaron Mulder wrote:

Now we only have a 1.0 branch and a dead-1.2 branch?  What's going on?

Thanks,
   Aaron




Aaron,

It was moved under tags/1.1.0.

Jay



Comment from the peanut gallery...
It is extremely poor form to modify 'tagged' releases. Once a release is tagged in SVN, it should not be 
changed, ever.


Comment from the peanut gallery...
It is extremely poor form to modify 'tagged' releases. Once a release is tagged in SVN, it should not be 
changed, ever. 1.1 should not have been tagged until after the vote to release 1.1 passed. FWIW.


Bill

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

[Bill Stoddard]

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 T&C's for this code? Do we know?


Bill

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

[Bill Stoddard]

Jacek Laskowski wrote:

Hi,

It struck me while I was about to commit Bill's patch
(http://issues.apache.org/jira/browse/GERONIMO-1686). Some files in it
(and in j2ee-schema module, actually), contain

Copyright 2003 Sun Microsystems, Inc., 901 San Antonio
Road, Palo Alto, California 94303, U.S.A. All rights
reserved.

What are the rules to store such files in our repo? Since they're in
our repo, they're ours and I was changing the header of the files in
Bill's patch to reference the ASL 2.0 license, 
but am not sure if I'm

allowed to. If I'm not, they should not be in our repo, either.

Is there a mistake in my reasoning? ;) Desparately looking for a guidance...

Jacek


Jacek,
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.


Bill

Re: Geronimo 2.0

[Bill Stoddard]

David Jencks wrote:
Either I don't understand what is being proposed or I think it is a  
recipe for disaster.


My past experience with open source projects leads me to believe that  
having more than one main development area that is leading to a  release 
is likely to cause only confusion, not progress towards  functionality.


In my opinion if we call head 2.0 and start adding JEE 5 features to  
it, there will never be any more j2ee 1.4 releases with added  
functionality.  We will have a couple bug fix 1.0 releases, then a  year 
or so while we try to finish JEE 5.  I don't think this is  acceptable.


From my experience working on the Apache HTTP Server, I agree with David.

Bill

Re: [jira] Commented: (GERONIMODEVTOOLS-26) Eclipse plugin build will always miss geronimo-jetty-j2ee-*.zip in the local maven repo

[Bill Stoddard]

Sachin Patel wrote:
Strange.  I have no idea.  I just tried on windows, and the scenario  
worked.   If the zip is in the local repo, it skipped the remote  
download.  When I deleted the zip from the local repo and reran, it  
pulled it down.


- sachin




Thanks for trying it Sachin.  It's very odd. I'll put together a simple test case to see if I can isolate the 
failure. Will let you know if I find anything interesting.


Bill

Re: [jira] Commented: (GERONIMODEVTOOLS-26) Eclipse plugin build will always miss geronimo-jetty-j2ee-*.zip in the local maven repo

[Bill Stoddard]

Sachin Patel (JIRA) wrote:
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-26?page=comments#action_12361088 ] 


Sachin Patel commented on GERONIMODEVTOOLS-26:
--

This is incorrect.  The current syntax is correct as is. If the zip is not 
available in the local repo, it will pull it down from cvs.apache.org

  




Yikes, after spending a bit of time with google I agree the original syntax is correct, but it's not producing 
the desired result.


Here is the original maven goal with an ant:echo for instrumentation.



zip.present is ${zip.present}

 
 http://cvs.apache.org/repository/geronimo/distributions/${geronimo.zip}"; 
dest="${maven.repo.local}/geronimo/distributions/${geronimo.zip}"/>






Here is the resulting build failure:

C:\home\apache\devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.j2ee.server.v1>maven
maven
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

build:start:

default:
java:prepare-filesystem:

java:compile:
[echo] Compiling to 
C:\home\apache\devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.j2ee.server.v1/target/classes

[echo] No java source files to compile.

java:jar-resources:
getzip:
[echo] zip.present is true<=== 
geronimo-jetty-j2ee-1.0.zip is in my local repo
[get] Getting: 
http://cvs.apache.org/repository/geronimo/distributions/geronimo-jetty-j2ee-1.0.zip
[get] Error opening connection java.io.IOException
[get] Error opening connection java.io.IOException
[get] Error opening connection java.io.IOException
[get] Can't get http://cvs.apache.org/repository/geronimo/distributions/geronimo-jetty-j2ee-1.0.zip to 
C:\Documents and Settings\Administrator\.maven\repository\geronimo\distributions\geronimo-jetty-j2ee-1.0.zip 
<=== So why did we take the branch to download the zip?


BUILD FAILED
File.. 
C:\home\apache\devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.j2ee.server.v1\maven.xml
Element... ant:get
Line.. 34
Column 164
Can't get http://cvs.apache.org/repository/geronimo/distributions/geronimo-jetty-j2ee-1.0.zip to C:\Documents 
and Settings\Administrator\.maven\repository\geronimo\distributions\geronimo-jetty-j2ee-1.0.zip

Total time: 3 seconds
Finished at: Wed Dec 21 22:17:45 EST 2005


If I force maven to bypass the download of geronimo-jetty-j2ee-1.0.zip, my 
plugin build completes.

What am I missing??

Bill

Re: [jira] Commented: (GERONIMODEVTOOLS-26) Eclipse plugin build will always miss geronimo-jetty-j2ee-*.zip in the local maven repo

[Bill Stoddard]

Sachin Patel (JIRA) wrote:
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-26?page=comments#action_12361088 ] 


Sachin Patel commented on GERONIMODEVTOOLS-26:
--

This is incorrect.  The current syntax is correct as is. If the zip is not 
available in the local repo, it will pull it down from cvs.apache.org




Have you tried it? Put the zip in the local maven repo and what what happens.

Bill

[jira] Created: (GERONIMODEVTOOLS-26) Eclipse plugin build will always miss geronimo-jetty-j2ee-*.zip in the local maven repo

[Bill Stoddard (JIRA)]

Eclipse plugin build will always miss geronimo-jetty-j2ee-*.zip in the local 
maven repo
---

 Key: GERONIMODEVTOOLS-26
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-26
 Project: Geronimo-Devtools
Type: Bug
  Components: eclipse-plugin  
 Environment: Discovered on Windows. Probably affects build on all operating 
systems.
Reporter: Bill Stoddard
Priority: Minor


Correct the file available test to enable the build to discover the file in the 
local maven repository.

C:\home\apache\devtools\modules\eclipse-plugin\plugins>svn diff
svn diff
Index: org.apache.geronimo.j2ee.server.v1/maven.xml
===
--- org.apache.geronimo.j2ee.server.v1/maven.xml(revision 358391)
+++ org.apache.geronimo.j2ee.server.v1/maven.xml(working copy)
@@ -28,7 +28,7 @@
   
 
 
-
+
  
  http://cvs.apache.org/repository/geronimo/distributions/${geronimo.zip}"; 
dest="${maven.repo.local}/geronimo/distributions/${geronimo.zip}"/>
 

-- 
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: (GERONIMODEVTOOLS-24) Clean checkout and build fails in geronimo-emf

[Bill Stoddard (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-24?page=comments#action_12361067
 ] 

Bill Stoddard commented on GERONIMODEVTOOLS-24:
---

Try this patch
svn diff geronimo-emf/maven.xml
Index: geronimo-emf/maven.xml
===
--- geronimo-emf/maven.xml  (revision 358391)
+++ geronimo-emf/maven.xml  (working copy)
@@ -95,9 +95,18 @@
classname="org.apache.tools.ant.taskdefs.optional.ReplaceRegExp"
classpathref="maven.dependency.classpath"/>
 
-  
+
+
+
+
+  
+  
+
+
+
 
-   
+
+   
 
 
 

C:\home\apache\devtools\modules\eclipse-plugin>

> Clean checkout and build fails in geronimo-emf
> --
>
>  Key: GERONIMODEVTOOLS-24
>  URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-24
>  Project: Geronimo-Devtools
> Type: Bug
>   Components: eclipse-plugin
>  Environment: Maven 1.0.2, WinXP, clean repo, new checkout of devtools trunk
> Reporter: Donald Woods
> Assignee: Sachin Patel
> Priority: Blocker

>
> Fresh checkout of devtools/trunk with Maven 1.0.2 and 1.1beta2 fails.
> Using latest trunk code from 12/18.
> Tried to build with a clean repo and after building the AG 1.0 branch and it 
> still fails during the geronimo-emf compiles.
> Here is the first failure and the other 4 fail the same way -
> +
> | Gathering project list assembly
> | Memory: 90M/128M
> +
> Starting the reactor...
> Our processing order:
> geronimo-emf
> org.apache.geronimo.deployment.model
> org.apache.geronimo.devtools.eclipse.core
> org.apache.geronimo.deployment.model.edit
> org.apache.geronimo.feature
> org.apache.geronimo.installableruntime.feature
> org.apache.geronimo.source.feature
> org.apache.geronimo.runtime.v1
> org.apache.geronimo.j2ee.server.v1
> org.apache.geronimo.ui
> org.apache.geronimo.feature.source
> assembly
> +
> | Executing jar:install geronimo-emf
> | Memory: 90M/128M
> +
> Attempting to download junit-3.8.1.jar.
> 118K downloaded
> Attempting to download commons-jelly-tags-antlr-20030211.143720.jar.
> 7K downloaded
> Attempting to download antlr-2.7.2.jar.
> 349K downloaded
> multiproject:goal:
> build:start:
> java:prepare-filesystem:
> java:compile:
> importschemas:
> [unzip] Expanding: 
> E:\Working\devtools\modules\eclipse-plugin\.maven\repository\openejb\jars\openejb-pkgen-builder-2.0.jar
>  into E:\Working\devtools\modules\eclipse-plugin\geronimo-emf\target\temp
> [unzip] Expanding: 
> E:\Working\devtools\modules\eclipse-plugin\.maven\repository\openejb\jars\openejb-builder-2.0.jar
>  into E:\Working\devtools\modules\eclipse-plugin\geronimo-emf\target\temp
> [unzip] Expanding: 
> E:\Working\devtools\modules\eclipse-plugin\.maven\repository\geronimo\jars\geronimo-security-builder-1.0.jar
>  into E:\Working\devtools\modules\eclipse-plugin\geronimo-emf\target\temp
> [unzip] Expanding: 
> E:\Working\devtools\modules\eclipse-plugin\.maven\repository\geronimo\jars\geronimo-naming-builder-1.0.jar
>  into E:\Working\devtools\modules\eclipse-plugin\geronimo-emf\target\temp
> [unzip] Expanding: 
> E:\Working\devtools\modules\eclipse-plugin\.maven\repository\geronimo\jars\geronimo-web-builder-1.0.jar
>  into E:\Working\devtools\modules\eclipse-plugin\geronimo-emf\target\temp
> [unzip] Expanding: 
> E:\Working\devtools\modules\eclipse-plugin\.maven\repository\geronimo\jars\geronimo-j2ee-builder-1.0.jar
>  into E:\Working\devtools\modules\eclipse-plugin\geronimo-emf\target\temp
> [unzip] Expanding: 
> E:\Working\devtools\modules\eclipse-plugin\.maven\repository\geronimo\jars\geronimo-service-builder-1.0.jar
>  into E:\Working\devtools\modules\eclipse-plugin\geronimo-emf\target\temp
> [unzip] Expanding: 
> E:\Working\devtools\modules\eclipse-plugin\.maven\repository\geronimo\jars\geronimo-j2ee-schema-1.0.jar
>  into E:\Working\devtools\modules\eclipse-plugin\geronimo-emf\target\temp
> [unzip] Expanding: 
> E:\Working\devtools\modules\eclipse-plugin\.maven\repository\geronimo\jars\geronimo-connector-builder-1.0.jar
>  into E:\Working\devtools\modules\eclipse-plugin\geronimo-emf\target\temp
> [unzip] Expanding: 
> E:\Working\devtools\modules\eclipse-plugin\.maven\repository\geronimo\jars\geronimo-client-builder-1.0.jar
>  into E:\Working\devtools\modules\eclipse-plugin\geronimo-emf\target\temp
> [move] Moving 14 files t

Re: svn commit: r356493 - in /geronimo/devtools/trunk/modules/eclipse-plugin: ./ features/org.apache.geronimo.installableruntime.feature/ plugins/org.apache.geronimo.deployment.model.edit/src/org/apac

[Bill Stoddard]

Sachin Patel wrote:

The [emf.XSD2Java] messages are normal.  What command are you using to
build?


From inside /devtools/modules/eclipse-plugin/ Try..


"maven clean build"



Thanks Sachin. I must be missing something obvious... Ran maven clean build and 
hit this:

BUILD FAILED
File.. C:\Documents and 
Settings\Administrator\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.jelly
Element... maven:reactor
Line.. 217
Column 9
The build cannot continue because of the following unsatisfied dependencies:

org.apache.geronimo.j2ee.server.v1-0.5.0-SNAPSHOT.jar
org.apache.geronimo.feature.source-0.5.0-SNAPSHOT.jar

Total time: 2 minutes 7 seconds
Finished at: Tue Dec 13 19:24:14 EST 2005

Neither of these are in the cvs.apache.org maven repo, 
http://cvs.apache.org/repository/geronimo-devtools/jars/

Are these autogenerated?

Bill

Re: svn commit: r356493 - in /geronimo/devtools/trunk/modules/eclipse-plugin: ./ features/org.apache.geronimo.installableruntime.feature/ plugins/org.apache.geronimo.deployment.model.edit/src/org/apac

[Bill Stoddard]

Sachin Patel wrote:

In the plugins directory. (org.apache.geronimo.deployment.model.edit) The
bundle activator is generated dynamically along with the rest of the classes
until I get to each of them individual to do custom overrides on the
generated code for our editors.  So currently there's only about 4 or 5
classes in the repo for that plugin.


When I do a build of the eclipse plugin, I see messages like this:

[java] [emf.XSD2Java] >>  Generating Java class 
org.apache.geronimo.deployment.model.edit.GeronimoEMFEditPlugin


Then hit a compile failure a bit further on:
  [javac] Compiling 5 source files to 
C:\home\apache\devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.deployment.model.edit\target\classes
C:\home\apache\devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.deployment.model.edit\src\org\apache\geronimo\xml\ns\naming\provider\EjbLocalRefTypeItemProvider.java:21: 
package org.apache.geronimo.deployment.model.edit does not exist

import org.apache.geronimo.deployment.model.edit.GeronimoEMFEditPlugin;

The five source files in the *.model.edit.* directory are:
 EjbLocalRefTypeItemProvider.java
 EjbRefTypeItemProvider.java
 NamingItemProviderAdapterFactory.java
 ResourceEnvRefTypeItemProvider.java
 ResourceRefTypeItemProvider.java

Building against the 1.0 branch. Any suggestions for how to debug?

Thanks,
Bill

Re: svn commit: r356499 - /geronimo/specs/branches/1_0/

[Bill Stoddard]

[EMAIL PROTECTED] wrote:

Author: adc
Date: Mon Dec 12 23:39:50 2005
New Revision: 356499

URL: http://svn.apache.org/viewcvs?rev=356499&view=rev
Log:
made a copy

Added:
geronimo/specs/branches/1_0/
  - copied from r356497, geronimo/specs/trunk/



Would it be better to use the same naming convention for the specs branch as for the geronimo kernel, 
geronimo/specs/branches/1.0?


foolish consistency and hobgoblins not withstanding :)

Bill

Re: svn commit: r356493 - in /geronimo/devtools/trunk/modules/eclipse-plugin: ./ features/org.apache.geronimo.installableruntime.feature/ plugins/org.apache.geronimo.deployment.model.edit/src/org/apac

[Bill Stoddard]

[EMAIL PROTECTED] wrote:

Author: sppatel
Date: Mon Dec 12 23:14:08 2005
New Revision: 356493

URL: http://svn.apache.org/viewcvs?rev=356493&view=rev
Log:
RC4 released

Added:

geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbLocalRefTypeItemProvider.java

geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbRefTypeItemProvider.java
Modified:

geronimo/devtools/trunk/modules/eclipse-plugin/features/org.apache.geronimo.installableruntime.feature/.project
geronimo/devtools/trunk/modules/eclipse-plugin/maven.xml

geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/ResourceRefTypeItemProvider.java







Added: 
geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbLocalRefTypeItemProvider.java
URL: 
http://svn.apache.org/viewcvs/geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbLocalRefTypeItemProvider.java?rev=356493&view=auto
==
--- 
geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbLocalRefTypeItemProvider.java
 (added)
+++ 
geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbLocalRefTypeItemProvider.java
 Mon Dec 12 23:14:08 2005
@@ -0,0 +1,338 @@
+/**





+
+import org.apache.geronimo.deployment.model.edit.GeronimoEMFEditPlugin;


Where is GeronimoEMFEditPlugin defined?

Thanks
Bill

Re: New 1.0.x build failure

[Bill Stoddard]

David Jencks wrote:
We may have done a bad thing by not hiding the test upload of released  
spec jars better.  The first upload of the spec uberjar was faulty and  
did not contain the javamail classes.  You might have downloaded this  
jar.  To fix the problem you need to remove your maven  
org.apache.geronimo.specs directory.


Yep, that fixed it. Thanks.

Bill

New 1.0.x build failure

[Bill Stoddard]

1.0 was building over the weekend. Did a svn update this morning followed by maven new clean and am seeing 
this failure in new4:


multiproject:install-callback:
[echo] Running car:install for JavaMail
44424 [main] ERROR org.apache.geronimo.deployment.Deployer  - Deployment failed 
due to
java.lang.NoClassDefFoundError: javax/mail/Authenticator
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:1655)
at java.lang.Class.getDeclaredMethod(Class.java:1262)



BUILD FAILED
File.. c:\home\apache\geronimo-1.0.x\maven.xml
Element... maven:reactor
Line.. 58
Column 112
Unable to obtain goal [multiproject:install-callback] -- C:\Documents and 
Settings\Administrator\.maven\cache\geronimo-packaging-plugin-1.0.0\plugin.jelly:67:15:  null

Total time: 8 minutes 39 seconds
Finished at: Mon Dec 12 13:35:18 EST 2005

Re: Build Status

[Bill Stoddard]

Aaron Mulder wrote:

I'll try the branch.  The interop and itest modules should be commented out.

Thanks,
Aaron



Just successfully built the 1.0 branch (test and itest disabled)

svn update (about 9:15 AM ET)
maven m:fresh-checkout
maven clean new

Bill

Re: [M1] Plugin hell, help desperately needed - JIRA 1308 created

[Bill Stoddard]

David Blevins wrote:
Just as an fyi, this is a nice addition but doesn't really deal with  
the "Plugin hell" issue David is talking about.  It seems to be hit  and 
miss trying to get the new plugins installed and used during any  
particular maven run.


 From my experience it seems as if you delete your ~/.maven/cache and  
~/.maven/plugins, then the cache gets rebuilt and the latest verision  
of the plugin from your ~/.maven/repository is used.  But as the  plugin 
is updated in the future, it will never reach the ~/.maven/ cache and 
builds will eventually start failing because of it.


There is more too it than that, David highlighted the frustrations  
around the problem a bit better in his email.


Indeed, there's a lot of indeterministic behaviour in the build process. It's interesting that some are able 
to successfully build the server w/o the two patches submitted by Donald. That's exceedingly odd and perhaps 
related to plugin hell?


Bill

Re: [M1] Plugin hell, help desperately needed

[Bill Stoddard]

Donald Woods wrote:
Finally got new4 goal to complete using Maven 1.1Beta2 (was always 
failing with the same error you mention below), by editing 
configs/geronimo-gbean-deployer/project.xml and removing the comments 
from around the geronimo-packaging-plugin dependency to re-enable it as 
a depend -



geronimo
geronimo-packaging-plugin
${geronimo_version}
plugin


I'm running a full build now via
   maven m:clean new -Dmaven.test.skip=true -Dmaven.itest.skip=true
to verify the change works repeatably before I open a JIRA and attach 
the patch.



-Donald



Thanks Donald, that change got me over the failure (and I'm using maven 1.0.2).  I manually placed 
geronimo-packaging-plugin into the .maven/cache. Ran into another failure to statisfy a dependency on 
tranql-connector-derby-embed-local-1.1-SNAPSHOT.rar but that's probably because I was doing an offline build.


It was a bit tricky mapping this message:
[echo] Running car:install for Geronimo Configuration for performing 
service deployments
to
geronimo-gbean-deployer/project.xml

I made the connection (thank you findstr/grep) but failed to investigate the dependencies in project.xml. 
Won't make that mistake again ;-)


Will clean out .maven/cache and kick off a 'maven clean new' build this evening 
and report back the results.

Bill

Re: [M1] Plugin hell, help desperately needed

[Bill Stoddard]

Bill Stoddard wrote:

David Jencks wrote:

In the geronimo project we are experiencing severe problems with our 
build related to plugins.  Any advice on how to improve this situation 
would be appreciated.




Perhaps this is stating the obvious, but on the off chance it is useful, 
here goes...


I am consistently getting this failure in new4:
...
multiproject:install-callback:
[echo] Running car:install for Geronimo Configuration for performing 
service deployments


BUILD FAILED
File.. C:\home\apache\geronimo\maven.xml
Element... maven:reactor
Line.. 58
Column 112
Unable to obtain goal [multiproject:install-callback] -- C:\Documents 
and 
Settings\Administrator\.maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly:256:30: 
 No goal [car:install]

Total time: 9 seconds

Goal [car:install] is implemented by the geronimo-packaging-plugin.

After my build fails, I check the maven cache and I only see the 
following two plugins:


dir c:/Documents and Settings/Administrator/.maven/cache/

geronimo-dependency-plugin-1.0-SNAPSHOT
geronimo-deployment-plugin-1.0-SNAPSHOT

No packaging plugin.  Do you think the plugin was removed from the cache 
or did it not get put in the cache in the first place?


Going to try an experiment... run sysinternals filemon watching for file 
geronimo-packaging-plugin-1.0-SNAPSHOT, kick off a build and watch what 
happens. If the file is never created, that will be a useful clue.


Bill





David,
Ran filemon while doing an offline build. File CREATE and DELETE log entries 
here:

11	4:19:26 PM	java.exe:1256	DELETE 
C:\home\apache\geronimo\plugins\geronimo-packaging-plugin\target\geronimo-packaging-plugin-1.0-SNAPSHOT.jar 
SUCCESS		
15	4:23:07 PM	java.exe:1256	CREATE 
C:\home\apache\geronimo\plugins\geronimo-packaging-plugin\target\geronimo-packaging-plugin-1.0-SNAPSHOT.jar 
SUCCESS	Options: OverwriteIf  Access: All


798	4:23:07 PM	java.exe:1256	CREATE	C:\Documents and 
Settings\Administrator\.maven\repository\geronimo\plugins\geronimo-packaging-plugin-1.0-SNAPSHOT.jar	SUCCESS 
Options: OverwriteIf  Access: All	
858	4:23:07 PM	java.exe:1256	CREATE	C:\Documents and 
Settings\Administrator\.maven\repository\geronimo\plugins\geronimo-packaging-plugin-1.0-SNAPSHOT.jar.md5 
SUCCESS	Options: OverwriteIf  Access: All	
888	4:23:07 PM	java.exe:1256	CREATE	C:\Documents and 
Settings\Administrator\.maven\repository\geronimo\plugins\geronimo-packaging-plugin-1.0-SNAPSHOT.jar.sha1 
SUCCESS	Options: OverwriteIf  Access: All	
918	4:23:07 PM	java.exe:1256	CREATE	C:\Documents and 
Settings\Administrator\.maven\repository\geronimo\poms\geronimo-packaging-plugin-1.0-SNAPSHOT.pom	SUCCESS 
Options: OverwriteIf  Access: All	
956	4:23:07 PM	java.exe:1256	CREATE	C:\Documents and 
Settings\Administrator\.maven\repository\geronimo\poms\geronimo-packaging-plugin-1.0-SNAPSHOT.pom.md5	SUCCESS 
Options: OverwriteIf  Access: All	
986	4:23:07 PM	java.exe:1256	CREATE	C:\Documents and 
Settings\Administrator\.maven\repository\geronimo\poms\geronimo-packaging-plugin-1.0-SNAPSHOT.pom.sha1 
SUCCESS	Options: OverwriteIf  Access: All	


I was expecting to see something showing up in the maven cache. Is this what 
you would expect to see?

Bill

Re: [M1] Plugin hell, help desperately needed

[Bill Stoddard]

David Jencks wrote:
In the geronimo project we are experiencing severe problems with our 
build related to plugins.  Any advice on how to improve this situation 
would be appreciated.




Perhaps this is stating the obvious, but on the off chance it is useful, here 
goes...

I am consistently getting this failure in new4:
...
multiproject:install-callback:
[echo] Running car:install for Geronimo Configuration for performing 
service deployments

BUILD FAILED
File.. C:\home\apache\geronimo\maven.xml
Element... maven:reactor
Line.. 58
Column 112
Unable to obtain goal [multiproject:install-callback] -- C:\Documents and 
Settings\Administrator\.maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly:256:30:  No goal 
[car:install]

Total time: 9 seconds

Goal [car:install] is implemented by the geronimo-packaging-plugin.

After my build fails, I check the maven cache and I only see the following two 
plugins:

dir c:/Documents and Settings/Administrator/.maven/cache/

geronimo-dependency-plugin-1.0-SNAPSHOT
geronimo-deployment-plugin-1.0-SNAPSHOT

No packaging plugin.  Do you think the plugin was removed from the cache or did it not get put in the cache in 
the first place?


Going to try an experiment... run sysinternals filemon watching for file 
geronimo-packaging-plugin-1.0-SNAPSHOT, kick off a build and watch what happens. If the file is never created, 
that will be a useful clue.


Bill

Re: [consolidation] next steps?

[Bill Stoddard]

Dain Sundstrom wrote:
Everyone seems very positive about consolidating the community. How  
should we proceed?


I was thinking that it would be nice to send an invitation to the  
projects to join the Geronimo community as a subproject.  The  
invitation letter would simply state our interest in having the  project 
join Geronimo and if they accept, to prepare a proposal for  the 
incubator.  When the proposals are ready, we would vote to accept  the 
project and forward it to incubator.


The projects mentioned in the "Consolidating the community" thread  and 
the email addresses for their dev lists.


ActiveCluster - [EMAIL PROTECTED]
ActiveIO - [EMAIL PROTECTED]
ActiveMQ - [EMAIL PROTECTED]
ActivetSpaces - [EMAIL PROTECTED]
OpenEJB - dev@openejb.org
ServiceMix - dev@servicemix.codehaus.org
TranQL - [EMAIL PROTECTED]
WADI - [EMAIL PROTECTED]
XBean - [EMAIL PROTECTED]

-dain


Dain,
This is great. +1 for the effort. I'd recommend bouncing this off the ASF board just in case there are issues 
we're overlooking (I don't see any). The ASF doesn't generally solicit projects but I can't imagine anyone 
having a problem with this proposal.


Bill

Re: Common Visual Design for Geronimo's User Interfaces

[Bill Stoddard]

Jeff Genender wrote:
Why yes it is!  Thanks for pointing it out...I haven't been as attentive 
as I should be...I just found out I am a dad-to-be for a third time ;-) 
 So my head has been slightly elsewhere :)


Jeff



Jeff, Congrats!

Bill

Re: Common Visual Design for Geronimo's User Interfaces

[Bill Stoddard]

Bruce Snyder wrote:

On 11/2/05, Bill Stoddard <[EMAIL PROTECTED]> wrote:



Very nice!  How about a "Powered by Apache Geronimo" logo for folks to display 
on their AG powered websites or
in their Apache Geronimo derivitive distros?



There is a powered by image on the lower right-hand corner of this page:

http://www.epiqtech.com/corp/products/technology/opensource/GeronimoWelcomeScreen.htm

But I'm sure that the Epiq team would be willing to design some more.


Bruce,
This was exactly what I was looking for. Thanks for pointing it out.

Bill

Re: Common Visual Design for Geronimo's User Interfaces

[Bill Stoddard]

David Klavon wrote:
Now that there is an official logo image for Geronimo, we thought that 
it would be useful to extend the color scheme, font style, icon use, 
etc. across the various user interfaces in the project, and create a 
common 'visual appearance' for the Geronimo project for v1.0. 


Very nice!  How about a "Powered by Apache Geronimo" logo for folks to display on their AG powered websites or 
in their Apache Geronimo derivitive distros?


Bill

Re: Weekly conference call - thoughts

[Bill Stoddard]

Jeff Genender wrote:
I have to say I am opposed as well.  IMHO a telecon is not fair to those 
who live in places where the time is not convenient.  There are also 
folks who are contributors who may not be able to engage in a such a 
call because their jobs do not allow them to take part (rules using 
phones, job duties, etc).


Although this may be an additional way to communicate with the 
community, many folks may not have the opportunity to participate, and I 
am not sure that it is community oriented.  


Jeff, your right, conference calls are not community oriented, and that's the main problem, imho. Apache != 
Eclipse and you'll find most folks in the Apache community would agree.


ApacheCon is coming up in december; that's a great opportunity to host a f2f hack-a-thon. You'll get a little 
bit done but build some very good working relationships going forward. Once you meet someone face to face, 
it's a bit more difficult to forget there's a real person behind the keyboard and that tends to make on-list 
interactions a bit more civil.


With our lists, there is no 
barrier to engaging and contribution.


Just my .02.


+1



Jeff


Bill

Re: JDBC Migration [was Re: Applications migration]

[Bill Stoddard]

Dain Sundstrom wrote:

This is awesome!  Keep up the good work.

-dain

On Oct 11, 2005, at 12:34 PM, Hernan Cunico wrote:

I found confluence easier than wiki for formating the text of the  
articles. I just published the "JBoss to Geronimo - JDBC Migration"  
article there.


http://opensource2.atlassian.com/confluence/oss/pages/ 
viewpage.action?pageId=937


I'll keep working on the other articles.

Cheers!
Hernan Cunico


Hernan,
This is really nice! My socks are knocked off!

Bill

Re: Applications migration

[Bill Stoddard]

David Blevins wrote:


On Oct 10, 2005, at 12:10 PM, Sachin Patel wrote:




David Jencks wrote:



I think we should discuss if we want to move to confluence as our  wiki

I think the move to confluence is an excellent idea and we should  
definitely start discussing this. Looking at the current wiki, I  
think there is a lot of great but unorganized information.  Since  M5 
has now been released we expect and enormous growth in "users"  and so 
I think we are are now at a point where it would be good to  start 
focusing on the organization and presentation of the wiki and  the 
move to confluence would be a good starting point to be able to  do so.





We have a confluence space if we want to start using it.  http:// 
opensource2.atlassian.com/confluence/oss/display/GERONIMO


Here is an example of what we could do with it   http:// 
opensource2.atlassian.com/confluence/oss/display/GERONIMO/Unassigned


-David


Humm... from discussions over on infrastructure I see Leo and Noel have some concerns about maintaining a 
confluence install on apache.org. Probably nothing that couldn't be solved by a few volunteers. If a case 
could be made to completely replace moin-moin and standardize on confluence, that'd be even better. Do you see 
the wiki as being the method of choice for Apache Geronimo doc delivery? Any interest in using xdoc & transforms?


Please don't send us down the path of hosting ASF project doc on non-ASF infrastructure. Nothing good can come 
from that exercise.


Bill

Re: Logo Contest Voting is On

[Bill Stoddard]

Erin Mulder wrote:


5) To that end, I think it would be great if the PMC chose 1 or 2 logos
and had the artists offer a few variants with different fonts, etc.
before making their final choice.  It would be a shame to reject
something worthy based on a small, easily changed detail.


+1, excellent idea.

Bill

[jira] Commented: (GERONIMO-861) Investigate warning from Pluto portal

[Bill Stoddard (JIRA)]

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

Bill Stoddard commented on GERONIMO-861:


Relevant info...
http://issues.apache.org/jira/browse/PLUTO-112


> Investigate warning from Pluto portal
> -
>
>  Key: GERONIMO-861
>  URL: http://issues.apache.org/jira/browse/GERONIMO-861
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0-M5
> Reporter: Jeremy Boynes
>  Fix For: 1.0

>
> Investigate the following message:
> 14:31:22,763 WARN  [Servlet] org.apache.pluto.portalImpl.Servlet#init(): 
> Couldn't read property "pluto.allowSetBufferSize" from config file 
> ConfigService.properties

-- 
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-861) Investigate warning from Pluto portal

[Bill Stoddard (JIRA)]

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

Bill Stoddard commented on GERONIMO-861:


This patch should eliminate the warning. Still investigating whether 'yes' is 
the right answer... more later.

Index: 
applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties
===
--- 
applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties
  (revision 307176)
+++ 
applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties
  (working copy)
@@ -39,6 +39,7 @@
 portletcontainer.uniquename = pluto
 portletcontainer.entrance.impl = org.apache.pluto.PortletContainerImpl
 portletcontainer.entrance.wrapper.impl = 
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl
+portletcontainer.supportsBuffering = yes
 
 servlet.insecure=/portal
 servlet.secure=/secure

> Investigate warning from Pluto portal
> -
>
>  Key: GERONIMO-861
>  URL: http://issues.apache.org/jira/browse/GERONIMO-861
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0-M5
> Reporter: Jeremy Boynes
>  Fix For: 1.0

>
> Investigate the following message:
> 14:31:22,763 WARN  [Servlet] org.apache.pluto.portalImpl.Servlet#init(): 
> Couldn't read property "pluto.allowSetBufferSize" from config file 
> ConfigService.properties

-- 
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: Java serizalization compatibility issues

[Bill Stoddard]

Matt Hogstrom wrote:
Not being totally familiar with all the nuances in G WRT to 
serialization my comments should be taken with a grain of salt.  From my 
perspetive there are two major problems with serialized data.  One, its 
very fragile 

Yes.

and two you can't change it if you need to.  One could 
argue users shouldn't be changing it but in extreme circumstances it is 
unavoidable.


I'd vote for the move to XML (ouch, did I say that?)

Matt


My inclination as well. I've been scratching my head trying to understand 'why serialization?' rather than 
nice, flat, intuitive text files. There may be a very good answer I just don't what it is.




Jeremy Boynes wrote:

Sachin's problem is not related to configuration persistence but to 
the serialization of classes between plugin and server when using JMX 
remoting over RMI.


The upshot of it all is unless we are going to ditch all use of 
serialization and replace it with XML then we need to exercise the 
necessary discipline and version the classes involved.


--
Jeremy

Re: Tomcat, logging, admin portlet, and GBeans

[Bill Stoddard]

Aaron Mulder wrote:
	I really believe that choice is a bad thing.  I don't believe we 
should offer 2 options to a user.  How are they supposed to decide?  How 
are we supposed to guide them?


I'll grant you that there may (*may*) be some possible reason for
a very advanced user to want to run 2 different web containers.  I really
believe this should be an advanced manual process (e.g. download Tomcat
build, then deploy Jetty plan).  I really really really don't want to
encumber every user with both Jetty and Tomcat in order to support this
dual-container feature. 


+1

Gratuitous feature creep is evil and this particular feature violates the "principle 
of least astonishment".

Bill

Re: unable to build - help

[Bill Stoddard]

Anushka Kumar wrote:

Hi all,

I tried to build geronimo source which was downloaded three days ago 
with svn. And I got the following error when assembly module was being 
built.



BUILD FAILED
File.. C:\Documents and 
Settings\anushka\.maven\cache\maven-multiproject-plu

gin-1.3.1\plugin.jelly
Element... maven:reactor
Line.. 217
Column 9
Unable to obtain goal [default] -- 
E:\Study\geronimo\geronimo\modules\assembly\m
aven.xml:350:15:  
org.apache.geronimo.kernel.repository.Mis
singDependencyException: uri tmporb/jars/tmporb-orb-1.0-SNAPSHOT.jar not 
found in repository


Can anybody please reply with the reason.



Running maven m:fresh-checkout followed by maven m:rebuild-all solved this 
problem for me.

Bill

Re: Unable to build...

[Bill Stoddard]

Jacek Laskowski wrote:

Neal Sanche wrote:

After killing that stray process, the build completed successfully 



Hi Neal,

It's a good news, but alas it keeps failing for me. It seems I can't 
build the latest version from today's sources because of some missing 
ActiveIO classes. I wonder how you got passed it? I haven't built 
Geronimo for a while so it'd mean that the local Maven repo is too old.


...
+
| Executing default Geronimo :: Security
| Memory: 23M/34M
+
... geronimo-common-1.0-SNAPSHOT.jar.
... geronimo-core-1.0-SNAPSHOT.jar.
... geronimo-j2ee-1.0-SNAPSHOT.jar.
... geronimo-management-1.0-SNAPSHOT.jar.
... geronimo-kernel-1.0-SNAPSHOT.jar.
... geronimo-system-1.0-SNAPSHOT.jar.
... geronimo-spec-j2ee-jacc-1.0-rc5-SNAPSHOT.jar.

jar:install:


build:end:

build:start:

default:
java:prepare-filesystem:
[mkdir] Created dir: C:\projs\geronimo\modules\security\target\classes

java:compile:
[depend] Deleted 0 out of date files in 0 seconds
[echo] Compiling to c:\projs\geronimo\modules\security/target/classes
[javac] Compiling 79 source files to 
C:\projs\geronimo\modules\security\target\classes
C:\projs\geronimo\modules\security\src\java\org\apache\geronimo\security\network\protocol\SubjectCarryingChannel.java:26: 
cannot resolve symbol

symbol  : class AsynchChannel
location: package activeio
import org.activeio.AsynchChannel;


I think this problem was caused by this change in activeio v2:
http://svn.activeio.org/trunk/activeio/src/java/org/activeio/AsyncChannel.java

Notice classname difference: AsyncChannel is used in v2 vs AsynchChannel used 
in v1.

You may be able to work around this issue by editing etc/project.properties to change the activeio version 
dependency from activeio_version=2.0-20050905 to activeio_version=1.1. Correct (?) solution is to update the 
class references in Geronimo to use the activeio v2 class names.


Bill

Re: IRC logs

[Bill Stoddard]

Dain Sundstrom wrote:

Logs for #geronimo on irc.freenode.org can now be found here:

http://servlet.uwyn.com/drone/log/bevinbot/geronimo

I'd like to thank Bevin for hosting this for us and Jacek for  bringing 
up the idea in the first place.


Geir, can you add a link on the http://geronimo.apache.org/get- 
involved.html page.


Cheers,

-dain


Nice!

Bill ("Old school ASF" ;-)

Re: [policy] Availability of resources for CTS

[Bill Stoddard]

Geir Magnusson Jr. wrote:
> I'd like to try to establish a quick agreement on policies for how we
> handle materials for running the TCK that we have created for  Geronimo
> will be available.
>
> Currently, there is a suite of deployment plans that we use for our  TCK
> testing.  These materials will be useful for any community member  that
> wishes to build a J2EE server product based on Geronimo.  I  think it's
> in our interest to make them available to help promote the  use of
> Geronimo as a base for J2EE server products.

Does anyone need convincing as to why this would be a "Good Thing"?

>
> So, I'd like to propose the following policy for those materials :
>
> 1) Interested community members should contact the PMC, preferably on
> the dev@ list, to ask for these materials.

Consider this an official request; I would like access to the Geronimo CTS 
deployment plans.

>
> 2) The PMC has the right to refuse any request.

With my ASF hat firmly on, if the PMC decides to make the material available outside the ASF I don't think we 
can justify refusing a request unless there are external license issues that adversely affect redistribution.


>
> 3) The materials are provided under the Apache License v2.

Sounds good...

>
> 4) We kindly ask that these materials are not republished.

Either we're ok with redistribution, or we're not. If not, then the license needs to be something other than 
ASL v2.



Bill

Re: Formalising private builds of external libraries (was Re: M4 - QA Branch details)

[Bill Stoddard]

Bill Stoddard wrote:

Alarm Bells going off... G uses a few custom patched packages...

Bill


Guess I am now an official member of the Ben H. misdirected e-mail club ;-) Sorry. I intended my email as a 
heads-up to a friend who could suffer some pain were he not aware of custom built packages in the Geronimo 
build. Again, my apologies.


FWIW, if the project does need to customize a package (not a great state of affairs, but it will occasionally 
happen), I'd suggest adopting a consistent naming convention for the custom package (whatever it is just be 
consistent). Ideally that naming convention would also serve as a key to building a url into the 
geronimo.apache.org URL space for finding the actual patch.


Bill

Re: Formalising private builds of external libraries (was Re: M4 - QA Branch details)

[Bill Stoddard]

Alarm Bells going off... G uses a few custom patched packages...

Bill

Geir Magnusson Jr. wrote:


On Jul 19, 2005, at 9:56 PM, [EMAIL PROTECTED] wrote:


"Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote on 12/07/2005  10:57:34 PM:




On Jul 11, 2005, at 11:07 PM, [EMAIL PROTECTED] wrote:




It appears we have already been building defacto releases of  external
libraries, e.g. the cglib library in our repo:
http://cvs.apache.org/repository/cglib/jars/



You're right - there is a problem we have to deal with, but I'd
rather see us try another approach to make things very clear and
accountable.

For any code that we must do this to we could adopt a strategery :

1) Make a copy in Apache SVN.  This code must be appropriately
licensed (the Apache License) and there should be a very clear NOTICE
about the source, what we're doing, that it's not a fork, etc,  etc

2) Produce a jar :

geronimo-private-cglib-20050711.jar

3) put that in

   geronimo/jars

So it's very clear that it's not a release by CGLib, but rather code
from us, by us, from our repo.



Are planning on formalising the privately built jars using the above
strategy proposed by Geir for M4 or would our time be better spent
starting in M5?



Well, someone is *already* doing it, right?  The difference is that  I'm 
suggesting we put in our SVN and change the name of the jar...




For example, the patched version of xmlbeans and wsdl4j  
(GERONIMO-751) in

M4?

If we have people reporting bugs in M4 that involve these custom built
libraries, it won't be easy for developers to debug if they don't  
have the

source for these custom builds.  Are we happy to take that risk in M4?



I'd prefer not.  It doesn't sound like a lot of overhead and removes  
another ambiguity in our process.


I'm happy to help here - just someone needs to help me out with the  
stuff we've patched...


geir



How do people feel about adopting the above approach and release
documentation discussed below, moving forward?

Thanks,

John






Maybe a compromise is to properly document in the release notes any
special versions of code we have with the following information:

* Have a disclaimer stating that a special version of the library
is being
used temporarily and we plan on moving to the a formal release of  the
library as soon as possible.  Maybe mention there could be a
'chance' of
compatibility issues when we move to the formal version?
* A description of why a special version of a library is needed and
what
the library is used by
* The version of the code that was patched
* A link/reference to the bug/issue tracking records for the
problem with
the library and the patch(s) that were submitted to the external
project.



Yes - all good, in that NOTICE in SVN, and also in the distribution
release notes.



This e-mail message and any attachments may contain confidential,
proprietary or non-public information.  This information is intended
solely for the designated recipient(s).  If an addressing or  
transmission

error has misdirected this e-mail, please notify the sender  immediately
and destroy this e-mail.  Any review, dissemination, use or  reliance 
upon

this information by unintended recipients is prohibited.  Any opinions
expressed in this e-mail are those of the author personally.

Re: Summary checkpoint - Roadmap / Things-to-do

[Bill Stoddard]

Jeremy Boynes wrote:

Jeff Genender wrote:

Not sure what you had in mind here.  I doubt you mean that XML 
hacking is not possible, or that is would be a high tech xml editor.
Do you have more detailed description, or better yet, can you point 
to some tool that does what you are thinking of?




This was one of my ideas...I can explain...

It would be great to have a GUI tool...prefereably in Swing...that will
build you a Geronimo configuration...

i.e... I want OpenJB, with Tomcat, and no JMS.  Click here...clik
there...Press a button...and out pop the plans...and it launches into a
quick assembly.  At the end, I have my server.jar with my special
configuration all built and wrapped for me.

Advanced options would allow us to tweak down to the Gbean level.

A great example is the Jetty vs Tomcat.  It's a PITA to uncomment and
comment many different Gbeans.  It would be great to just have a GUI 
where I

can choose a component(s), and the XML plans are complete.



This would be cool - this would be very similar to a JSR-88 DConfig tool 
so could be used for apps to. Should be easy to add into the Eclipse WTP 
plugin as well.


Eclipse RCP?  http://www.eclipse.org/rcp/

Bill

Re: Stable/Unstable/Sandbox

[Bill Stoddard]

Geir Magnusson Jr. wrote:
Can we agree that we need to somehow construct the stable, unstable  and 
sandbox codebases?


If so, can we move on to how?


geir


Check out the httpd project:

http://svn.apache.org/repos/asf/httpd/httpd/

essential features:
'trunk' is 'development' (unstable) reporitory. It is constantly moving forward under loose rules for what can 
be committed.


'branches' contains the 'stable' code. httpd 2.0.x (and 1.3.x) constantly move forward but under a 
'review-then-commit' policy. All code that goes into the stable branch must be reviewed and voted on before it 
can come into the stable branch.


'tags' contains all the tagged releases
http://svn.apache.org/repos/asf/httpd/httpd/branches/

So using this model, one of the geronimo branches could be 1.0.x. When 1.0 is 'done', tag the release and 
continue on the next 'stable' drop, migrating function out of trunk and into 1.x using whatever process you 
like (RTC, CTR, votes, whatever). The RTC + vote policy httpd 2.0.x uses may be too restrictive for geronimo 
1.0.x, so do whatever makes sense for this project.


There will come a day when you want another stable branch of geronimo (presumably forked from trunk). When 
that day comes, just create a new tree under 'branches', named differently (maybe 2.0.x or 1.2.x, whatever).


I know this doesn't really answer the more interesting question about how to structure the repository to 
support assemblying components into a 'custom' install.


Bill