Re: Entropy, or the heat death of the geronimo code base

2008-02-29 Thread Prasad Kashyap

 prasad:
 sandbox/restructure

This has served its purpose and is obsolete now. Feel free to delete it.

Cheers
Prasad

On Thu, Feb 28, 2008 at 6:07 PM, David Jencks [EMAIL PROTECTED] wrote:
 A few years ago I read about an information based perpetual motion
 machine someone came up with.  IIRC many people studied it for quite
 a while before realizing that the flaw was an assumption that erasing
 information was free.  It turned out to require the same energy as
 apparently extracted from the machine.

 By applying this green svn energy saving principle we have an
 unparalleled opportunity to assure that future visitors to our svn
 repo will have no way of finding the live code.

 OR...

 we could clean up the leftovers from completed refactoring efforts
 and releases.

 Here's the stuff I have located in a quick scan that I think has more
 recent versions elsewhere or is completely obsolete and can be
 removed, organized by last committer:

 pmcmahan:

 plugins/activemq
 plugins/console
 plugins/debugviews
 plugins/jee-management
 plugins/plancreator
 plugins/pluto
 plugins/system-database

 djencks:
 sandbox/servlet-2.5 (I'm not the last committer but did merge this
 into trunk) (I've removed this)
 sandbox/geronimo-jaspi (I merged this into trunk, and removed it)

 jdillon

 sandbox/g1.1-activemq4
 sandbox/repository (did this make it into the wiki?  I'm planning to
 propose using http://maven.apache.org/developers/release/
 releasing.html as the basis for releasing g. stuff, is this relevant?)

 dain:
 sandbox/plugins/global-jndi (I'm pretty sure I've got this all into
 trunk)

 prasad:
 sandbox/restructure

 kevan:
 sandbox/xsds  Didn't these get moved somewhere more appropriate?

 rick:
 sandbox/mail  (You had nothing to do with this, but could you look
 and check if there is anything useful inside?)

 alan:
 sandbox/james (this appears to be a basically unmodified copy of james)

 dblevins:
 server/branches/jpa-plugin  (looks like a branch to play with jpa
 that never went anywhere)
 specs/branches/jee5-spec (See GERONIMO-2358 Not sure why this didn't
 get removed or is my svn messed up?)

 gnodet:
 specs/branches/geronimo-servlet_2.5_spec-1.1.1
 specs/branches/geronimo-stax-api_1.0_spec-1.0.1



 Does anyone have any clue what this is:

 sandbox/spring-assembly (last modified 2006)


 --

 If you know about one of these and think it should stay please
 reply.  If you know it should go you can remove it, tell me to remove
 it, or do nothing and I will in a few days.

 thanks
 david jencks









Re: Documentation mega index

2008-02-29 Thread Prasad Kashyap
That is sooo cool.

I also noticed that there were version specific user and developer
guides in the first column too.  They can be merged into a single row
as User Guide with appropriate links in the remaining columns.

Cheers
Prasad

On Thu, Feb 28, 2008 at 5:22 PM, David Blevins [EMAIL PROTECTED] wrote:
 I created a very high level view of our documentation as it exists
 across the various versions.  Hopefully a very macro few of things may
 help us clear the fog on documentation related thinking.  At least I
 found it very difficult to see the whole elephant.

 http://cwiki.apache.org/GMOxDEV/mega-index.html

 The code I used to generate the page is attached to the page.  It's
 pretty small.  Should be a fairly easy manual process to regenerate
 the page once in a while if we find it useful.

 -David




Re: TCK Dog

2008-02-21 Thread Prasad Kashyap
Most definitely. Thank you Joe for shouldering such a big
responsibility for the project.

Cheers
Prasad

On Wed, Feb 20, 2008 at 4:58 PM, Kevan Miller [EMAIL PROTECTED] wrote:

 On Feb 20, 2008, at 1:15 PM, Jay D. McHugh wrote:

  I've been referred to as a puppy before :)
 
  But I'd be happy to graduate to TCK Dog.  And, I already have my NDA
  registered.  I am still trying to get my local TCK build environment
  set up though.
 
  But as long as I was able to transition into the role with some
  help, I'll volunteer.

 Cool. Thanks a lot Jay!

 I think we all owe Joe a big thanks. He's done a great job keeping our
 TCK status in the green...

 --kevan



Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo

2008-01-16 Thread Prasad Kashyap
Thanx Matt.

Congrats Kevan !  (the band is now playing *Hail to the Chief* )

Cheers
Prasad

On Jan 16, 2008 3:10 PM, Matt Hogstrom [EMAIL PROTECTED] wrote:
 Recently I have had several things change personally and I have found
 it increasingly difficult to keep up with the Geronimo mailing lists
 on a daily basis.  As a result, I did some soul searching and decided
 that my intentions to stay on top of Geronimo were good but my follow
 through wasn't   This was specifically in regard to being able to
 respond to people on issues that I needed to do as PMC chair.

 I tendered my resignation to the Board earlier this week.  There was
 some discussion on the PMC list about a replacement and the PMC
 unanimously approved Kevan Miller as my successor.  The board just
 approved this request so Kevan now has the mantle for Geronimo as the
 PMC chair.

 It is with great pleasure that I announce that Kevan has accepted this
 responsibility of PMC chair.  The beauty is that Kevan has already
 been doing most of the work of the PMC chair anyway and is the right
 person going forward.  Please give it up for Kevan Miller, VP, Apache
 Geronimo!

 I'm still noodling with some performance work as time allows so I'm
 not gone.  I'll prolly continue to nag in my own unique way.

 Matt



Re: Integrating Jetspeed with Geronimo

2008-01-14 Thread Prasad Kashyap
 for j2-admin::ForgottenPasswordPortlet
 00:16:10,455 WARN  [JetspeedPortletContainerWrapper] Could not render
 PortletWindowdp-22 as it has no PortletDefintion defined.
 00:16:10,456 WARN  [PersistenceBrokerPortletEntityAccess] Failed to retrieve
 Portlet Definition for j2-admin::UserRegistrationPortlet
 00:16:10,458 WARN  [JetspeedPortletContainerWrapper] Could not render
 PortletWindowdp-23 as it has no PortletDefintion defined.
 00:16:10,461 WARN  [PersistenceBrokerPortletEntityAccess] Failed to retrieve
 Portlet Definition for demo::WeatherPortlet
 00:16:10,463 WARN  [JetspeedPortletContainerWrapper] Could not render
 PortletWindowdp-24 as it has no PortletDefintion defined.
 00:16:10,464 WARN  [PersistenceBrokerPortletEntityAccess] Failed to retrieve
 Portlet Definition for demo::PickANumberPortlet
 00:16:10,465 WARN  [JetspeedPortletContainerWrapper] Could not render
 PortletWindowdp-7 as it has no PortletDefintion defined.
 00:16:10,467 WARN  [PersistenceBrokerPortletEntityAccess] Failed to retrieve
 Portlet Definition for demo::RoleSecurityTest
 00:16:10,468 WARN  [JetspeedPortletContainerWrapper] Could not render
 PortletWindowdp-16 as it has no PortletDefintion defined.
 00:16:10,470 WARN  [PersistenceBrokerPortletEntityAccess] Failed to retrieve
 Portlet Definition for demo::IFramePortlet
 00:16:10,473 WARN  [JetspeedPortletContainerWrapper] Could not render
 PortletWindowdp-9 as it has no PortletDefintion defined.
 00:16:10,475 WARN  [PersistenceBrokerPortletEntityAccess] Failed to retrieve
 Portlet Definition for demo::IFramePortlet
 00:16:10,477 WARN  [JetspeedPortletContainerWrapper] Could not render
 PortletWindowdp-10 as it has no PortletDefintion defined.
 00:16:10,478 WARN  [PersistenceBrokerPortletEntityAccess] Failed to retrieve
 Portlet Definition for demo::UserInfoTest
 00:16:10,481 WARN  [JetspeedPortletContainerWrapper] Could not render
 PortletWindowdp-17 as it has no PortletDefintion defined.
 00:16:10,483 WARN  [PersistenceBrokerPortletEntityAccess] Failed to retrieve
 Portlet Definition for demo::BookmarkPortlet
 00:16:10,485 WARN  [JetspeedPortletContainerWrapper] Could not render
 PortletWindowdp-18 as it has no PortletDefintion defined.
 00:16:10,487 WARN  [PersistenceBrokerPortletEntityAccess] Failed to retrieve
 Portlet Definition for jetspeed-layouts::VelocityTwoColumns
 00:16:10,490 WARN  [JetspeedPortletContainerWrapper] Could not render
 PortletWindowdp-1 as it has no PortletDefintion defined.

 Is this similar to what you see or have I come up with a whole different set
 of errors?

 thanks
 david jencks



 On Jan 11, 2008, at 1:58 PM, Prasad Kashyap wrote:

 The work on integrating Jetspeed with Geronimo is currently in the sandbox.
 http://svn.apache.org/viewvc/geronimo/sandbox/jetspeed-integration/

 This is what the following modules do.

 jetspeed-base:
 -
 This module installs 5 common jetspeed jars into the G repository.
 jetspeed-api-2.0.jar, jetspeed-commons-2.0.jar, pluto-1.0.1.jar,
 portals-bridges-common-1.0.jar, portlet-api-1.0.jar,
 derby-10.1.1.0.jar

 jetspeed-database:
 
 This module carries SQL scripts for different DBs. These SQL scripts
 are used to  create DB tables and initialize them.

 jetspeed-derby-database:
 -
 This is the CAR configuration for jetspeed's derby datasource. It
 includes the connector module tranql-connector-embed-local.rar.  It
 invokes the o.a.g.connector.DatabaseInitializationGBean which executes
 the derby SQL scripts that were carried in the above etspeed-database
 module.

 jetspeed-geronimo:
 
 This module carries and installs the jars for jetspeed's portal
 runtime. It has the JetspeedSerializerGBean which will be used to
 seed/populate the databases before the portal starts.

 jetspeed-tomcat:
 
 This is a configuration for Jetspeed portal application on Tomcat web
 container.
 It carries -
 a) db-page-manager.xml, interceptor.xml and request-context.xml that
 will be needed to seed some tables.
 b) geronimo-datasource.xml which will be used by Spring to seed the tables.
 c) j2-seed.xml which provide data for seeding the tables.
 It invokes the JetspeedSerializerGBean from the above module which
 uses a bunch of other xmls in the web-inf/assembly directory of the
 jetspeed application to seed the tables.

 During the process-resources phase of building this configuration, the
 j2-layouts.jar is dropped in  the jetspeed app's web-inf/deploy dir.
 Once the portal app starts running, it deploys the layouts
 appropriately.

 jetspeed-builder:
 ---
 It has the JetspeedModuleBuilderExtension.

 jetspeed-deployer:
 ---
 Configuration for the above jetspeed-builder.

 Status:
 ---
 The jetspeed portal application starts up fine.
 The j2-layouts portlet application seems to deploy fine when placed
 under web-inf/deploy.
 The j2-admin portlet

Re: Shouldn't subprojects use their file system parents as maven parents?

2008-01-14 Thread Prasad Kashyap
My thinking on this was to leave it as is for 2.1. We fix this right
for 2.2, when we split the trunk into different svn trees.

Moving the c-m-p configuration settings from configs parent pom to the
root pom is not a problem. It is the boatload of property settings
that will cause Jason good grief :-)

Cheers
Prasad

On Jan 11, 2008 1:12 AM, David Jencks [EMAIL PROTECTED] wrote:
 After the reorganization into plugins most everything still has its
 old pom parent, either o.a.g.modules/modules or o.a.g.plugins/
 plugins.  This seems to me like a bad idea.

 I don't see any problem fixing this for jars, but cars would need the
 car plugin setup moved to perhaps the root pom I don't know if
 that will work.

 I opened GERONIMO-2747 about this.

 Anyone else think this should be fixed before 2.1 goes out?

 thanks
 david jencks




Integrating Jetspeed with Geronimo

2008-01-11 Thread Prasad Kashyap
The work on integrating Jetspeed with Geronimo is currently in the sandbox.
http://svn.apache.org/viewvc/geronimo/sandbox/jetspeed-integration/

This is what the following modules do.

jetspeed-base:
-
This module installs 5 common jetspeed jars into the G repository.
jetspeed-api-2.0.jar, jetspeed-commons-2.0.jar, pluto-1.0.1.jar,
portals-bridges-common-1.0.jar, portlet-api-1.0.jar,
derby-10.1.1.0.jar

jetspeed-database:

This module carries SQL scripts for different DBs. These SQL scripts
are used to  create DB tables and initialize them.

jetspeed-derby-database:
-
This is the CAR configuration for jetspeed's derby datasource. It
includes the connector module tranql-connector-embed-local.rar.  It
invokes the o.a.g.connector.DatabaseInitializationGBean which executes
the derby SQL scripts that were carried in the above etspeed-database
module.

jetspeed-geronimo:

This module carries and installs the jars for jetspeed's portal
runtime. It has the JetspeedSerializerGBean which will be used to
seed/populate the databases before the portal starts.

jetspeed-tomcat:

This is a configuration for Jetspeed portal application on Tomcat web
container.
It carries -
a) db-page-manager.xml, interceptor.xml and request-context.xml that
will be needed to seed some tables.
b) geronimo-datasource.xml which will be used by Spring to seed the tables.
c) j2-seed.xml which provide data for seeding the tables.
It invokes the JetspeedSerializerGBean from the above module which
uses a bunch of other xmls in the web-inf/assembly directory of the
jetspeed application to seed the tables.

During the process-resources phase of building this configuration, the
j2-layouts.jar is dropped in  the jetspeed app's web-inf/deploy dir.
Once the portal app starts running, it deploys the layouts
appropriately.

jetspeed-builder:
---
It has the JetspeedModuleBuilderExtension.

jetspeed-deployer:
---
Configuration for the above jetspeed-builder.

Status:
---
The jetspeed portal application starts up fine.
The j2-layouts portlet application seems to deploy fine when placed
under web-inf/deploy.
The j2-admin portlet app seems to deploy fine using the jetspped-deployer.

However, accessing the portal app at http://localhost:8080/portal
returns a 500 error because the portal loads
web-inf/pages/default-pages.psml. This contains fragments from
j2-layouts and j2-admin portlet apps.  The portal app cannot recognize
portlet apps under it.

The portlet app deployed in this portal should have the portal
configuration as it's parent. But the portal app now cannot see the
child portlet app when it tries to load fragments from it. I *think*
this is what is happening.

Also see the wiki page at
http://cwiki.apache.org/confluence/display/GMOxDEV/Integrating+Jetspeed+with+Geronimo

Cheers
Prasad


Re: Running integration tests by default?

2008-01-02 Thread Prasad Kashyap
On Dec 31, 2007 4:41 PM, David Jencks [EMAIL PROTECTED] wrote:
 First of all I appear to have broken the build last night with some
 changes to get the roller plugin building again.  I think I've
 managed to fix all the problems -- the it tests all pass for me.  Let
 me know if there are still problems.

 I think its still too hard to run the integration tests.

I would like to know what exactly you think is hard about it. It would
be great if you could please share your thoughts and ideas on making
it simpler.

 I've made a
 possibly annoying change so that the default build includes IT.  If
 you don't want them run

 mvn clean install -P no-it

 If this is too annoying we could reverse the profiles and have the
 default leave out the it as before and a with-it profile that
 includes them.

Yeah. I think the default profile should not run the IT. IMHO, I think
it should not even run the unit tests by default. Developers (should)
run unit  IT tests before committing their code. And we have
automation builds with all tests that run 4 times a day anyways. So
the default profile can well do away with tests. But that may just be
my opinion.


 Comments?

 This might have bad effects on Prasad's automation but I'm not sure
 how that is run.

For now, the automation builds have been modified to use the no-it profile.


 thanks  Happy New Year!
 david jencks

Happy New Year to ya'll !
Prasad


Re: [BUILD] 2.1: Failed for Revision: 608130

2008-01-02 Thread Prasad Kashyap
Root cause:

11:19:20,898 INFO  [Log4jService] --
11:19:33,423 ERROR [[TomcatWebContainer]] Restricted listeners
property file not found
11:19:36,093 INFO  [startup] Creating TransactionManager(id=Default
Transaction Manager)
11:19:36,096 ERROR [GBeanInstanceState] Error while starting; GBean is
now in the FAILED state:
abstractName=org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car,j2eeType=GBean,name=OpenEjbSystem
java.lang.NoSuchFieldError: CASE_INSENSITIVE_PROPERTIES
at 
org.apache.openejb.assembler.classic.Assembler.createRecipe(Assembler.java:1096)
at 
org.apache.openejb.assembler.classic.Assembler.createTransactionManager(Assembler.java:1032)
at 
org.apache.geronimo.openejb.OpenEjbSystemGBean.init(OpenEjbSystemGBean.java:125)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:946)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:534)
at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
at 
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at 
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at 
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at 
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$5ba37b8d.startConfiguration(generated)
at 
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:156)
at 
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)

On 2 Jan 2008 16:40:10 -,  [EMAIL PROTECTED] wrote:
 OpenEJB trunk at 608102
 Geronimo Revision: 608130 built with tests included

 See the full build-1037.log file at 
 http://people.apache.org/~prasad/binaries/trunk/20080102/build-1037.log

 Download the binaries from 
 http://people.apache.org/~prasad/binaries/trunk/20080102
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 29 minutes 44 seconds
 [INFO] Finished at: Wed Jan 02 11:14:37 EST 2008
 [INFO] Final Memory: 288M/1001M
 [INFO] 
 

 TESTSUITE RESULTS (Failures only)
 =
 See detailed results at 
 http://people.apache.org/~prasad/testsuite/ResultsSummary.html

 Assembly: tomcat
 =
 See the full test.log file at 
 http://people.apache.org/~prasad/binaries/trunk/20080102/logs-1037-tomcat/test.log


 [INFO] 
 
 [INFO] Building Geronimo TestSuite :: Console Testsuite
 [INFO]task-segment: [install]
 [INFO] 
 
 [INFO] snapshot org.codehaus.mojo:selenium-maven-plugin:1.0-beta-2-SNAPSHOT: 
 checking for updates from 

Re: J2EE application client in geronimo 2.0.2

2007-12-20 Thread Prasad Kashyap
Most of the tests in the webservices-testsuite have a client piece in
it. You will find simple examples of the plan there.

http://svn.apache.org/repos/asf/geronimo/server/branches/2.0/testsuite/webservices-testsuite/

Cheers
Prasad

On Dec 20, 2007 6:33 AM, ivanrc [EMAIL PROTECTED] wrote:

 Hello,

  Can I deploy J2EE 5 application client in geronimo 2.0.2?. there is no way
 to do it work!. The previous versions of application-client.xml and
 geronimo-application-client.xml for geronimo 1.1 don´t work in geronimo
 2.0.2.

  Please write me down some examples of application-client.xml and
 geronimo-application-client.xml.

 Thanks.

 --
 View this message in context: 
 http://www.nabble.com/J2EE-application-client-in-geronimo-2.0.2-tp14434684s134p14434684.html
 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.




Re: J2EE application client in geronimo 2.0.2

2007-12-20 Thread Prasad Kashyap
My first guess is that the deploy tool could be broken. The client
jars in the webservices-testsuite are deployed with the help of
geronimo-maven-plugin:deploy-module.

Just for kicks, can you please try using the deploy.bat ?

Cheers
Prasad

On Dec 20, 2007 11:24 AM, ivanrc [EMAIL PROTECTED] wrote:

 I´m has created application client with that deployment descriptors
 (geronimo-application-client.xml and application-client.xml)   but when I
 deploy it, I obtain this error:

 D:\temp\ejb3\geronimo_clientjava -jar
 D:\geronimo-tomcat6-jee5-2.0.2/bin/deploy
 er.jar --user system --password manager --host localhost --port 1099 deploy
 app_
 client.jar
 Error: Unable to distribute app_client.jar: Cannot deploy the
 requested application module because no deployer is able to handle
 it.  This can happen if you have omitted the J2EE deployment
 descriptor, disabled a deployer module, or if, for example, you are
 trying to deploy an EJB module on a minimal Geronimo server that
 does not have EJB support installed.

 (moduleFile=D:\geronimo-tomcat6-jee5-2.0.2\servers\node1\var\temp\geronimo-d
 eployer42379.tmpdir\app_client.jar)

 D:\temp\ejb3\geronimo_clientpause
 Presione una tecla para continuar . . .


 Do you know what is the problem?

 My jar is named app_client.jar and it contains..

  - client/MainClient.class that contains main static method

  - META-INF/application-client.xml:

 ?xml version=1.0?
 application-client xmlns=http://java.sun.com/xml/ns/j2ee;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
 http://java.sun.com/xml/ns/j2ee/applicationclient_1_4.xsd;
 version=1.4

 display-nameJAXB Client/display-name

 /application-client

 - META-INF/geronimo-application-client.xml:

 ?xml version=1.0?
 application-client
xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-client-1.2;
xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2;

dep:client-environment
 dep:moduleId
   dep:groupIdJEE5/dep:groupId
   dep:artifactIdJAXBClient/dep:artifactId
   dep:version1.1/dep:version
   dep:typecar/dep:type
 /dep:moduleId
/dep:client-environment

dep:server-environment
 dep:moduleId
   dep:groupIdJEE5/dep:groupId
   dep:artifactIdJAXBClientServer/dep:artifactId
   dep:version1.1/dep:version
   dep:typecar/dep:type
 /dep:moduleId
/dep:server-environment

 /application-client

 - META-INF/MANIFEST.MF contains: Main-Class: client.MainClient
















 prasad wrote:
 
  Most of the tests in the webservices-testsuite have a client piece in
  it. You will find simple examples of the plan there.
 
  http://svn.apache.org/repos/asf/geronimo/server/branches/2.0/testsuite/webservices-testsuite/
 
  Cheers
  Prasad
 
  On Dec 20, 2007 6:33 AM, ivanrc [EMAIL PROTECTED] wrote:
 
  Hello,
 
   Can I deploy J2EE 5 application client in geronimo 2.0.2?. there is no
  way
  to do it work!. The previous versions of application-client.xml and
  geronimo-application-client.xml for geronimo 1.1 don´t work in geronimo
  2.0.2.
 
   Please write me down some examples of application-client.xml and
  geronimo-application-client.xml.
 
  Thanks.
 
  --
  View this message in context:
  http://www.nabble.com/J2EE-application-client-in-geronimo-2.0.2-tp14434684s134p14434684.html
  Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
 
 
 
 

 --
 View this message in context: 
 http://www.nabble.com/J2EE-application-client-in-geronimo-2.0.2-tp14434684s134p14439820.html

 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.




Re: Unable to render portlet SecurityRealmPortlet

2007-12-19 Thread Prasad Kashyap
I don't think we have a way of knowing what svn revision a final
Geronimo binary came from. Is there ?

Maybe we should include a revision.txt file in ${geronimo_home} which
contains the svn revision number of the build from which the binary
was built.

Cheers
Prasad

On Dec 19, 2007 10:03 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:

On Dec 19, 2007 7:11 PM, Hernan Cunico  [EMAIL PROTECTED]
  wrote:
   
 This is from Monday's rev #605334

   The last good build was rev. 605315
 http://people.apache.org/~prasad/binaries/trunk/20071218/build-1500.log

The build is broken since rev. 605384
 http://people.apache.org/~prasad/binaries/trunk/20071218/build-2100.log

 Thanks
 Anita


   
 
 Looking for last minute shopping deals?
 Find them fast with Yahoo! Search.  
 http://tools.search.yahoo.com/newsearch/category.php?category=shopping



Re: Unable to render portlet SecurityRealmPortlet

2007-12-19 Thread Prasad Kashyap
Anita,

This is the svn revision number of the build. This is got from doing a
svn info soon after a svn co was done.

Cheers
Prasad

On Dec 19, 2007 12:19 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
 What is this rev no?


 Building Geronimo trunk at Revision: 605315
 Building OpenEJB trunk at 605298

 java version 1.5.0_12
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
 Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode)

 + Error stacktraces are turned on.
 [INFO] Scanning for projects...
 Downloading:
 http://download.java.net/maven/1//org.apache.geronimo.genesis.config/poms/project-config-1.2.pom
 Downloading:
 http://repo1.maven.org/maven2/org/apache/geronimo/genesis/config/project-config/1.2/project-config-1.2.pom
 21K downloaded..
 .

 Thanks
 Anita


 --- Prasad Kashyap [EMAIL PROTECTED] wrote:

  I don't think we have a way of knowing what svn revision a final
  Geronimo binary came from. Is there ?
 
  Maybe we should include a revision.txt file in ${geronimo_home} which
  contains the svn revision number of the build from which the binary
  was built.
 
  Cheers
  Prasad
 
  On Dec 19, 2007 10:03 AM, Anita Kulshreshtha [EMAIL PROTECTED]
  wrote:
  
  On Dec 19, 2007 7:11 PM, Hernan Cunico  [EMAIL PROTECTED]
wrote:
 
   This is from Monday's rev #605334
  
 The last good build was rev. 605315
  
 
 http://people.apache.org/~prasad/binaries/trunk/20071218/build-1500.log
  
  The build is broken since rev. 605384
  
 
 http://people.apache.org/~prasad/binaries/trunk/20071218/build-2100.log
  
   Thanks
   Anita
  
  
  
 
 
   Looking for last minute shopping deals?
   Find them fast with Yahoo! Search.
 
 http://tools.search.yahoo.com/newsearch/category.php?category=shopping
  
 



   
 
 Never miss a thing.  Make Yahoo your home page.
 http://www.yahoo.com/r/hs



Re: Unable to render portlet SecurityRealmPortlet

2007-12-19 Thread Prasad Kashyap
I know but this is not for the binaries that we build daily. I was
thinking of this as a good general practice for all binaries we build
anywhere. And even for the binaries we build daily, it isn't a simple
task to retrieve the revision number a few days after the binary has
been installed. When I go back to a few of the geronimo installations
I have on my machine now, I can't tell easily which svn revision they
were built from.

Cheers
Prasad

On Dec 19, 2007 12:36 PM, Jarek Gawor [EMAIL PROTECTED] wrote:
 You can figure this out from the timestamps of the binary and the log
 files. The log files and the binary files are uploaded at the same
 time so their timestamp will be close. The log file also contains the
 svn revision of Geronimo. So look at the timestamp of  the binary,
 find corresponding log file, and then lookup the svn revision number
 in the log file.
 The right svn revision numbers are also included in the email
 notifications, so that's another way to figure this out.

 Jarek


 On Dec 19, 2007 11:29 AM, Prasad Kashyap [EMAIL PROTECTED] wrote:
  I don't think we have a way of knowing what svn revision a final
  Geronimo binary came from. Is there ?
 
  Maybe we should include a revision.txt file in ${geronimo_home} which
  contains the svn revision number of the build from which the binary
  was built.
 
  Cheers
  Prasad
 
 
  On Dec 19, 2007 10:03 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
  
  On Dec 19, 2007 7:11 PM, Hernan Cunico  [EMAIL PROTECTED]
wrote:
 
   This is from Monday's rev #605334
  
 The last good build was rev. 605315
   http://people.apache.org/~prasad/binaries/trunk/20071218/build-1500.log
  
  The build is broken since rev. 605384
   http://people.apache.org/~prasad/binaries/trunk/20071218/build-2100.log
  
   Thanks
   Anita
  
  
 
   
   Looking for last minute shopping deals?
   Find them fast with Yahoo! Search.  
   http://tools.search.yahoo.com/newsearch/category.php?category=shopping
  
 



Re: [VOTE] Release Genesis 1.3

2007-12-14 Thread Prasad Kashyap
+1

Cheers
Prasad

On Dec 11, 2007 4:58 AM, Jason Dillon [EMAIL PROTECTED] wrote:
 Folks, a small change to Genesis was made to support a custom legal
 resource bundle for the GShell release.  I'd like to get this out so
 we can get GShell out too.

 +1 -Release it
 +0 -Eh, whatever
 -1 -Um, no no no no no...

 --jason



Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

2007-12-10 Thread Prasad Kashyap
I'm with Matt on this. Since it is not perfect to everybody's
satisfaction, let us move it to the /plugins tree (at least for now).
Sandbox is definitely not the place for it.

Erik, contrary to your belief, the /plugins tree does not contain only
those plugins that work independent of G.  It *mostly* contains
plugins that integrate independent projects (like Liferay, ApacheDS,
roller etc) with G. Now the monitoring plugin does not actually fit
that bill. Neverthless,  that is still a step above sandbox, and still
on the road to trunk/plugins.  It can still be released with 2.1 and
still available in the plugins catalog for possible installation.

Cheers
Prasad

On Dec 8, 2007 12:00 AM, Matt Hogstrom [EMAIL PROTECTED] wrote:

 On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote:

  2. If yes, then where should we move it to? Should it be in server/
  trunk/plugins or should the monitoring plugin be a subproject.
 
 I was thinking of plugins..

 I'm not sure it really matters where the code goes in the interim.
 Plugins makes sense but I would move it to trunk first.  Trunk is
 certainly viable and would likely get more people to look at the code,
 report issues, and most likely ooh and awe about cool looking graphs
 and statistics.

 If it turns out that the monitoring bloats the server in an
 unacceptable way, has incorrect statistics or consumes too many
 resources then I would think that moving it to plugins would be a
 reasonable approach.





Re: Uninstalling an application

2007-12-06 Thread Prasad Kashyap
I have noticed this irksome behavior too. AFAIK, there isn't a better
way. For now, this is a gaping hole in our plugin design.

Seems like when a plugin is uninstalled, we'll have to uninstall all
the child components recursively.

Cheers
Prasad

On Dec 6, 2007 10:04 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
 I installed a plugin using 'plugins' portlet in the admin console.
 It worked as expected. After the plugin is uninstalled it leaves its
 dependent cars and ears behind. I have tried it from both command line
 and console. Next time I install the plugin using 'plugins' I get old
 dependencies. I have to hand delete the stuff from G/repository and
 edit config.xml to install it correctly. Is there a better way to do
 this?


 Thanks
 Anita



   
 
 Be a better friend, newshound, and
 know-it-all with Yahoo! Mobile.  Try it now.  
 http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ




Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2

2007-12-06 Thread Prasad Kashyap
I agree. We should make GShell flexible like our Geronimo server.

I don't know if this makes sense but I'll just think aloud. At it's
core should be the most basic features like start/stop and
deploy/undeploy. Since Groovy is the culprit, can Groovy sit this one
out ? I believe we use goals from g-m-p anyways to achieve those basic
features. Everything else should be optionally built up using G-shell
plugins. Groovy support can be one such optional plugin.

Cheers
Prasad

On Dec 5, 2007 9:50 PM, Kevan Miller [EMAIL PROTECTED] wrote:

 On Dec 3, 2007, at 8:04 PM, Gianny Damour wrote:

  On 04/12/2007, at 11:45 AM, Jason Dillon wrote:
 
  On Dec 2, 2007, at 5:10 PM, Kevan Miller wrote:
  A bit harder to apples-to-apples compare the longer term growth.
  lib/gshell accounts for a 5 meg growth (unpacked). So, that
  would help account for most of the growth in the minimal
  assembly...
 
  I wonder if we should consider allowing gshell to be optional...
 
  I'd recommend *not*, though if we aren't happy with the additional
  bloat from the current impl, we can re-implement in pure-java and
  remove the dependency on Groovy.  Its possible, though not very
  elegant IMO, as the AntBuilder syntax is ideal for launching new
  processes.
  Hi,
 
  I am actually quite a fan of Groovy commands and really would like
  Groovy to stick around. Beside the fact that the AntBuilder syntax
  is neat, Groovy commands could provide a very neat and simple way to
  dynamically introduce new commands w/o going through a compile
  cycle. I believe many Geronimo users are Java savvy enough, and
  hence also Groovy savvy enough to directly implement their commands
  in Groovy. It is in my understanding that gshell provides a gsh-bsf
  command (not tried, just read the code) and this is a first way to
  launch Groovy scripts; however, it would be great to directly map
  commands to groovy scripts out-of-the-box.

 Understood. Playing a bit of the devil's advocate here...

 A high percentage of Geronimo users will never create a custom
 Geronimo command, nor create or use GShell scripting capabilities.
 They'll want to start/stop Geronimo and deploy/undeploy applications.

 For these capabilities, geronimo-boilerplate-minimal-2.1.jar has grown
 by nearly 200% (3.0 meg - 8.3 meg).

 Also, most users will never generate new server assemblies. Yet, for
 this capability, we're increasing the minimal server size by 8.3 megs
 (essentially including the boilerplate-minimal jar twice). At the
 moment, minimal assembly has grown from 16 megs to 31 megs.

 IMO one of Geronimo's major advantages is that it's lightweight and
 flexible. We're still flexible, but we seem to have put on a few
 holiday pounds... I'd like to think about how we can slim things back
 down...

 --kevan





Re: [VOTE] Make Yoko core orb a Yoko subproject.

2007-12-06 Thread Prasad Kashyap
+1

Cheers
Prasad

On Dec 6, 2007 9:43 AM, Rick McGuire [EMAIL PROTECTED] wrote:
 The discussion thread has been out there long enough for comment, and
 those who have responded appear positive about the prospect.  I think
 it's time to put this to a vote.  The full proposal from Matt Hogstrom
 is attached at the end, but the basic proposal we're voting on
 implementing in Geronimo is:

 1)  Accept the Yoko core modules (corba spec, corba core implemenation,
 rmi spec and rmi implementation) as a subproject of Geronimo.
 2)  The Yoko subproject will be maintained as a stand-alone component so
 it can be used by Harmony as well as Geronimo.
 3)  Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join
 the Geronimo project as commiters so that they may continue contributing
 to the Yoko ORB.

 This is a single vote on the entire proposal (accepting the code and
 inviting the commiters).

 [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above.
 [ ] 0 No opinion
 [ ] -1 Do not implement the Yoko subproject as proposed.

 Only PMC member's votes are binding, but we invite anybody in the
 community to speak up and vote on this.

 Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern
 time on Monday.

 Rick

 Matt's full proposal presented to the Yoko project:

 The members of project yoko have been considering the future of Yoko as
 a project.  There have been several milestones delivered and the project
 is used by other ASF projects.   The project is not as active as other
 ASF projects and it makes sense to move the code from Yoko to other
 projects.  The Yoko team has the following proposal for your consideration.

 Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo

 The Yoko community has been successful in delivering several milestones
 of the ORB implementation while in the Apache Incubator.  These
 milestones are used by other Apache projects (namely Geronimo and
 Harmony) to support their releases.  The WebServices bindings are
 dependent on CXF.  The Yoko community has decided that the Yoko project
 does not have quite the momentum to carry itself as an independent
 project but has sufficient value for other projects for them to consider
 receiving the code and committers for that code-base as sub-projects.
 Since the code under consideration is used by Apache Geronimo, Apache
 CXF and Apache Harmony the movement of the code should continue to allow
 for independent releases so the code can be easily shared with other
 dependent projects.

 The proposed division is:

 yoko-spec-corba - this is the org.omg interface classes.
 rmi-spec - this is the javax.rmi spec implementation
 core - This is the actual ORB implementation.
 rmi-impl - This is the implementation of the RMIIIOP support.

 These modules are also used by Harmony.

 In addition to the code we propose that the following committers in
 Apache Yoko be accepted as committers in Apache Geronimo given their
 demonstration of delivering code, creating releases and functioning as a
 community.  Those noted with asterisks are already Geronimo committers.

 Continued involvement with the core:

 Rick McGuire *
 David Jencks *
 Alan Cabrera  *
 Lars Kuhne
 Alexey Petrenko
 Darren Middleman

 The remainder of the modules in Yoko are part of the webservices support
 and are independent of the underlying ORB implementation.

 api -- interface classes used for the web services support.
 bindings -- code to implement the CORBA-Web services bindings.
 tools -- tools for generation WSDL and IDL for the bindings
 maven-plugin -- some maven plugins that can use the tools for generating
 binding-related build artifacts.  None of the maven-plugin code is used
 by the ORB.

 There is also a distribution directory with some sample applications.
 One set of samples demonstrates using the core ORB, the other set is for
 WebServices.  We recommend that the distribution directory should move
 to Apache CXF as the webservices examples use the orb samples to bind
 them as web services.  Since Apache Geronimo's only use of CORBA is for
 exporting EJBs, these samples are not particularly valuable for Geronimo.

 The Yoko community did not have any committers that expressed an
 interest in continuing work on these bindings.  As such, only the code
 would be moving to apache CXF.




Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC

2007-12-05 Thread Prasad Kashyap
Congrats Jay !

Cheers
Prasad

On Dec 4, 2007 11:26 PM, Kevan Miller [EMAIL PROTECTED] wrote:
 All,
 Please join us in congratulating Jay McHugh as the newest member of
 the Geronimo PMC. It's been great to have Jay working with us as a
 committer on Geronimo. Even better to have him join us in providing
 oversight of the Geronimo project.

 Way to go Jay!!!

 The Apache Geronimo PMC

 --kevan



Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer

2007-11-21 Thread Prasad Kashyap
Congrats Erik !

Cheers
Prasad

On Nov 20, 2007 11:45 AM, Matt Hogstrom [EMAIL PROTECTED] wrote:
 Please extend a welcome to Erik Craig who is the latest committer to
 be added to the Geronimo fold.  Erik has had a sustained and continued
 track record in working on the J2G conversion tool as well as his
 recent work on monitoring with Anita. and others.

 Give it up for Mr Craig !

 Matt



Re: [BUILD] 2.1: Failed for Revision: 592996

2007-11-08 Thread Prasad Kashyap
Hi Jacek,

The testsuite runs only after a successful build. So yes, the build
here too has had no failures.

To run the testsuite-
cd ${geronimo}/testsuite
mvn [-DassemblyId=tomcat] [-DinstallDirectory=c:\apache]

The -DinstallDirectory option is useful on a windows machine to
circumvent the long path problem. Without this, it will install the
server in testsuite/${foo}-testsuite/target dir.

Cheers
Prasad

On 11/8/07, Jacek Laskowski [EMAIL PROTECTED] wrote:
 On 8 Nov 2007 03:21:12 -,  [EMAIL PROTECTED] wrote:

  TESTSUITE RESULTS (Failures only)
  =
  See detailed results at 
  http://people.apache.org/~prasad/testsuite/ResultsSummary.html
  See the full test.log file at 
  http://people.apache.org/~prasad/binaries/trunk/20071107/logs-2100/test.log
 
  [INFO] Running console-testsuite.basic-console
  [INFO] Tests run: 110, Failures: 3, Errors: 0, Skipped: 107, Time elapsed: 
  0.872 sec  FAILURE!
  [INFO] Running console-testsuite.advance-test
  [INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 
  3.452 sec  FAILURE!
  --
  [INFO] Running enterprise-testsuite.ejbtests
  [INFO] Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 
  0.125 sec  FAILURE!

 How can I run the tests on my computer? I could build geronimo fine
 yesterday with no failures.

 Jacek

 --
 Jacek Laskowski
 http://www.JacekLaskowski.pl



Re: Should we move the framework assembly into framework?

2007-11-07 Thread Prasad Kashyap
Just FYI -,

The framework/modules/geronimo-j2ee is just one artifact that
does/should not be included in the framework-assembly.

This artifact is needed to build c-m-p. So it builds along with the
other modules in framework. It's need there is seen the greatest in a
bootstrap build.

Cheers
Prasad

On 11/6/07, David Jencks [EMAIL PROTECTED] wrote:

 On Nov 6, 2007, at 2:39 PM, Joe Bohn wrote:

 
 
  David Jencks wrote:
  Moving the boilerplate and framework assembly into framework might
  make it simpler to see how to construct custom servers and check
  that the framework assembly only has what it should inside.
  Thoughts?
 
  I'm ok with it in either location.
 
  If it is moved then it would be valuable if we could modify the
  build to automatically include everything under configs in the
  assembly.  That way there would be no doubt that it included
  exactly what should be in framework.

 That might not be appropriate.  In fact I think we should trim the
 framework assembly further by removing the geronimo-gbean-deployer
 config.  _Maybe_ we can assemble all the configs in framwork with the
 bootstrap gbean deployer. in which case maybe your idea would
 work.  I think the most important thing about the framework assembly
 is to keep it small :-)

 thanks
 david jencks

 
  Joe




Re: Should we move the framework assembly into framework?

2007-11-07 Thread Prasad Kashyap
My initial roadmap was to split the tree into smaller svn projects
post 2.2 release. So when we create projects for framework, apps,
plugins etc, we could also move the assemblies to the appropriate
tree. So assembling the framework will be done in the framework svn
project while the javaee5 assemblies will be assembled in the plugins
svn project. This will get rid of the current assemblies dir too.

Do ya'll want to do this now itself ? How much ? Just moves the
assemblies ? Or even split the tree into smaller projects ?

Cheers
Prasad

On 11/7/07, Joe Bohn [EMAIL PROTECTED] wrote:


 David Jencks wrote:
 
  On Nov 6, 2007, at 2:39 PM, Joe Bohn wrote:
 
 
 
  David Jencks wrote:
  Moving the boilerplate and framework assembly into framework might
  make it simpler to see how to construct custom servers and check that
  the framework assembly only has what it should inside.
  Thoughts?
 
  I'm ok with it in either location.
 
  If it is moved then it would be valuable if we could modify the build
  to automatically include everything under configs in the assembly.
  That way there would be no doubt that it included exactly what should
  be in framework.
 
  That might not be appropriate.  In fact I think we should trim the
  framework assembly further by removing the geronimo-gbean-deployer
  config.  _Maybe_ we can assemble all the configs in framwork with the
  bootstrap gbean deployer. in which case maybe your idea would work.
  I think the most important thing about the framework assembly is to keep
  it small :-)

 No doubt that we want to keep it small.  I just just trying to come up
 with a way to prevent errors when removing things from the /framework
 directory but leaving them in the assembly and vice-versa (to ensure the
 framework assembly only included what was necessary).

 IIUC, the purpose of the /framework directory is to contain only core
 items required for the framework assembly.  So if we could build the
 assembly based upon the plugins in /framework/configs we should have
 just what we need.  We can still trim the size by moving items from
 /framework/configs to /plugins which (if automated) would result in
 removing the plugin from the framework assembly.

 ... just an idea ...

 Joe



[jira] Commented: (GERONIMO-3586) monitoring plugin: collecting agent should have separate jetty and tomcat plugins

2007-11-07 Thread Prasad Kashyap (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540915
 ] 

Prasad Kashyap commented on GERONIMO-3586:
--

This is a delicate fine line.  I think I understand Anita's pov that monitoring 
and management does not pull down container-specific anything and hence the 
code can co-exist in a single plugin. However the fact remains that container 
specific code has to be executed at runtime to make this work.  Case in point, 
Jetty*Stats and Jetty*StatsImpl.

Now, we have sorta established an unwritten convention where we have (tried to) 
split the container-specific code into their own plugins for all scopes, 
compile and/or runtime. With other related work items we are very close to   
creating a flexible server with a very small footprint. A server can now be 
really tailor-made to every individual user/server instance. So in light of 
this, it makes sense to split the container specific code into their own 
plugins to avoid dead-weight. 

Or, maybe I'm still not getting what Anita is trying to convey .

 monitoring plugin: collecting agent should have separate jetty and tomcat 
 plugins
 -

 Key: GERONIMO-3586
 URL: https://issues.apache.org/jira/browse/GERONIMO-3586
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Jarek Gawor
 Attachments: geronimo-3586.patch


 The collecting agent plugin needs to have separate jetty and tomcat plugins 
 in order to accommodate for the differences in container specific 
 dependencies on stats implementation (.e.g JettyContainerStatsImpl and 
 JettyConnectorStatsImpl). When the collecting agent was an EAR, this was not 
 a problem; however, as a plugin, it is more tied down to having to specify 
 all dependencies in the plugin's classpath.

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



Re: [PLEASE read before you commit]: Restructuring trunk in SVN !!!

2007-11-03 Thread Prasad Kashyap
As per this thread,
http://www.nabble.com/forum/ViewPost.jtp?post=12460948framed=yskin=134
the strategy is to break the tree into smaller trees.

Quoting from that note -
So, based on that I think that:
 framework|core/trunk
 components/component/trunk
 plugins/plugin/trunk
 apps/app/trunk
 server/server/trunk (where server is javaee/minimal/crackpipe/
etc)
 uberserver/trunk (uses svn:externals to make a workspace with
all the bits to compile for those who like to watch paint dry as the
beast builds)

This is why I left the applications directory there. Maybe we'll merge
it with plugins, maybe we won't.

OK. I'll create a wiki page to refelect this work.

Cheers
Prasad




On 11/3/07, Donald Woods [EMAIL PROTECTED] wrote:
 Thanks for all the hard work.

 Is there still a need for a applications directory?  Shouldn't these all
 be moved into the plugins directory now?

 Also, shouldn't we include some notes in the BUILDING.txt and/or GMOxDEV
 about the new directory layout and where new code should be placed, like
 the difference between the framework, component and plugin directories...


 -Donald

 Prasad Kashyap wrote:
  server/trunk/modules deleted via Revision 591372
 
  server/trunk/configs deleted via Revision 591373.
 
  This completes Geronimo-3565.
 
  Cheers
  Prasad
 
  On 10/31/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
  The restructured trunk has built successfully 3 times now. It has
  passed our testsuite and TCK tests. At this point, I am not going to
  waste any time trying to fix -Dstage=former profile to build our old
  trunk.
 
  The unused pieces of old trunk will be deleted tomorrow.
 
  Cheers
  Prasad
 
  On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
  The -Dstage=former is not working as desired. I was unsuccessful in
  fixing it tonight. I'll try again tomorrow.
 
  However, the new restructuring is building fine. It has passed
  testsuite tests too.
 
  (If it passes TCK too, I may not waste any more time trying to fix old
  build, esp when I am deleting it the day after). Does anybody really
  really want it to work ?
 
  Cheers
  Prasad
 
  On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
  Sorry and thanx Jarek. I have fixed the security-deployer-config
  pom.xml and plan.xml. This will remove any extraneous dependencies it
  has on plugin artifacts.
 
  Cheers
  Prasad
 
  On 10/30/07, Jarek Gawor [EMAIL PROTECTED] wrote:
  I removed all org/apache/geronimo from my m2 repo and executed mvn
  install -Dstage=bootstrap. That failed with the error below in
  ./framework/configs/server-security-config. Looks like the
  dependencies are not setup right since it was also downloading
  j2ee-deployer/car and a bunch of other modules which have not been
  built yet.
 
  Jarek
 
  [INFO] 
  
  [ERROR] BUILD ERROR
  [INFO] 
  
  [INFO] start of
  org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed
 
  Could not find a valid constructor for GBean:
  org.apache.geronimo.j2ee.deployment.EARConfigBuilder
  ParameterTypes: [class
  org.apache.geronimo.kernel.repository.Environment, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  org.apache.geronimo.kernel.Kernel]
  constructor types: [class
  org.apache.geronimo.kernel.repository.Environment, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface org.apache.geronimo.kernel.Kernel]
  constructor types: [class
  org.apache.geronimo.kernel.repository.Environment, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class

[DISCUSS/FEEDBACK] Usability improvements to Geronimo

2007-11-02 Thread Prasad Kashyap
As we get close to releasing Geronimo 2.1 and look beyond, I'd like to
discuss a few usability improvements we can do to G. I am
cross-posting this to the user-list so that we can get a direct
feedback from our dear users.

1. Dynamic status messages. Some operations may take a certain amount
of time which could make the administrator uneasy as he waits. On a
local machine, he has the luxury of tailing the geronimo.log or seeing
the startup terminal. On a remote machine, he is almost flying blind
in the absence of any dynamically updating status messages. It would
be nice if we had another portlet at the bottom that showed status of
the operation being performed. This is really useful for long running
operations.

2. Geronimo Workbench. With the addition of features like Plan
Creator and Create Plugin, the Admin Console has slowly begun to
tread into the domain of tooling. Now we are introducing features for
monitoring the server. It's debatable whether such features should
even exist in the console. Purists might want the console to be solely
for configuration of the server. But given the fact, that they are
already there, we should consider creating tabs at the top or
sectional categories in the navigation menu. Since we have a
navigation tree which does not collapse, we have already crossed a
point where we have to scroll down to see all the links. This is a
usability no-no. It's time to transform the Console to a Workbench as
more Tooling and Monitoring features find their way in.

3. Plugin Creator Enhancements: Our current plugin create feature in
the console is limited to exporting an already deployed configuration.
It does not even include the geronimo-plugin.xml inside the exported
car. It would be nice to enhance this tool such that any plugin can be
created based on a set of already existing plugins as dependencies.
This should allow users to create simple plugins without having to
learn maven or the car-maven-plugin.

4. Enhanced logging framework which can specify logging filters at the
package level.

Please feel free to discuss the merits and demerits of these features
and/or add to the list.

Cheers
Prasad.


Re: [PLEASE read before you commit]: Restructuring trunk in SVN !!!

2007-11-02 Thread Prasad Kashyap
server/trunk/modules deleted via Revision 591372

server/trunk/configs deleted via Revision 591373.

This completes Geronimo-3565.

Cheers
Prasad

On 10/31/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
 The restructured trunk has built successfully 3 times now. It has
 passed our testsuite and TCK tests. At this point, I am not going to
 waste any time trying to fix -Dstage=former profile to build our old
 trunk.

 The unused pieces of old trunk will be deleted tomorrow.

 Cheers
 Prasad

 On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
  The -Dstage=former is not working as desired. I was unsuccessful in
  fixing it tonight. I'll try again tomorrow.
 
  However, the new restructuring is building fine. It has passed
  testsuite tests too.
 
  (If it passes TCK too, I may not waste any more time trying to fix old
  build, esp when I am deleting it the day after). Does anybody really
  really want it to work ?
 
  Cheers
  Prasad
 
  On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
   Sorry and thanx Jarek. I have fixed the security-deployer-config
   pom.xml and plan.xml. This will remove any extraneous dependencies it
   has on plugin artifacts.
  
   Cheers
   Prasad
  
   On 10/30/07, Jarek Gawor [EMAIL PROTECTED] wrote:
I removed all org/apache/geronimo from my m2 repo and executed mvn
install -Dstage=bootstrap. That failed with the error below in
./framework/configs/server-security-config. Looks like the
dependencies are not setup right since it was also downloading
j2ee-deployer/car and a bunch of other modules which have not been
built yet.
   
Jarek
   
[INFO] 

[ERROR] BUILD ERROR
[INFO] 

[INFO] start of
org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed
   
Could not find a valid constructor for GBean:
org.apache.geronimo.j2ee.deployment.EARConfigBuilder
ParameterTypes: [class
org.apache.geronimo.kernel.repository.Environment, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, interface
java.util.Collection, interface java.util.Collection, interface
java.util.Collection, interface java.util.Collection, interface
java.util.Collection, interface java.util.Collection, interface
java.util.Collection, interface java.util.Collection, interface
java.util.Collection, interface java.util.Collection, interface
org.apache.geronimo.kernel.Kernel]
constructor types: [class
org.apache.geronimo.kernel.repository.Environment, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, interface
java.util.Collection, interface java.util.Collection, interface
java.util.Collection, interface java.util.Collection, interface
java.util.Collection, interface java.util.Collection, interface
java.util.Collection, interface java.util.Collection, interface
java.util.Collection, interface org.apache.geronimo.kernel.Kernel]
constructor types: [class
org.apache.geronimo.kernel.repository.Environment, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, class
org.apache.geronimo.gbean.AbstractNameQuery, interface
java.util.Collection, interface
org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
org.apache.geronimo.j2ee.deployment.ActivationSpecInfoLocator,
interface org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface
org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface
org.apache.geronimo.j2ee.deployment.ModuleBuilderExtension, class
org.apache.geronimo.kernel.Naming]
   
   
On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
 GERONIMO-3565 has now checked in the new restructured trunk  into svn.

 The default profile will build the new trunk pieces.

 The -Dstage=former profile will build the old trunk pieces.

 Let's closely monitor the automated builds, testsuites and TCK

Re: [DISCUSS/FEEDBACK] Usability improvements to Geronimo

2007-11-02 Thread Prasad Kashyap
On 11/2/07, Joe Bohn [EMAIL PROTECTED] wrote:


 Prasad Kashyap wrote:
  As we get close to releasing Geronimo 2.1 and look beyond, I'd like to
  discuss a few usability improvements we can do to G. I am
  cross-posting this to the user-list so that we can get a direct
  feedback from our dear users.
 
  1. Dynamic status messages. Some operations may take a certain amount
  of time which could make the administrator uneasy as he waits. On a
  local machine, he has the luxury of tailing the geronimo.log or seeing
  the startup terminal. On a remote machine, he is almost flying blind
  in the absence of any dynamically updating status messages. It would
  be nice if we had another portlet at the bottom that showed status of
  the operation being performed. This is really useful for long running
  operations.

 Can you be more specific here?  What operations and how does a message
 make things any more dynamic?  Is this a web console only concern or is
 it also a command line concern?

Yes. Let me give you an example. Recently I was deploying a
configuration. For a while the wheels turned and then I received an
operation successful message. However, the deployment had spewn a
boatload of stack traces to the geronimo.log file.

In another example, the Websphere App Server shows informational
messages as an app is being deployed. That is quite reassuring to an
administrator.

For now, this is a console-only concern.


 If we really begin to include multiple portlets on pages then it might
 get difficult to associate responses with porlets/actions that initiated
 them.  It might be more beneficial to provide some interactive feedback
 (dojo?) within the portlet.

 
  2. Geronimo Workbench. With the addition of features like Plan
  Creator and Create Plugin, the Admin Console has slowly begun to
  tread into the domain of tooling. Now we are introducing features for
  monitoring the server. It's debatable whether such features should
  even exist in the console. Purists might want the console to be solely
  for configuration of the server. But given the fact, that they are
  already there, we should consider creating tabs at the top or
  sectional categories in the navigation menu. Since we have a
  navigation tree which does not collapse, we have already crossed a
  point where we have to scroll down to see all the links. This is a
  usability no-no. It's time to transform the Console to a Workbench as
  more Tooling and Monitoring features find their way in.

 I agree that the plan creators are more in the domain of tooling and
 perhaps should not be part of the console.  I think of the web console
 as an Administration Console rather than just a configuration console
 so I think monitoring makes perfect sense to be included. That aside, I
 think it makes sense to make the navigation tree collapse.  I'd add tabs
 as a last resort because this is not always intuitive to the user.
 Along with this I think it would be nice if we could enable the
 navigation and display area to scroll independently.

Sure. Collapsible navigation sections and/or scrollable navigation
frame are great improvements.

Also, I wonder if plugin creators also fall under the under the domain
of tooling along with plan creators.


 
  3. Plugin Creator Enhancements: Our current plugin create feature in
  the console is limited to exporting an already deployed configuration.
  It does not even include the geronimo-plugin.xml inside the exported
  car. It would be nice to enhance this tool such that any plugin can be
  created based on a set of already existing plugins as dependencies.
  This should allow users to create simple plugins without having to
  learn maven or the car-maven-plugin.
 Not sure if I follow this one.  You can export a deployed something as a
 plugin now without learning maven or the car-maven-plugin.

So today you can create a plugin only by exporting an already deployed
something.  It would be nice to assemble a simple plugin with other
available artifacts.  Again, a tooling feature.


 
  4. Enhanced logging framework which can specify logging filters at the
  package level.
 This has been proposed before and it is a good idea.  It would require a
 logging/trace strategy and architecture and a lot of leg work to
 implement it across the code ... but I think it would be worth the effort.

Yes. Worth the effort.


 
  Please feel free to discuss the merits and demerits of these features
  and/or add to the list.
 
  Cheers
  Prasad.
 



[jira] Closed: (GERONIMO-3565) Restructure build tree to reflect flexible server

2007-11-02 Thread Prasad Kashyap (JIRA)

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

Prasad Kashyap closed GERONIMO-3565.


Resolution: Fixed
  Assignee: Prasad Kashyap

http://www.nabble.com/forum/ViewPost.jtp?post=13495116framed=yskin=134

 Restructure build tree to reflect flexible server
 -

 Key: GERONIMO-3565
 URL: https://issues.apache.org/jira/browse/GERONIMO-3565
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: ActiveMQ, application client, buildsystem, 
 car-maven-plugin, Clustering, common, connector, console, CORBA, core, 
 crypto, databases, dependencies, deployment, documentation, gbuild, general, 
 geronimo-maven-plugin, Hot Deploy Dir, installer, J2G, Jetty, JIRA, 
 JVM-compatibility, kernel, legal, Logging, mail, management, Memory Leaks, 
 monitoring, naming, OpenEJB, persistence, Plugins, sample apps, security, 
 ServiceMix, specs, startup/shutdown, testsuite, Tomcat, transaction manager, 
 web, webservices
Affects Versions: 2.1
Reporter: Prasad Kashyap
Assignee: Prasad Kashyap
 Fix For: 2.1


 http://www.nabble.com/forum/ViewPost.jtp?post=13469170framed=yskin=134

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



Re: [DISCUSS] 2.1 Release

2007-11-01 Thread Prasad Kashyap
Yep. It's time !

I really want to see how flexibly the user community will actually
build their servers.

I also wish we'd all spend some extra time and effort to check for
security issues in the server in general and in our individual domain
of expertise, in particular.

Cheers
Prasad

On 11/1/07, Kevan Miller [EMAIL PROTECTED] wrote:
 I think it's time to start discussing the particulars of a 2.1 release.

 There's been a lot of advancements made in our plugin infrastructure.
 There's also been the pluggable console enhancements. It would be good
 to get a release out, with these capabilities. They provide a more
 solid platform for future enhancements, I think.

 There's also GShell and new monitoring capabilities. I'm probably
 missing a few other new functions.

 Finally, IIUC, 2.1 would be able to support a Terracotta plugin. I'd
 also be very interested to hear what WADI capabilities that could be
 exposed.

 I'm willing to bang the release manager drum. I see that Joe has
 already started tugging on the TCK chain

 What do others think? How close are we to a 2.1 release? What
 additional capabilities and bug fixes are needed? Can we wrap up
 development activities in the next week or two?

 --kevan



Re: svn commit: r588726 - in /geronimo/samples/trunk/samples: jsp-examples/jsp-examples-jetty/src/plan/ jsp-examples/jsp-examples-tomcat/src/plan/ jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF

2007-10-31 Thread Prasad Kashyap
I think it should.

Cheers
Prasad

On 10/27/07, Donald Woods [EMAIL PROTECTED] wrote:
 Shouldn't the groupId be org.apache.geronimo.samples instead of
 org.apache.geronimo.applications, to match the existing samples and
 directory name?

 -Donald

 [EMAIL PROTECTED] wrote:
  Author: gawor
  Date: Fri Oct 26 11:02:00 2007
  New Revision: 588726
 
  URL: http://svn.apache.org/viewvc?rev=588726view=rev
  Log:
  more cleanup (updated module ids, and removed old plans)
 
  Removed:
  geronimo/samples/trunk/samples/jsp-examples/jsp-examples-jetty/src/plan/
  
  geronimo/samples/trunk/samples/jsp-examples/jsp-examples-tomcat/src/plan/
  
  geronimo/samples/trunk/samples/servlet-examples/servlet-examples-jetty/src/plan/
  
  geronimo/samples/trunk/samples/servlet-examples/servlet-examples-tomcat/src/plan/
  Modified:
  
  geronimo/samples/trunk/samples/jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml
  
  geronimo/samples/trunk/samples/ldap-sample-app/ldap-sample-app-war/src/main/webapp/WEB-INF/geronimo-web.xml
  
  geronimo/samples/trunk/samples/servlet-examples/servlet-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml
 
  Modified: 
  geronimo/samples/trunk/samples/jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml
  URL: 
  http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml?rev=588726r1=588725r2=588726view=diff
  ==
  --- 
  geronimo/samples/trunk/samples/jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml
   (original)
  +++ 
  geronimo/samples/trunk/samples/jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml
   Fri Oct 26 11:02:00 2007
  @@ -23,8 +23,8 @@
 
 dep:environment
   dep:moduleId
  -  dep:groupIdorg.apache.geronimo.applications.examples/dep:groupId
  -  dep:artifactIdgeronimo-jsp-examples/dep:artifactId
  +  dep:groupIdorg.apache.geronimo.applications/dep:groupId
  +  dep:artifactIdjsp-examples-war/dep:artifactId
 dep:version2.1-SNAPSHOT/dep:version
   /dep:moduleId
   dep:dependencies/
 
  Modified: 
  geronimo/samples/trunk/samples/ldap-sample-app/ldap-sample-app-war/src/main/webapp/WEB-INF/geronimo-web.xml
  URL: 
  http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/ldap-sample-app/ldap-sample-app-war/src/main/webapp/WEB-INF/geronimo-web.xml?rev=588726r1=588725r2=588726view=diff
  ==
  --- 
  geronimo/samples/trunk/samples/ldap-sample-app/ldap-sample-app-war/src/main/webapp/WEB-INF/geronimo-web.xml
   (original)
  +++ 
  geronimo/samples/trunk/samples/ldap-sample-app/ldap-sample-app-war/src/main/webapp/WEB-INF/geronimo-web.xml
   Fri Oct 26 11:02:00 2007
  @@ -20,9 +20,9 @@
   web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.2;
environment
moduleId
  - groupIdsamples/groupId
  - artifactIdLDAP_Sample/artifactId
  - version1.2/version
  + groupIdorg.apache.geronimo.applications/groupId
  + artifactIdldap-sample-app-war/artifactId
  + version2.1-SNAPSHOT/version
/moduleId
/environment
   context-root/LDAP_Sample/context-root
 
  Modified: 
  geronimo/samples/trunk/samples/servlet-examples/servlet-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml
  URL: 
  http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/servlet-examples/servlet-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml?rev=588726r1=588725r2=588726view=diff
  ==
  --- 
  geronimo/samples/trunk/samples/servlet-examples/servlet-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml
   (original)
  +++ 
  geronimo/samples/trunk/samples/servlet-examples/servlet-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml
   Fri Oct 26 11:02:00 2007
  @@ -23,8 +23,8 @@
 
 dep:environment
   dep:moduleId
  -  dep:groupIdorg.apache.geronimo.applications.examples/dep:groupId
  -  dep:artifactIdgeronimo-servlet-examples/dep:artifactId
  +  dep:groupIdorg.apache.geronimo.applications/dep:groupId
  +  dep:artifactIdservlet-examples-war/dep:artifactId
 dep:version2.1-SNAPSHOT/dep:version
   /dep:moduleId
   dep:dependencies/
 
 
 




Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration

2007-10-31 Thread Prasad Kashyap
Whoa ! Somehow this thread never showed up on my radar screen.

Comments inline -

Cheers
Prasad.

On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote:
 On Oct 27, 2007, at 11:32 AM, David Jencks wrote:

  The admin console needs to be lightweight and portable so it is
  based on Pluto.  The Jetspeed MBE (as currently designed) would
  interfere with the deployment of admin console extensions.
  Adding something to the Geronimo plan to activate the Jetspeed
  MBE instead of just looking for a WEB-INF/portlet.xml sounds like
  a reasonable solution.   Let's pursue that approach.
 
  +1 as I see many situations where the Pluto Admin Console will
  still be used even when Jetspeed or Liferay are installed.
 
  I haven't looked into exactly how the admin console plugins get
  added to the admin console but if they are geronimo plugins they
  have already gone through the deployment process and there is no
  chance for the jetspeed MBE to see them as the deployment machinery
  is not activated at all when a plugin is installed.

 I see your point.   Limiting portal apps to installation via plugin
 would offer an advantage that developers can pick the appropriate
 MBEs at build time, giving them  us (the MBE provider) fine grained
 control over every step in the deployment process.

Isn't that a serious limitation ? We are forcing all portlet app
developers to use maven and c-m-p. Most 3rd party developers would
just want to build and deploy a portlet war and an associated geronimo
plan. If the geronimo plan conveyed which portal and MBE to use, we
don't have to have this limitation.



 While using MBEs has proven to be a very successful approach for
 deploying services and enterprise apps in Geronimo I am concerned
 that the lack of any standardization or a specification for deploying
 portal apps could make this difficult and fragile in the case of
 portlets.  My observation has been that deployment into most portals
 (Liferay, Pluto, uPortal, and even Jetspeed itself) is based on the
 concept that the developer creates a standard WAR and uses the
 Portal's runtime or build-time utility for preprocessing it.   Then
 the portal deploys the preprocessed WAR using the app server's
 standard deployment mechanism, or relies on the end user to do this.
 Can/should deployment of portlet into Geronimo be an extension of
 that process?  I have been inclined to follow that approach so far
 but there may be disadvantages I haven't thought of.

If the portal's runtime or built-time utility is preprocessing the WAR
and deploying it to an appserver, then isn't the onus on them to
deploy it accordingly for the appropriate appserver they support ? The
portal can continue to have their own deployment mechanism while we
can have ours, say in the form of plugins. This two-pronged approach
should fill all gaps and cover all types of users.


 BTW, I have started using the term console extension instead of
 console plugin because adding portlets to the admin console doesn't
 currently require them to be packaged as plugins.A console
 extension can be installed as a plugin or it could be deployed like
 any other ordinary WAR.   I hope most developers will offer their
 console extensions as plugins because they are easier for end users
 to browse and install.   But I think the latter option (deploying
 console extensions as a WAR) will be important to developers that
 don't want to create plugins for reasons such as the reliance on
 maven to build them, the sensitivity of plugins to Geronimo server
 versions, etc.


 Best wishes,
 Paul




Re: [PLEASE read before you commit]: Restructuring trunk in SVN !!!

2007-10-31 Thread Prasad Kashyap
The restructured trunk has built successfully 3 times now. It has
passed our testsuite and TCK tests. At this point, I am not going to
waste any time trying to fix -Dstage=former profile to build our old
trunk.

The unused pieces of old trunk will be deleted tomorrow.

Cheers
Prasad

On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
 The -Dstage=former is not working as desired. I was unsuccessful in
 fixing it tonight. I'll try again tomorrow.

 However, the new restructuring is building fine. It has passed
 testsuite tests too.

 (If it passes TCK too, I may not waste any more time trying to fix old
 build, esp when I am deleting it the day after). Does anybody really
 really want it to work ?

 Cheers
 Prasad

 On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
  Sorry and thanx Jarek. I have fixed the security-deployer-config
  pom.xml and plan.xml. This will remove any extraneous dependencies it
  has on plugin artifacts.
 
  Cheers
  Prasad
 
  On 10/30/07, Jarek Gawor [EMAIL PROTECTED] wrote:
   I removed all org/apache/geronimo from my m2 repo and executed mvn
   install -Dstage=bootstrap. That failed with the error below in
   ./framework/configs/server-security-config. Looks like the
   dependencies are not setup right since it was also downloading
   j2ee-deployer/car and a bunch of other modules which have not been
   built yet.
  
   Jarek
  
   [INFO] 
   
   [ERROR] BUILD ERROR
   [INFO] 
   
   [INFO] start of
   org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed
  
   Could not find a valid constructor for GBean:
   org.apache.geronimo.j2ee.deployment.EARConfigBuilder
   ParameterTypes: [class
   org.apache.geronimo.kernel.repository.Environment, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, interface
   java.util.Collection, interface java.util.Collection, interface
   java.util.Collection, interface java.util.Collection, interface
   java.util.Collection, interface java.util.Collection, interface
   java.util.Collection, interface java.util.Collection, interface
   java.util.Collection, interface java.util.Collection, interface
   org.apache.geronimo.kernel.Kernel]
   constructor types: [class
   org.apache.geronimo.kernel.repository.Environment, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, interface
   java.util.Collection, interface java.util.Collection, interface
   java.util.Collection, interface java.util.Collection, interface
   java.util.Collection, interface java.util.Collection, interface
   java.util.Collection, interface java.util.Collection, interface
   java.util.Collection, interface org.apache.geronimo.kernel.Kernel]
   constructor types: [class
   org.apache.geronimo.kernel.repository.Environment, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, class
   org.apache.geronimo.gbean.AbstractNameQuery, interface
   java.util.Collection, interface
   org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
   org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
   org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
   org.apache.geronimo.j2ee.deployment.ActivationSpecInfoLocator,
   interface org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
   org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface
   org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface
   org.apache.geronimo.j2ee.deployment.ModuleBuilderExtension, class
   org.apache.geronimo.kernel.Naming]
  
  
   On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
GERONIMO-3565 has now checked in the new restructured trunk  into svn.
   
The default profile will build the new trunk pieces.
   
The -Dstage=former profile will build the old trunk pieces.
   
Let's closely monitor the automated builds, testsuites and TCK results.
   
If everything is going smoothly, I shall remove the old trunk pieces
by eod, Thursday, Nov 1 2007.
   
Cheers
Prasad
   
On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
 I am restructuring the trunk in svn to reflect our flexible server.
 Instead of a move

Re: Inaccuracies on http://geronimo.apache.org webpage

2007-10-31 Thread Prasad Kashyap
Good catch. I have updated this. Let's wait for the wheels to turn and
the page to be federated.

Cheers
Prasad

On 10/31/07, Erik B. Craig [EMAIL PROTECTED] wrote:
 Hmmm,

 Right you are... Yeah... I agree with Jason, this should /probably/ get
 updated a bit =P.

 Jason Warner wrote:
  Hey all,
 
  I was poking around on the main page and stumble on this: Our most
  popular distribution is a fully certified J2EE 1.4 application server
  runtime. We are working on our next version of the server which is
  based on Java EE 5.  I'd hate for people to show up and say I was
  going to use geronimo but it's looks like they're not even certified
  on J2EE 5!
 
  ~Jason Warner



Re: Restructuring build for flexible server

2007-10-30 Thread Prasad Kashyap
Interesting points. However, I think we should tackle this and other
further restructuring in our next rev. For now, just baby steps.

To dos:
---
1. Consider breaking specs after a risk-benefit analysis.

2. Change groupIds and artifactIds. While most cars(plugins) are under
o.a.g.configs, there are some plugins (present plugins dir) under
o.a.g.plugins. But at the end of the day, they are all plugins now.

3. Break the tree into 4-5 smaller trees.

Cheers
Prasad

On 10/29/07, Joe Bohn [EMAIL PROTECTED] wrote:


 Donald Woods wrote:
  I think we really need to find some way to break the specs into smaller
  pieces.  Having to install all of the JEE specs just for the simple
  minimal web container assembly is ugly and wastes disk space.
 

 Well, we could have a config per spec ... but that might be a bit too
 much.  I'm not sure what smaller organizations would look like.

 We thought about breaking jee-specs up when we created the minimal
 assemblies but at the time it didn't seem worthy of the effort.  Now
 that we are getting closer to making the flexible server a reality
 perhaps it is time.  But I'm still not convinced that it would be worth
 the complexities it would bring and it doesn't consume a huge amount of
 space.

 Joe

 
  David Jencks wrote:
  Good work!!  A couple comments inline.
  On Oct 29, 2007, at 7:48 AM, Prasad Kashyap wrote:
 
  I spend most of the weekend trying to restructure trunk to reflect the
  new flexible server and I should tell you, it has been one shitty job
  much akin to untangling the knots of Medusa's hair.
 
  To begin with I wanted to build just the modules and configs (along
  with the necessary buildsupport and  maven-plugins artifacts) that go
  into a framework assembly.I believe that if we effectively want to
  restructure the build tree to reflect the flexible server, then we
  should be able to build just the framework artifacts ONLY. The
  framework artifacts should not have a dependency on plugins artifacts
  because they are optionally choosen to build an assembly of choice.
 
  Also, if our strategic vision is to break down the tree into smaller
  projects for framework, plugins etc, this we should break this
  cyclical dependency too. See Jason's response here -
  http://www.nabble.com/forum/ViewPost.jtp?post=12460948framed=yskin=134
 
  First hitch - Our framework assembly contains jee-specs car. This car
  has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is
  in a incorrect dependency which we don't need at this point or it
  might be truly needed here so that it gets in the classpath for later
  use. I commented this dependency out and proceeded to build jee-specs
  car. I strongly tend to believe that this myfaces dep is wrongly
  placed here. If it is really req'd then we have a bigger problem of
  fixing our classloader scheme.
 
  I don't understand the problem here and what you want to do.  We have
  several other specs (from axis and jstl) that we don't build that are
  included in jee-specs.  Is the jsf api different from these in some
  way?  Do you want to remove the jsf spec from jee-specs or the
  jee-specs from the framework assembly?  I remember having a lot of
  classloader problems trying to get stuff to run and pass the tck
  before we came up with the jee-specs module, but it might be possible
  to split it up and put the jars with the implementations that use
  them.  I think this will be difficult so I'd like to postpone that.
 
  Second hitch - Trying to build framework assembly's
  server-security-config car requires you to build j2ee-deployer. If you
  wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars
  which in turn has a dependency on webservices. Slowly we are building
  more and more plugins which are optional artifacts.
 
  This is definitely a problem.  I think we can solve it with a
  security-deployer config that has the security related gbeans from
  j2ee-deployer in it.  What do you think?
 
  If we really have to build a lot of plugins just to build the
  framework artifacts, then there is little point in restructuring the
  build tree now or breaking the tree later.
 
  I have checked in the restructured code under sandbox/restructure. I
  have been able to do a bootstrap build thus far.
 
  To build this on your machine, take the following steps
 
  1) begin with a good local repository for your trunk build
  2) delete applications, assemblies, modules, geronimo, configs,
  plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your
  local repo.
  3) svn co https://svn.apache.org/repos/asf/geronimo/sandbox/restructure
  4) mvn -o -Dstage=bootstrap
  5) mvn -o -Dstage=assembly   You should fail here
 
  Thanks!
  david jencks
 
 
  Cheers
  Prasad
 
 



Re: J2G future positioning

2007-10-30 Thread Prasad Kashyap
I'm with Paul on this. I envision a Migrate2Geronimo Toolkit that will
consist of a suite of  individual plugins (for Eclipse and G), each
handling the migration from a specific appserver to G. Of course, all
these may depend on a base or common plugin. But  the user will only
deal with the plugin relevant to him.  He will not have to install one
big huge uber migrator if he only has jboss apps.

Next week, we'll look forward to Jason adding a BEA2G plugin to this
M2G Toolkit ;-)

Cheers
Prasad.


On 10/30/07, Paul McMahan [EMAIL PROTECTED] wrote:
 I'm not in favor of generalizing the J2G Eclipse plugin into a super
 migrator that grows in complexity as we incorporate new types of
 source formats.   I think that instead we should look into factoring
 out the parts of J2G that could be used for other types migrators
 into a separate Eclipse plugin.   Then J2G could remain as J2G but
 could prereq this new Eclipse plugin, as would any other new
 migrators we create.

 Best wishes,
 Paul


 On Oct 29, 2007, at 11:32 AM, Tim McConnell wrote:

  Hi, Does anyone have any thoughts as to how we'll position the J2G
  plugin in the future ?? I understand now that in its initial
  iteration that it is narrowly scoped to work for JBoss specific
  migrations only (thus the JBoss in the name). However, it seems if
  we want to eventually enhance it as a more generic tool for
  migrating multiple applications to Geronimo (which I would hope we
  would), it might be a good time now to reconsider a more generic
  and/or appropriate name. Any thoughts ??
 
  --
  Thanks,
  Tim McConnell




Re: basic security review

2007-10-30 Thread Prasad Kashyap
I agree. Our strategy to make Geronimo secure should include an
elaborate set of unit testcases, a rich set of tests in the
security-testsuite in our testsuite framework,  along with  peer
review of code in components that are potential security risks.

We should aim to have imbricate or maybe even duplicate tests than have gaps.

Towards this end, I created a security-testsuite in our testsuite
framework. It contains one test now. I shall add some more soon.
Please contribute to this testsuite with more and more tests that you
can think of.

Thanx
Prasad

On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 A few security problems were discovered in Geronimo in the last few
 months and weeks. Most of them were Geronimo-specific except one.
 Therefore, I think we should spend a little bit of our time to review
 our code and check for potential security problems.
 As the first step, I think we should identify components that make
 security decisions (e.g. LoginModules) or enable access to server
 management and control (e.g. MEJB) or any other components that might
 be important for sever security.
 Once we have a few components identified we can start the review.
 Besides finding and fixing the potential security problems during the
 review we must also ensure that we have decent tests for these
 components that cover a range of inputs. For each problem that we do
 discover, we must write a test case to make sure it never happens
 again. Basically, a problem is not fully addressed until we have a
 test for it.

 For now, I created the following page where we can keep track of the
 components and the review:
 http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review
 Feel free to update it in any way.

 Opinions? Ideas? Thoughts?

 Jarek



Re: Restructuring build for flexible server

2007-10-30 Thread Prasad Kashyap
OK. This is how I restructured it.

But first, the aim was to keep the groupdId and artifactId of all
artifacts as is so that our assemblies and final server is not
affected. So the gIds and aIds of the modules and configs pieces were
left unchanged for now.

| geronimo
  |--- framework
  |--- modules
  |--- configs
  |--- components
  |--- plugins

The framework dir contains only those modules and deployers that are
needed by the framework assembly. Only geronimo-j2ee module in
included here because it is needed to build the car-maven-plugin.

The bootstrap profile now builds framework/modules and then builds
mavenplugins (including c-m-p).

All other modules, builders and their corresponding configs (cars) are
moved to their respective dirs under plugins. So plugins/myfaces
contain only myfaces modules and configs.

I put artifacts like spring, transformer-agent and upgrade under
components dir. Maybe they don't belong there. Maybe they can go
elsewhere.

The config pieces for the applications also moved to reside along with
the application wars in the application dirs.

Cheers
Prasad



On 10/30/07, Paul McMahan [EMAIL PROTECTED] wrote:
 On Oct 29, 2007, at 3:47 PM, Prasad Kashyap wrote:

  With the latest commit to sandbox, I have all the artifacts building
  successfully. We have good assemblies too. Tthe groupId and artifactId
  of all the artifacts have essentially remained the same.

 I noticed that the groupIds in the poms don't always match their
 placement in the svn directory structure.   Is the intention to keep
 things this way?  For example:
  https://svn.apache.org/repos/asf/geronimo/sandbox/restructure/
 plugins/cxf/cxf/pom.xml

 Also I'm curious what qualifies a subproject as belonging under
 plugins, applications, components, configs, or modules .   Currently
 it's arranged as:

 applications:
 # ca-helper/
 # geronimo-uddi-db/
 # mejb/
 # remote-deploy/
 # sharedlib/
 # uddi-server/
 # welcome/

 components:
 # spring/
 # transformer-agent/
 # upgrade/

 framework/configs:
 # client-system/
 # geronimo-gbean-deployer/
 # geronimo-gbean-deployer-bootstrap/
 # j2ee-security/
 # j2ee-system/
 # jee-specs/
 # jsr88-cli/
 # jsr88-deploymentfactory/
 # offline-deployer/
 # online-deployer/
 # rmi-naming/
 # server-security-config/
 # shutdown/
 # upgrade-cli/
 # xmlbeans/

 framework/modules:
 # geronimo-cli/
 # geronimo-commands/
 # geronimo-common/
 # geronimo-core/
 # geronimo-deploy-config/
 # geronimo-deploy-jsr88/
 # geronimo-deploy-jsr88-bootstrapper/
 # geronimo-deploy-tool/
 # geronimo-deployment/
 # geronimo-interceptor/
 # geronimo-j2ee/
 # geronimo-jdbc/
 # geronimo-jmx-remoting/
 # geronimo-kernel/
 # geronimo-management/
 # geronimo-naming/
 # geronimo-security/
 # geronimo-service-builder/
 # geronimo-system/
 # geronimo-transformer/
 # geronimo-upgrade/
 # geronimo-util/

 plugins:
 # activemq/
 # axis/
 # axis2/
 # client/
 # clustering/
 # connector/
 # console/
 # corba/
 # cxf/
 # debugviews/
 # dojo/
 # hotdeploy/
 # j2ee/
 # jasper/
 # javamail/
 # jaxws/
 # jetty/
 # myfaces/
 # openejb/
 # openjpa/
 # plancreator/
 # pluto/
 # system-database/
 # tomcat/
 # webservices/



 Best wishes,
 Paul



[PLEASE read before you commit]: Restructuring trunk in SVN !!!

2007-10-30 Thread Prasad Kashyap
I am restructuring the trunk in svn to reflect our flexible server.
Instead of a move, it will be a two-step copy/delete process. I shall
first begin by copying some directories to other directories. Server
binaries will be built from the newly created directories. After they
have gone thro' 2 days of automated builds, testsuites and TCK
smoketests, I shall remove the old directories.

So until further notice, please commit all your changes to both
directories, old and new.

Most modules and config directories have gone into their feature
specific directory under plugins. For eg, changes to
configs/myfaces-deployer should be made to that dir and also to
plugins/myfaces/myfaces-deployer.

A few modules and configs have been copied into framework directory
(to build framework assembly).

For a more detailed discussion about the restructuring, please see
this thread -
http://www.nabble.com/forum/ViewPost.jtp?post=13469170framed=yskin=134

Cheers
Prasad


[jira] Created: (GERONIMO-3565) Restructure build tree to reflect flexible server

2007-10-30 Thread Prasad Kashyap (JIRA)
Restructure build tree to reflect flexible server
-

 Key: GERONIMO-3565
 URL: https://issues.apache.org/jira/browse/GERONIMO-3565
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: ActiveMQ, application client, buildsystem, 
car-maven-plugin, Clustering, common, connector, console, CORBA, core, crypto, 
databases, dependencies, deployment, documentation, gbuild, general, 
geronimo-maven-plugin, Hot Deploy Dir, installer, J2G, Jetty, JIRA, 
JVM-compatibility, kernel, legal, Logging, mail, management, Memory Leaks, 
monitoring, naming, OpenEJB, persistence, Plugins, sample apps, security, 
ServiceMix, specs, startup/shutdown, testsuite, Tomcat, transaction manager, 
web, webservices
Affects Versions: 2.1
Reporter: Prasad Kashyap
 Fix For: 2.1


http://www.nabble.com/forum/ViewPost.jtp?post=13469170framed=yskin=134



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



Re: [PLEASE read before you commit]: Restructuring trunk in SVN !!!

2007-10-30 Thread Prasad Kashyap
GERONIMO-3565 has now checked in the new restructured trunk  into svn.

The default profile will build the new trunk pieces.

The -Dstage=former profile will build the old trunk pieces.

Let's closely monitor the automated builds, testsuites and TCK results.

If everything is going smoothly, I shall remove the old trunk pieces
by eod, Thursday, Nov 1 2007.

Cheers
Prasad

On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
 I am restructuring the trunk in svn to reflect our flexible server.
 Instead of a move, it will be a two-step copy/delete process. I shall
 first begin by copying some directories to other directories. Server
 binaries will be built from the newly created directories. After they
 have gone thro' 2 days of automated builds, testsuites and TCK
 smoketests, I shall remove the old directories.

 So until further notice, please commit all your changes to both
 directories, old and new.

 Most modules and config directories have gone into their feature
 specific directory under plugins. For eg, changes to
 configs/myfaces-deployer should be made to that dir and also to
 plugins/myfaces/myfaces-deployer.

 A few modules and configs have been copied into framework directory
 (to build framework assembly).

 For a more detailed discussion about the restructuring, please see
 this thread -
 http://www.nabble.com/forum/ViewPost.jtp?post=13469170framed=yskin=134

 Cheers
 Prasad



Re: [PLEASE read before you commit]: Restructuring trunk in SVN !!!

2007-10-30 Thread Prasad Kashyap
Sorry and thanx Jarek. I have fixed the security-deployer-config
pom.xml and plan.xml. This will remove any extraneous dependencies it
has on plugin artifacts.

Cheers
Prasad

On 10/30/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 I removed all org/apache/geronimo from my m2 repo and executed mvn
 install -Dstage=bootstrap. That failed with the error below in
 ./framework/configs/server-security-config. Looks like the
 dependencies are not setup right since it was also downloading
 j2ee-deployer/car and a bunch of other modules which have not been
 built yet.

 Jarek

 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] start of
 org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed

 Could not find a valid constructor for GBean:
 org.apache.geronimo.j2ee.deployment.EARConfigBuilder
 ParameterTypes: [class
 org.apache.geronimo.kernel.repository.Environment, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, interface
 java.util.Collection, interface java.util.Collection, interface
 java.util.Collection, interface java.util.Collection, interface
 java.util.Collection, interface java.util.Collection, interface
 java.util.Collection, interface java.util.Collection, interface
 java.util.Collection, interface java.util.Collection, interface
 org.apache.geronimo.kernel.Kernel]
 constructor types: [class
 org.apache.geronimo.kernel.repository.Environment, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, interface
 java.util.Collection, interface java.util.Collection, interface
 java.util.Collection, interface java.util.Collection, interface
 java.util.Collection, interface java.util.Collection, interface
 java.util.Collection, interface java.util.Collection, interface
 java.util.Collection, interface org.apache.geronimo.kernel.Kernel]
 constructor types: [class
 org.apache.geronimo.kernel.repository.Environment, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, class
 org.apache.geronimo.gbean.AbstractNameQuery, interface
 java.util.Collection, interface
 org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
 org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
 org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
 org.apache.geronimo.j2ee.deployment.ActivationSpecInfoLocator,
 interface org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
 org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface
 org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface
 org.apache.geronimo.j2ee.deployment.ModuleBuilderExtension, class
 org.apache.geronimo.kernel.Naming]


 On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
  GERONIMO-3565 has now checked in the new restructured trunk  into svn.
 
  The default profile will build the new trunk pieces.
 
  The -Dstage=former profile will build the old trunk pieces.
 
  Let's closely monitor the automated builds, testsuites and TCK results.
 
  If everything is going smoothly, I shall remove the old trunk pieces
  by eod, Thursday, Nov 1 2007.
 
  Cheers
  Prasad
 
  On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
   I am restructuring the trunk in svn to reflect our flexible server.
   Instead of a move, it will be a two-step copy/delete process. I shall
   first begin by copying some directories to other directories. Server
   binaries will be built from the newly created directories. After they
   have gone thro' 2 days of automated builds, testsuites and TCK
   smoketests, I shall remove the old directories.
  
   So until further notice, please commit all your changes to both
   directories, old and new.
  
   Most modules and config directories have gone into their feature
   specific directory under plugins. For eg, changes to
   configs/myfaces-deployer should be made to that dir and also to
   plugins/myfaces/myfaces-deployer.
  
   A few modules and configs have been copied into framework directory
   (to build framework assembly).
  
   For a more detailed discussion about the restructuring, please see
   this thread -
   http://www.nabble.com/forum/ViewPost.jtp?post=13469170framed=yskin=134
  
   Cheers
   Prasad
  
 



Re: [PLEASE read before you commit]: Restructuring trunk in SVN !!!

2007-10-30 Thread Prasad Kashyap
The -Dstage=former is not working as desired. I was unsuccessful in
fixing it tonight. I'll try again tomorrow.

However, the new restructuring is building fine. It has passed
testsuite tests too.

(If it passes TCK too, I may not waste any more time trying to fix old
build, esp when I am deleting it the day after). Does anybody really
really want it to work ?

Cheers
Prasad

On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
 Sorry and thanx Jarek. I have fixed the security-deployer-config
 pom.xml and plan.xml. This will remove any extraneous dependencies it
 has on plugin artifacts.

 Cheers
 Prasad

 On 10/30/07, Jarek Gawor [EMAIL PROTECTED] wrote:
  I removed all org/apache/geronimo from my m2 repo and executed mvn
  install -Dstage=bootstrap. That failed with the error below in
  ./framework/configs/server-security-config. Looks like the
  dependencies are not setup right since it was also downloading
  j2ee-deployer/car and a bunch of other modules which have not been
  built yet.
 
  Jarek
 
  [INFO] 
  
  [ERROR] BUILD ERROR
  [INFO] 
  
  [INFO] start of
  org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed
 
  Could not find a valid constructor for GBean:
  org.apache.geronimo.j2ee.deployment.EARConfigBuilder
  ParameterTypes: [class
  org.apache.geronimo.kernel.repository.Environment, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  org.apache.geronimo.kernel.Kernel]
  constructor types: [class
  org.apache.geronimo.kernel.repository.Environment, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface java.util.Collection, interface
  java.util.Collection, interface org.apache.geronimo.kernel.Kernel]
  constructor types: [class
  org.apache.geronimo.kernel.repository.Environment, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, class
  org.apache.geronimo.gbean.AbstractNameQuery, interface
  java.util.Collection, interface
  org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
  org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
  org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
  org.apache.geronimo.j2ee.deployment.ActivationSpecInfoLocator,
  interface org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface
  org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface
  org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface
  org.apache.geronimo.j2ee.deployment.ModuleBuilderExtension, class
  org.apache.geronimo.kernel.Naming]
 
 
  On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
   GERONIMO-3565 has now checked in the new restructured trunk  into svn.
  
   The default profile will build the new trunk pieces.
  
   The -Dstage=former profile will build the old trunk pieces.
  
   Let's closely monitor the automated builds, testsuites and TCK results.
  
   If everything is going smoothly, I shall remove the old trunk pieces
   by eod, Thursday, Nov 1 2007.
  
   Cheers
   Prasad
  
   On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
I am restructuring the trunk in svn to reflect our flexible server.
Instead of a move, it will be a two-step copy/delete process. I shall
first begin by copying some directories to other directories. Server
binaries will be built from the newly created directories. After they
have gone thro' 2 days of automated builds, testsuites and TCK
smoketests, I shall remove the old directories.
   
So until further notice, please commit all your changes to both
directories, old and new.
   
Most modules and config

Re: Promoting GShell to a real subproject

2007-10-29 Thread Prasad Kashyap
Thanx Kevan.

+1.

Cheers
Prasad

On 10/26/07, Kevan Miller [EMAIL PROTECTED] wrote:

 On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote:

  I don't see why we shouldn't. But can someone more informed please
  list the pros and cons.

 Here's my list:

 Pro's

   * Easier for other projects to reuse GShell
   * Release cycle not tied to Geronimo server release cycle

 Con's

   * Small overhead for being a separately released project --
 documentation, release voting, etc
   * Separate source tree can complicate debugging (can make the
 counterpoint that debugging GShell is easier...)

 The Geronimo tx-manager components (transaction and connector) is
 another example where we've done this. Note that prior to (or
 concurrent with) voting on our last two releases, we've been voting
 on a tx-manager release. Although it need not be that way, we're
 falling into a lock-step release cycle...

 I assume that Guillaume is interested in using GShell outside of
 Geronimo. I assume that there will be others...

 I'd support GShell as a subproject...

 --kevan




Restructuring build for flexible server

2007-10-29 Thread Prasad Kashyap
I spend most of the weekend trying to restructure trunk to reflect the
new flexible server and I should tell you, it has been one shitty job
much akin to untangling the knots of Medusa's hair.

To begin with I wanted to build just the modules and configs (along
with the necessary buildsupport and  maven-plugins artifacts) that go
into a framework assembly.I believe that if we effectively want to
restructure the build tree to reflect the flexible server, then we
should be able to build just the framework artifacts ONLY. The
framework artifacts should not have a dependency on plugins artifacts
because they are optionally choosen to build an assembly of choice.

Also, if our strategic vision is to break down the tree into smaller
projects for framework, plugins etc, this we should break this
cyclical dependency too. See Jason's response here -
http://www.nabble.com/forum/ViewPost.jtp?post=12460948framed=yskin=134

First hitch - Our framework assembly contains jee-specs car. This car
has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is
in a incorrect dependency which we don't need at this point or it
might be truly needed here so that it gets in the classpath for later
use. I commented this dependency out and proceeded to build jee-specs
car. I strongly tend to believe that this myfaces dep is wrongly
placed here. If it is really req'd then we have a bigger problem of
fixing our classloader scheme.

Second hitch - Trying to build framework assembly's
server-security-config car requires you to build j2ee-deployer. If you
wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars
which in turn has a dependency on webservices. Slowly we are building
more and more plugins which are optional artifacts.

If we really have to build a lot of plugins just to build the
framework artifacts, then there is little point in restructuring the
build tree now or breaking the tree later.

I have checked in the restructured code under sandbox/restructure. I
have been able to do a bootstrap build thus far.

To build this on your machine, take the following steps

1) begin with a good local repository for your trunk build
2) delete applications, assemblies, modules, geronimo, configs,
plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your
local repo.
3) svn co https://svn.apache.org/repos/asf/geronimo/sandbox/restructure
4) mvn -o -Dstage=bootstrap
5) mvn -o -Dstage=assembly   You should fail here

Cheers
Prasad


Re: deploying snapshots of the samples to a new location in m2-snapshot-repo

2007-10-29 Thread Prasad Kashyap
While a part of me seems to agree with you that we should remove the
zip file from the samples' wiki pages, a greater part of me feels that
we may be forcing some our users to now get SVN.

A user who just downloads and installs from a binary server will have
no need for svn. But just to get to the samples, he now has to get
SVN.

Then he has to get maven to play with the samples. So we are making
him jump thro' many hoops just to see our prized samples.

Hmm..

Cheers
Prasad

On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote:
 
  One other question -- should we try to have parity between what's in
  samples/trunk and what's in the samples section of the wiki?  Are
  there barriers, technical or otherwise, that make this difficult?
 
 http://cwiki.apache.org/GMOxSAMPLES/index.html
 http://svn.apache.org/repos/asf/geronimo/samples/trunk/

 Yes, definitely. That was the goal for 2.0 samples at least. The wiki
 documentation should be up to date (expect the artifact version) and
 all the code in wiki should be in the samples svn. If anything, I
 would like to remove the attached sample .zip files from the wiki and
 instead direct the users to checkout the sample code from svn.

 Also, I think we should release samples at the same time (or close to)
 when we release Geronimo.

 Jarek



Re: deploying snapshots of the samples to a new location in m2-snapshot-repo

2007-10-29 Thread Prasad Kashyap
Paul,

I can help you do this.

Cheers
Prasad

On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote:
 On Oct 28, 2007, at 3:22 PM, Donald Woods wrote:

  Any thoughts on setting up automated builds of Samples at least
  once a week?

 That would be helpful.  Now that we have catalog support in car-maven-
 plugin we could also automatically update the online plugins catalog
 as well.  This would require some coordination around building server/
 trunk and samples/trunk.Basically:
 1.)  build server/trunk
 2.)  build samples/trunk
 3.)  run a script on ~/.m2/repository/geronimo-plugins.xml to remove
 references to the local repo
 4.)  svn commit site/trunk/docs/plugins/geronimo-x.x/geronimo-
 plugins.xml

 I can help with a perl script for #3 if someone more savvy with build
 automation wants to look further into this.

 One other question -- should we try to have parity between what's in
 samples/trunk and what's in the samples section of the wiki?  Are
 there barriers, technical or otherwise, that make this difficult?

http://cwiki.apache.org/GMOxSAMPLES/index.html
http://svn.apache.org/repos/asf/geronimo/samples/trunk/


 Best wishes,
 Paul




Re: Restructuring build for flexible server

2007-10-29 Thread Prasad Kashyap
Thanx David.

With the latest commit to sandbox, I have all the artifacts building
successfully. We have good assemblies too. Tthe groupId and artifactId
of all the artifacts have essentially remained the same.

The final server should now pass TCK smoketests and our testsuite.

More comments inline -

On 10/29/07, David Jencks [EMAIL PROTECTED] wrote:
 Good work!!  A couple comments inline.
 On Oct 29, 2007, at 7:48 AM, Prasad Kashyap wrote:

  I spend most of the weekend trying to restructure trunk to reflect the
  new flexible server and I should tell you, it has been one shitty job
  much akin to untangling the knots of Medusa's hair.
 
  To begin with I wanted to build just the modules and configs (along
  with the necessary buildsupport and  maven-plugins artifacts) that go
  into a framework assembly.I believe that if we effectively want to
  restructure the build tree to reflect the flexible server, then we
  should be able to build just the framework artifacts ONLY. The
  framework artifacts should not have a dependency on plugins artifacts
  because they are optionally choosen to build an assembly of choice.
 
  Also, if our strategic vision is to break down the tree into smaller
  projects for framework, plugins etc, this we should break this
  cyclical dependency too. See Jason's response here -
  http://www.nabble.com/forum/ViewPost.jtp?
  post=12460948framed=yskin=134
 
  First hitch - Our framework assembly contains jee-specs car. This car
  has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is
  in a incorrect dependency which we don't need at this point or it
  might be truly needed here so that it gets in the classpath for later
  use. I commented this dependency out and proceeded to build jee-specs
  car. I strongly tend to believe that this myfaces dep is wrongly
  placed here. If it is really req'd then we have a bigger problem of
  fixing our classloader scheme.

 I don't understand the problem here and what you want to do.  We have
 several other specs (from axis and jstl) that we don't build that are
 included in jee-specs.  Is the jsf api different from these in some
 way?  Do you want to remove the jsf spec from jee-specs or the jee-
 specs from the framework assembly?  I remember having a lot of
 classloader problems trying to get stuff to run and pass the tck
 before we came up with the jee-specs module, but it might be possible
 to split it up and put the jars with the implementations that use
 them.  I think this will be difficult so I'd like to postpone that.

I'm sorry. I had misrepresented the problem. The j2ee-specs and it's
dependencies are fine. The problem is with myfaces artifacts showing
up as missing even though they are in very much present in the local
repo. I learnt that this is a problem even with the current build. It
seemed to be caused by an incorrect publish of the myfaces artifacts.
We are fine here as long as we do a online build.

 
  Second hitch - Trying to build framework assembly's
  server-security-config car requires you to build j2ee-deployer. If you
  wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars
  which in turn has a dependency on webservices. Slowly we are building
  more and more plugins which are optional artifacts.

 This is definitely a problem.  I think we can solve it with a
 security-deployer config that has the security related gbeans from
 j2ee-deployer in it.  What do you think?

The CredentialStore gbean in security-deployer config needed the
j2eeDeployer during c-m-p. The gbean was all but commented out as it
is. So I reduced it to a standard empty gbean and removed the
j2eeDeployer in the deploymentConfig of the c-m-p. This has solved the
problem.

 
  If we really have to build a lot of plugins just to build the
  framework artifacts, then there is little point in restructuring the
  build tree now or breaking the tree later.
 
  I have checked in the restructured code under sandbox/restructure. I
  have been able to do a bootstrap build thus far.
 
  To build this on your machine, take the following steps
 
  1) begin with a good local repository for your trunk build
  2) delete applications, assemblies, modules, geronimo, configs,
  plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your
  local repo.
  3) svn co https://svn.apache.org/repos/asf/geronimo/sandbox/
  restructure
  4) mvn -o -Dstage=bootstrap
  5) mvn -o -Dstage=assemble   You should fail here

I have had to add deps in the console-tomcat and console-jetty poms on
a few deployers to impose build order.  But for that, we now have a
restructured  tree.


 Thanks!
 david jencks

 
  Cheers
  Prasad




Re: deploying snapshots of the samples to a new location in m2-snapshot-repo

2007-10-29 Thread Prasad Kashyap
+1 to that.

If we released it, then we could point it to the published binaries.

Cheers
Prasad

On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote:
 When I mentioned parity between svn and the wiki I really meant to
 stress the same stuff showing both locations, which I think Jarek's
 suggestion would help achieve.Another idea would be to build and
 deploy the samples using maven.  Then we could point the wiki page at
 the maven repo for both the compiled binary and for the source.zip
 (which is automatically created by maven).

 Best wishes,
 Paul

 On Oct 29, 2007, at 2:12 PM, Jarek Gawor wrote:

  Binary files in wiki and source in svn? That works for me.
 
  Jarek
 
  On 10/29/07, Erik B. Craig [EMAIL PROTECTED] wrote:
  Prasad,
  I have put some thought into this myself and agree with you. It
  would be
  too much of a hassle for users, I think, if they have to download
  subversion and maven along with the sample app, and THEN compile it
  before attempting to deploy it. Probably the best thing would be
  to have
  'releases' or snapshots of the sample apps up on the wiki, along with
  the source being in the subversion repo.
 
 
  -Erik
 
  Prasad Kashyap wrote:
  While a part of me seems to agree with you that we should remove the
  zip file from the samples' wiki pages, a greater part of me feels
  that
  we may be forcing some our users to now get SVN.
 
  A user who just downloads and installs from a binary server will
  have
  no need for svn. But just to get to the samples, he now has to get
  SVN.
 
  Then he has to get maven to play with the samples. So we are making
  him jump thro' many hoops just to see our prized samples.
 
  Hmm..
 
  Cheers
  Prasad
 
  On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 
  On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote:
 
  One other question -- should we try to have parity between
  what's in
  samples/trunk and what's in the samples section of the wiki?  Are
  there barriers, technical or otherwise, that make this difficult?
 
 http://cwiki.apache.org/GMOxSAMPLES/index.html
 http://svn.apache.org/repos/asf/geronimo/samples/trunk/
 
  Yes, definitely. That was the goal for 2.0 samples at least. The
  wiki
  documentation should be up to date (expect the artifact version)
  and
  all the code in wiki should be in the samples svn. If anything, I
  would like to remove the attached sample .zip files from the
  wiki and
  instead direct the users to checkout the sample code from svn.
 
  Also, I think we should release samples at the same time (or
  close to)
  when we release Geronimo.
 
  Jarek
 
 
 
 
 




Re: svn commit: r589918 - in /geronimo/server/trunk/configs: activemq-broker/src/main/ activemq-ra/src/main/ axis-deployer/src/main/ axis/src/main/ axis2-deployer/src/main/ axis2-ejb-deployer/src/main

2007-10-29 Thread Prasad Kashyap
Vamsi, you have removed the wrong plan.

This is THE actual plan. The plan to be removed is the one under src/plan

http://www.nabble.com/forum/ViewPost.jtp?post=13435934framed=yskin=134

Cheers
Prasad

On 10/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Author: vamsic007
 Date: Mon Oct 29 17:36:56 2007
 New Revision: 589918

 URL: http://svn.apache.org/viewvc?rev=589918view=rev
 Log:
 GERONIMO-3563 Remove duplicate plan.xml files under configs
  o Removed the trivial ones where the plan.xml under src/plan is not 
 significantly different from the one under src/main/plan except for some 
 formatting etc.

 Removed:
 geronimo/server/trunk/configs/activemq-broker/src/main/
 geronimo/server/trunk/configs/activemq-ra/src/main/
 geronimo/server/trunk/configs/axis-deployer/src/main/
 geronimo/server/trunk/configs/axis/src/main/
 geronimo/server/trunk/configs/axis2-deployer/src/main/
 geronimo/server/trunk/configs/axis2-ejb-deployer/src/main/
 geronimo/server/trunk/configs/axis2-ejb/src/main/
 geronimo/server/trunk/configs/axis2/src/main/
 geronimo/server/trunk/configs/ca-helper-jetty/src/main/
 geronimo/server/trunk/configs/ca-helper-tomcat/src/main/
 geronimo/server/trunk/configs/client-corba-yoko/src/main/
 geronimo/server/trunk/configs/client-deployer/src/main/
 geronimo/server/trunk/configs/client-security/src/main/
 geronimo/server/trunk/configs/client-system/src/main/plan/
 geronimo/server/trunk/configs/client-transaction/src/main/
 geronimo/server/trunk/configs/client/src/main/
 geronimo/server/trunk/configs/clustering/src/main/
 geronimo/server/trunk/configs/connector-deployer/src/main/
 geronimo/server/trunk/configs/cxf-deployer/src/main/
 geronimo/server/trunk/configs/cxf-ejb-deployer/src/main/
 geronimo/server/trunk/configs/cxf-ejb/src/main/
 geronimo/server/trunk/configs/cxf/src/main/
 geronimo/server/trunk/configs/dojo-jetty6/src/main/
 geronimo/server/trunk/configs/dojo-tomcat/src/main/
 geronimo/server/trunk/configs/hot-deployer/src/main/
 geronimo/server/trunk/configs/j2ee-corba-yoko/src/main/
 geronimo/server/trunk/configs/j2ee-deployer/src/main/
 geronimo/server/trunk/configs/j2ee-security/src/main/
 geronimo/server/trunk/configs/j2ee-server/src/main/
 geronimo/server/trunk/configs/j2ee-system/src/main/plan/
 geronimo/server/trunk/configs/jasper-deployer/src/main/
 geronimo/server/trunk/configs/jasper/src/main/
 geronimo/server/trunk/configs/jaxws-deployer/src/main/plan/
 geronimo/server/trunk/configs/jaxws-ejb-deployer/src/main/
 geronimo/server/trunk/configs/jee-specs/src/main/
 geronimo/server/trunk/configs/jetty6-clustering-builder-wadi/src/main/
 geronimo/server/trunk/configs/jetty6-clustering-wadi/src/main/
 geronimo/server/trunk/configs/jetty6/src/main/
 geronimo/server/trunk/configs/jsr88-cli/src/main/
 geronimo/server/trunk/configs/jsr88-deploymentfactory/src/main/plan/
 geronimo/server/trunk/configs/mejb/src/main/
 geronimo/server/trunk/configs/myfaces-deployer/src/main/
 geronimo/server/trunk/configs/myfaces/src/main/
 geronimo/server/trunk/configs/online-deployer/src/main/plan/
 geronimo/server/trunk/configs/openejb-corba-deployer/src/main/
 geronimo/server/trunk/configs/openejb/src/main/
 geronimo/server/trunk/configs/persistence-jpa10-deployer/src/main/
 geronimo/server/trunk/configs/remote-deploy-jetty/src/main/
 geronimo/server/trunk/configs/remote-deploy-tomcat/src/main/
 geronimo/server/trunk/configs/rmi-naming/src/main/
 geronimo/server/trunk/configs/server-security-config/src/main/
 geronimo/server/trunk/configs/sharedlib/src/main/
 geronimo/server/trunk/configs/shutdown/src/main/plan/
 geronimo/server/trunk/configs/spring/src/main/
 geronimo/server/trunk/configs/tomcat6-deployer/src/main/
 geronimo/server/trunk/configs/tomcat6/src/main/
 geronimo/server/trunk/configs/transaction/src/main/
 geronimo/server/trunk/configs/transformer-agent/src/main/plan/
 geronimo/server/trunk/configs/wadi-clustering/src/main/
 geronimo/server/trunk/configs/webservices-common/src/main/
 geronimo/server/trunk/configs/welcome-jetty/src/main/
 geronimo/server/trunk/configs/welcome-tomcat/src/main/
 geronimo/server/trunk/configs/xmlbeans/src/main/




Re: Restructuring build for flexible server

2007-10-29 Thread Prasad Kashyap
I ran the tck smoketest (both Jetty  Tomcat) on the restructured
build and the results were consistent with the ones from the current
trunk build.

What are the next steps ?  If we plan to use this tree for 2.1 trunk,
then we should merge ASAP before the trees get too much out of synch.

I'd appreciate if folks checked out the restructure dir from sandbox
and built the new tree.

The steps are listed here again

1) begin with a good local repository for your trunk build.
2) delete applications, assemblies, modules, geronimo, configs,
plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your
local repo.
3) svn co https://svn.apache.org/repos/asf/geronimo/sandbox/restructure
4) mvn -o -Dstage=bootstrap
5) mvn -o -Dstage=assemble

P.S: If jee-specs and myfaces modules fail to build due to missing
o.a.myfaces.core/myfaces-* dependencies, just build those in the
online mode.

Cheers
Prasad

On 10/29/07, Joe Bohn [EMAIL PROTECTED] wrote:


 Donald Woods wrote:
  I think we really need to find some way to break the specs into smaller
  pieces.  Having to install all of the JEE specs just for the simple
  minimal web container assembly is ugly and wastes disk space.
 

 Well, we could have a config per spec ... but that might be a bit too
 much.  I'm not sure what smaller organizations would look like.

 We thought about breaking jee-specs up when we created the minimal
 assemblies but at the time it didn't seem worthy of the effort.  Now
 that we are getting closer to making the flexible server a reality
 perhaps it is time.  But I'm still not convinced that it would be worth
 the complexities it would bring and it doesn't consume a huge amount of
 space.

 Joe

 
  David Jencks wrote:
  Good work!!  A couple comments inline.
  On Oct 29, 2007, at 7:48 AM, Prasad Kashyap wrote:
 
  I spend most of the weekend trying to restructure trunk to reflect the
  new flexible server and I should tell you, it has been one shitty job
  much akin to untangling the knots of Medusa's hair.
 
  To begin with I wanted to build just the modules and configs (along
  with the necessary buildsupport and  maven-plugins artifacts) that go
  into a framework assembly.I believe that if we effectively want to
  restructure the build tree to reflect the flexible server, then we
  should be able to build just the framework artifacts ONLY. The
  framework artifacts should not have a dependency on plugins artifacts
  because they are optionally choosen to build an assembly of choice.
 
  Also, if our strategic vision is to break down the tree into smaller
  projects for framework, plugins etc, this we should break this
  cyclical dependency too. See Jason's response here -
  http://www.nabble.com/forum/ViewPost.jtp?post=12460948framed=yskin=134
 
  First hitch - Our framework assembly contains jee-specs car. This car
  has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is
  in a incorrect dependency which we don't need at this point or it
  might be truly needed here so that it gets in the classpath for later
  use. I commented this dependency out and proceeded to build jee-specs
  car. I strongly tend to believe that this myfaces dep is wrongly
  placed here. If it is really req'd then we have a bigger problem of
  fixing our classloader scheme.
 
  I don't understand the problem here and what you want to do.  We have
  several other specs (from axis and jstl) that we don't build that are
  included in jee-specs.  Is the jsf api different from these in some
  way?  Do you want to remove the jsf spec from jee-specs or the
  jee-specs from the framework assembly?  I remember having a lot of
  classloader problems trying to get stuff to run and pass the tck
  before we came up with the jee-specs module, but it might be possible
  to split it up and put the jars with the implementations that use
  them.  I think this will be difficult so I'd like to postpone that.
 
  Second hitch - Trying to build framework assembly's
  server-security-config car requires you to build j2ee-deployer. If you
  wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars
  which in turn has a dependency on webservices. Slowly we are building
  more and more plugins which are optional artifacts.
 
  This is definitely a problem.  I think we can solve it with a
  security-deployer config that has the security related gbeans from
  j2ee-deployer in it.  What do you think?
 
  If we really have to build a lot of plugins just to build the
  framework artifacts, then there is little point in restructuring the
  build tree now or breaking the tree later.
 
  I have checked in the restructured code under sandbox/restructure. I
  have been able to do a bootstrap build thus far.
 
  To build this on your machine, take the following steps
 
  1) begin with a good local repository for your trunk build
  2) delete applications, assemblies, modules, geronimo, configs,
  plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your

Re: Question about a sample Application

2007-10-29 Thread Prasad Kashyap
#1. The example asks you to create a DB named InventoryDB and then run
some sql commands to create tables.

#2. Your web.xml has a resource ref to jdbc/InventoryDS. This is a
part of the jndi name of the datasource (not database).

#3. The geronimo-web.xml links your jdbc/InventoryDS with the
datasource's name called InventoryPool.

#4. Then the InventoryPool.xml which is the alt-DD for the RA links
the InventoryPool datasource with the InventoryDB you created in #1.
http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/inventory/inventory-ear/src/main/resources/InventoryPool.xml?view=markup

For further reading, check out this link
http://localhost:8080/console/portal//Services/Database%20Pools/__pm0x3system-database0x2DBWizard!1134683811%7C0_view/__rp0x3system-database0x2DBWizard!1134683811%7C0_name/InventoryPool/__rp0x3system-database0x2DBWizard!1134683811%7C0_mode/usage/__rp0x3system-database0x2DBWizard!1134683811%7C0_abstractName/org0x2apache0x2geronimo0x2samples0x3inventory-ear0x320x20-SNAPSHOT0x3ear0xaJ2EEApplication=org0x2apache0x2geronimo0x2samples0x3inventory-ear0x320x20-SNAPSHOT0x3ear,JCAConnectionFactory=InventoryPool,JCAResource=tranql-connector-ra-10x230x2rar,ResourceAdapter=tranql-connector-ra-10x230x2rar,ResourceAdapterModule=tranql-connector-ra-10x230x2rar,j2eeType=JCAManagedConnectionFactory,name=InventoryPool

This is the usage link for the InventoryPool under Database Pools
navigational link. If you have deployed the Inventory app, you will
see this link too.

Hope this helps

Cheers
Prasad

On 10/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Hi , we are working on the geronimo one project. We were looking at a
 sample application that connects to the database in geronimo . Upone
 studying it we stumbled upon a syntax that has a little confused

 In your DBManager.java for the inventory application we found this line of
 code.

 DataSource ds =
  (DataSource)context.lookup(java:comp/env/jdbc/InventoryDS);

 We know what the function does . We just don't know what the parameter
 represents. Which part of the parameter represents the database we are
 connecting to? We need to know the nature of the parameter so that we can
 use it in our own application.





Re: Promoting GShell to a real subproject

2007-10-26 Thread Prasad Kashyap
I don't see why we shouldn't. But can someone more informed please
list the pros and cons.

Thanx
Prasad

On 10/26/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
 i think the subject is explicit.  What do people think about that ?

 --
 Cheers,
 Guillaume Nodet
 
 Blog: http://gnodet.blogspot.com/



Re: GShell as main starting component for 2.1

2007-10-25 Thread Prasad Kashyap
+1

I don't know if GShell already has this capability but I'd like it to
be useful for installing plugins too.

Cheers
Prasad

On 10/25/07, Jeff Genender [EMAIL PROTECTED] wrote:
 Title says it all...I'd really like to see gshell as the default
 execution for Geronimo 2.1.  Any objectsions?  Jason, is this something
 you can get going?

 Jeff



Re: [BUILD] 2.0: Failed for Revision: 587047

2007-10-23 Thread Prasad Kashyap
You may hitting the case of an unresponsive ibiblio.  Add the
following snippet to your ~/.m2/settings.xml

settings
   !-- central repo repo1 is mirrored to ibiblio. explictly
overriding that to be repo1 itself --
  mirrors
mirror
  idibiblio.org/id
  nameMirror of http://repo1.maven.org/maven2//name
  urlhttp://repo1.maven.org/maven2/url
  mirrorOfcentral/mirrorOf
/mirror
  /mirrors
/settings


Cheers
Prasad

On 10/23/07, Peter Petersson [EMAIL PROTECTED] wrote:
 I still have problem building G v2.0.2 from svn tag
 org.apache.xbean:xbean-naming:jar:3.2-r579367 is missing anyone else
 seeing this ?
 regards
Peter

 Prasad Kashyap wrote:
  The problem occurred b'coz one of the remote repos
  (ws.zones.apache.org) used by the axis2-kernel was down.
 
  This problem has now been fixed with help from Dims and ASF Infra.
 
  Cheers
  Prasad
 
  On 10/22/07, Peter Petersson [EMAIL PROTECTED] wrote:
 
  Thank you for the information!
 
  I am a bit surprised by this error as I would expect to be able to build
  a svn tagged version of Geronimo at any time with no changes what so
  ever compared to the original packaging as long as all maven repos is up
  and running even (especially) if I have a clean local geronimo/ maven
  repository.
 
  Changing  the version property
  woden.version1.0-incubating-M7b/woden.version
  to
  woden.version1.0-incubating--SNAPSHOT/woden.version
  in axis2-parent-1.3.pom in my local repo
  dose NOT fixed the problem, as I guess it would.
 
  I am obviously doing something wrong here. And btw should I really get a
  SNAPSHOT as I am trying to build from the v2.0.2 tag of the svn tree?
 
  Cheers
 Peter Petersson
 
 
 
  Prasad Kashyap wrote:
 
  The org.apache.axis2:axis2-kernel:jar:1.3 which depends on this
  artifact should have it's woden dependency set to
  1.0-incubating-SNAPSHOT. This can then be found at
 
  http://people.apache.org/repo/m2-snapshot-repository/org/apache/woden/woden/1.0-incubating-SNAPSHOT/
 
  Cheers
  Prasad
 
 
  On 10/22/07, Peter Petersson [EMAIL PROTECTED] wrote:
 
 
  Anybody else seeing this ?  I am trying to do a clean build of the 2.0.2
  tag but it seems that org.apache.woden:woden:jar:1.0-incubating-M7b has
  been revoked from the maven repos (Its now version M7). It seem to me
  that this artifact is implicitly pulled in by some web services artifact
  so I guess wait and see if it getting resolved by some 3rd party is what
  I can do at the moment.
 
  regards
 Peter Petersson
 
  [EMAIL PROTECTED] wrote:
 
 
  Geronimo Revision: 587047 built with tests included
 
  See the full build-0600.log file at 
  http://people.apache.org/~prasad/binaries/2.0/20071022/build-0600.log
 
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:compile]
  [INFO] Nothing to compile - all classes are up to date
  [INFO] [resources:testResources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:testCompile]
  [INFO] Nothing to compile - all classes are up to date
  [INFO] [surefire:test]
  [INFO] Surefire report directory: 
  /home/prasad/geronimo/2.0/modules/geronimo-activemq/target/surefire-reports
 
  ---
   T E S T S
  ---
  Running org.apache.geronimo.activemq.ConnectorTest
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.218 
  sec
 
  Results :
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
 
  [INFO] [jar:jar]
  [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
  [INFO] Checking legal files in: geronimo-activemq-2.0.3-SNAPSHOT.jar
  [INFO] [install:install]
  [INFO] Installing 
  /home/prasad/geronimo/2.0/modules/geronimo-activemq/target/geronimo-activemq-2.0.3-SNAPSHOT.jar
   to 
  /home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-activemq/2.0.3-SNAPSHOT/geronimo-activemq-2.0.3-SNAPSHOT.jar
  [INFO] 
  
  [INFO] Building Geronimo :: Web Services
  [INFO]task-segment: [install]
  [INFO] 
  
  [INFO] [enforcer:enforce {execution: default}]
  [INFO] [tools:copy-legal-files {execution: install-legal-files}]
  [INFO] [resources:resources]
  [INFO] Using default encoding to copy filtered resources.
  Downloading: 
  http://download.java.net/maven/1//axis/poms/axis-jaxrpc-1.4.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.pom
  Downloading: 
  http://repo1.maven.org/maven2/axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.pom
  Downloading: 
  http://download.java.net/maven/1//jaxen/poms/jaxen-1.1-beta-10.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom
  Downloading: 
  http://repo1.maven.org/maven2/jaxen/jaxen/1.1-beta-10/jaxen-1.1

Re: [Announcement] SOA Stack based on Apache Geronimo - GASwerk

2007-10-22 Thread Prasad Kashyap
Interesting ! Yet another SOA choice, along with Apache Tuscany.

Cheers
Prasad

On 10/22/07, Kristian Köhler [EMAIL PROTECTED] wrote:
 Hi

 we developed a OpenSource SOA Stack based on Apache Geronimo. The stack 
 includes an Enterprise Service Bus (Apache ServiceMix), a Business Process 
 Execution Engine (Apache ODE), Rule Based Routing (Apache Camel) and of 
 course JavaEE feature support (Apache Geronimo).

 The idea is to prevent companies to 'reinvent the OpenSource SOA wheel' when 
 building SOA solutions. ;-)

 The first release is avaliable from our Sourceforge Web Site:
 http://gaswerk.sourceforge.net

 The stack is called GASwerk SOA Stack. A simple sample is also available as 
 download to see GASwerk SOA Stack in action.

 Kristian

 ---
 http://gaswerk.sourceforge.net



Re: [BUILD] 2.1: Failed for Revision: 587014

2007-10-22 Thread Prasad Kashyap
The woden artifact is being pulled in as a transitive dependency of
axis-2. The fix should go there. A temporary fix would be to exclude
this from our geronimo-webservices module. But I am not sure how
important woden is for us and what else it will break.

Cheers
Prasad

On 10/22/07, Jacek Laskowski [EMAIL PROTECTED] wrote:
 Hi,

 Is anyone working on fixing the build/the build script or should we
 disregard it (and the whole point of sending failed builds
 announcements)? I could build Geronimo trunk 2-3 days ago fine.

 Jacek

 On 22 Oct 2007 08:14:15 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  OpenEJB trunk at 586981
  Geronimo Revision: 587014 built with tests included
 
  See the full build-0300.log file at 
  http://people.apache.org/~prasad/binaries/trunk/20071022/build-0300.log
 
  [INFO] [enforcer:enforce {execution: default}]
  [INFO] [tools:copy-legal-files {execution: install-legal-files}]
  [INFO] [resources:resources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:compile]
  [INFO] Nothing to compile - all classes are up to date
  [INFO] [resources:testResources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:testCompile]
  [INFO] Nothing to compile - all classes are up to date
  [INFO] [surefire:test]
  [INFO] Surefire report directory: 
  /home/prasad/geronimo/trunk/modules/geronimo-activemq/target/surefire-reports
 
  ---
   T E S T S
  ---
  Running org.apache.geronimo.activemq.ConnectorTest
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.168 sec
 
  Results :
 
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
 
  [INFO] [jar:jar]
  [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
  [INFO] Checking legal files in: geronimo-activemq-2.1-SNAPSHOT.jar
  [INFO] [install:install]
  [INFO] Installing 
  /home/prasad/geronimo/trunk/modules/geronimo-activemq/target/geronimo-activemq-2.1-SNAPSHOT.jar
   to 
  /home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-activemq/2.1-SNAPSHOT/geronimo-activemq-2.1-SNAPSHOT.jar
  [INFO] 
  
  [INFO] Building Geronimo :: Web Services
  [INFO]task-segment: [install]
  [INFO] 
  
  Downloading: http://download.java.net/maven/1//axis/poms/axis-jaxrpc-1.4.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.pom
  Downloading: 
  http://repo1.maven.org/maven2/axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.pom
  Downloading: 
  http://download.java.net/maven/1//jaxen/poms/jaxen-1.1-beta-10.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom
  Downloading: 
  http://repo1.maven.org/maven2/jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom
  Downloading: 
  http://download.java.net/maven/1//org.apache.woden/poms/woden-1.0-incubating-M7b.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.pom
  Downloading: 
  http://repo1.maven.org/maven2/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.pom
  Downloading: 
  http://download.java.net/maven/1//org.apache.neethi/poms/neethi-2.0.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//org/apache/neethi/neethi/2.0/neethi-2.0.pom
  Downloading: 
  http://repo1.maven.org/maven2/org/apache/neethi/neethi/2.0/neethi-2.0.pom
  Downloading: 
  http://download.java.net/maven/1//org.apache.woden/jars/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://ws.zones.apache.org/repository2/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://tomcat.apache.org/dev/dist/m2-repository/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://repo1.maven.org/eclipse/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://jibx.sourceforge.net/maven/org.apache.woden/jars/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://repo1.maven.org/maven2/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  [INFO] 
  
  [ERROR] BUILD ERROR
  [INFO] 
  
  [INFO] Failed to resolve artifact.
 
  Missing:
  --
  1) org.apache.woden:woden:jar:1.0-incubating-M7b

Re: [BUILD] 2.0: Failed for Revision: 587047

2007-10-22 Thread Prasad Kashyap
The org.apache.axis2:axis2-kernel:jar:1.3 which depends on this
artifact should have it's woden dependency set to
1.0-incubating-SNAPSHOT. This can then be found at

http://people.apache.org/repo/m2-snapshot-repository/org/apache/woden/woden/1.0-incubating-SNAPSHOT/

Cheers
Prasad


On 10/22/07, Peter Petersson [EMAIL PROTECTED] wrote:
 Anybody else seeing this ?  I am trying to do a clean build of the 2.0.2
 tag but it seems that org.apache.woden:woden:jar:1.0-incubating-M7b has
 been revoked from the maven repos (Its now version M7). It seem to me
 that this artifact is implicitly pulled in by some web services artifact
 so I guess wait and see if it getting resolved by some 3rd party is what
 I can do at the moment.

 regards
Peter Petersson

 [EMAIL PROTECTED] wrote:
  Geronimo Revision: 587047 built with tests included
 
  See the full build-0600.log file at 
  http://people.apache.org/~prasad/binaries/2.0/20071022/build-0600.log
 
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:compile]
  [INFO] Nothing to compile - all classes are up to date
  [INFO] [resources:testResources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:testCompile]
  [INFO] Nothing to compile - all classes are up to date
  [INFO] [surefire:test]
  [INFO] Surefire report directory: 
  /home/prasad/geronimo/2.0/modules/geronimo-activemq/target/surefire-reports
 
  ---
   T E S T S
  ---
  Running org.apache.geronimo.activemq.ConnectorTest
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.218 sec
 
  Results :
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
 
  [INFO] [jar:jar]
  [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
  [INFO] Checking legal files in: geronimo-activemq-2.0.3-SNAPSHOT.jar
  [INFO] [install:install]
  [INFO] Installing 
  /home/prasad/geronimo/2.0/modules/geronimo-activemq/target/geronimo-activemq-2.0.3-SNAPSHOT.jar
   to 
  /home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-activemq/2.0.3-SNAPSHOT/geronimo-activemq-2.0.3-SNAPSHOT.jar
  [INFO] 
  
  [INFO] Building Geronimo :: Web Services
  [INFO]task-segment: [install]
  [INFO] 
  
  [INFO] [enforcer:enforce {execution: default}]
  [INFO] [tools:copy-legal-files {execution: install-legal-files}]
  [INFO] [resources:resources]
  [INFO] Using default encoding to copy filtered resources.
  Downloading: http://download.java.net/maven/1//axis/poms/axis-jaxrpc-1.4.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.pom
  Downloading: 
  http://repo1.maven.org/maven2/axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.pom
  Downloading: 
  http://download.java.net/maven/1//jaxen/poms/jaxen-1.1-beta-10.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom
  Downloading: 
  http://repo1.maven.org/maven2/jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom
  Downloading: 
  http://download.java.net/maven/1//org.apache.woden/poms/woden-1.0-incubating-M7b.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.pom
  Downloading: 
  http://repo1.maven.org/maven2/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.pom
  Downloading: 
  http://download.java.net/maven/1//org.apache.neethi/poms/neethi-2.0.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//org/apache/neethi/neethi/2.0/neethi-2.0.pom
  Downloading: 
  http://repo1.maven.org/maven2/org/apache/neethi/neethi/2.0/neethi-2.0.pom
  Downloading: 
  http://download.java.net/maven/1//org.apache.woden/jars/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://ws.zones.apache.org/repository2/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://tomcat.apache.org/dev/dist/m2-repository/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://repo1.maven.org/eclipse/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://jibx.sourceforge.net/maven/org.apache.woden/jars/woden-1.0-incubating-M7b.jar
  Downloading: 
  http://repo1.maven.org/maven2/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.jar
  [INFO] 
  
  [ERROR] 

Re: [BUILD] 2.0: Failed for Revision: 587047

2007-10-22 Thread Prasad Kashyap
The problem occurred b'coz one of the remote repos
(ws.zones.apache.org) used by the axis2-kernel was down.

This problem has now been fixed with help from Dims and ASF Infra.

Cheers
Prasad

On 10/22/07, Peter Petersson [EMAIL PROTECTED] wrote:
 Thank you for the information!

 I am a bit surprised by this error as I would expect to be able to build
 a svn tagged version of Geronimo at any time with no changes what so
 ever compared to the original packaging as long as all maven repos is up
 and running even (especially) if I have a clean local geronimo/ maven
 repository.

 Changing  the version property
 woden.version1.0-incubating-M7b/woden.version
 to
 woden.version1.0-incubating--SNAPSHOT/woden.version
 in axis2-parent-1.3.pom in my local repo
 dose NOT fixed the problem, as I guess it would.

 I am obviously doing something wrong here. And btw should I really get a
 SNAPSHOT as I am trying to build from the v2.0.2 tag of the svn tree?

 Cheers
Peter Petersson



 Prasad Kashyap wrote:
  The org.apache.axis2:axis2-kernel:jar:1.3 which depends on this
  artifact should have it's woden dependency set to
  1.0-incubating-SNAPSHOT. This can then be found at
 
  http://people.apache.org/repo/m2-snapshot-repository/org/apache/woden/woden/1.0-incubating-SNAPSHOT/
 
  Cheers
  Prasad
 
 
  On 10/22/07, Peter Petersson [EMAIL PROTECTED] wrote:
 
  Anybody else seeing this ?  I am trying to do a clean build of the 2.0.2
  tag but it seems that org.apache.woden:woden:jar:1.0-incubating-M7b has
  been revoked from the maven repos (Its now version M7). It seem to me
  that this artifact is implicitly pulled in by some web services artifact
  so I guess wait and see if it getting resolved by some 3rd party is what
  I can do at the moment.
 
  regards
 Peter Petersson
 
  [EMAIL PROTECTED] wrote:
 
  Geronimo Revision: 587047 built with tests included
 
  See the full build-0600.log file at 
  http://people.apache.org/~prasad/binaries/2.0/20071022/build-0600.log
 
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:compile]
  [INFO] Nothing to compile - all classes are up to date
  [INFO] [resources:testResources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:testCompile]
  [INFO] Nothing to compile - all classes are up to date
  [INFO] [surefire:test]
  [INFO] Surefire report directory: 
  /home/prasad/geronimo/2.0/modules/geronimo-activemq/target/surefire-reports
 
  ---
   T E S T S
  ---
  Running org.apache.geronimo.activemq.ConnectorTest
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.218 sec
 
  Results :
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
 
  [INFO] [jar:jar]
  [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
  [INFO] Checking legal files in: geronimo-activemq-2.0.3-SNAPSHOT.jar
  [INFO] [install:install]
  [INFO] Installing 
  /home/prasad/geronimo/2.0/modules/geronimo-activemq/target/geronimo-activemq-2.0.3-SNAPSHOT.jar
   to 
  /home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-activemq/2.0.3-SNAPSHOT/geronimo-activemq-2.0.3-SNAPSHOT.jar
  [INFO] 
  
  [INFO] Building Geronimo :: Web Services
  [INFO]task-segment: [install]
  [INFO] 
  
  [INFO] [enforcer:enforce {execution: default}]
  [INFO] [tools:copy-legal-files {execution: install-legal-files}]
  [INFO] [resources:resources]
  [INFO] Using default encoding to copy filtered resources.
  Downloading: 
  http://download.java.net/maven/1//axis/poms/axis-jaxrpc-1.4.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.pom
  Downloading: 
  http://repo1.maven.org/maven2/axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.pom
  Downloading: 
  http://download.java.net/maven/1//jaxen/poms/jaxen-1.1-beta-10.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom
  Downloading: 
  http://repo1.maven.org/maven2/jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom
  Downloading: 
  http://download.java.net/maven/1//org.apache.woden/poms/woden-1.0-incubating-M7b.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.pom
  Downloading: 
  http://repo1.maven.org/maven2/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.pom
  Downloading: 
  http://download.java.net/maven/1//org.apache.neethi/poms/neethi-2.0.pom
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//org/apache/neethi/neethi/2.0/neethi-2.0.pom
  Downloading: 
  http://repo1.maven.org/maven2/org/apache/neethi/neethi/2.0/neethi-2.0.pom
  Downloading: 
  http://download.java.net/maven

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

2007-10-16 Thread Prasad Kashyap
+1.

Most popular downloads (Maven, SunJZDK etc) are like this.

Cheers
Prasad

On 10/16/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 Just a small thought, since I think we are trying to move G 1.2 and
 1.1 users onto G 2.0 maybe we should separate 2.0 downloads from the
 older downloads. Right now all the downloads are under the same
 Available releases tab. I would propose creating Current releases
 tab with the latest 2.0.x download and Previous releases tab with
 all the other older releases. Also increasing the font size of the
 2.0.x download would help to distinguish itself from other downloads.

 Jarek



Re: [VOTE] Geronimo 2.0.2 (rc1)

2007-10-15 Thread Prasad Kashyap
+1

Cheers
Prasad

On 10/12/07, Kevan Miller [EMAIL PROTECTED] wrote:
 All,
 I've prepared a 2.0.2 release candidate for review and vote.

 http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/
 contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty)
 binaries. Here are pointers to the zip files:

 http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/
 geronimo-jetty6-jee5-2.0.2-bin.zip
 http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/
 geronimo-tomcat6-jee5-2.0.2-bin.zip
 http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/
 geronimo-jetty6-minimal-2.0.2-bin.zip
 http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/
 geronimo-tomcat6-minimal-2.0.2-bin.zip

 Source for the release is packaged here: http://people.apache.org/
 ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip

 Note that this release is dependent upon the geronimo-txmanager
 release that is currently being voted on. To build Geronimo 2.0.2,
 you'll need to either build geronimo-txmanager from source or copy
 the geronimo-txmanager artifacts into your local maven repo.

 The maven artifacts for Geronimo 2.0.2 are here -- http://
 people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the
 following archive -- http://people.apache.org/~kevan/release-votes/
 geronimo-2.0.2.tar.gz.

 The rat report for the Geronimo 2.0.2 source is here -- http://
 people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt

 The source for the release currently resides here -- https://
 svn.apache.org/repos/asf/geronimo/server/branches/2.0.2

 Once the release is approved, I'll move this branch to https://
 svn.apache.org/repos/asf/geronimo/server/tags/2.0.2

 [ ] +1 Release Geronimo 2.0.2
 [ ] 0 No opinion
 [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale)

 I'll plan on calling this vote on Tuesday morning (EDT).

 --kevan








Re: geronimo-dependency.xml

2007-10-12 Thread Prasad Kashyap
A quick investigation into this gave rise to some insights and more questions -

Insights:
1) An explicit-versions.properties gets generated by the PackageMojo
while building every config.
2) I doubt if this is getting serialized into the car. So I am unsure
if this ever gets used.
3) An explicit-version.properties gets generated by the
InstallModulesMojo while building assembles in 2.0 but not in trunk.
4) And obviously, we are not using InstallModulesMojo for assembly in trunk.

Questions:
1) what is the explicit-version.properties used for (in configs and in
2.0 assembly) ?
2) what is the geronimo-dependency.xml used for ? (a handful of
modules contain it)

Thanx
Prasad






On 10/12/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 Folks,

 In trunk, I've noticed that dependencies specified in
 geronimo-dependency.xml without an explicit version get resolved to an
 incorrect version when installed. For example, the root pom defines
 geronimo-schema-j2ee_1.4 dependency with version 1.2. But in the final
 javaee assembly only the version 1.1-SNAPSHOT was installed. I see the
 same issue with other such dependencies.

 Is anyone else seeing that too? Looks like we will need to specify
 explicit versions in the geronimo-dependency.xml files. If so, how do
 we keep the versions in synch with the root pom?

 Jarek



Re: Build issue with trunk - build hangs

2007-10-11 Thread Prasad Kashyap
I had to use the MaxPermSize of 256m on RedHat for this to work.

On Windows, my mavenrc_pre.bat had some settings that I had to remove.
Now it works fine with just 128M

Cheers
Prasad

On 10/11/07, Shiva Kumar H R [EMAIL PROTECTED] wrote:
 I used a MaxPermSize of 256m and build worked fine for me on Windows.


 On 10/11/07, Joe Bohn [EMAIL PROTECTED]  wrote:
 
  I'm consistently hitting a build hang with trunk that I can't get past.
 Is anybody else hitting these problems or does anybody know what
  might be going wrong?  Perhaps I need to bump up the MaxPermSize?
 
  The build hangs when I get to building the car-maven-plugin.  This is on
OpenSUSE 10.2 with maven 2.0.7 (although I had the failures first with
  2.0.5 and moving to 2.0.7 didn't change the results) and Sun JDK 1.5.0_11.
 
  My MAVEN_OPTS are set to:
  -XX:MaxPermSize=128m -Xms512m -Xmx512m
 
  Here's the last thing I always see:
  ---
T E S T S
  ---
  Running
 org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest
  Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.6 sec
  Running
 org.apache.geronimo.mavenplugins.car.PluginMetadataTest
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.691 sec
 
  Results :
 
  Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
 
  [INFO] [jar:jar]
  [INFO] Building jar:
 
 /home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-maven-plugin-2.1-SNAPSHOT.jar
  [INFO] [plugin:addPluginArtifactMetadata]
  [INFO] [shitty:install {execution: default}]
  [INFO] Installing
 
 /home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-maven-plugin-2.1-SNAPSHOT.jar
  to
 
 /home/jbohn/.m2/repository/org/apache/geronimo/plugins/car-maven-plugin/2.1-SNAPSHOT/car-
 maven-plugin-2.1-SNAPSHOT.jar
 



 --
 Thanks,
 Shiva

 Come to ApacheCon US 2007 or OS Summit Asia 2007 and learn about
 Java EE 5 App Development on Geronimo 2.0 simplified using Eclipse
 http://us.apachecon.com/us2007/program/talk/2003
 http://www.ossummit.com/2007/program/talk/16


Re: Make useMavenDependencies default true ?

2007-10-11 Thread Prasad Kashyap
So in summary, do we keep the lists mutually exclusive ? Paul, do you
still see a need for a merge/override option ?

If so, I'll slowly deprecate the useMavenDependency option. Since
almost all configs have now been converted to plugins, I think it is
time we used the maven dependencies as default anyways. The presence
of any dependencies in the c-m-p configuration will make the c-m-p use
those deps only and exclude all maven deps.

Cheers
Prasad

On 10/10/07, Paul McMahan [EMAIL PROTECTED] wrote:
 On Oct 10, 2007, at 3:32 PM, David Jencks wrote:

  Indeed it might.  AFAIK no one has found an actual use for
  importservice/import dependencies before could I inquire
  what use you found for it and how you avoided class cast exceptions?

 I looked into to using it to enforce module startup order.The
 console should startup before any console extensions because the
 console listens for extensions being added to its navigator.  But
 those extensions should not (necessarily) inherit the console's
 classloader, especially since the console uses spring for configuring
 the pluto internals.  The services dependency type didn't work as I
 had expected while using the c-m-p so I never actually used it in a
 server to see any class cast exceptions.


 Best wishes,
 Paul



Re: Make useMavenDependencies default true ?

2007-10-11 Thread Prasad Kashyap
Ah..  #2 in your list above hadn't registered well. Sorry.

Anyways, I get it now. But I'll still answer your questions below.

Cheers
Prasad

On 10/11/07, David Jencks [EMAIL PROTECTED] wrote:

 On Oct 11, 2007, at 10:07 AM, Prasad Kashyap wrote:

  So in summary, do we keep the lists mutually exclusive ?

 You've said mutually exclusive a couple of times and I don't
 understand why.  The list of dependencies in the c-m-p configuration
 has to be a subset of the dependencies in the maven configuration.
 This is required by maven to get the build order right.  What do you
 mean by mutually exclusive?

Mutually exclusive is using either the maven dependencies or c-mp
configuration deps but not both. This is what we have at present. The
current useMavenDep option makes it mutually exclusive.


  Paul, do you
  still see a need for a merge/override option ?

 I do.

Now I see it. Based on #2 in your note, there is an override option.
So this means we will merge the list from maven deps and the c-m-p.
Some deps in the c-m-p may override the ones in the maven deps but the
other deps will be used as is.

 
  If so, I'll slowly deprecate the useMavenDependency option. Since
  almost all configs have now been converted to plugins, I think it is
  time we used the maven dependencies as default anyways. The presence
  of any dependencies in the c-m-p configuration will make the c-m-p use
  those deps only and exclude all maven deps.

 This is decidedly different from what I thought you proposed and what
 I thought was a good idea.  I thought you proposed always using all
 the qualifying maven dependencies (i.e. leave out provided and test,
 as at present) but modify the import type based on the c-m-p
 configuration.

This is still on the same veins, where the presence of deps in the
c-m-p will obviate the need for a separate useMavenDep option.



 However, I don't think we should proceed with this refinement until
 all the configs are checked to be generating reasonable geronimo-
 plugin.xml files

 thanks
 david jencks

 
  Cheers
  Prasad
 
  On 10/10/07, Paul McMahan [EMAIL PROTECTED] wrote:
  On Oct 10, 2007, at 3:32 PM, David Jencks wrote:
 
  Indeed it might.  AFAIK no one has found an actual use for
  importservice/import dependencies before could I inquire
  what use you found for it and how you avoided class cast exceptions?
 
  I looked into to using it to enforce module startup order.The
  console should startup before any console extensions because the
  console listens for extensions being added to its navigator.  But
  those extensions should not (necessarily) inherit the console's
  classloader, especially since the console uses spring for configuring
  the pluto internals.  The services dependency type didn't work as I
  had expected while using the c-m-p so I never actually used it in a
  server to see any class cast exceptions.
 
 
  Best wishes,
  Paul
 




Re: Make useMavenDependencies default true ?

2007-10-10 Thread Prasad Kashyap
On 10/10/07, David Jencks [EMAIL PROTECTED] wrote:

 On Oct 8, 2007, at 7:45 PM, Prasad Kashyap wrote:

  Comments inline -
 
  Thank you for your patience.
 
  On 10/8/07, David Jencks [EMAIL PROTECTED] wrote:
  2 replies in one go :-)
 
  On Oct 8, 2007, at 2:27 PM, Paul McMahan wrote:
 
  On Oct 8, 2007, at 4:49 PM, Prasad Kashyap wrote:
 
  Can we make the c-m-p use the maven dependencies by default ? 58 of
  the 95 configs already use the maven deps. There are approx 15-20
  configs that need to be converted to plugins. Odds are we'll end up
  with 75% of our configs using maven deps. Thus we should consider
  using the maven deps as default.
 
  +1, can this setting can be inherited from the parent project like
  the other settings such as source-repository currently are?  see
  configs/pom.xml and plugins/pom.xml
 
  we can do this as soon as all the existing configs have been
  converted to using really using the c-m-p to generate the geronimo-
  plugin.xml.  Before that I believe we will get into big problems,
  which is why I didn't do it in the first place.
 
  Right, right. We'll get to this after we convert all our configs to
  plugins.
 
 
  Also, by default, it should merge the maven deps with the explicit
  deps, IF ANY are specified in the c-m-p configuration. I don't
  see a
  use case for this now, but if there ever is a need to use both
  maven
  deps and an explicit list, this will let us achieve it.
 
  +1, one use case would be when you want to use the
  importservices/import environmental setting for a plugin
  dependency.  I was trying to do that earlier today but it didn't
  seem to work right.
 
  I don't really understand the behavior you are proposing here.
  Currently you have a choice between including all the maven
  dependencies with importall/import or explicitly specifying all
  the dependencies you want with the import you want.  If you
  explicitly specify the dependencies in the c-m-p config section each
  one has to be a maven dependency as well.
 
  What exactly are you proposing to be different here?
 
  You are right here. It seems like the inherited maven deps are
  included as well. In such a case, yes - the deps explicitly listed in
  the c-m-p are already have a maven dep somewhere (same pom or parent).
 
  However, the use case I was thinking was when you'd need to override
  the import of just one (of the many) maven dep in the c-m-p. In this
  case, you would include the maven deps by default, and then override
  the ones in c-m-p. But I reckon, we may be complicating things here.
 
  So should there never be a case when both the deps listings (maven
  deps and c-m-p deps) need to merge ? So the listings are always
  mutually exclusive ?
 
 
 
  Lastly, the exisiting useMavenDependencies parameter can be
  used to
  specifically exclude the maven deps. This will include only the
  explicit deps in the c-m-p configuration.
 
  would this match the current behavior when you explicitly
  configure c-
  m-p dependencies?
 
  settings inherited from the parent projects can be overridden.
 
  Is this relevant to the preceding?  I'm not seeing how yet.
 
  If we do use maven deps as default,  then this becomes relevant when
  we need to exclude the maven deps.
 
  However, this was very much relevant when I thought we could merge the
  two listings. But if the 2 listings cannot be merged, then it's
  relevancy gets lost. If c-m-p has a deps explicitly listed, then it
  should automatically exclude the maven deps. Why use this flag at all
  ?
 
 
  I'm a little leery of more configuration choices than are absolutely
  necessary.  I wonder if we could get by with one behavior, namely
  always using the maven dependencies with import type all unless the
  import type is overridden in the c-m-p config.  Are there any cases
  this wouldn't work for?
 
  Again, if deps cannot be merge, then even if one dep's import type is
  overridden, then all the remaining deps should be listed in the c-m-p,
  right ?
 
 
  I think we'd still want the include version flag.
 
  Yes. Me too.

 I'm not sure I understand all of what you are saying but I think you
 have pointed out a valuable possible simplification in the c-m-p
 configuration.  Let me try to restate it:

 0. As at present, any dependency in the c-m-p config must already be
 in the pom dependencies.

 1. All the (compile, runtime) scoped maven dependencies in the pom
 turn into plan dependencies and geronimo-plugin.xml dependencies

 2. Unless overridden the import type is all

 3. For other import types or other customization a dependency can be
 mentioned in the c-m-p config in the pom.

 At this point the useMavenDependencies is pointless

 The includeVersion flag is still useful: if it is false but a version
 is supplied in the c-m-p config for a particular dependency it should
 be included despite the flag.

 Does this make sense?  Is it what you were proposing?

Yes David. This is what I was proposing.

Cheers

Re: [BUILD] 2.1: Failed for Revision: 582825

2007-10-08 Thread Prasad Kashyap
I removed all version in the c-m-p configuration to let it get resolved.

Cheers
Prasad

On 8 Oct 2007 14:10:48 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 OpenEJB trunk at 582811
 Geronimo Revision: 582825 built with tests included

 See the full build-0935.log file at 
 http://people.apache.org/~prasad/binaries/trunk/20071008/build-0935.log

 [INFO] [enforcer:enforce {execution: default}]
 [INFO] [tools:copy-legal-files {execution: install-legal-files}]
 [INFO] Created dir: 
 /home/prasad/geronimo/trunk/configs/transaction/target/classes/META-INF
 [INFO] Copying 2 files to 
 /home/prasad/geronimo/trunk/configs/transaction/target/classes/META-INF
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [car:validate-configuration]
 [INFO] [car:prepare-plan]
 [INFO] Generated: 
 /home/prasad/geronimo/trunk/configs/transaction/target/resources/META-INF/plan.xml
 [INFO] [car:prepare-metadata]
 [INFO] [car:package]
 [INFO] Packaging module configuration: 
 /home/prasad/geronimo/trunk/configs/transaction/target/resources/META-INF/plan.xml
 [INFO] snapshot org.apache.geronimo.configs:j2ee-server:2.1-SNAPSHOT: 
 checking for updates from apache-snapshots
 [INFO] snapshot org.apache.geronimo.configs:j2ee-server:2.1-SNAPSHOT: 
 checking for updates from codehaus-snapshots
 [INFO] snapshot org.apache.geronimo.configs:j2ee-server:2.1-SNAPSHOT: 
 checking for updates from apache.snapshots
 [INFO] snapshot org.apache.geronimo.configs:j2ee-security:2.1-SNAPSHOT: 
 checking for updates from apache-snapshots
 [INFO] snapshot org.apache.geronimo.configs:j2ee-security:2.1-SNAPSHOT: 
 checking for updates from codehaus-snapshots
 [INFO] snapshot org.apache.geronimo.configs:j2ee-security:2.1-SNAPSHOT: 
 checking for updates from apache.snapshots
 [INFO] snapshot org.apache.geronimo.modules:geronimo-connector:2.1-SNAPSHOT: 
 checking for updates from apache-snapshots
 [INFO] snapshot org.apache.geronimo.modules:geronimo-connector:2.1-SNAPSHOT: 
 checking for updates from codehaus-snapshots
 [INFO] snapshot org.apache.geronimo.modules:geronimo-connector:2.1-SNAPSHOT: 
 checking for updates from apache.snapshots
 [INFO] snapshot 
 org.apache.geronimo.modules:geronimo-transaction:2.1-SNAPSHOT: checking for 
 updates from apache-snapshots
 [INFO] snapshot 
 org.apache.geronimo.modules:geronimo-transaction:2.1-SNAPSHOT: checking for 
 updates from codehaus-snapshots
 [INFO] snapshot 
 org.apache.geronimo.modules:geronimo-transaction:2.1-SNAPSHOT: checking for 
 updates from apache.snapshots
 [INFO] snapshot 
 org.apache.geronimo.modules:geronimo-persistence-jpa10:2.1-SNAPSHOT: checking 
 for updates from apache-snapshots
 [INFO] snapshot 
 org.apache.geronimo.modules:geronimo-persistence-jpa10:2.1-SNAPSHOT: checking 
 for updates from codehaus-snapshots
 [INFO] snapshot 
 org.apache.geronimo.modules:geronimo-persistence-jpa10:2.1-SNAPSHOT: checking 
 for updates from apache.snapshots
 [INFO] Building jar: 
 /home/prasad/geronimo/trunk/configs/transaction/target/transaction-2.1-SNAPSHOT.car
 [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
 [INFO] Checking legal files in: transaction-2.1-SNAPSHOT.car
 [INFO] [install:install]
 [INFO] Installing 
 /home/prasad/geronimo/trunk/configs/transaction/target/transaction-2.1-SNAPSHOT.car
  to 
 /home/prasad/.m2/repository/org/apache/geronimo/configs/transaction/2.1-SNAPSHOT/transaction-2.1-SNAPSHOT.car
 [INFO] [car:update-pluginlist]
 [INFO] 
 
 [INFO] Building Geronimo Configs :: XMLBeans
 [INFO]task-segment: [install]
 [INFO] 
 
 [INFO] [enforcer:enforce {execution: default}]
 [INFO] [tools:copy-legal-files {execution: install-legal-files}]
 [INFO] Created dir: 
 /home/prasad/geronimo/trunk/configs/xmlbeans/target/classes/META-INF
 [INFO] Copying 2 files to 
 /home/prasad/geronimo/trunk/configs/xmlbeans/target/classes/META-INF
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [car:validate-configuration]
 [INFO] [car:prepare-plan]
 [INFO] Generated: 
 /home/prasad/geronimo/trunk/configs/xmlbeans/target/resources/META-INF/plan.xml
 [INFO] [car:prepare-metadata]
 [INFO] [car:package]
 [INFO] Packaging module configuration: 
 /home/prasad/geronimo/trunk/configs/xmlbeans/target/resources/META-INF/plan.xml
 [INFO] Building jar: 
 /home/prasad/geronimo/trunk/configs/xmlbeans/target/xmlbeans-2.1-SNAPSHOT.car
 [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
 [INFO] Checking legal files in: xmlbeans-2.1-SNAPSHOT.car
 [INFO] [install:install]
 [INFO] Installing 
 /home/prasad/geronimo/trunk/configs/xmlbeans/target/xmlbeans-2.1-SNAPSHOT.car 
 to 
 /home/prasad/.m2/repository/org/apache/geronimo/configs/xmlbeans/2.1-SNAPSHOT/xmlbeans-2.1-SNAPSHOT.car
 [INFO] [car:update-pluginlist]
 [INFO] 
 

Re: [BUILD] 2.1: Failed for Revision: 582939

2007-10-08 Thread Prasad Kashyap
The script that runs the build has MAVEN_OPTS set thus
export MAVEN_OPTS=-XX:MaxPermSize=128m -Xms512m -Xmx1024m

I guess this is related to the same trunk build hanging while building configs
http://www.nabble.com/Trunk-build-hangs-on-windows-tf4571564s134.html

Cheers
Prasad

On 10/8/07, Paul McMahan [EMAIL PROTECTED] wrote:
 This looks like the OOM PermGen problem we were seeing a while ago:
 http://www.nabble.com/FATAL-ERROR-build-tf3227422s134.html#a8965424

 The solution in that case was to bump the memory args.

 Best wishes,
 Paul

 On Oct 8, 2007, at 3:41 PM, [EMAIL PROTECTED] wrote:

  [INFO] Packaging module configuration: /home/prasad/geronimo/trunk/
  plugins/console/console-jetty/target/resources/META-INF/plan.xml
  [INFO]
  --
  --
  [ERROR] FATAL ERROR
  [INFO]
  --
  --
  ---
  constituent[0]: file:/usr/local/maven/lib/maven-core-2.0.7-uber.jar
  constituent[1]: file:/home/prasad/.m2/repository/org/apache/
  geronimo/genesis/config/checkstyle-config/1.2/checkstyle-
  config-1.2.jar
  constituent[2]: file:/home/prasad/.m2/repository/org/apache/maven/
  wagon/wagon-ssh-common/1.0-beta-2/wagon-ssh-common-1.0-beta-2.jar




Make useMavenDependencies default true ?

2007-10-08 Thread Prasad Kashyap
Can we make the c-m-p use the maven dependencies by default ? 58 of
the 95 configs already use the maven deps. There are approx 15-20
configs that need to be converted to plugins. Odds are we'll end up
with 75% of our configs using maven deps. Thus we should consider
using the maven deps as default.

Also, by default, it should merge the maven deps with the explicit
deps, IF ANY are specified in the c-m-p configuration. I don't see a
use case for this now, but if there ever is a need to use both maven
deps and an explicit list, this will let us achieve it.

Lastly, the exisiting useMavenDependencies parameter can be used to
specifically exclude the maven deps. This will include only the
explicit deps in the c-m-p configuration.

Thoughts ?


Re: Make useMavenDependencies default true ?

2007-10-08 Thread Prasad Kashyap
Comments inline -

Thank you for your patience.

On 10/8/07, David Jencks [EMAIL PROTECTED] wrote:
 2 replies in one go :-)

 On Oct 8, 2007, at 2:27 PM, Paul McMahan wrote:

  On Oct 8, 2007, at 4:49 PM, Prasad Kashyap wrote:
 
  Can we make the c-m-p use the maven dependencies by default ? 58 of
  the 95 configs already use the maven deps. There are approx 15-20
  configs that need to be converted to plugins. Odds are we'll end up
  with 75% of our configs using maven deps. Thus we should consider
  using the maven deps as default.
 
  +1, can this setting can be inherited from the parent project like
  the other settings such as source-repository currently are?  see
  configs/pom.xml and plugins/pom.xml

 we can do this as soon as all the existing configs have been
 converted to using really using the c-m-p to generate the geronimo-
 plugin.xml.  Before that I believe we will get into big problems,
 which is why I didn't do it in the first place.

Right, right. We'll get to this after we convert all our configs to plugins.

 
  Also, by default, it should merge the maven deps with the explicit
  deps, IF ANY are specified in the c-m-p configuration. I don't see a
  use case for this now, but if there ever is a need to use both maven
  deps and an explicit list, this will let us achieve it.
 
  +1, one use case would be when you want to use the
  importservices/import environmental setting for a plugin
  dependency.  I was trying to do that earlier today but it didn't
  seem to work right.

 I don't really understand the behavior you are proposing here.
 Currently you have a choice between including all the maven
 dependencies with importall/import or explicitly specifying all
 the dependencies you want with the import you want.  If you
 explicitly specify the dependencies in the c-m-p config section each
 one has to be a maven dependency as well.

 What exactly are you proposing to be different here?

You are right here. It seems like the inherited maven deps are
included as well. In such a case, yes - the deps explicitly listed in
the c-m-p are already have a maven dep somewhere (same pom or parent).

However, the use case I was thinking was when you'd need to override
the import of just one (of the many) maven dep in the c-m-p. In this
case, you would include the maven deps by default, and then override
the ones in c-m-p. But I reckon, we may be complicating things here.

So should there never be a case when both the deps listings (maven
deps and c-m-p deps) need to merge ? So the listings are always
mutually exclusive ?


 
  Lastly, the exisiting useMavenDependencies parameter can be used to
  specifically exclude the maven deps. This will include only the
  explicit deps in the c-m-p configuration.

 would this match the current behavior when you explicitly configure c-
 m-p dependencies?
 
  settings inherited from the parent projects can be overridden.

 Is this relevant to the preceding?  I'm not seeing how yet.

If we do use maven deps as default,  then this becomes relevant when
we need to exclude the maven deps.

However, this was very much relevant when I thought we could merge the
two listings. But if the 2 listings cannot be merged, then it's
relevancy gets lost. If c-m-p has a deps explicitly listed, then it
should automatically exclude the maven deps. Why use this flag at all
?


 I'm a little leery of more configuration choices than are absolutely
 necessary.  I wonder if we could get by with one behavior, namely
 always using the maven dependencies with import type all unless the
 import type is overridden in the c-m-p config.  Are there any cases
 this wouldn't work for?

Again, if deps cannot be merge, then even if one dep's import type is
overridden, then all the remaining deps should be listed in the c-m-p,
right ?


 I think we'd still want the include version flag.

Yes. Me too.



 thanks
 david jencks

Cheers
Prasad

 
 
  Best wishes,
  Paul




Re: [BUILD] 2.0: Successful

2007-10-07 Thread Prasad Kashyap
These test results are not accurate. The tests were hanging and
stepping into the next scheduled builds. I killed it.

Cheers
Prasad

On 7 Oct 2007 14:33:10 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Geronimo Revision: 582613 built with tests included

 See the full build-0800.log file at 
 http://people.apache.org/~prasad/binaries/2.0/20071007/build-0800.log

 Download the binaries from 
 http://people.apache.org/~prasad/binaries/2.0/20071007
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 23 minutes 48 seconds
 [INFO] Finished at: Sun Oct 07 08:28:38 EDT 2007
 [INFO] Final Memory: 203M/1005M
 [INFO] 
 

 TESTSUITE RESULTS (Failures only)
 =
 See detailed results at 
 http://people.apache.org/~prasad/testsuite/ResultsSummary.html
 See the full test-0800.log file at 
 http://people.apache.org/~prasad/binaries/2.0/20071007/test-0800.log

 [INFO] Running console-testsuite.basic-console
 [INFO] Tests run: 38, Failures: 38, Errors: 0, Skipped: 0, Time elapsed: 
 1,142.247 sec  FAILURE!
 --
 [INFO] Running console-testsuite.advance-test
 [INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 
 361.532 sec  FAILURE!
 --
 [INFO] Running corba-testsuite.corba-mytime
 [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.132 
 sec  FAILURE!
 --
 [INFO] Running deployment-testsuite.deployment
 [INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.138 
 sec  FAILURE!
 --
 [INFO] Running deployment-testsuite.jca-cms
 [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 60.193 
 sec  FAILURE!
 --
 [INFO] Running enterprise-testsuite.jms
 [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.1 
 sec  FAILURE!
 --
 [INFO] Running jpa-testsuite.jpa
 [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.083 
 sec  FAILURE!
 --
 [INFO] Running sec-testsuite.security
 [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 60.213 
 sec  FAILURE!
 --
 [INFO] Running web-testsuite.jsps
 [INFO] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 
 120.233 sec  FAILURE!
 --
 [INFO] Running web-testsuite.myfaces
 [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.142 
 sec  FAILURE!
 --
 [INFO] Running web-testsuite.security
 [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.151 
 sec  FAILURE!
 --
 [INFO] Running web-testsuite.references
 [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.112 
 sec  FAILURE!
 --
 [INFO] Running web-testsuite.servlets
 [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 60.202 
 sec  FAILURE!
 --
 [INFO] Running web-testsuite.jetty
 [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 60.086 
 sec  FAILURE!
 --
 [INFO] Running org.apache.geronimo.testsuite.testset.JaxWSTest
 [INFO] Tests run: 5, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 
 2,000.201 sec  FAILURE!
 --
 [INFO]  ... 27 more
 [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.321 
 sec  FAILURE!
 --
 [INFO] Hello foo bar
 [INFO] Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 
 800.884 sec  FAILURE!
 --
 [INFO] Running org.apache.geronimo.testsuite.testset.WebJAXRTest
 [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 
 800.172 sec  FAILURE!
 --
 [INFO] Running org.apache.geronimo.testsuite.testset.WebStaxTest
 [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 
 800.181 sec  FAILURE!




Re: Trunk build hangs on windows

2007-10-05 Thread Prasad Kashyap
Yes. I noticed this once too. I rebuilt all the assemblies and kept going.

I thought it was an aberration then and forgot all about it

Cheers
Prasad

On 10/5/07, David Jencks [EMAIL PROTECTED] wrote:

 On Oct 5, 2007, at 6:33 AM, Anita Kulshreshtha wrote:

 Thanks to Jareck's URL fix I can build from c:\Documents and
  settings/../.m2 repo. I can start the framework and jetty minimal
  server. I am getting corrupt jar for both javaee5 servers.

 I should have mentioned this I guess, I thought it was something
 weird on my setup.  If I build a javaee server by itself the
 server.jar is corrupt -- one byte larger than it is supposed to be.
 If I build all the assemblies together all the assemblies work.  I
 have no idea where to start looking for a cause.

 thanks
 david jencks

 
  Thanks
  Anita
 
  --- Tim McConnell [EMAIL PROTECTED] wrote:
 
  Hi Prasad, I'm not -- I just successfully built trunk on
  Windows..
 
 
  Prasad Kashyap wrote:
  Since 10/03, I'm seeing the trunk build hang on windows while doing
  one of the configs. It was packaging the car while it froze.
 
  The memory usage was at 300+. The build was the only program
  running.
 
  The automated builds on Linux doesn't seem to have this problem.
 
  Any other windows user seeing this ?
 
  Cheers
  Prasad
 
 
  --
  Thanks,
  Tim McConnell
 
 
 
 
 
  __
  __
  Tonight's top picks. What will you watch tonight? Preview the
  hottest shows on Yahoo! TV.
  http://tv.yahoo.com/
 




Re: [BUILD] 2.0: Successful

2007-10-04 Thread Prasad Kashyap
OK. I cheated.. slightly.. just a li'l bit :-)

Yes. On the build machine, we do build with a clean repo every time.

Maven, I think, automatically mirrors it's central repo to ibiblio.
Ibiblio has now become slow and timesout frequently. Now I have
overridden the mirror settings for the central repo. After resisting
doing this for a while I finally let Jarek talk me into cheating the
build. It's all his fault :-)

!-- central repo repo1 is mirrored to ibiblio. explictly overriding
that to be repo1 itself --
  mirrors
mirror
  idibiblio.org/id
  nameMirror of http://repo1.maven.org/maven2//name
  urlhttp://repo1.maven.org/maven2/url
  mirrorOfcentral/mirrorOf
/mirror
  /mirrors

On 10/4/07, Lin Sun [EMAIL PROTECTED] wrote:
 On the build machine, do we always run the build after a clean .m2 repo?

 After seeing so many 2.0 good build notification, I still cannot build
 2.0 branch.  I kept getting failure here -

 Missing:
 --
 1) org.apache.xbean:xbean-naming:jar:3.2-r579367

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.xbean
 -DartifactId=xbean-nam
 ing \
-Dversion=3.2-r579367 -Dpackaging=jar -Dfile=/path/to/file
 Alternatively, if you host your own repository you can deploy the file
 there:
  mvn deploy:deploy-file -DgroupId=org.apache.xbean
 -DartifactId=xbean-naming
 \
-Dversion=3.2-r579367 -Dpackaging=jar -Dfile=/path/to/file \
 -Durl=[url] -DrepositoryId=[id]

Path to dependency:
  1) org.apache.geronimo.configs:client-corba-yoko:car:2.0.2-SNAPSHOT
  2)
 org.apache.geronimo.configs:openejb-corba-deployer:car:2.0.2-SNAPSHOT

  3) org.apache.geronimo.configs:j2ee-deployer:car:2.0.2-SNAPSHOT
  4) org.apache.geronimo.modules:geronimo-client:jar:2.0.2-SNAPSHOT
  5) org.apache.geronimo.modules:geronimo-naming:jar:2.0.2-SNAPSHOT
  6) org.apache.xbean:xbean-naming:jar:3.2-r579367

 --
 1 required artifact is missing.

 for artifact:
org.apache.geronimo.configs:client-corba-yoko:car:2.0.2-SNAPSHOT

 What am I missing?

 Lin


 [EMAIL PROTECTED] wrote:
  Geronimo Revision: 581864 built with tests included
 
  See the full build-0800.log file at 
  http://people.apache.org/~prasad/binaries/2.0/20071004/build-0800.log
 
  Download the binaries from 
  http://people.apache.org/~prasad/binaries/2.0/20071004
  [INFO] BUILD SUCCESSFUL
  [INFO] 
  
  [INFO] Total time: 24 minutes 25 seconds
  [INFO] Finished at: Thu Oct 04 08:31:38 EDT 2007
  [INFO] Final Memory: 202M/973M
  [INFO] 
  
 
  TESTSUITE RESULTS (Failures only)
  =
  See detailed results at 
  http://people.apache.org/~prasad/testsuite/ResultsSummary.html
  See the full test-0800.log file at 
  http://people.apache.org/~prasad/binaries/2.0/20071004/test-0800.log
 
  [INFO] locationURI=http://localhost:8080/JAXWSBeanService/JAXWSBean
  [INFO] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
  0.864 sec  FAILURE!
  --
  [INFO] Running org.apache.geronimo.testsuite.testset.EJBJAXRTest
  [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
  0.255 sec  FAILURE!
  --
  [INFO] Running org.apache.geronimo.testsuite.testset.EJBStaxTest
  [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.25 
  sec  FAILURE!
  --
  [INFO] Running org.apache.geronimo.testsuite.testset.EJBJAXBTest
  [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
  0.267 sec  FAILURE!
  --
  [INFO] ?xml version=1.0 encoding=UTF-8?soapenv:Envelope 
  xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; 
  xmlns:xsd=http://www.w3.org/2001/XMLSchema; 
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;soapenv:BodygreetMeResponse
   xmlns=http://org.apache.org/greeter;out xsi:type=xsd:string 
  xmlns=Hello foo 
  bar/out/greetMeResponse/soapenv:Body/soapenv:Envelope
  [INFO] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
  0.429 sec  FAILURE!
 
 




Trunk build hangs on windows

2007-10-04 Thread Prasad Kashyap
Since 10/03, I'm seeing the trunk build hang on windows while doing
one of the configs. It was packaging the car while it froze.

The memory usage was at 300+. The build was the only program running.

The automated builds on Linux doesn't seem to have this problem.

Any other windows user seeing this ?

Cheers
Prasad


Re: System Module descriptions

2007-10-03 Thread Prasad Kashyap
On 10/3/07, Ted Kirby [EMAIL PROTECTED] wrote:
 Cool!  I wrote a (cough, cough) perl script to generate wiki markup
 for a table from the data in the configs/*/pom.xml files, and updated
 the wiki page with it.  I then produced a merged table to compare
 existing pom descriptions to the ones I had entered.  I'd like to get
 further input, store updated descriptions in the pom.xml description
 element, and then I think it makes sense to generate a page from the
 pom.xml data.  There appear to be two attributes for each that would
 be nice to capture in doc:  whether the module is initially started,
 and whether it should *never* be started.  I wonder if any sort of
 attribute could be added for capturing this in pom.xml?

IIUC,  are you wondering if we should add attributes in the pom.xml
that will say whether this configuration is initially started or
should never be started ?

Other than for updating the wiki, will this attribute be useful for
anything else ?

Cheers
Prasad

 Ted Kirby

 On 10/2/07, David Jencks [EMAIL PROTECTED] wrote:
  Nice!
 
  In trunk, the description element in the config's pom gets put into
  the geronimo-plugin.xml description so it really needs to be
  accurate.  It would be great if we could generate future versions of
  this page from the plugin catalog.  Meanwhile it might be worthwhile
  comparing the descriptions here with the descriptions in the trunk
  configs' poms to make sure they are consistent and the most
  informative wins :-)
 
  thanks!
  david jencks
 
  On Oct 2, 2007, at 3:05 PM, Ted Kirby wrote:
 
   I have added this wiki page
   http://cwiki.apache.org/GMOxDOC20/system-modules.html to list the
   modules that come with the (2.0.1) server, along with:
  
   1. A brief description of what the module does
   2. Is it started by default, or
   3. Should it never be started?
  
   This is a first draft.  I solicit feedback and encourage folks to
   update the page as appropriate.  There are some modules with which I
   am not familiar.
  
   Ted Kirby
 
 



Re: Trunk fails

2007-10-03 Thread Prasad Kashyap
I'm seeing a different trunk failure on Windows. I'm at Rev: 581764.

Fresh checkout and a clean repo.

http://rifers.org/paste/show/5677

The automated builds on linux does not seem to have this problem. I'm
going to verify this on another windows machine tomorrow.

Cheers
Prasad

On 10/3/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 Please see 
 http://people.apache.org/~prasad/binaries/trunk/20071003/test-1800.log
 for test failure. I'm seeing the same on Windows.

 Jarek

 On 3 Oct 2007 22:53:56 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  OpenEJB trunk at 581589
  Geronimo Revision: 581737 built with tests included
 
  See the full build-1800.log file at 
  http://people.apache.org/~prasad/binaries/trunk/20071003/build-1800.log
 
  Download the binaries from 
  http://people.apache.org/~prasad/binaries/trunk/20071003
  [INFO] BUILD SUCCESSFUL
  [INFO] 
  
  [INFO] Total time: 31 minutes 30 seconds
  [INFO] Finished at: Wed Oct 03 18:36:12 EDT 2007
  [INFO] Final Memory: 212M/1010M
  [INFO] 
  
 
  TESTSUITE RESULTS (Failures only)
  =
  See detailed results at 
  http://people.apache.org/~prasad/testsuite/ResultsSummary.html
  See the full test-1800.log file at 
  http://people.apache.org/~prasad/binaries/trunk/20071003/test-1800.log
 
 
 



Frequent build breaks due to missing dependencies

2007-10-02 Thread Prasad Kashyap
Following my earlier mail on these now frequently occurring build
breaks due to missing dependencies, I tried to stagger the builds of
the 2 trees and also upgraded to maven 2.0.7.

Yesterday was a successful day. We had very good builds on both trees
and ran tck tests successfully too.

Today, it has fallen back to it's old ways of reporting missing
dependencies of geronimo-axis - openjpa artifacts.

My next attempt would be to move the builds from behind the firewall
to out into the zones machines.

Any other ideas ? Any other machines ?

Cheers
Prasad

On 10/1/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
 These build problems have consistently occurred while downloading the
 transitive dependencies of geronimo-axis, particularly, transitive
 dependencies of openjpa.

 I am going to try the following two things to fix this problem -
 1) stagger the 2.0 and 2.1 builds
 2) upgrade to maven 2.0.7.

 If this fails, we should consider moving the builds out of the
 firewall to zones. I did this with OpenEJB builds and that has been
 successful so far.

 If we do end up having to move the builds to zones, it would be
 preferable to build 2.0 and 2.1 on separate machines. Along with the
 existing OpenEJB, I can run one other build (say 2.1) on my zones
 site.

 We'd now need to find a place to build the other version. Ideas ?

 Cheers
 Prasad


 On 1 Oct 2007 14:49:49 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  OpenEJB trunk at 580938
  Geronimo Revision: 580962 built with tests included
 
  See the full build-1000.log file at
 http://people.apache.org/~prasad/binaries/trunk/20071001/build-1000.log
 
  Downloading:
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-kernel-5/1.0.0/openjpa-kernel-5-1.0.0.jar
  Downloading:
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-kernel-5/1.0.0/openjpa-kernel-5-1.0.0.jar
  28K downloaded
  Downloading:
 http://download.java.net/maven/1//net.sourceforge.serp/jars/serp-1.11.0.jar
  Downloading:
 http://people.apache.org/repo/m2-incubating-repository//net/sourceforge/serp/serp/1.11.0/serp-1.11.0.jar
  Downloading:
 http://www.ibiblio.org/maven2/net/sourceforge/serp/serp/1.11.0/serp-1.11.0.jar
  185K downloaded
  Downloading:
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-persistence-1.0.0.jar
  Downloading:
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-persistence/1.0.0/openjpa-persistence-1.0.0.jar
  Downloading:
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-persistence/1.0.0/openjpa-persistence-1.0.0.jar
  Downloading:
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-jdbc-1.0.0.jar
  Downloading:
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-jdbc/1.0.0/openjpa-jdbc-1.0.0.jar
  Downloading:
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-jdbc/1.0.0/openjpa-jdbc-1.0.0.jar
  1006K downloaded
  Downloading:
 http://download.java.net/maven/1//commons-pool/jars/commons-pool-1.3.jar
  Downloading:
 http://people.apache.org/repo/m2-incubating-repository//commons-pool/commons-pool/1.3/commons-pool-1.3.jar
  Downloading:
 http://www.ibiblio.org/maven2/commons-pool/commons-pool/1.3/commons-pool-1.3.jar
  60K downloaded
  Downloading:
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-persistence-jdbc-1.0.0.jar
  Downloading:
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
  Downloading:
 http://people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
  Downloading:
 http://tomcat.apache.org/dev/dist/m2-repository/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
  Downloading:
 http://svn.apache.org/repos/asf/openejb/repo//org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
  Downloading:
 http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
  108K downloaded
  Downloading:
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-kernel-1.0.0.jar
  Downloading:
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-kernel/1.0.0/openjpa-kernel-1.0.0.jar
  Downloading:
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-kernel/1.0.0/openjpa-kernel-1.0.0.jar
  1098K downloaded
  Downloading:
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-lib-1.0.0.jar
  Downloading:
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-lib/1.0.0/openjpa-lib-1.0.0.jar
  Downloading:
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-lib/1.0.0/openjpa-lib-1.0.0.jar
  424K downloaded
  Downloading:
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-jdbc-5-1.0.0.jar
  Downloading:
 http

Re: Frequent build breaks due to missing dependencies

2007-10-02 Thread Prasad Kashyap
They say, misery loves company.  Pardon my schadenfreude, but I'm
relieved to know I've not been on some list targeted for victimization
:-)

Cheers
Prasad

On 10/2/07, Joe Bohn [EMAIL PROTECTED] wrote:


 Lin Sun wrote:
  Me too!  I haven't been able to build geronimo 2.0 branch since this AM,
  after some similar failures every time.

 Persistence paid off for me.  I had to build like 8 times and with each
 failure I built the individual component that was failing.  Eventually I
 was able to get everything downloaded and built.  very painful.

 Joe




Re: Plugin progress

2007-10-02 Thread Prasad Kashyap
Hi David,

I have taken a stab at converting the servlet-examples and welcome
configs to plugins.  I have committed the code. Please give it a
looksy. Better to catch any mistakes now before I go full steam ahead.

Cheers
Prasad


On 10/1/07, David Jencks [EMAIL PROTECTED] wrote:

 On Oct 1, 2007, at 3:21 PM, Prasad Kashyap wrote:

  Does this list of problems still exist ?

 see comments inline
 
  Cheers
  Prasad
 
  On 9/11/07, David Jencks [EMAIL PROTECTED] wrote:
  I've now updated enough of the configs so  we can see if we can
  assemble them into a server.  It would be great if some one else
  could take a look at some of the remaining ones, list at the end of
  this email.  To get your own list of un-cleaned-up configs build g,
  fire it up, and run search-plugins from the command line deployer:
  the no category ones aren't done yet.
 

 this list of uncategorized plugins that need attention is still valid.
  To provide a more reasonable sized testbed for assembling servers out
  of plugins I also shrank geronimo-framework to the minimum possible
  size: rmi-naming plus enough security to enable the command line
  deployer to connect to it.
 
  So, while some parts of plugin installation work, overall it
  doesn't.  I keep seeing plugin installation pull in the wrong version
  of jars and cars and sometimes not find jars that are present in the
  local maven repo.
 
  Here are the problems I've noted so far, in order of discovery:
 
  1. While reviewing config poms I saw some suspicious dependencies.
  Axis and Axis2 depend on openejb which subverts any attempt to run
  axis web services on a minimal server.  The openejb-deployer requires
  openejb to be running which subverts any attempt to deploy offline
  while another server is running on the same machine (port conflicts).
 
 I think this is entirely resolved by now.

  2. Figuring out which repository to look in doesn't work yet.  While
  what is specified in the geronimo-plugin.xml and geronimo-plugins.xml
  does appear to be honored, using these isn't compatible with
  developing and testing plugins, since while a plugin is being worked
  on you want to use only your local repo but after its published you
  don't (unless perhaps its is hooked up to some kind of maven proxy)
  I wonder if  having a default repo configured in the plugin
  installer system would work, or perhaps merging the repos at the end
  of geronimo-plugins.xml with those in each geronimo-plugin.xml.
 
 this is less of an immediate issue, I added the remote maven central
 repo in and now most things are found, but the problem of moving from
 I'm developing this on my machine to its published at this repo
 remains and I don't have any good ideas.

  3. version resolution appears to have some serious problems.  I think
  pretty much all of the geronimo-plugin.xmls contain versions for
  every jar (something I'm hoping to change) but I ran into a lot of
  problems.  First most of the artifacts got resolved to the 2.0.1
  released artifacts which didn't work because the car files didn't
  have valid geronimo-plugin.xmls in them.  After I removed all my
  2.0.1 artifacts things were slightly better until I got to something
  that wouldn't resolve at all, xbean-reflect 3.2-SNAPSHOT.  The jar is
  in my local repo but for some reason it wasn't found.
 

 Most or all of these problems went away when I added maven central
 repo in.  The problems were mostly caused by missing maven-
 metadata.xml files: this prevented finding snapshots or resolving
 dependencies that lacked a version.
  4. I am doubting more and more that the current requires and
  obsoletes data are appropriate. For instance, most of the web apps
  require jetty (or tomcat, pick your flavor).  IMO this is the wrong
  idea.  If I want to install one of these web apps, it should install
  the web server if it's not already present.  What I think is more
  appropriate would be if I'm trying to install a jetty web app and
  tomcat is installed it should complain: if no other web server is
  installed then it should install jetty for me.

 I still think these are highly questionable.
 
  5.  Trying to extract information about what went wrong is really
  hard and unpleasant.

 maybe I got used to this one :-)
 
  6.  With the CTS configs that happen to be on my machine, there are
  93.  This is a lot to wade through.  We need a better way of
  organizing them, at least on the command line.  Perhaps providing a
  list of categories to pick from, then the plugins from that category,
  would be more manageable.  Also a deploy this from this maven repo
  command would be good: this might exist but I haven't found it yet.
 

 I think that's related to the install-plugin command :-)  Better
 categorization would still be helpful.

 hope this helps
 david jencks
  thanks
  david jencks
 
 
 
  no category
 Geronimo Configs :: Welcome app Jetty
   8 :  (2.1-SNAPSHOT)
 Geronimo Configs :: Unavailable Client

Re: [BUILD] 2.1: Failed for Revision: 580962

2007-10-01 Thread Prasad Kashyap
These build problems have consistently occurred while downloading the
transitive dependencies of geronimo-axis, particularly, transitive
dependencies of openjpa.

I am going to try the following two things to fix this problem -
1) stagger the 2.0 and 2.1 builds
2) upgrade to maven 2.0.7.

If this fails, we should consider moving the builds out of the
firewall to zones. I did this with OpenEJB builds and that has been
successful so far.

If we do end up having to move the builds to zones, it would be
preferable to build 2.0 and 2.1 on separate machines. Along with the
existing OpenEJB, I can run one other build (say 2.1) on my zones
site.

We'd now need to find a place to build the other version. Ideas ?

Cheers
Prasad


On 1 Oct 2007 14:49:49 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 OpenEJB trunk at 580938
 Geronimo Revision: 580962 built with tests included

 See the full build-1000.log file at 
 http://people.apache.org/~prasad/binaries/trunk/20071001/build-1000.log

 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-kernel-5/1.0.0/openjpa-kernel-5-1.0.0.jar
 Downloading: 
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-kernel-5/1.0.0/openjpa-kernel-5-1.0.0.jar
 28K downloaded
 Downloading: 
 http://download.java.net/maven/1//net.sourceforge.serp/jars/serp-1.11.0.jar
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//net/sourceforge/serp/serp/1.11.0/serp-1.11.0.jar
 Downloading: 
 http://www.ibiblio.org/maven2/net/sourceforge/serp/serp/1.11.0/serp-1.11.0.jar
 185K downloaded
 Downloading: 
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-persistence-1.0.0.jar
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-persistence/1.0.0/openjpa-persistence-1.0.0.jar
 Downloading: 
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-persistence/1.0.0/openjpa-persistence-1.0.0.jar
 Downloading: 
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-jdbc-1.0.0.jar
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-jdbc/1.0.0/openjpa-jdbc-1.0.0.jar
 Downloading: 
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-jdbc/1.0.0/openjpa-jdbc-1.0.0.jar
 1006K downloaded
 Downloading: 
 http://download.java.net/maven/1//commons-pool/jars/commons-pool-1.3.jar
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//commons-pool/commons-pool/1.3/commons-pool-1.3.jar
 Downloading: 
 http://www.ibiblio.org/maven2/commons-pool/commons-pool/1.3/commons-pool-1.3.jar
 60K downloaded
 Downloading: 
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-persistence-jdbc-1.0.0.jar
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
 Downloading: 
 http://tomcat.apache.org/dev/dist/m2-repository/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
 Downloading: 
 http://svn.apache.org/repos/asf/openejb/repo//org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-persistence-jdbc/1.0.0/openjpa-persistence-jdbc-1.0.0.jar
 108K downloaded
 Downloading: 
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-kernel-1.0.0.jar
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-kernel/1.0.0/openjpa-kernel-1.0.0.jar
 Downloading: 
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-kernel/1.0.0/openjpa-kernel-1.0.0.jar
 1098K downloaded
 Downloading: 
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-lib-1.0.0.jar
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-lib/1.0.0/openjpa-lib-1.0.0.jar
 Downloading: 
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-lib/1.0.0/openjpa-lib-1.0.0.jar
 424K downloaded
 Downloading: 
 http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-jdbc-5-1.0.0.jar
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-jdbc-5/1.0.0/openjpa-jdbc-5-1.0.0.jar
 Downloading: 
 http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa-jdbc-5/1.0.0/openjpa-jdbc-5-1.0.0.jar
 17K downloaded
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to resolve artifact.

 Missing:
 --
 1) net.sourceforge.serp:serp:jar:1.11.0

   Try downloading the file manually from the project website.

   Then, install it using the command:
   mvn 

Re: Plugin progress

2007-10-01 Thread Prasad Kashyap
Does this list of problems still exist ?

Cheers
Prasad

On 9/11/07, David Jencks [EMAIL PROTECTED] wrote:
 I've now updated enough of the configs so  we can see if we can
 assemble them into a server.  It would be great if some one else
 could take a look at some of the remaining ones, list at the end of
 this email.  To get your own list of un-cleaned-up configs build g,
 fire it up, and run search-plugins from the command line deployer:
 the no category ones aren't done yet.

 To provide a more reasonable sized testbed for assembling servers out
 of plugins I also shrank geronimo-framework to the minimum possible
 size: rmi-naming plus enough security to enable the command line
 deployer to connect to it.

 So, while some parts of plugin installation work, overall it
 doesn't.  I keep seeing plugin installation pull in the wrong version
 of jars and cars and sometimes not find jars that are present in the
 local maven repo.

 Here are the problems I've noted so far, in order of discovery:

 1. While reviewing config poms I saw some suspicious dependencies.
 Axis and Axis2 depend on openejb which subverts any attempt to run
 axis web services on a minimal server.  The openejb-deployer requires
 openejb to be running which subverts any attempt to deploy offline
 while another server is running on the same machine (port conflicts).

 2. Figuring out which repository to look in doesn't work yet.  While
 what is specified in the geronimo-plugin.xml and geronimo-plugins.xml
 does appear to be honored, using these isn't compatible with
 developing and testing plugins, since while a plugin is being worked
 on you want to use only your local repo but after its published you
 don't (unless perhaps its is hooked up to some kind of maven proxy)
 I wonder if  having a default repo configured in the plugin
 installer system would work, or perhaps merging the repos at the end
 of geronimo-plugins.xml with those in each geronimo-plugin.xml.

 3. version resolution appears to have some serious problems.  I think
 pretty much all of the geronimo-plugin.xmls contain versions for
 every jar (something I'm hoping to change) but I ran into a lot of
 problems.  First most of the artifacts got resolved to the 2.0.1
 released artifacts which didn't work because the car files didn't
 have valid geronimo-plugin.xmls in them.  After I removed all my
 2.0.1 artifacts things were slightly better until I got to something
 that wouldn't resolve at all, xbean-reflect 3.2-SNAPSHOT.  The jar is
 in my local repo but for some reason it wasn't found.

 4. I am doubting more and more that the current requires and
 obsoletes data are appropriate. For instance, most of the web apps
 require jetty (or tomcat, pick your flavor).  IMO this is the wrong
 idea.  If I want to install one of these web apps, it should install
 the web server if it's not already present.  What I think is more
 appropriate would be if I'm trying to install a jetty web app and
 tomcat is installed it should complain: if no other web server is
 installed then it should install jetty for me.

 5.  Trying to extract information about what went wrong is really
 hard and unpleasant.

 6.  With the CTS configs that happen to be on my machine, there are
 93.  This is a lot to wade through.  We need a better way of
 organizing them, at least on the command line.  Perhaps providing a
 list of categories to pick from, then the plugins from that category,
 would be more manageable.  Also a deploy this from this maven repo
 command would be good: this might exist but I haven't found it yet.

 thanks
 david jencks



 no category
Geronimo Configs :: Welcome app Jetty
  8 :  (2.1-SNAPSHOT)
Geronimo Configs :: Unavailable Client Deployer
  9 :  (2.1-SNAPSHOT)
Geronimo Configs :: GBean Deployer
  11:  (2.1-SNAPSHOT)
Geronimo Configs :: Shared Library
  12:  (2.1-SNAPSHOT)
Geronimo Configs :: System Database
  13:  (2.1-SNAPSHOT)
Geronimo Configs :: Application Client Deployments
  14:  (2.1-SNAPSHOT)
Geronimo Configs :: J2EE Client transaction
  15:  (2.1-SNAPSHOT)
Geronimo Configs :: CLI Upgrade
  16:  (2.1-SNAPSHOT)
Geronimo Configs :: Unavailable EJB Deployer
  17:  (2.1-SNAPSHOT)
Geronimo Configs :: Plan Upgrade
  20:  (2.1-SNAPSHOT)
Geronimo Configs :: Shutdown
  21:  (2.1-SNAPSHOT)
Geronimo Configs :: JSR88 JAR Configurer
  23:  (2.1-SNAPSHOT)
Geronimo Configs :: Welcome app Tomcat
  24:  (2.1-SNAPSHOT)
Geronimo Configs :: Corba J2EE Client
  25:  (2.1-SNAPSHOT)
Geronimo Configs :: Client System
  26:  (2.1-SNAPSHOT)
Geronimo Configs :: JSR88 EAR Configurer
  27:  (2.1-SNAPSHOT)
Geronimo Configs :: GBean Deployer Boostrap version
  28:  (2.1-SNAPSHOT)
Geronimo Configs :: JSR88 DeploymentFactory
  29:  (2.1-SNAPSHOT)
Geronimo Configs :: Servlet Examples for 

Re: where is the Web application security sample svn repo?

2007-09-28 Thread Prasad Kashyap
Toby,

That sample is in svn now.
http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/timereport/

Feel free to submit a patch :-)

Cheers
Prasad

On 9/17/07, toby cabot [EMAIL PROTECTED] wrote:
 Hi Folks,

 I'm playing around with application security in Geronimo and found the
 Web application security sample[1].  It's helpful, thanks!  I needed
 to make a few changes to get it to work with 2.0, so I'm curious if I
 can check it out of subversion somewhere and use svn to make a patch
 for you guys.

 If looks as if the zip file is just a wiki attachment so I imagine
 there's a subversion repo somewhere but I can't find it.  Pointers
 appreciated.

 Thanks,
 Toby

 [1] http://cwiki.apache.org/GMOxDOC20/web-application-security-sample.html



Re: where is the Web application security sample svn repo?

2007-09-28 Thread Prasad Kashyap
Oh.. btw, I've already fixed this app to work on 2.0.1.

Cheers
Prasad

On 9/28/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
 Toby,

 That sample is in svn now.
 http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/timereport/

 Feel free to submit a patch :-)

 Cheers
 Prasad

 On 9/17/07, toby cabot [EMAIL PROTECTED] wrote:
  Hi Folks,
 
  I'm playing around with application security in Geronimo and found the
  Web application security sample[1].  It's helpful, thanks!  I needed
  to make a few changes to get it to work with 2.0, so I'm curious if I
  can check it out of subversion somewhere and use svn to make a patch
  for you guys.
 
  If looks as if the zip file is just a wiki attachment so I imagine
  there's a subversion repo somewhere but I can't find it.  Pointers
  appreciated.
 
  Thanks,
  Toby
 
  [1] http://cwiki.apache.org/GMOxDOC20/web-application-security-sample.html
 



Re: [BUILD] Trunk: Successful

2007-09-26 Thread Prasad Kashyap
Yep. I thought so too. Working on it already.

Cheers
Prasad

On 9/26/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 Well, maybe it's time to fail the build if the tests fail (or as in
 this case the server doesn't even startup).

 Jarek

 On 26 Sep 2007 20:49:25 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  OpenEJB trunk at 579286
  Geronimo Revision: 579781 built with tests included
 
  See the full build-1600.log file at 
  http://people.apache.org/~prasad/binaries/trunk/20070926/build-1600.log
  Download the binaries from 
  http://people.apache.org/~prasad/binaries/trunk/20070926
 
  [INFO] BUILD SUCCESSFUL
  [INFO] 
  
  [INFO] Total time: 34 minutes 15 seconds
  [INFO] Finished at: Wed Sep 26 16:41:03 EDT 2007
  [INFO] Final Memory: 214M/998M
  [INFO] 
  
 
  TESTSUITE RESULTS (Failures only)
  =
  See detailed results at 
  http://people.apache.org/~prasad/testsuite/ResultsSummary.html
 
 
  Downloading: 
  http://repo1.maven.org/maven2/org/apache/geronimo/genesis/plugins/maven-maven-plugin/1.2/maven-maven-plugin-1.2.pom
  1K downloaded
  Downloading: 
  http://repo1.maven.org/maven2/org/apache/geronimo/genesis/plugins/maven-maven-plugin/1.2/maven-maven-plugin-1.2.jar
  10K downloaded
  [INFO] snapshot 
  org.apache.geronimo.plugins:geronimo-maven-plugin:2.1-SNAPSHOT: checking 
  for updates from apache-snapshots
  [INFO] snapshot 
  org.apache.geronimo.plugins:geronimo-maven-plugin:2.1-SNAPSHOT: checking 
  for updates from codehaus-snapshots
  [INFO] snapshot 
  org.apache.geronimo.plugins:geronimo-maven-plugin:2.1-SNAPSHOT: checking 
  for updates from apache.snapshots
  [INFO] [enforcer:enforce {execution: default}]
  [INFO] [tools:copy-legal-files {execution: install-legal-files}]
  Downloading: 
  http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/mojo/selenium-maven-plugin/1.0-beta-2-SNAPSHOT/selenium-maven-plugin-1.0-beta-2-20070925.221748-16.pom
  Downloading: 
  http://snapshots.repository.codehaus.org/org/codehaus/mojo/selenium-maven-plugin/1.0-beta-2-SNAPSHOT/selenium-maven-plugin-1.0-beta-2-20070925.221748-16.pom
  11K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/client-drivers/selenium-java-client-driver/0.9.2/selenium-java-client-driver-0.9.2.pom
  4K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/client-drivers/selenium-client-drivers/0.9.2/selenium-client-drivers-0.9.2.pom
  3K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/selenium-rc/0.9.2/selenium-rc-0.9.2.pom
  8K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/core/selenium-core/0.8.3/selenium-core-0.8.3.pom
  16K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/server/selenium-server-coreless/0.9.1/selenium-server-coreless-0.9.1.pom
  2K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/selenium-rc/0.9.1/selenium-rc-0.9.1.pom
  7K downloaded
  Downloading: 
  http://maven.openqa.org/jetty/org.mortbay.jetty/5.1.10/org.mortbay.jetty-5.1.10.pom
  Downloading: 
  http://repo1.maven.org/maven2/jetty/org.mortbay.jetty/5.1.10/org.mortbay.jetty-5.1.10.pom
  157b downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/server/selenium-server/0.9.2/selenium-server-0.9.2.pom
  6K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/server/selenium-server-coreless/0.9.2/selenium-server-coreless-0.9.2.pom
  2K downloaded
  Downloading: 
  http://maven.openqa.org/bouncycastle/bcprov-jdk15/135/bcprov-jdk15-135.pom
  194b downloaded
  Downloading: 
  http://maven.openqa.org/bouncycastle/bcprov-jdk15/135/bcprov-jdk15-135.jar
  1239K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/server/selenium-server-coreless/0.9.2/selenium-server-coreless-0.9.2.jar
  293K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/client-drivers/selenium-java-client-driver/0.9.2/selenium-java-client-driver-0.9.2.jar
  21K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/core/selenium-core/0.8.3/selenium-core-0.8.3.jar
  1582K downloaded
  Downloading: 
  http://maven.openqa.org/jetty/org.mortbay.jetty/5.1.10/org.mortbay.jetty-5.1.10.jar
  Downloading: 
  http://download.java.net/maven/1//jetty/jars/org.mortbay.jetty-5.1.10.jar
  Downloading: 
  http://people.apache.org/repo/m2-incubating-repository//jetty/org.mortbay.jetty/5.1.10/org.mortbay.jetty-5.1.10.jar
  Downloading: 
  http://maven.openqa.org/jetty/org.mortbay.jetty/5.1.10/org.mortbay.jetty-5.1.10.jar
  Downloading: 
  http://repo1.maven.org/maven2/jetty/org.mortbay.jetty/5.1.10/org.mortbay.jetty-5.1.10.jar
  660K downloaded
  Downloading: 
  http://maven.openqa.org/org/openqa/selenium/server/selenium-server/0.9.2/selenium-server-0.9.2-standalone.jar
  4946K 

Re: [BUILD] Trunk: Successful

2007-09-25 Thread Prasad Kashyap
http://people.apache.org/~prasad/binaries/trunk/20070925/test-1600.log

We have to exclude the ejbcontainer tests.

Cheers
Prasad.


On 9/25/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 Prasad,

 Do you know why the ResultsSummary page only shows a subset of the
 results for 2.1? For example, the results for web-testsuite are
 missing.

 Jarek

 On 25 Sep 2007 21:09:21 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  OpenEJB trunk at 579286
  Geronimo Revision: 579360 built with tests included
 
  See the full build-1600.log file at 
  http://people.apache.org/~prasad/binaries/trunk/20070925/build-1600.log
  Download the binaries from 
  http://people.apache.org/~prasad/binaries/trunk/20070925
 
  [INFO] BUILD SUCCESSFUL
  [INFO] 
  
  [INFO] Total time: 28 minutes 55 seconds
  [INFO] Finished at: Tue Sep 25 16:40:36 EDT 2007
  [INFO] Final Memory: 211M/1010M
  [INFO] 
  
 
  TESTSUITE RESULTS (Failures only)
  =
  See detailed results at 
  http://people.apache.org/~prasad/testsuite/ResultsSummary.html
 
  [INFO] Running console-testsuite.advance-test
  [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
  141.882 sec  FAILURE!
  --
  [INFO] Running deployment-testsuite.jca-cms
  [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
  0.313 sec  FAILURE!
  --
  [INFO] Running sec-testsuite.security
  [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 
  0.638 sec  FAILURE!
 
 



Re: [BUILD] Trunk: Successful

2007-09-25 Thread Prasad Kashyap
This is weird. The maven-maven-plugin aborts when it encounters an
error on Linux. On Windows, it keeps going.

Cheers
Prasad

On 9/25/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 Oh, nice. Is there a way to configure maven not to abort the tests in such 
 case?

 Jarek

 On 9/25/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
  http://people.apache.org/~prasad/binaries/trunk/20070925/test-1600.log
 
  We have to exclude the ejbcontainer tests.
 
  Cheers
  Prasad.
 
 
  On 9/25/07, Jarek Gawor [EMAIL PROTECTED] wrote:
   Prasad,
  
   Do you know why the ResultsSummary page only shows a subset of the
   results for 2.1? For example, the results for web-testsuite are
   missing.
  
   Jarek
  
   On 25 Sep 2007 21:09:21 -, [EMAIL PROTECTED] [EMAIL PROTECTED] 
   wrote:
OpenEJB trunk at 579286
Geronimo Revision: 579360 built with tests included
   
See the full build-1600.log file at 
http://people.apache.org/~prasad/binaries/trunk/20070925/build-1600.log
Download the binaries from 
http://people.apache.org/~prasad/binaries/trunk/20070925
   
[INFO] BUILD SUCCESSFUL
[INFO] 

[INFO] Total time: 28 minutes 55 seconds
[INFO] Finished at: Tue Sep 25 16:40:36 EDT 2007
[INFO] Final Memory: 211M/1010M
[INFO] 

   
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/~prasad/testsuite/ResultsSummary.html
   
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
141.882 sec  FAILURE!
--
[INFO] Running deployment-testsuite.jca-cms
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
0.313 sec  FAILURE!
--
[INFO] Running sec-testsuite.security
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 
0.638 sec  FAILURE!
   
   
  
 



Re: testsuite cleanup (in trunk)

2007-09-24 Thread Prasad Kashyap
 deployment-testsuite
   o deploy-tests
The 1 error in deployment-testsuite/deploy-tests is caused by this JIRA.
https://issues.apache.org/jira/browse/GERONIMO-3199

 enterprise-testsuite
   o ejbcontainer-tests
We had a full good run of ejbcontainer tests when we had Openejb 2.1.
We need to do something similar by getting their new 3.0 itests-webapp
to deploy on Geronimo.

Cheers
Prasad

On 9/21/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 Some of the tests in testsuite are broken and fail for one reason or
 another. I tried to fix as many tests as I could but there is still a
 bunch of them that I'm not sure how to fix. It would be great if
 people could take a look at the tests that they are familiar with and
 try to fix them (or disable/remove them if too outdated or whatever).

 Here's a list of the tests that fail for me:

 web-testsuite
   o test-jetty
   o test-tomcat
   o test-security

 deployment-testsuite
   o jca-cms-tests

 enterprise-testsuite
   o ejbcontainer-tests
   o jms-tests
   o sec-tests

 Jarek



Re: [BUILD] 2.0: Failed for Revision: 578034

2007-09-21 Thread Prasad Kashyap
David Blevins,

Can you please create an account for me on that machine you promised.
Maybe that will help me get successful OpenEJB builds and thus
successful G builds.

Cheers
Prasad

On 21 Sep 2007 10:06:26 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 OpenEJB trunk at 0
 Geronimo Revision: 578034 built with tests included

 See the full build-0400.log file at 
 http://people.apache.org/~prasad/binaries/2.0/20070921/build-0400.log

 [INFO] Installing 
 /home/prasad/geronimo/2.0/configs/webservices-common/target/webservices-common-2.0.2-SNAPSHOT.car
  to 
 /home/prasad/.m2/repository/org/apache/geronimo/configs/webservices-common/2.0.2-SNAPSHOT/webservices-common-2.0.2-SNAPSHOT.car
 [INFO] 
 
 [INFO] Building Geronimo Configs :: OpenJPA with dependencies
 [INFO]task-segment: [install]
 [INFO] 
 
 [INFO] [enforcer:enforce {execution: default}]
 [INFO] [tools:copy-legal-files {execution: install-legal-files}]
 [INFO] Created dir: 
 /home/prasad/geronimo/2.0/configs/openjpa/target/classes/META-INF
 [INFO] Copying 2 files to 
 /home/prasad/geronimo/2.0/configs/openjpa/target/classes/META-INF
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [car:prepare-plan]
 [INFO] Generated: 
 /home/prasad/geronimo/2.0/configs/openjpa/target/plan/plan.xml
 Downloading: 
 http://download.java.net/maven/1//commons-lang/poms/commons-lang-2.0.pom
 [WARNING] Unable to get resource 'commons-lang:commons-lang:pom:2.0' from 
 repository java.net (http://download.java.net/maven/1/)
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//commons-lang/commons-lang/2.0/commons-lang-2.0.pom
 [WARNING] Unable to get resource 'commons-lang:commons-lang:pom:2.0' from 
 repository apache-incubator 
 (http://people.apache.org/repo/m2-incubating-repository/)
 Downloading: 
 http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.pom
 2K downloaded
 Downloading: 
 http://download.java.net/maven/1//net.sourceforge.serp/poms/serp-1.11.0.pom
 [WARNING] Unable to get resource 'net.sourceforge.serp:serp:pom:1.11.0' from 
 repository java.net (http://download.java.net/maven/1/)
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//net/sourceforge/serp/serp/1.11.0/serp-1.11.0.pom
 [WARNING] Unable to get resource 'net.sourceforge.serp:serp:pom:1.11.0' from 
 repository apache-incubator 
 (http://people.apache.org/repo/m2-incubating-repository/)
 Downloading: 
 http://repo1.maven.org/maven2/net/sourceforge/serp/serp/1.11.0/serp-1.11.0.pom
 4K downloaded
 Downloading: 
 http://download.java.net/maven/1//net.sourceforge.serp/jars/serp-1.11.0.jar
 [WARNING] Unable to get resource 'net.sourceforge.serp:serp:jar:1.11.0' from 
 repository java.net (http://download.java.net/maven/1/)
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//net/sourceforge/serp/serp/1.11.0/serp-1.11.0.jar
 [WARNING] Unable to get resource 'net.sourceforge.serp:serp:jar:1.11.0' from 
 repository apache-incubator 
 (http://people.apache.org/repo/m2-incubating-repository/)
 Downloading: 
 http://repo1.maven.org/maven2/net/sourceforge/serp/serp/1.11.0/serp-1.11.0.jar
 185K downloaded
 Downloading: 
 http://download.java.net/maven/1//commons-lang/jars/commons-lang-2.0.jar
 [WARNING] Unable to get resource 'commons-lang:commons-lang:jar:2.0' from 
 repository java.net (http://download.java.net/maven/1/)
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//commons-lang/commons-lang/2.0/commons-lang-2.0.jar
 [WARNING] Unable to get resource 'commons-lang:commons-lang:jar:2.0' from 
 repository apache-incubator 
 (http://people.apache.org/repo/m2-incubating-repository/)
 Downloading: 
 http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.jar
 165K downloaded
 [INFO] [car:package]
 [INFO] Packaging module configuration: 
 /home/prasad/geronimo/2.0/configs/openjpa/target/plan/plan.xml
 [INFO] snapshot org.apache.geronimo.modules:geronimo-openjpa:2.0.2-SNAPSHOT: 
 checking for updates from apache-snapshots
 [INFO] snapshot org.apache.geronimo.modules:geronimo-openjpa:2.0.2-SNAPSHOT: 
 checking for updates from codehaus-snapshots
 [INFO] snapshot org.apache.geronimo.modules:geronimo-openjpa:2.0.2-SNAPSHOT: 
 checking for updates from apache.snapshots
 [INFO] Building jar: 
 /home/prasad/geronimo/2.0/configs/openjpa/target/openjpa-2.0.2-SNAPSHOT.car
 [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
 [INFO] Checking legal files in: openjpa-2.0.2-SNAPSHOT.car
 [INFO] [install:install]
 [INFO] Installing 
 /home/prasad/geronimo/2.0/configs/openjpa/target/openjpa-2.0.2-SNAPSHOT.car 
 to 
 /home/prasad/.m2/repository/org/apache/geronimo/configs/openjpa/2.0.2-SNAPSHOT/openjpa-2.0.2-SNAPSHOT.car
 [INFO] 
 

Re: automatic builds with tests

2007-09-20 Thread Prasad Kashyap
Right. We have talked about this before and the majority opinion was
to have a separate subject line.

I have a gmail reader, but then again it's not about how I want it.
I'll gladly put whatever the majority of the community decides.

Start a [VOTE] thread :-))

Cheers
Prasad

On 9/19/07, Kevan Miller [EMAIL PROTECTED] wrote:

 On Sep 19, 2007, at 4:28 PM, Prasad Kashyap wrote:

  OK. I have enabled the unit tests to run on all builds for both trees
  (2.0 and trunk).
 
  The testsuite presently runs only with all 2.0 builds. I'm soon going
  to enable it to run on all trunk builds too.
 
  Now that all tests are running, there will be only 4 builds a day - 4
  am, 10 am, 4 pm and 10 pm.

 Great.

 Seems like we talked about this, before... I wish your emails would
 have non-mutable Subjects. Rather than including the Revision number
 or number of tests passed/failed, just indicate success or failure.
 Details are in the body of the mail, already...

 For example:

 [BUILD] Trunk: Successful for Revision: 577451
 [BUILD] 2.0: Failed for Revision: 577231

 Since the revision number is always changing, each of those emails
 will be a separate Subject thread.

 [BUILD] Trunk: Successful
 [BUILD] branches/2.0: Failed

 These emails would be sorted into the same discussion thread as
 previous notifications...

 I don't know about your mail reader, but this would really reduce the
 amount of real estate your notifications take up. Also, much easier
 for me to delete ;-)

 --kevan






Re: [BUILD] 2.0: Failed for Revision: 577231

2007-09-19 Thread Prasad Kashyap
Anybody know what the deal with this error is ?

[ERROR] BUILD ERROR
[INFO] 
[INFO] Unable to create configuration for deployment

Unable to resolve dependency org.codehaus.swizzle/swizzle-stream//jar
 Parent stack:
org.apache.geronimo.modules/geronimo-openejb/2.0.2-SNAPSHOT/jar (top)


Cheers
Prasad


On 19 Sep 2007 10:30:23 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 OpenEJB trunk at 0
 Geronimo Revision: 577231 built with tests included

 See the full build-0400.log file at 
 http://people.apache.org/~prasad/binaries/2.0/20070919/build-0400.log

 [INFO] Installing 
 /home/prasad/geronimo/2.0/configs/webservices-common/target/webservices-common-2.0.2-SNAPSHOT.car
  to 
 /home/prasad/.m2/repository/org/apache/geronimo/configs/webservices-common/2.0.2-SNAPSHOT/webservices-common-2.0.2-SNAPSHOT.car
 [INFO] 
 
 [INFO] Building Geronimo Configs :: OpenJPA with dependencies
 [INFO]task-segment: [install]
 [INFO] 
 
 [INFO] [enforcer:enforce {execution: default}]
 [INFO] [tools:copy-legal-files {execution: install-legal-files}]
 [INFO] Created dir: 
 /home/prasad/geronimo/2.0/configs/openjpa/target/classes/META-INF
 [INFO] Copying 2 files to 
 /home/prasad/geronimo/2.0/configs/openjpa/target/classes/META-INF
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [car:prepare-plan]
 [INFO] Generated: 
 /home/prasad/geronimo/2.0/configs/openjpa/target/plan/plan.xml
 Downloading: 
 http://download.java.net/maven/1//commons-lang/poms/commons-lang-2.0.pom
 [WARNING] Unable to get resource 'commons-lang:commons-lang:pom:2.0' from 
 repository java.net (http://download.java.net/maven/1/)
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//commons-lang/commons-lang/2.0/commons-lang-2.0.pom
 [WARNING] Unable to get resource 'commons-lang:commons-lang:pom:2.0' from 
 repository apache-incubator 
 (http://people.apache.org/repo/m2-incubating-repository/)
 Downloading: 
 http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.pom
 2K downloaded
 Downloading: 
 http://download.java.net/maven/1//net.sourceforge.serp/poms/serp-1.11.0.pom
 [WARNING] Unable to get resource 'net.sourceforge.serp:serp:pom:1.11.0' from 
 repository java.net (http://download.java.net/maven/1/)
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//net/sourceforge/serp/serp/1.11.0/serp-1.11.0.pom
 [WARNING] Unable to get resource 'net.sourceforge.serp:serp:pom:1.11.0' from 
 repository apache-incubator 
 (http://people.apache.org/repo/m2-incubating-repository/)
 Downloading: 
 http://repo1.maven.org/maven2/net/sourceforge/serp/serp/1.11.0/serp-1.11.0.pom
 4K downloaded
 Downloading: 
 http://download.java.net/maven/1//net.sourceforge.serp/jars/serp-1.11.0.jar
 [WARNING] Unable to get resource 'net.sourceforge.serp:serp:jar:1.11.0' from 
 repository java.net (http://download.java.net/maven/1/)
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//net/sourceforge/serp/serp/1.11.0/serp-1.11.0.jar
 [WARNING] Unable to get resource 'net.sourceforge.serp:serp:jar:1.11.0' from 
 repository apache-incubator 
 (http://people.apache.org/repo/m2-incubating-repository/)
 Downloading: 
 http://repo1.maven.org/maven2/net/sourceforge/serp/serp/1.11.0/serp-1.11.0.jar
 185K downloaded
 Downloading: 
 http://download.java.net/maven/1//commons-lang/jars/commons-lang-2.0.jar
 [WARNING] Unable to get resource 'commons-lang:commons-lang:jar:2.0' from 
 repository java.net (http://download.java.net/maven/1/)
 Downloading: 
 http://people.apache.org/repo/m2-incubating-repository//commons-lang/commons-lang/2.0/commons-lang-2.0.jar
 [WARNING] Unable to get resource 'commons-lang:commons-lang:jar:2.0' from 
 repository apache-incubator 
 (http://people.apache.org/repo/m2-incubating-repository/)
 Downloading: 
 http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.jar
 165K downloaded
 [INFO] [car:package]
 [INFO] Packaging module configuration: 
 /home/prasad/geronimo/2.0/configs/openjpa/target/plan/plan.xml
 [INFO] snapshot org.apache.geronimo.modules:geronimo-openjpa:2.0.2-SNAPSHOT: 
 checking for updates from apache-snapshots
 [INFO] snapshot org.apache.geronimo.modules:geronimo-openjpa:2.0.2-SNAPSHOT: 
 checking for updates from codehaus-snapshots
 [INFO] snapshot org.apache.geronimo.modules:geronimo-openjpa:2.0.2-SNAPSHOT: 
 checking for updates from apache.snapshots
 [INFO] Building jar: 
 /home/prasad/geronimo/2.0/configs/openjpa/target/openjpa-2.0.2-SNAPSHOT.car
 [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
 [INFO] Checking legal files in: openjpa-2.0.2-SNAPSHOT.car
 [INFO] [install:install]
 [INFO] Installing 
 

Re: automatic builds with tests

2007-09-19 Thread Prasad Kashyap
OK. I have enabled the unit tests to run on all builds for both trees
(2.0 and trunk).

The testsuite presently runs only with all 2.0 builds. I'm soon going
to enable it to run on all trunk builds too.

Now that all tests are running, there will be only 4 builds a day - 4
am, 10 am, 4 pm and 10 pm.

Cheers
Prasad.

On 9/17/07, Paul McMahan [EMAIL PROTECTED] wrote:
 +1

 On Sep 14, 2007, at 4:43 PM, Jarek Gawor wrote:

  I know that at least the 5am build runs with tests on. I would like to
  change that so that each build always runs with all tests enabled.
  Some of the tests in testsuite/ directory actaully start the server so
  if they are successful we should at least know that the server starts
  up ok and applications can be deployed to it. That should enable us to
  quickly catch and address problems as people commit their changes.
 
  If people agree on this change, I'm willing to spend whatever time is
  necessary to make this happen.
 
  Jarek




Re: [DISCUSS] Default server log level

2007-09-11 Thread Prasad Kashyap
I don't mind if INFO is the default log level. It would be nice if we
can also change it
1. during Geronimo startup.
2. during runtime.

Possible ?

Cheers
Prasad

On 9/11/07, Kevan Miller [EMAIL PROTECTED] wrote:
 The intent of this thread is to discuss the default log level for the
 Geronimo server. I'd like to limit the discussion to the near-term
 (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging
 code. I'd like to see more structure and consistency in our logging.
 However, that's not a 2.0.x issue.

 The current default log level for a Geronimo 2.0.1 server is ERROR.
 IMO, this is too restrictive. I think we should set the default to
 INFO. This will make our server logging more verbose. However, I'd
 rather have too much information, rather than too little.

 I think our default target audience should be application developers
 and new users evaluating Geronimo. Currently, these users are forced
 to configure log levels to INFO, so that they can obtain necessary
 information for building and deploying applications on Geronimo. This
 information should be available by default, not requiring
 configuration...

 Users who want to limit the logging output can reconfigure the
 default logging levels, once they are more comfortable with Geronimo.

 Comments?

 --kevan



[jira] Created: (GERONIMO-3464) A webapp with init-param fails deployment

2007-09-10 Thread Prasad Kashyap (JIRA)
A webapp with init-param fails deployment
---

 Key: GERONIMO-3464
 URL: https://issues.apache.org/jira/browse/GERONIMO-3464
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment
 Environment: Windows XP
Reporter: Prasad Kashyap
Assignee: David Jencks
Priority: Critical
 Fix For: 2.0.2


I have a very simple web.xml whose only servlet definition contains an 
init-param

{code}
servlet
  display-nameAsyncServlet/display-name
  servlet-nameAsyncServlet/servlet-name
  servlet-classorg.apache.geronimo.AsyncServlet/servlet-class
  init-param
param-nameremoteUrl/param-name
param-valuehttp://puffyshirt:8080/param-value
/init-param  
/servlet
{code}

This webapp fails deployment with the following exception:
   error: cvc-complex-type.2.4a: Expected elements
   '[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee
   [EMAIL PROTECTED]://java.sun.com/xml/ns/javaee' instead of
   '[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee' here in element
   [EMAIL PROTECTED]://java.sun.com/xml/ns/javaee

The same app deploys successfully on Tomcat


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



[jira] Closed: (GERONIMO-3464) A webapp with init-param fails deployment

2007-09-10 Thread Prasad Kashyap (JIRA)

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

Prasad Kashyap closed GERONIMO-3464.


Resolution: Invalid

Failure caused by load-on-startup preceding init-param
Guess Tomcat is more flexible. 

 A webapp with init-param fails deployment
 ---

 Key: GERONIMO-3464
 URL: https://issues.apache.org/jira/browse/GERONIMO-3464
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: deployment
 Environment: Windows XP
Reporter: Prasad Kashyap
Assignee: David Jencks
Priority: Critical
 Fix For: 2.0.2


 I have a very simple web.xml whose only servlet definition contains an 
 init-param
 {code}
 servlet
   display-nameAsyncServlet/display-name
   servlet-nameAsyncServlet/servlet-name
   servlet-classorg.apache.geronimo.AsyncServlet/servlet-class
   init-param
   param-nameremoteUrl/param-name
   param-valuehttp://puffyshirt:8080/param-value
 /init-param  
 /servlet
 {code}
 This webapp fails deployment with the following exception:
error: cvc-complex-type.2.4a: Expected elements
'[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee
[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee' instead of
'[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee' here in element
[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee
 The same app deploys successfully on Tomcat

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



Re: Help with car-maven-plugin site generation needed

2007-09-08 Thread Prasad Kashyap
The javadoc-plugin configuration in genesis in set to use jdk 1.4.
Rebuild genesis/configs/project-config by changing the javadoc-plugin
configuration in it to use jdk 1.5. Then run site at c-m-p. This
should fix it.

Cheers
Prasad

On 9/8/07, David Jencks [EMAIL PROTECTED] wrote:
 I thought I might try to document the c-m-p a bit but when I try to run

 mvn site

 the javadoc plugin complains that I'm not using jdk 1.4 syntax.  I
 tried everything I could think of to set source1.5/source but
 with no success whatsoever.  If anyone has a clue how to fix this
 please demonstrate!

 btw I'm using maven 2.0.7 and wonder if we should make that a
 requirement.

 thanks
 david jencks




Re: [ANNOUNCE] Welcome Donald Woods as the newest member of the Geronimo PMC

2007-09-07 Thread Prasad Kashyap
Congrats Donald !

Cheers
Prasad

On 9/6/07, Hernan Cunico [EMAIL PROTECTED] wrote:
 Please join us in congratulating Donald Woods as the newest member of the 
 Geronimo PMC. Donald has contributed to Geronimo in many different areas; he 
 has provided tons of patches, added functionality, testing and security among 
 others. We are very pleased he accepted our invitation to join us in the 
 project's oversight.

 Welcome aboard Donald!!!

 The Apache Geronimo PMC



 Cheers!
 Hernan



Re: [ANNOUNCE] Welcome Shiva Kumar H R as Apache Geronimo's latest committer

2007-09-07 Thread Prasad Kashyap
About time ! Congrats Shiva !

Cheers
Prasad

On 9/7/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
 Hi All,

 The Geronimo PMC is pleased to announce that Shiva Kumar H R has recently
 accepted our invitation to become an Apache Geronimo committer.  Shiva has
 been contributing to Geronimo for quite sometime and is very active on
 lists.  His Eclipse Plugin Development skill is awesome and I am sure he
 will take our Geronimo DEVTOOLS project to new heights.

 We're thrilled to hand him a committer hat and look forward to his continued
 contributions to the project.

 Congratulations and welcome aboard, Shiva!

 -Vamsi


Re: [ANNOUNCE] Welcome Jarek Gawor as the newest member of the Geronimo PMC

2007-09-05 Thread Prasad Kashyap
Congratulations Jarek !

Cheers
Prasad

On 9/4/07, Joe Bohn [EMAIL PROTECTED] wrote:

 Please us in congratulating Jarek Gawor as the newest member of the
 Geronimo PMC.  In addition to being involved in all things related to
 web services, he also has demonstrated a clear commitment to Geronimo in
 numerous other areas.   We're very glad that he has accepted our
 invitation to join us in providing oversight of the Geronimo project.

 Way to go Jarek !!!

 The Apache Geronimo PMC




Re: [BUILD] Trunk: Failed for Revision: 572896

2007-09-05 Thread Prasad Kashyap
David,

I believe this failure occurs only on a clean repo. I was unable to
recreate it on a populated repo.

Anyways, here are the logs and the entire tar ball of the
car-maven-plugin after it failed.

http://people.apache.org/~prasad/build.log
http://people.apache.org/~prasad/car-maven-plugin.tar.gz

Cheers
Prasad

On 9/5/07, David Jencks [EMAIL PROTECTED] wrote:
 This appears to be related to some of my changes but I can't
 reproduce this problem.  Knowing what is in /home/prasad/geronimo/
 trunk/maven-plugins/car-maven-plugin/src/it/j2ee-system/build.log
 would be very helpful

 thanks
 david jencks
 On Sep 5, 2007, at 1:29 AM, [EMAIL PROTECTED] wrote:

  OpenEJB trunk at 0
  Geronimo Revision: 572896 built with tests included
 
  See the full build-0400.log file at http://people.apache.org/
  ~prasad/binaries/trunk/20070905/build-0400.log
 
  Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/
  plexus-utils/1.4/plexus-utils-1.4.pom
  1K downloaded
  Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/groovy/
  groovy-mojo-support/1.0-beta-1/groovy-mojo-support-1.0-beta-1.pom
  2K downloaded
  Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/groovy/
  groovy/1.0-beta-1/groovy-1.0-beta-1.pom
  14K downloaded
  Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/groovy/
  groovy-mojo-common/1.0-beta-1/groovy-mojo-common-1.0-beta-1.pom
  2K downloaded
  Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/groovy/
  groovy-mojo-support/1.0-beta-1/groovy-mojo-support-1.0-beta-1.jar
  32K downloaded
  Downloading: http://download.java.net/maven/1//
  org.codehaus.mojo.groovy/jars/groovy-mojo-common-1.0-beta-1.jar
  [WARNING] Unable to get resource 'org.codehaus.mojo.groovy:groovy-
  mojo-common:jar:1.0-beta-1' from repository java.net (http://
  download.java.net/maven/1/)
  Downloading: http://people.apache.org/repo/m2-incubating-
  repository//org/codehaus/mojo/groovy/groovy-mojo-common/1.0-beta-1/
  groovy-mojo-common-1.0-beta-1.jar
  [WARNING] Unable to get resource 'org.codehaus.mojo.groovy:groovy-
  mojo-common:jar:1.0-beta-1' from repository apache-incubator
  (http://people.apache.org/repo/m2-incubating-repository/)
  Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/groovy/
  groovy-mojo-common/1.0-beta-1/groovy-mojo-common-1.0-beta-1.jar
  5K downloaded
  [INFO] [shitty:clean {execution: default}]
  Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
  plugin-tools-api/2.0.5/maven-plugin-tools-api-2.0.5.pom
  880b downloaded
  Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
  plugin-tools/2.0.5/maven-plugin-tools-2.0.5.pom
  4K downloaded
  Downloading: http://repo1.maven.org/maven2/org/apache/maven/shared/
  maven-shared-components/6/maven-shared-components-6.pom
  3K downloaded
  [WARNING]
Artifact org.apache.maven:maven-plugin-tools-api:jar:2.0.5:runtime
  retains local scope 'runtime' overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or remove
  the local scope.
 
  Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
  plugin-descriptor/2.0.4/maven-plugin-descriptor-2.0.4.pom
  1K downloaded
  Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
  plugin-tools-beanshell/2.0.5/maven-plugin-tools-beanshell-2.0.5.pom
  879b downloaded
  Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
  plugin-tools-java/2.0.5/maven-plugin-tools-java-2.0.5.pom
  871b downloaded
  Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
  plugin-tools-api/2.0.5/maven-plugin-tools-api-2.0.5.jar
  28K downloaded
  Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
  plugin-tools-beanshell/2.0.5/maven-plugin-tools-beanshell-2.0.5.jar
  11K downloaded
  Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
  plugin-tools-java/2.0.5/maven-plugin-tools-java-2.0.5.jar
  13K downloaded
  [INFO] [plugin:descriptor]
  [WARNING] Goal prefix is: car; Maven currently expects it to be car
  [INFO] Using 2 extractors.
  [INFO] Applying extractor for language: java
  [INFO] Extractor for language: java found 6 mojo descriptors.
  [INFO] Applying extractor for language: groovy
  [INFO] Extractor for language: groovy found 0 mojo descriptors.
  [INFO] [tools:copy-legal-files {execution: install-legal-files}]
  [INFO] Copying 2 files to /home/prasad/geronimo/trunk/maven-plugins/
  car-maven-plugin/target/classes/META-INF
  [INFO] [resources:resources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:compile]
  [INFO] Compiling 18 source files to /home/prasad/geronimo/trunk/
  maven-plugins/car-maven-plugin/target/classes
  [INFO] [resources:testResources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:testCompile]
  [INFO] Compiling 1 source file to /home/prasad/geronimo/trunk/maven-
  plugins/car-maven-plugin/target/test-classes
  [INFO] 

  1   2   3   4   5   6   7   8   9   10   >