date:20060215


Vote passed with:

+1 Jeff Genender, Alan Cabrera, Sachin Patel, Dain Sundstrom, David  
Blevins, Andy Piper, Aaron Mulder, Davanum Srinivas, Jacek Laskowski,  
Bruce Snyder, Jason Dillion, Gianny Damour, John Sission, David  
Jencks, James Strachan, Jules Gosnell, Guillaume Nodet, Rob Davies,  
Kevin Miller, Hiram Chirino, Srinath Perera


No -1s

The paper work has been filed with incubator and I will post a JIRA  
to infrastructure to the code imported.


-dain

On Jan 27, 2006, at 12:08 PM, Dain Sundstrom wrote:


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


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

-dain

Re: Sample plan bits for configId branch, please review!


On Feb 15, 2006, at 6:01 PM, Sachin Patel wrote:


Is it possible to define an enumeration of the possible properties?


The idea I have, is that literally any value would be allowed.  The  
one value David Jencks and I mentioned is something that a user  
should never see or mess with.


-dain

[jira] Created: (GERONIMO-1633) "resource-ref" not available in ServletFilter.init(..)

2006-02-15 Thread Andrus Adamchik (JIRA)

"resource-ref" not available in ServletFilter.init(..) 
---

 Key: GERONIMO-1633
 URL: http://issues.apache.org/jira/browse/GERONIMO-1633
 Project: Geronimo
Type: Bug
  Components: naming  
Versions: 1.0
 Environment: Linux, JDK 1.4.2, Geronimo -jetty 1.0
Reporter: Andrus Adamchik
Priority: Minor


I saw a few similar issues marked as fixed, but FWIW, I am getting an error 
when accessing a G DataSource from inside ServletFilter.init(..), while i have 
no problem getting the same resource later from ServletFilter.doFilter(..).

web.xml

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/web-app_2_4.xsd";
 version="2.4">
  
CayenneDS
javax.sql.DataSource
Container
Shareable
  
  
  
CayenneFilter
test.GTestFilter
  

  
CayenneFilter
/*
  


geronimo-web.xml:


http://geronimo.apache.org/xml/ns/web";
xmlns:naming="http://geronimo.apache.org/xml/ns/naming";
configId="transaction-tests2">

/transaction-tests2
true


CayenneDS
jdbc/derby-cayenne-test




Stack:

javax.naming.NameNotFoundException: comp/env/CayenneDS
at 
org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:45)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at test.GTestFilter.init(GTestFilter.java:33)
at org.mortbay.jetty.servlet.FilterHolder.start(FilterHolder.java:71)
at 
org.apache.geronimo.jetty.JettyFilterHolder.(JettyFilterHolder.java:41)
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:274)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:901)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:520)
at 
org.apache.geronimo.gbean.runtime.GBeanSingleReference.attemptFullStart(GBeanSingleReference.java:154)
at 
org.apache.geronimo.gbean.runtime.GBeanSingleReference.targetAdded(GBeanSingleReference.java:127)
at 
org.apache.geronimo.gbean.runtime.AbstractGBeanReference.addTarget(AbstractGBeanReference.java:242)
at 
org.apache.geronimo.gbean.runtime.GBeanSingleReference$1.running(GBeanSingleReference.java:163)
at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:155)
at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:38)
at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:231)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:350)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
at 
org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315)
at 
org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at 
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at 
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at 
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173)
at 
org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142)
at 
org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at 
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.runtime.GBeanOperatio

Re: Thoughts on splitting out "core" from, well, products & other stuff


On Feb 13, 2006, at 7:15 PM, Aaron Mulder wrote:


What would folks think of (in principle, not right now) splitting out
the core Geronimo components from anything that wraps a 3rd-party
product/project?  So have one area for modules like kernel, security,
core, system, etc. and a separate area for modules like Jetty, Tomcat,
ActiveMQ, Directory, jUDDI, etc.  I guess mainly to draw the
distinction between what's really part of the infrastructure and
what's really "optional packages" that can be added on top (and I'm
talking about "optional" in a non-J2EE-server sense where you start
with literally nothing but the infrastructure and add only waht you
want, or something like that).  So we'd still pull a lot of that in
for our "J2EE" builds, but it would make a clearer distinction for
anyone who wanted a more custom build.



I've got the current openejb 3 tree setup somewhat like this and it's  
really nice.  Makes it really easy to say, things in this area cannot  
depend on things in that area.. and so on.


Otherwise things tend to spider together and become coupled.

Obviously the "devil is in the details" as Dain says.

-David

Re: Sample plan bits for configId branch, please review!

2006-02-15 Thread Sachin Patel



- sachin



On Feb 15, 2006, at 6:07 PM, John Sisson wrote:


David Jencks wrote:


On Feb 15, 2006, at 2:04 PM, David Blevins wrote:


On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:


On Feb 15, 2006, at 1:23 PM, David Blevins wrote:


So we should call it something like:


...
  

  base-name
  geronimo.maven:J2EEServer=geronimo

  
...


Cause IMHO, having a  element with a  
 sub element implies something all together different:


[...]

Also I would prefer to not imply that these properties are  
limited to only "naming-properties".  I gut tells me that this  
will be a useful extension place in the geronimo configurations.


Ok.  I was under the impression via DJ's comments that these were  
only for naming.


On Feb 15, 2006, at 10:59 AM, David Jencks wrote:


Dain:
 I'm not sure about the names of name-keys and name-key.  These  
are really intended for use by the naming system and are rarely  
used, so I prefer to name them that way rather than  
"properties".  What could other properties be used for?  How  
would we distinguish them from the ones for the naming system?


And your comment on using any naming system made me think my  
impression was definitely write.  I guess this isn't one of those  
agreed upon things just yet.


So what is the general idea behind them?  A generic bucket for  
properties that are easily available to all gbeans in my  
configuration?


I originally thought of them as having only to do with the naming  
system, but after Dain suggested "properties" I realized that we  
might think of something else to use them for in the future.  They  
would be available to parts of the deployment infrastructure such  
as the naming system, but not really to any gbeans.
I am wondering whether having both naming properties and other  
properties under the one  element may make it difficult  
for any tools (e.g. a GUI/web based tool that can read/build plans)  
to identify and display the naming properties when reading the  
plans without hard coded knowledge of the property names used for  
naming.


Is it possible to define an enumeration of the possible properties?



John


thanks
david jencks



-David

[jira] Created: (GERONIMO-1632) Test

Test


 Key: GERONIMO-1632
 URL: http://issues.apache.org/jira/browse/GERONIMO-1632
 Project: Geronimo
Type: Bug
Reporter: Alan Cabrera
 Assigned to: Alan Cabrera 


Test

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Migrating to maven 2 - conversion idea



On Feb 15, 2006, at 2:52 PM, Alan D. Cabrera wrote:


David Blevins wrote, On 2/14/2006 5:29 PM:

On Feb 14, 2006, at 5:01 PM, Dain Sundstrom wrote:
  I get the impression that people are proposing that we create   
parallel builds for modules one at a time, and I just don't see   
that working.
Both the OpenEJB and ActiveMQ builds were done as parallel  
builds.   I've got ActiveMQ up in continuum building as an M2  
projects, so we  know it stays good. Obviously, the OpenEJB build  
was done way before  we had continuum and it got crufty.
ActiveMQ still does releases from m1 as they still don't have all   
their tests converted over.  Other than that their m2 build works.
But I'm in the same boat as you, I don't have the bandwidth to  
work  on it aside from helping people get it running in continuum.


I feel the same way as Dain but I am willing to back it up w/ warm  
bodies to help.  Continuum will not help, imho.  It will only  
remind us how badly the two versions are drifting.


Ok, now *that* is feedback I can use.  The whole "i don't think it  
will work" with no reasons why is not as useful.


And thanks for the warm bodies.

-David

[jira] Updated: (GERONIMO-1630) IONA's Initial Yoko Contribution

 [ http://issues.apache.org/jira/browse/GERONIMO-1630?page=all ]

Alan Cabrera updated GERONIMO-1630:
---

Attachment: test_1.zip

Test

> IONA's Initial Yoko Contribution
> 
>
>  Key: GERONIMO-1630
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1630
>  Project: Geronimo
> Type: New Feature
>   Components: CORBA
> Versions: 1.1
> Reporter: Adi Sakala
> Assignee: Alan Cabrera
>  Attachments: Yoko_ob.zip, Yoko_ob.zip.MD5, test_1.zip
>
> As per the accepted CORBA Proposal [1], IONA Technologies would like to 
> donate a full CORBA implementation to Geronimo Yoko sub project.
> The contribution includes full CORBA ORB and IIOP transport from IONA 
> Technologies. The contribution is delivered using the package named 
> Yoko_ob.zip (attached to this message) with following MD5 Checksum  
> (41fd6b5857c5366cf0e28e852839ad84).
> This implementation claims full support for ORB and IIOP transport as per 
> CORBA 2.6 specification [2].
> Following this I expect community to take and perform required next steps in 
> making a world-class vendor neutral CORBA System available via Apache and 
> delivering a successful project out of CORBA Proposal [1] and corba binding 
> via Celtix to Geronimo providing at least support for IIOP & RMI.
> [1] - http://wiki.apache.org/incubator/CorbaProposal
> [2] - http://www.omg.org/cgi-bin/doc?formal/01-12-35
> thanks,
> Adi Sakala
> IONA Technologies Inc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sample plan bits for configId branch, please review!



On Feb 15, 2006, at 2:31 PM, David Jencks wrote:



On Feb 15, 2006, at 2:04 PM, David Blevins wrote:


On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:


On Feb 15, 2006, at 1:23 PM, David Blevins wrote:


So we should call it something like:


...
  

  base-name
  geronimo.maven:J2EEServer=geronimo

  
...


Cause IMHO, having a  element with a   
sub element implies something all together different:


[...]

Also I would prefer to not imply that these properties are  
limited to only "naming-properties".  I gut tells me that this  
will be a useful extension place in the geronimo configurations.


Ok.  I was under the impression via DJ's comments that these were  
only for naming.


On Feb 15, 2006, at 10:59 AM, David Jencks wrote:


Dain:
 I'm not sure about the names of name-keys and name-key.  These  
are really intended for use by the naming system and are rarely  
used, so I prefer to name them that way rather than  
"properties".  What could other properties be used for?  How  
would we distinguish them from the ones for the naming system?


And your comment on using any naming system made me think my  
impression was definitely write.  I guess this isn't one of those  
agreed upon things just yet.


So what is the general idea behind them?  A generic bucket for  
properties that are easily available to all gbeans in my  
configuration?


I originally thought of them as having only to do with the naming  
system, but after Dain suggested "properties" I realized that we  
might think of something else to use them for in the future.  They  
would be available to parts of the deployment infrastructure such  
as the naming system, but not really to any gbeans.


I like this.  Nice, simple, flexible.   It's great to have things  
strongly defined and structured out for what is known, but nice to  
have a bucked for the unknown to exist.  Gives you a nice place too  
look for stuff you may want to deal with better some day.


One other use case I could think of is "hinting" the deployment  
system to maybe user more strict or loose rules, more or less  
validation, more implicit or explicit reference linking.  Just some  
ideas, these aren't features we have yet obviously.



-David

RE: Ode Proposal (Sybase BPEL engine donation))

2006-02-15 Thread Noel J. Bergman

Sanjiva,

> - Given the, um, strong feelings expressed by so many people about this
> project, how about if we get the Incubator PMC to sponsor this poddling?

Agreed.  That is what I said to the Geronimo PMC, as well.  The Incubator
PMC will sponsor the project.

--- Noel

Re: Ode Proposal (Sybase BPEL engine donation))

2006-02-15 Thread Bruce Snyder

On 2/15/06, Greg Stein <[EMAIL PROTECTED]> wrote:

> A number of folks here in the Incubator believe it is best to
> establish a community with no prior ties, and have repeated that on a
> number of occasions (including Sanjiva's and Noel's comments today).
> The general belief is that this will create a better community around
> the ASF's BPEL work.

Greg, I'm trying to understand the statements above. The more I read
them the more it seems that the Incubator PMC can decide what's best
for a proposal at any given time including making decisions about the
oversight. Are there documents about this topic on the Incubator site
that I've missed? I truly want to understand this and I'd appreciate
any further explanation or identification of any documents that
clarifies this issue.

> Part of the problem that I'm seeing is you use of "we" in your
> message. Who is "we"? And that leads to, who is "not we"? Why is there
> a partition? I believe this is one of the primary issues that is being
> dealt with right now, Dain. You are dividing BPEL workers into a "we"
> and "others" camp.
>
> Or, let's just say that was a random term to refer to the Geronimo
> project and you're not really seeing two groups. i.e. not fair of me
> to assign that way of thinking to you. Okay. So moving on: why is it
> important for this to be Geronimo sponsored? Why? Seriously. WTF does
> it matter?
>
> We've already said the IP clearance paperwork is the same no matter
> what. Great. Get that done and start working. When BPEL is ready to
> graduate, then we look at where it goes. Quite possibly Geronimo. But
> what does it matter that Geronimo is the sponsor? Why are you so keyed
> in on that?
>
> I can clearly see benefits with "absence of ties". I don't see the
> benefit of Geronimo sponsoring that you're seeing. And without that
> understanding, then I get to make up crazy reasons :-P

And the statements above aren't helping me understand this any
further. Can you help clarify this for me please?

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)

Castor (http://castor.org/)

Re: Ode Proposal (Sybase BPEL engine donation))

2006-02-15 Thread Greg Stein

[trimmed individuals and pmc's from the cc: list]

On Wed, Feb 15, 2006 at 03:22:23PM -0800, Dain Sundstrom wrote:
> On Feb 15, 2006, at 3:09 PM, Noel J. Bergman wrote:
> >Sanjiva,
> >
> >>- Given the, um, strong feelings expressed by so many people about  
> >>this project, how about if we get the Incubator PMC to sponsor this  
> >>poddling?
> >
> >Agreed.  That is what I said to the Geronimo PMC, as well.  The  
> >Incubator PMC will sponsor the project.
>...
> I know it doesn't mean much, but I personally would like to see this  
> as a Geronimo sponsored project.  We are the ones that have taken the  
> licks over this for the past 2 weeks and would really like to work to  
> carry this through the full process.
> 
> So to flip things around on you...
> 
>   There is no need for the Incubator PMC to sponsor.  The Geronimo  
> PMC will sponsor the project.
> 
> Thanks for your understanding.

A number of folks here in the Incubator believe it is best to
establish a community with no prior ties, and have repeated that on a
number of occasions (including Sanjiva's and Noel's comments today).
The general belief is that this will create a better community around
the ASF's BPEL work.

Part of the problem that I'm seeing is you use of "we" in your
message. Who is "we"? And that leads to, who is "not we"? Why is there
a partition? I believe this is one of the primary issues that is being
dealt with right now, Dain. You are dividing BPEL workers into a "we"
and "others" camp.

Or, let's just say that was a random term to refer to the Geronimo
project and you're not really seeing two groups. i.e. not fair of me
to assign that way of thinking to you. Okay. So moving on: why is it
important for this to be Geronimo sponsored? Why? Seriously. WTF does
it matter?

We've already said the IP clearance paperwork is the same no matter
what. Great. Get that done and start working. When BPEL is ready to
graduate, then we look at where it goes. Quite possibly Geronimo. But
what does it matter that Geronimo is the sponsor? Why are you so keyed
in on that?

I can clearly see benefits with "absence of ties". I don't see the
benefit of Geronimo sponsoring that you're seeing. And without that
understanding, then I get to make up crazy reasons :-P

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

[jira] Commented: (GERONIMO-1631) NoSuchConfigException when restarting app after undeploying

2006-02-15 Thread Sachin Patel (JIRA)

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

Sachin Patel commented on GERONIMO-1631:


This can be reproduced with the modules on 
http://people.apache.org/~sppatel/temp/

(1) Install TestEJB
(2) Install TestWar (which contains an import to TestEJB)
(3) Uninstall TestEJB
(4) Restart
(5) NoSuchConfig on TestEJB

> NoSuchConfigException when restarting app after undeploying
> ---
>
>  Key: GERONIMO-1631
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1631
>  Project: Geronimo
> Type: Bug
>   Components: deployment
> Versions: 1.0
> Reporter: Sachin Patel
>  Fix For: 1.1

>
> If I have config A that imports config B.  If undeploy is invoked on B... 
> then...
> Module B/B unloaded.
> Module B/B uninstalled.
> Undeployed B/B
> So module B is not being stopped, thus resulting in a NoSuchConfigException 
> on B when the server is restarted.
> If A is undeployed before B, then all is ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sample plan bits for configId branch, please review!



On Feb 15, 2006, at 3:07 PM, John Sisson wrote:


David Jencks wrote:


On Feb 15, 2006, at 2:04 PM, David Blevins wrote:


On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:


On Feb 15, 2006, at 1:23 PM, David Blevins wrote:


So we should call it something like:


...
  

  base-name
  geronimo.maven:J2EEServer=geronimo

  
...


Cause IMHO, having a  element with a  
 sub element implies something all together different:


[...]

Also I would prefer to not imply that these properties are  
limited to only "naming-properties".  I gut tells me that this  
will be a useful extension place in the geronimo configurations.


Ok.  I was under the impression via DJ's comments that these were  
only for naming.


On Feb 15, 2006, at 10:59 AM, David Jencks wrote:


Dain:
 I'm not sure about the names of name-keys and name-key.  These  
are really intended for use by the naming system and are rarely  
used, so I prefer to name them that way rather than  
"properties".  What could other properties be used for?  How  
would we distinguish them from the ones for the naming system?


And your comment on using any naming system made me think my  
impression was definitely write.  I guess this isn't one of those  
agreed upon things just yet.


So what is the general idea behind them?  A generic bucket for  
properties that are easily available to all gbeans in my  
configuration?


I originally thought of them as having only to do with the naming  
system, but after Dain suggested "properties" I realized that we  
might think of something else to use them for in the future.  They  
would be available to parts of the deployment infrastructure such  
as the naming system, but not really to any gbeans.
I am wondering whether having both naming properties and other  
properties under the one  element may make it difficult  
for any tools (e.g. a GUI/web based tool that can read/build plans)  
to identify and display the naming properties when reading the  
plans without hard coded knowledge of the property names used for  
naming.


I think we are going off the deep end here :-).  Currently the only  
use anyone has thought of for this is to supply the domain and server  
name components of gbeans in configurations with no parent such as  
j2ee-system.  I don't think anyone who has the knowledge to set one  
of these configurations up will have any problems doing it in say  
pico rather than a gui tool :-).  Really, if you are setting one of  
these up, you are setting up an entirely different kind of geronimo  
server, not just a minor reassembly such as going from j2ee-tomcat to  
minimal-tomcat.


thanks
david jencks



John


thanks
david jencks



-David

Re: Sample plan bits for configId branch, please review!

2006-02-15 Thread John Sisson


Dain Sundstrom wrote:

On Feb 15, 2006, at 10:59 AM, David Jencks wrote:



  
base-name
geronimo.maven:J2EEServer=geronimo
  



I like this but I think the name should be name spaces to avoid 
conflict.  Also we are the only ones that will touch this property so 
if it is long it doesn't matter.  How about 
org.apache.geronimo.j2ee.BaseName?
I agree we should be using name spaces.  If we think there may be other 
naming systems in the future, would it be worth having a prefix before 
the j2ee part of the name space to make it easier to find all uses (e.g. 
using grep or an IDE search function) of geronimo's naming properties 
regardless of the naming system used?  E.G:


org.apache.geronimo.name.j2ee.BaseName
org.apache.geronimo.name.fooNamingSystem.BaseName

'name' may not be the best choice in the example.. I chose it because 
'org.apache.geronimo.naming' is already used as a package name.


John


On Feb 15, 2006, at 10:59 AM, David Jencks wrote:

  < dependency>
geronimo
geronimo-deployment
1.0.1-SNAPSHOT

  


For those that are not aware, include means to literally include the 
contents of the dependency jar into the car created by the 
configuration.  This makes it easy to create stand alone self 
executing configurations.  I suggest we move this feature to the 
deploy tool using an optional flag and leave it out of this xml file.


On Feb 15, 2006, at 12:51 PM, Matt Hogstrom wrote:
I'd prefer to make the version and type as optional.  Version would 
default to some server default.  Also, type can default to *car*.


I think type "jar" will be the most common.  My guess is a component 
will have 0-2 parents most of the time, but lots of jars.



  
geronimo
geronimo-common
1.0.1-SNAPSHOT
class


I'd prefer multiple  tags like

classes
services


Since "include" has an existing meaning in Geronimo service plans, I 
suggest that we name this element "import" to avoid any possible 
confusion.



or the ever popular

*


We are only talking about 2 items which isn't a big deal.  Also David 
mentioned somewhere that the default in the absence to any "load" 
(name David is using) tags it to do both classes and services.


-dain

Re: Ode Proposal (Sybase BPEL engine donation))


On Feb 15, 2006, at 3:09 PM, Noel J. Bergman wrote:


Sanjiva,

- Given the, um, strong feelings expressed by so many people about  
this
project, how about if we get the Incubator PMC to sponsor this  
poddling?


Agreed.  That is what I said to the Geronimo PMC, as well.  The  
Incubator

PMC will sponsor the project.


Since you brought this public, I'll post my response along with you  
original email.  I hope you don't mind...



On Feb 15, 2006, at 1:25 PM, Noel J. Bergman wrote:


No need for this vote.  The Incubator PMC will sponsor the project.

--- Noel



I know it doesn't mean much, but I personally would like to see this  
as a Geronimo sponsored project.  We are the ones that have taken the  
licks over this for the past 2 weeks and would really like to work to  
carry this through the full process.


So to flip things around on you...

  There is no need for the Incubator PMC to sponsor.  The Geronimo  
PMC will sponsor the project.


Thanks for your understanding.

-dain

[jira] Created: (GERONIMO-1631) NoSuchConfigException when restarting app after undeploying

2006-02-15 Thread Sachin Patel (JIRA)

NoSuchConfigException when restarting app after undeploying
---

 Key: GERONIMO-1631
 URL: http://issues.apache.org/jira/browse/GERONIMO-1631
 Project: Geronimo
Type: Bug
  Components: deployment  
Versions: 1.0
Reporter: Sachin Patel
 Fix For: 1.1


If I have config A that imports config B.  If undeploy is invoked on B... 
then...

Module B/B unloaded.
Module B/B uninstalled.
Undeployed B/B

So module B is not being stopped, thus resulting in a NoSuchConfigException on 
B when the server is restarted.

If A is undeployed before B, then all is ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sample plan bits for configId branch, please review!

2006-02-15 Thread John Sisson


David Jencks wrote:


On Feb 15, 2006, at 2:04 PM, David Blevins wrote:


On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:


On Feb 15, 2006, at 1:23 PM, David Blevins wrote:


So we should call it something like:


...
  

  base-name
  geronimo.maven:J2EEServer=geronimo

  
...


Cause IMHO, having a  element with a  
sub element implies something all together different:


[...]

Also I would prefer to not imply that these properties are limited 
to only "naming-properties".  I gut tells me that this will be a 
useful extension place in the geronimo configurations.


Ok.  I was under the impression via DJ's comments that these were 
only for naming.


On Feb 15, 2006, at 10:59 AM, David Jencks wrote:


Dain:
 I'm not sure about the names of name-keys and name-key.  These are 
really intended for use by the naming system and are rarely used, so 
I prefer to name them that way rather than "properties".  What could 
other properties be used for?  How would we distinguish them from 
the ones for the naming system?


And your comment on using any naming system made me think my 
impression was definitely write.  I guess this isn't one of those 
agreed upon things just yet.


So what is the general idea behind them?  A generic bucket for 
properties that are easily available to all gbeans in my configuration?


I originally thought of them as having only to do with the naming 
system, but after Dain suggested "properties" I realized that we might 
think of something else to use them for in the future.  They would be 
available to parts of the deployment infrastructure such as the naming 
system, but not really to any gbeans.
I am wondering whether having both naming properties and other 
properties under the one  element may make it difficult for 
any tools (e.g. a GUI/web based tool that can read/build plans) to 
identify and display the naming properties when reading the plans 
without hard coded knowledge of the property names used for naming.


John


thanks
david jencks



-David

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

2006-02-15 Thread Lance Waterman

In the spirit of nailing down criteria, I would agree with; > ... avoid the BPEL> engine having to write a container, a deployment model and a suite of> 'binding components' to different SOAP stacks, WS-* policies and
> transports - together with all the runtime management.With regard to "runtime management" I am thinking transactions, resource allocation, etc ... but not BPEL process instance management.
LanceOn 2/15/06, James Strachan <[EMAIL PROTECTED]
> wrote:On 14 Feb 2006, at 21:38, Matthieu Riou wrote:>> Also, I don't at all agree with your comparison of a BPEL Engine to
>> Geronimo.  I would compare it to the transaction manager within>> Geronimo.  It's a discrete component, and we're not going to take the>> best of 20 different projects to make a transaction manager, and I
>> don't see why we'd do the same to make a BPEL Engine.>> I've been trying to stay out of the discussion so far because I'm> obviously partial (as a contributor on Agila BPEL), however I've seen
> this opinion voiced many time on these threads and can't ignore it> anymore. Aaron it's not against you at all :)>> I've worked enough on BPEL implementing it to say, really strongly,> that BPEL is very far from being a discrete component. You can see it
> as something "behind the scene" when you're working on a JBI> container, however when you're interested in having an orchestration> layer, you really don't. I don't think Oracle, IBM and many other
> editors would be so successful in selling their product if it was so> discrete.>> You really don't need a JBI container if you're only dealing with web> services interfaces.Sure but it really helps. The JBI container does much of the heavy
lifting, letting the BPEL engine focus on its core feature -correlation & orchestration and not worrying about all the otherstuff as well.> Actually my view on this was that an ESB is just

> a communication bus around an orchestration layer. Quite the reverse> opinion, isn't it? And I can't see any JBI implementation dealing with> the BPEL grammar. Is the JBI implementation going to deal with
> compensation, correlation and partner links? I don't think so.Agreed. But similarly - should a BPEL engine deal with differentintegration components, different SOAP stacks, different WS-*policies, monitoring, management, using HTTP or JMS or Jabber or file
systems, deployment, versioning, runtime management & monitoring ofeach flow? The J2EE analogy is quite good; BPEL is a discrete servicebut can reuse the container environment of JBI to avoid the BPEL
engine having to write a container, a deployment model and a suite of
'binding components' to different SOAP stacks, WS-* policies andtransports - together with all the runtime management.BPEL engines and orchestration services were one of the primarydrivers of JSR 208 (JBI)
> What> about editing BPEL process descriptions? And eventually, is the JBI> implementation going to provide BAM interfaces?Yes - BAM hooks at least.

http://incubator.apache.org/servicemix/Publish+Subscribe+RoutingJames---http://radio.weblogs.com/0112098/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: 
[EMAIL PROTECTED]

Re: Jira Changes

2006-02-15 Thread Andrew McIntyre

On Feb 11, 2006, at 7:17 AM, Alan D. Cabrera wrote:On 1/25/2006 9:31 PM, Alan D. Cabrera wrote:  I want to add a field that marks bugs w/ a regression flag so that we can track tests that used to pass.  Currently people just exclude the tests or, worse, comment them out in the code.   So, it seems that the consensus is that it's a good idea to have this flag.  How do we get this added to our project?  I know how to do it for Jira but lack the admin karma to do so. Hi Alan,I added a "Regression" checkbox next to the Patch Available checkbox. Check it out, and if it's acceptable, please comment as so on INFRA-721.Cheers,Andrew

[jira] Updated: (GERONIMO-1630) IONA's Initial Yoko Contribution

2006-02-15 Thread Adi Sakala (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1630?page=all ]

Adi Sakala updated GERONIMO-1630:
-

Attachment: Yoko_ob.zip

second try...

> IONA's Initial Yoko Contribution
> 
>
>  Key: GERONIMO-1630
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1630
>  Project: Geronimo
> Type: New Feature
>   Components: CORBA
> Versions: 1.1
> Reporter: Adi Sakala
> Assignee: Alan Cabrera
>  Attachments: Yoko_ob.zip, Yoko_ob.zip.MD5
>
> As per the accepted CORBA Proposal [1], IONA Technologies would like to 
> donate a full CORBA implementation to Geronimo Yoko sub project.
> The contribution includes full CORBA ORB and IIOP transport from IONA 
> Technologies. The contribution is delivered using the package named 
> Yoko_ob.zip (attached to this message) with following MD5 Checksum  
> (41fd6b5857c5366cf0e28e852839ad84).
> This implementation claims full support for ORB and IIOP transport as per 
> CORBA 2.6 specification [2].
> Following this I expect community to take and perform required next steps in 
> making a world-class vendor neutral CORBA System available via Apache and 
> delivering a successful project out of CORBA Proposal [1] and corba binding 
> via Celtix to Geronimo providing at least support for IIOP & RMI.
> [1] - http://wiki.apache.org/incubator/CorbaProposal
> [2] - http://www.omg.org/cgi-bin/doc?formal/01-12-35
> thanks,
> Adi Sakala
> IONA Technologies Inc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1630) IONA's Initial Yoko Contribution

 [ http://issues.apache.org/jira/browse/GERONIMO-1630?page=all ]

Alan Cabrera updated GERONIMO-1630:
---

Attachment: (was: Yoko_ob.zip)

> IONA's Initial Yoko Contribution
> 
>
>  Key: GERONIMO-1630
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1630
>  Project: Geronimo
> Type: New Feature
>   Components: CORBA
> Versions: 1.1
> Reporter: Adi Sakala
> Assignee: Alan Cabrera
>  Attachments: Yoko_ob.zip.MD5
>
> As per the accepted CORBA Proposal [1], IONA Technologies would like to 
> donate a full CORBA implementation to Geronimo Yoko sub project.
> The contribution includes full CORBA ORB and IIOP transport from IONA 
> Technologies. The contribution is delivered using the package named 
> Yoko_ob.zip (attached to this message) with following MD5 Checksum  
> (41fd6b5857c5366cf0e28e852839ad84).
> This implementation claims full support for ORB and IIOP transport as per 
> CORBA 2.6 specification [2].
> Following this I expect community to take and perform required next steps in 
> making a world-class vendor neutral CORBA System available via Apache and 
> delivering a successful project out of CORBA Proposal [1] and corba binding 
> via Celtix to Geronimo providing at least support for IIOP & RMI.
> [1] - http://wiki.apache.org/incubator/CorbaProposal
> [2] - http://www.omg.org/cgi-bin/doc?formal/01-12-35
> thanks,
> Adi Sakala
> IONA Technologies Inc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1630) IONA's Initial Yoko Contribution

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

Alan Cabrera commented on GERONIMO-1630:


It seems that the ZIP was not completely uploaded.  I have removed it.  Can you 
try uploading it again?

> IONA's Initial Yoko Contribution
> 
>
>  Key: GERONIMO-1630
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1630
>  Project: Geronimo
> Type: New Feature
>   Components: CORBA
> Versions: 1.1
> Reporter: Adi Sakala
> Assignee: Alan Cabrera
>  Attachments: Yoko_ob.zip, Yoko_ob.zip.MD5
>
> As per the accepted CORBA Proposal [1], IONA Technologies would like to 
> donate a full CORBA implementation to Geronimo Yoko sub project.
> The contribution includes full CORBA ORB and IIOP transport from IONA 
> Technologies. The contribution is delivered using the package named 
> Yoko_ob.zip (attached to this message) with following MD5 Checksum  
> (41fd6b5857c5366cf0e28e852839ad84).
> This implementation claims full support for ORB and IIOP transport as per 
> CORBA 2.6 specification [2].
> Following this I expect community to take and perform required next steps in 
> making a world-class vendor neutral CORBA System available via Apache and 
> delivering a successful project out of CORBA Proposal [1] and corba binding 
> via Celtix to Geronimo providing at least support for IIOP & RMI.
> [1] - http://wiki.apache.org/incubator/CorbaProposal
> [2] - http://www.omg.org/cgi-bin/doc?formal/01-12-35
> thanks,
> Adi Sakala
> IONA Technologies Inc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Migrating to maven 2 - conversion idea

2006-02-15 Thread Alan D. Cabrera


David Blevins wrote, On 2/14/2006 5:29 PM:


On Feb 14, 2006, at 5:01 PM, Dain Sundstrom wrote:


On Feb 14, 2006, at 4:30 PM, David Blevins wrote:



On Feb 14, 2006, at 4:06 PM, Dain Sundstrom wrote:

Is there an easy way to do this with m1?  I'm concerned about  
having two dependency lists: one in the project.xml and one in  the 
pom.xml.  Is there a tool that can merge the project.xml  
dependencies into a template pom.xml?



If there was a tool we'd probably go from pom.xml to project.xml  for 
transitive deps reasons rather than the other way around.


But really, I wouldn't worry about having two deps lists.  Here is  
an idea for keeping things working ...


Why don't we:
  - use an non-conflicting groupId like org.apache.geronimo-m2 or  
something specifically for conversion

  - set it up in our continuum install as another project
  - and continuously build *both*

?

The reason for the new groupId is so that the m2 build doesn't  
interfere at all with our regular m1 build.  We just won't sycn  
org.apache.geronimo-m2.


When our m2 build is read, we just drop the "-m2" suffix from the  
groupId and delete the old maven.xml and project.xml files.


Thoughts?



Take my comments with a large dose of salt since, I'm not  
volunteering to do the work  I would like to see a module  
completely converted to m2 (one at a time) and stay converted.



I think the continuum aspect would be the thing to ensure something  
stays converted.  We could even do one at a time too, just that most  
people (and the release process) would continue to rely on m1 till m2  
conversion is completely done.


  I get the impression that people are proposing that we create  
parallel builds for modules one at a time, and I just don't see  that 
working.



Both the OpenEJB and ActiveMQ builds were done as parallel builds.   
I've got ActiveMQ up in continuum building as an M2 projects, so we  
know it stays good. Obviously, the OpenEJB build was done way before  we 
had continuum and it got crufty.


ActiveMQ still does releases from m1 as they still don't have all  their 
tests converted over.  Other than that their m2 build works.


But I'm in the same boat as you, I don't have the bandwidth to work  on 
it aside from helping people get it running in continuum.


I feel the same way as Dain but I am willing to back it up w/ warm 
bodies to help.  Continuum will not help, imho.  It will only remind us 
how badly the two versions are drifting.



Regards,
Alan

[jira] Commented: (GERONIMO-1630) IONA's Initial Yoko Contribution

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

Alan Cabrera commented on GERONIMO-1630:


Will look for the Software Grant that was faxed to Apache.  This will go 
directly into the incubator SVN; this needs to be created.

> IONA's Initial Yoko Contribution
> 
>
>  Key: GERONIMO-1630
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1630
>  Project: Geronimo
> Type: New Feature
>   Components: CORBA
> Versions: 1.1
> Reporter: Adi Sakala
> Assignee: Alan Cabrera
>  Attachments: Yoko_ob.zip, Yoko_ob.zip.MD5
>
> As per the accepted CORBA Proposal [1], IONA Technologies would like to 
> donate a full CORBA implementation to Geronimo Yoko sub project.
> The contribution includes full CORBA ORB and IIOP transport from IONA 
> Technologies. The contribution is delivered using the package named 
> Yoko_ob.zip (attached to this message) with following MD5 Checksum  
> (41fd6b5857c5366cf0e28e852839ad84).
> This implementation claims full support for ORB and IIOP transport as per 
> CORBA 2.6 specification [2].
> Following this I expect community to take and perform required next steps in 
> making a world-class vendor neutral CORBA System available via Apache and 
> delivering a successful project out of CORBA Proposal [1] and corba binding 
> via Celtix to Geronimo providing at least support for IIOP & RMI.
> [1] - http://wiki.apache.org/incubator/CorbaProposal
> [2] - http://www.omg.org/cgi-bin/doc?formal/01-12-35
> thanks,
> Adi Sakala
> IONA Technologies Inc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (GERONIMO-1630) IONA's Initial Yoko Contribution

 [ http://issues.apache.org/jira/browse/GERONIMO-1630?page=all ]

Alan Cabrera reassigned GERONIMO-1630:
--

Assign To: Alan Cabrera

> IONA's Initial Yoko Contribution
> 
>
>  Key: GERONIMO-1630
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1630
>  Project: Geronimo
> Type: New Feature
>   Components: CORBA
> Versions: 1.1
> Reporter: Adi Sakala
> Assignee: Alan Cabrera
>  Attachments: Yoko_ob.zip, Yoko_ob.zip.MD5
>
> As per the accepted CORBA Proposal [1], IONA Technologies would like to 
> donate a full CORBA implementation to Geronimo Yoko sub project.
> The contribution includes full CORBA ORB and IIOP transport from IONA 
> Technologies. The contribution is delivered using the package named 
> Yoko_ob.zip (attached to this message) with following MD5 Checksum  
> (41fd6b5857c5366cf0e28e852839ad84).
> This implementation claims full support for ORB and IIOP transport as per 
> CORBA 2.6 specification [2].
> Following this I expect community to take and perform required next steps in 
> making a world-class vendor neutral CORBA System available via Apache and 
> delivering a successful project out of CORBA Proposal [1] and corba binding 
> via Celtix to Geronimo providing at least support for IIOP & RMI.
> [1] - http://wiki.apache.org/incubator/CorbaProposal
> [2] - http://www.omg.org/cgi-bin/doc?formal/01-12-35
> thanks,
> Adi Sakala
> IONA Technologies Inc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sample plan bits for configId branch, please review!



On Feb 15, 2006, at 2:04 PM, David Blevins wrote:


On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:


On Feb 15, 2006, at 1:23 PM, David Blevins wrote:


So we should call it something like:


...
  

  base-name
  geronimo.maven:J2EEServer=geronimo

  
...


Cause IMHO, having a  element with a   
sub element implies something all together different:


[...]

Also I would prefer to not imply that these properties are limited  
to only "naming-properties".  I gut tells me that this will be a  
useful extension place in the geronimo configurations.


Ok.  I was under the impression via DJ's comments that these were  
only for naming.


On Feb 15, 2006, at 10:59 AM, David Jencks wrote:


Dain:
 I'm not sure about the names of name-keys and name-key.  These  
are really intended for use by the naming system and are rarely  
used, so I prefer to name them that way rather than "properties".   
What could other properties be used for?  How would we distinguish  
them from the ones for the naming system?


And your comment on using any naming system made me think my  
impression was definitely write.  I guess this isn't one of those  
agreed upon things just yet.


So what is the general idea behind them?  A generic bucket for  
properties that are easily available to all gbeans in my  
configuration?


I originally thought of them as having only to do with the naming  
system, but after Dain suggested "properties" I realized that we  
might think of something else to use them for in the future.  They  
would be available to parts of the deployment infrastructure such as  
the naming system, but not really to any gbeans.


thanks
david jencks



-David

Re: Sample plan bits for configId branch, please review!


On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:


On Feb 15, 2006, at 1:23 PM, David Blevins wrote:


So we should call it something like:


...
  

  base-name
  geronimo.maven:J2EEServer=geronimo

  
...


Cause IMHO, having a  element with a   
sub element implies something all together different:


[...]

Also I would prefer to not imply that these properties are limited  
to only "naming-properties".  I gut tells me that this will be a  
useful extension place in the geronimo configurations.


Ok.  I was under the impression via DJ's comments that these were  
only for naming.


On Feb 15, 2006, at 10:59 AM, David Jencks wrote:


Dain:
 I'm not sure about the names of name-keys and name-key.  These are  
really intended for use by the naming system and are rarely used,  
so I prefer to name them that way rather than "properties".  What  
could other properties be used for?  How would we distinguish them  
from the ones for the naming system?


And your comment on using any naming system made me think my  
impression was definitely write.  I guess this isn't one of those  
agreed upon things just yet.


So what is the general idea behind them?  A generic bucket for  
properties that are easily available to all gbeans in my configuration?


-David

[jira] Updated: (GERONIMO-1630) IONA's Initial Yoko Contribution

2006-02-15 Thread Adi Sakala (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1630?page=all ]

Adi Sakala updated GERONIMO-1630:
-

Attachment: Yoko_ob.zip
Yoko_ob.zip.MD5

Attaching Contribution Package.

> IONA's Initial Yoko Contribution
> 
>
>  Key: GERONIMO-1630
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1630
>  Project: Geronimo
> Type: New Feature
>   Components: CORBA
> Versions: 1.1
> Reporter: Adi Sakala
>  Attachments: Yoko_ob.zip, Yoko_ob.zip.MD5
>
> As per the accepted CORBA Proposal [1], IONA Technologies would like to 
> donate a full CORBA implementation to Geronimo Yoko sub project.
> The contribution includes full CORBA ORB and IIOP transport from IONA 
> Technologies. The contribution is delivered using the package named 
> Yoko_ob.zip (attached to this message) with following MD5 Checksum  
> (41fd6b5857c5366cf0e28e852839ad84).
> This implementation claims full support for ORB and IIOP transport as per 
> CORBA 2.6 specification [2].
> Following this I expect community to take and perform required next steps in 
> making a world-class vendor neutral CORBA System available via Apache and 
> delivering a successful project out of CORBA Proposal [1] and corba binding 
> via Celtix to Geronimo providing at least support for IIOP & RMI.
> [1] - http://wiki.apache.org/incubator/CorbaProposal
> [2] - http://www.omg.org/cgi-bin/doc?formal/01-12-35
> thanks,
> Adi Sakala
> IONA Technologies Inc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1630) IONA's Initial Yoko Contribution

2006-02-15 Thread Adi Sakala (JIRA)

IONA's Initial Yoko Contribution


 Key: GERONIMO-1630
 URL: http://issues.apache.org/jira/browse/GERONIMO-1630
 Project: Geronimo
Type: New Feature
  Components: CORBA  
Versions: 1.1
Reporter: Adi Sakala


As per the accepted CORBA Proposal [1], IONA Technologies would like to donate 
a full CORBA implementation to Geronimo Yoko sub project.

The contribution includes full CORBA ORB and IIOP transport from IONA 
Technologies. The contribution is delivered using the package named Yoko_ob.zip 
(attached to this message) with following MD5 Checksum  
(41fd6b5857c5366cf0e28e852839ad84).

This implementation claims full support for ORB and IIOP transport as per CORBA 
2.6 specification [2].

Following this I expect community to take and perform required next steps in 
making a world-class vendor neutral CORBA System available via Apache and 
delivering a successful project out of CORBA Proposal [1] and corba binding via 
Celtix to Geronimo providing at least support for IIOP & RMI.

[1] - http://wiki.apache.org/incubator/CorbaProposal
[2] - http://www.omg.org/cgi-bin/doc?formal/01-12-35

thanks,
Adi Sakala
IONA Technologies Inc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sample plan bits for configId branch, please review!


On Feb 15, 2006, at 1:23 PM, David Blevins wrote:


So we should call it something like:


...
  

  base-name
  geronimo.maven:J2EEServer=geronimo

  
...


Cause IMHO, having a  element with a   
sub element implies something all together different:



...
  

  base-name
  geronimo.maven:J2EEServer=geronimo

  
...



The xml is more like this:

http://geronimo.apache.org/xml/ns/deployment-1.1";>
  

  geronimo
  car
  geronimo-gbean-deployer
  1.0.1-SNAPSHOT


  
base-name
geronimo.maven:J2EEServer=geronimo
  

  



I think it is fairly clear that these are properties of the  
environment.  Also I would prefer to not imply that these properties  
are limited to only "naming-properties".  I gut tells me that this  
will be a useful extension place in the geronimo configurations.


-dain

Re: Sample plan bits for configId branch, please review!


On Feb 15, 2006, at 10:59 AM, David Jencks wrote:



  
base-name
geronimo.maven:J2EEServer=geronimo
  



I like this but I think the name should be name spaces to avoid  
conflict.  Also we are the only ones that will touch this property so  
if it is long it doesn't matter.  How about  
org.apache.geronimo.j2ee.BaseName?


On Feb 15, 2006, at 10:59 AM, David Jencks wrote:

  < dependency>
geronimo
geronimo-deployment
1.0.1-SNAPSHOT

  


For those that are not aware, include means to literally include the  
contents of the dependency jar into the car created by the  
configuration.  This makes it easy to create stand alone self  
executing configurations.  I suggest we move this feature to the  
deploy tool using an optional flag and leave it out of this xml file.


On Feb 15, 2006, at 12:51 PM, Matt Hogstrom wrote:
I'd prefer to make the version and type as optional.  Version would  
default to some server default.  Also, type can default to *car*.


I think type "jar" will be the most common.  My guess is a component  
will have 0-2 parents most of the time, but lots of jars.



  
geronimo
geronimo-common
1.0.1-SNAPSHOT
class


I'd prefer multiple  tags like

classes
services


Since "include" has an existing meaning in Geronimo service plans, I  
suggest that we name this element "import" to avoid any possible  
confusion.



or the ever popular

*


We are only talking about 2 items which isn't a big deal.  Also David  
mentioned somewhere that the default in the absence to any  
"load" (name David is using) tags it to do both classes and services.


-dain

Re: Sample plan bits for configId branch, please review!


So we should call it something like:


...
  

  base-name
  geronimo.maven:J2EEServer=geronimo

  
...


Cause IMHO, having a  element with a  sub  
element implies something all together different:



...
  

  base-name
  geronimo.maven:J2EEServer=geronimo

  
...



-David



On Feb 15, 2006, at 12:51 PM, Matt Hogstrom wrote:




Dain Sundstrom wrote:
I prefer to have them a properties, and then we can support  
multiple  naming systems and use them for future extension.




I like properties as well.


-dain
On Feb 15, 2006, at 12:17 PM, David Blevins wrote:
This is also awkward and not quite right.  But throwing it out   
there hoping someone can think of something better



   
  base-name
  geronimo.maven:J2EEServer=geronimo
   


-David

On Feb 15, 2006, at 10:59 AM, David Jencks wrote:

Here's a new version to  look at incorporating some feedback.
General comments are at the end, followed by some specific   
responses.  It looks like most people liked the second example  
so  I have only worked on it.


http://geronimo.apache.org/xml/ns/  
deployment-1.1">

  

  geronimo
  car
  geronimo-gbean-deployer
  1.0.1-SNAPSHOT


  
base-name
geronimo.maven:J2EEServer=geronimo
  




I'd prefer to make the version and type as optional.  Version would  
default to some server default.  Also, type can default to *car*.  
My preference for order would be groupId, artifactId, version and  
type.  If its going to break compatbility with Maven then leave  
it.  However, I'm also not in favor of letting the underlying  
technology bleed through and make the user experience more  
complicated than it needs to be.



  < dependency>
geronimo
car
geronimo-system
1.0.1-SNAPSHOT
  
  
geronimo
geronimo-common
1.0.1-SNAPSHOT
class


I'd prefer multiple  tags like

classes
services

or the ever popular

*


  
  < dependency>
geronimo
geronimo-deployment
1.0.1-SNAPSHOT

  
  < dependency>
geronimo
car
geronimo-j2ee
1.0.1-SNAPSHOT
service
  




org.apache.commons.logging



Ooh...looks OSGi like above :)



java

  
  
  class="org.apache.geronimo.deployment.Deployer">


The previous examples omitted the inverse-classloading,  
suppress- default-environment, and class filter elements.  They   
are  included here.


"scope" has been renamed "load".  A particular artifact can  
have  only classes (e.g. jar) or both classes and services  
(car)  associated with it.  The default would be to use  
everything  available, so we only need restrictive elements for  
the car files,  classes and services.  I've put include as a  
separate element.


There may be some other items that could be loaded like resource  
bundles or something that we haven't thought of.  I think we should  
allow for exansion in the future.




I've added enclosing elements for the properties and dependencies.

I've taken Bruce's idea of a single name string that can be  
parsed  by the naming system.  I think that this further reduces  
our  dependency on the naming system chosen, but I am open to  
arguments  the other way :-)


As Dain noted with the original, at least the version will   
normally be optional.



Dain:
 I'm not sure about the names of name-keys and name-key.  These   
are really intended for use by the naming system and are rarely   
used, so I prefer to name them that way rather than  
"properties".   What could other properties be used for?  How  
would we distinguish  them from the ones for the naming system?


Aaron:
I am very reluctant to have a format with so much overlap with  
the  m2 dependency without using the same element names.  This  
way you  can copy an m2 dependency out of your pom and add the  
load tag if  necessary.  I think changing the element names is  
going to cause  too much confusion.  I agree that the xml should  
clearly express  our function and purpose the problem is  
figuring out what  does  that best.  I liked the classloader  
element and separately  named dependency-structure elements  
since I thought it showed the  purpose more blatantly.  I worry  
a bit that this structure will  not make it very clear that car  
dependencies with services are not going on the  
classpath.


Paul:
I don't quite understand your example.  While configId has the   
same xml structure as a dependency, it is the name of the  
current  configuration, not a reference to something outside the  
current  configuration.  Do the load/include elements in this  
example work  for you in place of the ambiguous scope in the  
previous example?



Thanks everyone and please keep commenting!
david jencks


On Feb 15, 2006, at 9:45 AM, Aaron Mulder wrote:


On 2/15/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

Re: Sample plan bits for configId branch, please review!

2006-02-15 Thread Sachin Patel

I would also prefer having as many optional elements as possible in  
configID.


- sachin



On Feb 15, 2006, at 3:51 PM, Matt Hogstrom wrote:




Dain Sundstrom wrote:
I prefer to have them a properties, and then we can support  
multiple  naming systems and use them for future extension.




I like properties as well.


-dain
On Feb 15, 2006, at 12:17 PM, David Blevins wrote:
This is also awkward and not quite right.  But throwing it out   
there hoping someone can think of something better



   
  base-name
  geronimo.maven:J2EEServer=geronimo
   


-David

On Feb 15, 2006, at 10:59 AM, David Jencks wrote:

Here's a new version to  look at incorporating some feedback.
General comments are at the end, followed by some specific   
responses.  It looks like most people liked the second example  
so  I have only worked on it.


http://geronimo.apache.org/xml/ns/  
deployment-1.1">

  

  geronimo
  car
  geronimo-gbean-deployer
  1.0.1-SNAPSHOT


  
base-name
geronimo.maven:J2EEServer=geronimo
  




I'd prefer to make the version and type as optional.  Version would  
default to some server default.  Also, type can default to *car*.  
My preference for order would be groupId, artifactId, version and  
type.  If its going to break compatbility with Maven then leave  
it.  However, I'm also not in favor of letting the underlying  
technology bleed through and make the user experience more  
complicated than it needs to be.



  < dependency>
geronimo
car
geronimo-system
1.0.1-SNAPSHOT
  
  
geronimo
geronimo-common
1.0.1-SNAPSHOT
class


I'd prefer multiple  tags like

classes
services

or the ever popular

*


  
  < dependency>
geronimo
geronimo-deployment
1.0.1-SNAPSHOT

  
  < dependency>
geronimo
car
geronimo-j2ee
1.0.1-SNAPSHOT
service
  




org.apache.commons.logging



Ooh...looks OSGi like above :)



java

  
  
  class="org.apache.geronimo.deployment.Deployer">


The previous examples omitted the inverse-classloading,  
suppress- default-environment, and class filter elements.  They   
are  included here.


"scope" has been renamed "load".  A particular artifact can  
have  only classes (e.g. jar) or both classes and services  
(car)  associated with it.  The default would be to use  
everything  available, so we only need restrictive elements for  
the car files,  classes and services.  I've put include as a  
separate element.


There may be some other items that could be loaded like resource  
bundles or something that we haven't thought of.  I think we should  
allow for exansion in the future.




I've added enclosing elements for the properties and dependencies.

I've taken Bruce's idea of a single name string that can be  
parsed  by the naming system.  I think that this further reduces  
our  dependency on the naming system chosen, but I am open to  
arguments  the other way :-)


As Dain noted with the original, at least the version will   
normally be optional.



Dain:
 I'm not sure about the names of name-keys and name-key.  These   
are really intended for use by the naming system and are rarely   
used, so I prefer to name them that way rather than  
"properties".   What could other properties be used for?  How  
would we distinguish  them from the ones for the naming system?


Aaron:
I am very reluctant to have a format with so much overlap with  
the  m2 dependency without using the same element names.  This  
way you  can copy an m2 dependency out of your pom and add the  
load tag if  necessary.  I think changing the element names is  
going to cause  too much confusion.  I agree that the xml should  
clearly express  our function and purpose the problem is  
figuring out what  does  that best.  I liked the classloader  
element and separately  named dependency-structure elements  
since I thought it showed the  purpose more blatantly.  I worry  
a bit that this structure will  not make it very clear that car  
dependencies with services are not going on the  
classpath.


Paul:
I don't quite understand your example.  While configId has the   
same xml structure as a dependency, it is the name of the  
current  configuration, not a reference to something outside the  
current  configuration.  Do the load/include elements in this  
example work  for you in place of the ambiguous scope in the  
previous example?



Thanks everyone and please keep commenting!
david jencks


On Feb 15, 2006, at 9:45 AM, Aaron Mulder wrote:


On 2/15/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:


If we are going with maven style dependencies I think we should
follow their xml (http://maven.apache.org/maven-model/  
maven.html) as

close as possible.  If we are going to split from their format, I
would like the

Re: Thoughts on splitting out "core" from, well, products & other stuff

2006-02-15 Thread Rajith Attapattu

Nice idea !! , especially considering all the things we are putting inside Geronimo and the list keeps growing.
 
If there is a way to do a build with only what you want in a less painful way then it's great !!!
 
Thanks,
 
Rajith 
On 2/13/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
What would folks think of (in principle, not right now) splitting outthe core Geronimo components from anything that wraps a 3rd-party
product/project?  So have one area for modules like kernel, security,core, system, etc. and a separate area for modules like Jetty, Tomcat,ActiveMQ, Directory, jUDDI, etc.  I guess mainly to draw thedistinction between what's really part of the infrastructure and
what's really "optional packages" that can be added on top (and I'mtalking about "optional" in a non-J2EE-server sense where you startwith literally nothing but the infrastructure and add only waht you
want, or something like that).  So we'd still pull a lot of that infor our "J2EE" builds, but it would make a clearer distinction foranyone who wanted a more custom build.Thanks,   Aaron

Re: Sample plan bits for configId branch, please review!

2006-02-15 Thread Matt Hogstrom




Dain Sundstrom wrote:
I prefer to have them a properties, and then we can support multiple  
naming systems and use them for future extension.




I like properties as well.


-dain

On Feb 15, 2006, at 12:17 PM, David Blevins wrote:

This is also awkward and not quite right.  But throwing it out  there 
hoping someone can think of something better



   
  base-name
  geronimo.maven:J2EEServer=geronimo
   


-David

On Feb 15, 2006, at 10:59 AM, David Jencks wrote:

Here's a new version to  look at incorporating some feedback.   
General comments are at the end, followed by some specific  
responses.  It looks like most people liked the second example so  I 
have only worked on it.


http://geronimo.apache.org/xml/ns/ 
deployment-1.1">

  

  geronimo
  car
  geronimo-gbean-deployer
  1.0.1-SNAPSHOT


  
base-name
geronimo.maven:J2EEServer=geronimo
  




I'd prefer to make the version and type as optional.  Version would default to 
some server default.  Also, type can default to *car*. My preference for order 
would be groupId, artifactId, version and type.  If its going to break 
compatbility with Maven then leave it.  However, I'm also not in favor of 
letting the underlying technology bleed through and make the user experience 
more complicated than it needs to be.



  < dependency>
geronimo
car
geronimo-system
1.0.1-SNAPSHOT
  
  
geronimo
geronimo-common
1.0.1-SNAPSHOT
class


I'd prefer multiple  tags like

classes
services

or the ever popular

*


  
  < dependency>
geronimo
geronimo-deployment
1.0.1-SNAPSHOT

  
  < dependency>
geronimo
car
geronimo-j2ee
1.0.1-SNAPSHOT
service
  




org.apache.commons.logging



Ooh...looks OSGi like above :)



java

  
  
  class="org.apache.geronimo.deployment.Deployer">


The previous examples omitted the inverse-classloading, suppress- 
default-environment, and class filter elements.  They  are  included 
here.


"scope" has been renamed "load".  A particular artifact can have  
only classes (e.g. jar) or both classes and services (car)  
associated with it.  The default would be to use everything  
available, so we only need restrictive elements for the car files,  
classes and services.  I've put include as a separate element.


There may be some other items that could be loaded like resource bundles or 
something that we haven't thought of.  I think we should allow for exansion in 
the future.




I've added enclosing elements for the properties and dependencies.

I've taken Bruce's idea of a single name string that can be parsed  
by the naming system.  I think that this further reduces our  
dependency on the naming system chosen, but I am open to arguments  
the other way :-)


As Dain noted with the original, at least the version will  normally 
be optional.



Dain:
 I'm not sure about the names of name-keys and name-key.  These  are 
really intended for use by the naming system and are rarely  used, so 
I prefer to name them that way rather than "properties".   What could 
other properties be used for?  How would we distinguish  them from 
the ones for the naming system?


Aaron:
I am very reluctant to have a format with so much overlap with the  
m2 dependency without using the same element names.  This way you  
can copy an m2 dependency out of your pom and add the load tag if  
necessary.  I think changing the element names is going to cause  too 
much confusion.  I agree that the xml should clearly express  our 
function and purpose the problem is figuring out what  does  that 
best.  I liked the classloader element and separately  named 
dependency-structure elements since I thought it showed the  purpose 
more blatantly.  I worry a bit that this structure will  not make it 
very clear that car dependencies with services are not 
going on the classpath.


Paul:
I don't quite understand your example.  While configId has the  same 
xml structure as a dependency, it is the name of the current  
configuration, not a reference to something outside the current  
configuration.  Do the load/include elements in this example work  
for you in place of the ambiguous scope in the previous example?



Thanks everyone and please keep commenting!
david jencks


On Feb 15, 2006, at 9:45 AM, Aaron Mulder wrote:


On 2/15/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:


If we are going with maven style dependencies I think we should
follow their xml (http://maven.apache.org/maven-model/ maven.html) as
close as possible.  If we are going to split from their format, I
would like the difference to not be subtle, which would rule out
dropping just the Id and reusing elements named "scope" or  "type" for
something other than what they mean in maven.



I hear you, I'm just not

Re: Sample plan bits for configId branch, please review!

2006-02-15 Thread Paul McMahan

Paul:I don't quite understand your example.  While configId has the samexml structure as a dependency, it is the name of the current
configuration, not a reference to something outside the currentconfiguration.
In my example I just (lazily) copy/pasted the configId from higher up
in the DD which I suppose would have created a circular reference
:-)  My intent was actually just to show the suggested element
structure, which would look like:


   
  
  
  
  
   
   


The rationale behind making  a child of
 (as well as ) would be to make a
clear separation between
identifying the target of the dependency vs. describing the way that
Geronimo should enable it (start its gbeans, load its classes, import
it, etc).  It would also allow the dependency element to
automatically inherit any future changes
in the schema for the configId element.

All that being said, I could certainly understand a counter argument
for mirroring maven's dependency element.  When it comes to tight
integration with maven I'm starting to "stop worrying and love the
bomb" ;-)


  Do the load/include elements in this example work for
you in place of the ambiguous scope in the previous example?
Yes -- makes sense, thanks.


Best wishes,
Paul

Re: Sample plan bits for configId branch, please review!

2006-02-15 Thread Bruce Snyder

On 2/15/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> On Feb 14, 2006, at 8:32 PM, Bruce Snyder wrote:
>
> > 1) It seems like the name-key elements should be wrapped in another
> > element. Perhaps an element named name-pattern or something similar.
>
> Maybe we just make these generic properties:
>
>
>  
>domain
>geronimo.maven
>  
>  
>J2EEServer
>geronimo
>  
>

Yes, using the properties element is a good idea. I like that.

> On Feb 15, 2006, at 5:13 AM, Aaron Mulder wrote:
>
> > The biggest change I'd request is to take the Id of the end of group
> > and artifact.  I don't think it adds anything, and it makes it harder
> > to read and repeat (is that Id or ld, for example).  If we really have
> > to keep it, I'd prefer artifact-id and group-id, but I really don't
> > see why we shouldn't just use group, type, artifact, and version.
>
> If we are going with maven style dependencies I think we should
> follow their xml (http://maven.apache.org/maven-model/maven.html) as
> close as possible.  If we are going to split from their format, I
> would like the difference to not be subtle, which would rule out
> dropping just the Id and reusing elements named "scope" or "type" for
> something other than what they mean in maven.

While I agree in theory, let's see how this proves out in practice. I
think building on the Maven concepts is fine.

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)

Castor (http://castor.org/)

Re: Thoughts on splitting out "core" from, well, products & other stuff

2006-02-15 Thread Bruce Snyder

On 2/14/06, David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Feb 14, 2006, at 9:01 AM, Dain Sundstrom wrote:
>
> > I like the idea, but he devil is in the details.  Before we move
> > forward, I'd like to look that devil in he eyes.
>
> Indeed.  I don't understand what this would give anyone except a more
> complicated build structure.  What I think would be substantially
> more useful and not introduce any more build complexity is a
> dependency diagram so you could easily see the answer to the
> question, if I include module/configuration X what do I need to make
> it work?  Right now I think you can answer this my making an assembly
> that includes X and seeing what you get in it but a picture would be
> a lot easier to think about.
>
> Part of this is that I pretty much regard anything above the kernel
> as optional... in particular connectors, transaction manager,
> security, and naming.  We just haven't succeeded in actually making
> them optional yet.

I've been thinking about this and I see quite a lot of value in this effort.

Right now creating custom assemblies is pretty painful. There's a lot
of extra pieces that users must deal with prior to ever getting their
own custom GBeans and configs for them into the assembly. For example,
users need to be concerned with all the modules that we consider core
to the server (e.g., kernel, system, J2EE junk, naming, security,
etc.). Even worse is the situation where a user needs to slim down the
server into a custom assembly. Picking through

This could be simplified if these modules were wrapped in a larger
configuration named core so that a user only needs to make sure that
the core config is included. This would be dramatically easier than
just showing all the working parts like we have today.

Doing something like this would require some thought. Because what
we'd really be doing is creating configs that are bundled up into each
component (component in this case being the core component, but we'd
eventually have other components like ejb, corba, etc.). And then the
assemblies would need to handle components and/or configurations. Of
course, if someone needs to modify the configs in the core component
or in the ejb component they'd need to dig into the component and
concern themself with all the pieces I'm talking about hiding away.

This would make building custom assemblies much easier because it
would mean that there are less moving parts for user to worry about.

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)

Castor (http://castor.org/)

Re: Sample plan bits for configId branch, please review!

I prefer to have them a properties, and then we can support multiple
naming systems and use them for future extension.

-dain

On Feb 15, 2006, at 12:17 PM, David Blevins wrote:

This is also awkward and not quite right. But throwing it out
there hoping someone can think of something better

base-name
geronimo.maven:J2EEServer=geronimo

-David

On Feb 15, 2006, at 10:59 AM, David Jencks wrote:

Here's a new version to look at incorporating some feedback.
General comments are at the end, followed by some specific
responses. It looks like most people liked the second example so
I have only worked on it.

http://geronimo.apache.org/xml/ns/
deployment-1.1">

geronimo
car
geronimo-gbean-deployer
1.0.1-SNAPSHOT

base-name
geronimo.maven:J2EEServer=geronimo

< dependency>
geronimo
car
geronimo-system
1.0.1-SNAPSHOT

geronimo
geronimo-common
1.0.1-SNAPSHOT
class

< dependency>
geronimo
geronimo-deployment
1.0.1-SNAPSHOT

< dependency>
geronimo
car
geronimo-j2ee
1.0.1-SNAPSHOT
service

org.apache.commons.logging

java

class="org.apache.geronimo.deployment.Deployer">

The previous examples omitted the inverse-classloading, suppress-
default-environment, and class filter elements. They are
included here.

"scope" has been renamed "load". A particular artifact can have
only classes (e.g. jar) or both classes and services (car)
associated with it. The default would be to use everything
available, so we only need restrictive elements for the car files,
classes and services. I've put include as a separate element.

I've added enclosing elements for the properties and dependencies.

I've taken Bruce's idea of a single name string that can be parsed
by the naming system. I think that this further reduces our
dependency on the naming system chosen, but I am open to arguments
the other way :-)

As Dain noted with the original, at least the version will
normally be optional.

Dain:
I'm not sure about the names of name-keys and name-key. These
are really intended for use by the naming system and are rarely
used, so I prefer to name them that way rather than "properties".
What could other properties be used for? How would we distinguish
them from the ones for the naming system?

Aaron:
I am very reluctant to have a format with so much overlap with the
m2 dependency without using the same element names. This way you
can copy an m2 dependency out of your pom and add the load tag if
necessary. I think changing the element names is going to cause
too much confusion. I agree that the xml should clearly express
our function and purpose the problem is figuring out what
does that best. I liked the classloader element and separately
named dependency-structure elements since I thought it showed the
purpose more blatantly. I worry a bit that this structure will
not make it very clear that car dependencies with servicesload> are not going on the classpath.

Paul:
I don't quite understand your example. While configId has the
same xml structure as a dependency, it is the name of the current
configuration, not a reference to something outside the current
configuration. Do the load/include elements in this example work
for you in place of the ambiguous scope in the previous example?

Thanks everyone and please keep commenting!
david jencks

On Feb 15, 2006, at 9:45 AM, Aaron Mulder wrote:

On 2/15/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

If we are going with maven style dependencies I think we should
follow their xml (http://maven.apache.org/maven-model/
maven.html) as

close as possible. If we are going to split from their format, I
would like the difference to not be subtle, which would rule out
dropping just the Id and reusing elements named "scope" or
"type" for

something other than what they mean in maven.

I hear you, I'm just not that concerned with how close we stick to
maven syntax since what we're doing here is in many cases quite
different from what maven does. For example, if I want to force the
CORBA ORB to be started before my EJB app is deployed, I don't think
"naturally, I should use Maven for that!", but that's one of the
things these elements are used for. I would much rather have clear
and easy syntax for what *we* want to do.

Thanks,
Aaron

Re: Migrating to maven 2 -- version properties



On Feb 15, 2006, at 11:29 AM, Anders Hessellund Jensen wrote:



geronimo-system has some jelly to create a geronimo- 
version.properties file.




Check out how I create the  openejb-version.properties via the maven- 
antrun-plugin here:


http://cvs.openejb.org/viewrep/openejb/trunk/openejb3/container/ 
openejb-core/pom.xml?r=2423


Might help.

-David

[jira] Updated: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size

2006-02-15 Thread Joe Bohn (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1613?page=all ]

Joe Bohn updated GERONIMO-1613:
---

Attachment: RemoveDeps2.1.patch

Please ignore the previous patch (RemoveDeps2.patch) and use this patch 
(RemoveDeps2.1.patch) instead.   I was a bit too eager to remove comments 
before I created the patch and accidentally removed a live dependency.

> Eliminate unncessary dependencies to reduce assemnbly footprint size
> 
>
>  Key: GERONIMO-1613
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1613
>  Project: Geronimo
> Type: Improvement
>   Components: general
> Versions: 1.1
>  Environment: all
> Reporter: Joe Bohn
> Assignee: David Jencks
>  Fix For: 1.1
>  Attachments: RemoveDeps.patch, RemoveDeps2.1.patch, RemoveDeps2.patch
>
> Clean up assembly project.xml and eliminate some unnecessary dependencies in 
> various modules and configs.  This will reduce the footprint size (with 
> special attention to the minimal-tomcat-assembly.
> The patch contains the following:
> - clean up minimal-tomcat-server\project.xml to remove commented out sections
> - clean up web-jms-tomcat-server\project.xml to remove commented out sections
> - remove dependencies from config\j2ee_server on xstream, jaxr-api, and 
> geronimo-derby
> - remove dependencies from config\j2ee_deployer on geronimo-client-builder
> - remove dependencies from module\tomcat on activecluster, wadi-core, and 
> wadi-tomcat55
> There are still more dependencies that should be removed but this is a start.
> These changes reduce the disk footprint of minimal-tomcat-server from 27 meg 
> to about 21 meg.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sample plan bits for configId branch, please review!

This is also awkward and not quite right.  But throwing it out there  
hoping someone can think of something better



   
  base-name
  geronimo.maven:J2EEServer=geronimo
   


-David

On Feb 15, 2006, at 10:59 AM, David Jencks wrote:

Here's a new version to  look at incorporating some feedback.   
General comments are at the end, followed by some specific  
responses.  It looks like most people liked the second example so I  
have only worked on it.


http://geronimo.apache.org/xml/ns/ 
deployment-1.1">

  

  geronimo
  car
  geronimo-gbean-deployer
  1.0.1-SNAPSHOT


  
base-name
geronimo.maven:J2EEServer=geronimo
  


  < dependency>
geronimo
car
geronimo-system
1.0.1-SNAPSHOT
  
  
geronimo
geronimo-common
1.0.1-SNAPSHOT
class
  
  < dependency>
geronimo
geronimo-deployment
1.0.1-SNAPSHOT

  
  < dependency>
geronimo
car
geronimo-j2ee
1.0.1-SNAPSHOT
service
  




org.apache.commons.logging


java

  
  
  class="org.apache.geronimo.deployment.Deployer">


The previous examples omitted the inverse-classloading, suppress- 
default-environment, and class filter elements.  They  are included  
here.


"scope" has been renamed "load".  A particular artifact can have  
only classes (e.g. jar) or both classes and services (car)  
associated with it.  The default would be to use everything  
available, so we only need restrictive elements for the car files,  
classes and services.  I've put include as a separate element.


I've added enclosing elements for the properties and dependencies.

I've taken Bruce's idea of a single name string that can be parsed  
by the naming system.  I think that this further reduces our  
dependency on the naming system chosen, but I am open to arguments  
the other way :-)


As Dain noted with the original, at least the version will normally  
be optional.



Dain:
 I'm not sure about the names of name-keys and name-key.  These are  
really intended for use by the naming system and are rarely used,  
so I prefer to name them that way rather than "properties".  What  
could other properties be used for?  How would we distinguish them  
from the ones for the naming system?


Aaron:
I am very reluctant to have a format with so much overlap with the  
m2 dependency without using the same element names.  This way you  
can copy an m2 dependency out of your pom and add the load tag if  
necessary.  I think changing the element names is going to cause  
too much confusion.  I agree that the xml should clearly express  
our function and purpose the problem is figuring out what does   
that best.  I liked the classloader element and separately named  
dependency-structure elements since I thought it showed the purpose  
more blatantly.  I worry a bit that this structure will not make it  
very clear that car dependencies with services are not  
going on the classpath.


Paul:
I don't quite understand your example.  While configId has the same  
xml structure as a dependency, it is the name of the current  
configuration, not a reference to something outside the current  
configuration.  Do the load/include elements in this example work  
for you in place of the ambiguous scope in the previous example?



Thanks everyone and please keep commenting!
david jencks


On Feb 15, 2006, at 9:45 AM, Aaron Mulder wrote:


On 2/15/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

If we are going with maven style dependencies I think we should
follow their xml (http://maven.apache.org/maven-model/maven.html) as
close as possible.  If we are going to split from their format, I
would like the difference to not be subtle, which would rule out
dropping just the Id and reusing elements named "scope" or "type"  
for

something other than what they mean in maven.


I hear you, I'm just not that concerned with how close we stick to
maven syntax since what we're doing here is in many cases quite
different from what maven does.  For example, if I want to force the
CORBA ORB to be started before my EJB app is deployed, I don't think
"naturally, I should use Maven for that!", but that's one of the
things these elements are used for.  I would much rather have clear
and easy syntax for what *we* want to do.

Thanks,
Aaron

Re: Migrating to maven 2 - conversion idea



On Feb 14, 2006, at 5:28 PM, Brett Porter wrote:


On 2/15/06, David Blevins <[EMAIL PROTECTED]> wrote:

Every m2 project i've worked with eventually ended up leveraging
maven 1 repositories.

We'd likely use the maven-one-plugin which puts jars into a maven 1
repo.  Also we'd likely still need to list cvs.apache.org in the repo
list of our m2 build.


That's because they're all depending on snapshot versions of geronimo
dependencies :)

You will want to limit the number of snapshot repos you use, and
eventually remove dependence on m1 repos. I'd suggest mapping out
"what goes where" first. If all you are using is ibiblio, there is no
need to use the m1 version, as it is just a mapping over the m2 one.

Isn't the current Geronimo group ID "geronimo", so the new one can be
"org.apache.geronimo" without a clash?



Oh, yea.  You're right.  We could just use "geronimo" groupId in m1  
and "org.apache.geronimo" groupId for m2.  For some reason I was  
thinking we switched groupIds already.


-David

Re: [Fwd: Re: Roadmap, tasks and things to do?]

Hi Calvin,
this is a great discussion, we need more people to jump in.
I put some comments inline.

Calvin Austin wrote:

Hernan Cunico wrote:

Hi Calvin,
I saw your prev note, good follow up. It is in my TO DO list to reply :)
I had planned to cover not just JBoss but also WebLogic, iPlanet,
Oracle AS and Websphere. Again, that was my original plan but then I
saw the need for expanding to other topics and I could not keep up the
pace with my original idea for migration.

I was also expecting to get more people involved in the doc.

JBoss would have been my first choice too, I've met a few JBoss users
who would like to move if they had the opportunity.

It would be great if we can continue the work on the migration area.
I've done several migrations in the past (across vendors and
platforms) and would really like to continue develoing this section
but I am not having the time. I am now trying to focus on the hot
topics discussed on the dev list.

Just reading the dev list is a task!

What is your idea to take back on the migration section

I have a couple of ideas, 1) Help fill in any gaps in your current
migration docs 2) I have 'access' for a better choice of words to a
partner who is going to go through some real life migrations, I want to
capture all that information and propose a tool if the work is too
manual 3) start placeholders for the other apps servers and work through
at least two

What platform are you planning to start migrating from?

I wrote a book based on a migration experience from a customer, it was a great experience for
everybody but I would count customer migrations as "Case studies" instead of adding them to a
subsection in the general "Migrating to Apahe Geronimo" section.

Migration tools/plugins are another great idea. I have used a few plugins in Rational for migrating
CMPs but could not find a way to automate the migration for the rest of the sample apps.

Feel free to add the place holders (and content) :) in the migration section. Let me know if you
need a hand with confluence.

Cheers!
Hernan

regards
calvin

Cheers!
Hernan

Calvin Austin wrote:

Hi Hernan

Have you considered migrations from other app servers too, obviously
IBM has their own roadmap with websphere, but what about weblogic,
sun/iplanet/sunone, oracle app server? I know when I tried to move
petstore over originally I ended up trying to automate as much as I
could

regards
calvin

Subject:
Re: Roadmap, tasks and things to do?
From:
Calvin Austin <[EMAIL PROTECTED]>
Date:
Wed, 15 Feb 2006 09:27:13 -0800
To:
dev@geronimo.apache.org

To:
dev@geronimo.apache.org

Dain Sundstrom wrote:

Ever since we shipped 1.0, I have been getting a surprising number
of private emails from old fiends, old Geronimo contributers,
companies, and just random people telling me that the are excited
about Geronimo and want to join in. They all inevitably ask me for
advise on what to work on, and I really have no idea other than
"look at JIRA". So I'd like to solicit the community to help me
create a roadmap, tasks, things to do list, what ever we call it.

Before we get into building this, I'd like to focus the discussion,
so we don't end up in mailing-list fantasy land :) Lets agree to
not talk about the technology used to track the tasks; once we have
the content we can discuss using JIRA, wiki, html or creating a
Gopher site. Secondly, lets focus on things that are reasonable to
do in the next 9 months. Finally, don't worry about someone else
working on something you want to work on. With open communication
on the mailing list, I think everyone will be able to work
something they find interesting without stepping on toes. Oh, one
final thing, please don't try to "take a task" until we have this
list complete.

Without further delay, here are some things off the top of my head:

o Conversion to Maven 2 - Very important and a huge task

o Ant versions of the Geronimo plugins

o XDoclet for all configurations

o Integration tests that cover servlets, webservices and jms

o Little-G - Geronimo with a small foot print

o Global non-persistent JNDI implementation

o EJB 2.x - Once I get my refractor committed, it will be obvious
where the 2.x implementation needs work like better caching

o JEE 5 - There is a ton of stuff under this, but it would be good
to start with a list of what is required for JEE 5

I don't want to speak for the other ares of Geronimo I don't work
on regularly, but I am sure that there are good opportunities to
help in the console, jms, javamail, ejb, clustering, esb/jbi/bpm,
tooling, performance, build, testing, samples, documentation, so if
you are more familiar with one of those areas, please post.

I think this is a "once in a project chance" to build a big vibrant
community of developers, and let's not let it pass us by.

Thanks in advan

[jira] Commented: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size

2006-02-15 Thread David Jencks (JIRA)

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

David Jencks commented on GERONIMO-1613:


After the RemoveDeps2 patch the stuff I think that can be removed from 
minimal-tomcat is:
axis
wsdl4j
xerces + xmlParserAPIs (present in lib)
geronimo-axis
commons-discovery (??)
geronimo-activation (?)
geronimo-j2ee_1.4_spec-1.1-SNAPSHOT
regexp(??)

An additional project would be to separate the jsp stuff out of tomcat and 
jetty.  I suspect we'd need separate plans for tomcat and jetty.  I don't know 
if we want jsp support in minimal, but it would be nice to have the option of 
removing it.

> Eliminate unncessary dependencies to reduce assemnbly footprint size
> 
>
>  Key: GERONIMO-1613
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1613
>  Project: Geronimo
> Type: Improvement
>   Components: general
> Versions: 1.1
>  Environment: all
> Reporter: Joe Bohn
> Assignee: David Jencks
>  Fix For: 1.1
>  Attachments: RemoveDeps.patch, RemoveDeps2.patch
>
> Clean up assembly project.xml and eliminate some unnecessary dependencies in 
> various modules and configs.  This will reduce the footprint size (with 
> special attention to the minimal-tomcat-assembly.
> The patch contains the following:
> - clean up minimal-tomcat-server\project.xml to remove commented out sections
> - clean up web-jms-tomcat-server\project.xml to remove commented out sections
> - remove dependencies from config\j2ee_server on xstream, jaxr-api, and 
> geronimo-derby
> - remove dependencies from config\j2ee_deployer on geronimo-client-builder
> - remove dependencies from module\tomcat on activecluster, wadi-core, and 
> wadi-tomcat55
> There are still more dependencies that should be removed but this is a start.
> These changes reduce the disk footprint of minimal-tomcat-server from 27 meg 
> to about 21 meg.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Apache-licensed version of jgroups?

2006-02-15 Thread lichtner


Is there any interest in an apache-licensed version of jgroups?

I am thinking something along these lines:

1. Well-understood layered architecture, of x-kernel, Ensemble, and
JGroups fame.

2. Performance-focused: low thread count per protocol layer (0+), no java
serialization.

3. Simple: implement best-of-breed protocols only, and provide
pre-assembled protocol stacks.

4. Release 1.0 with basic protocols: membership, mnak, flow control, etc.

I would be happiest with an arrangement where somebody junior would code
it and I would serve as an advisor (if needed) based on my experience with
EVS4J, with the actual coder taking the credit for it.

I would like to see Geronimo evolve quickly into an industrial strength
server (which I think it will) so I can stop using all the other app
servers ..

Guglielmo

Re: Migrating to maven 2



On Feb 15, 2006, at 5:25 AM, Gianny Damour wrote:
Then I don't understand why it would save us any work *now*? How  
could

m1 and m2 know about the dependencies if there were no project.xml or
pom.xml, respectively? Once we provide pom.xml's, I understand it
would be the next step to just call off m2 from m1, but it's not
possible now.

It save us from the extra work of ensuring that the m2 build works  
properly all along the migration.


We could hook them up into continuum, no?  We have to do that anyway.

I'm personally a little weary about forcing everyone to choke down  
every step of the migration.  It's trivial to run both the maven1 and  
work-in-progress maven2 builds in continuum.


I'm not understanding why people think that's not good enough to get  
started?


-David

Re: Migrating to maven 2


Prasad Kashyap wrote:

That's right. I have the deployment plugin in m2. I'm testing each of
the goals one by one as I use them in the itests project. The itests
project is also in m2.

I like Gianny's roadmap. We'll know the potholes and pitfalls only
when we start driving. So either we could randomly take a few modules
to convert or identify the complex ones.

Even with the complex ones, we have 2 options
1) convert them the first, they'll be the prototype for the rest.
2) convert them the last, at which point we drop all m1 and it's
baggage complete and make that final dash to m2.


I have already created m2 poms for a lot of modules. A list can be found 
here: http://issues.apache.org/jira/browse/GERONIMO-1629 .


Modules still missing m2 builds are:

axis, axis-builder, jetty, jetty-builder, tomcat, tomcat-builder, 
console-web, activemq-embedded-rar, interop, installer-processing, 
installer-support.


Most modules pose no problems regarding conversion. Short list of 
problems I have encountered:


Some modules uses various j2ee archives for testing which are assembled 
using jelly. An example of such a module is connector-builder. Any 
suggestions for migrating these?


Some modules have various resources placed in non-standard places, e.g. 
deploy-tool has a manifest.mf in src/conf. These resources should be 
moved to a standard place.


geronimo-system has some jelly to create a geronimo-version.properties file.

Lots of modules probably have redundant dependencies, since m2 has 
transitive dependencies. I have basically just copied the dependencies 
from the m1 project.xml.


The scope for the various dependencies needs to be specified.

Some modules uses geronimo-dependency-plugin.

If the m2 modules need to be used in the m1 builds, they should have 
groupId geronimo. Currently they have groupId org.apache.geronimo.


In short, all the 30 or so modules that I have submitted m2 poms for 
compiles. A couple of them skips tests, and a couple of them lacks some 
meta-info such as manifests.


/Anders

Geronimo documentation


Hi All,
do we have any Geronimo implementation on a customer that would be willing to participate in a "Case 
Studies / Success Stories" section. It would be great to add a section like this to the updated site.


Cheers!
Hernan

Re: Covalent and Geronimo support

2006-02-15 Thread Jim Jagielski



I will get one from Covalent's PR dept...



... and make sure it's correct and forward it :)


On Feb 15, 2006, at 10:13 AM, Hernan Cunico wrote:


Hi Jim,
Pls don't feel uncomfortable. Would you have a prepared "speach"  
for this announcement in the "Geronimo News" section (about a  
paragraph). I'll be glad to add it to the updated site.


Look at the following example for an idea on how the section is  
structured.


2006-01-05
Geronimo Version 1.0 is now Available

Geronimo Version 1.0 which has passed the J2EE Certification Test  
Suite is now available for download here. This release represents  
the combined efforts of many engineers from several OpenSource  
projects and individual contributors from around the world. Please  
download, use the product and provide your comments and feedback to  
[EMAIL PROTECTED]


I'll squeeze this update in the JIRA as soon as I get it from you.

Cheers!
Hernan

Jim Jagielski wrote:

On Feb 7, 2006, at 9:21 AM, Rodent of Unusual Size wrote:


http://www.covalent.net/about/news/pressreleases.html?pressid=83

Let's put a link to that in the 'news' section on the
project front page.
- --
#kenP-)}

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

"Millennium hand and shrimp!"

Feeling very uncomfortable asking about this, for
obvious reasons :), but with the updates going on
with the site, could this be added in?

Re: [jira] Commented: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size

2006-02-15 Thread Joe Bohn


Dave,

Based upon your request for a single JIRA with multiple patches I 
re-opened GERONIMO-1613 and added another patch (RemoveDeps2.patch).


Not much of an additional reduction with this one but it's taking me 
much longer to figure out what is going on with XmlBeans and 
geronimo-gbean-deployer and I didn't want to lose these changes along 
the way.


Joe


David Jencks wrote:


On Feb 14, 2006, at 10:03 AM, Joe Bohn wrote:


David,

Thanks for the clarification.  I'm still having some problems  
understanding our classloader construction ... so can I ask for a  
little more clarification?


When I encountered this problem it was because I had removed 3  derby 
dependencies (geronimo-derby, derby, and derbynet) from  config 
j2ee-server.  Daytrader had a parent of j2ee-server ... so  it makes 
sense that this change could have affected daytrader.  I  had a fix 
that I hadn't made available yet where I added the  dependencies 
directly into daytrader for these same three derby  configs.  However, 
I noticed that you chose instead to add system- database (which also 
included these 3 dependencies) as a parent of  daytrader.  What 
additional benefits does this provide?



I don't think your change would have worked, since I believe it would  
have still resulted in 2 copies of the derby classes being loaded and  
the derby engine (started and loaded from the system-database config)  
being in a different classloader than the jdbc classes trying to use  it 
in the daytrader app.


Making daytrader a child of system-database forces all the classes to  
come from the system-database classloader.




Also, I'm working on additional updates.  Would you prefer to have  
individual JIRAs for these items or larger ones with more "bang for  
buck" in reducing the size of minimal?  What I have right now  doesn't 
provide a lot of additional savings yet.



I think I might be happiest with a single jira item with mutliple  
patches on it: when we decide we can't get any smaller we can close it.


thanks
david jencks



Thanks,
Joe


David Jencks (JIRA) wrote:

[ http://issues.apache.org/jira/browse/GERONIMO-1613? 
page=comments#action_12366301 ] David Jencks commented on  
GERONIMO-1613:


To be a little clearer, I fixed the derby problems in daytrader  
also. r377628



Eliminate unncessary dependencies to reduce assemnbly footprint size


Key: GERONIMO-1613
URL: http://issues.apache.org/jira/browse/GERONIMO-1613
Project: Geronimo
   Type: Improvement
 Components: general
   Versions: 1.1
Environment: all
   Reporter: Joe Bohn
   Assignee: David Jencks
Fix For: 1.1
Attachments: RemoveDeps.patch

Clean up assembly project.xml and eliminate some unnecessary  
dependencies in various modules and configs.  This will reduce  the 
footprint size (with special attention to the minimal-tomcat- assembly.

The patch contains the following:
- clean up minimal-tomcat-server\project.xml to remove commented  
out sections
- clean up web-jms-tomcat-server\project.xml to remove commented  
out sections
- remove dependencies from config\j2ee_server on xstream, jaxr- api, 
and geronimo-derby
- remove dependencies from config\j2ee_deployer on geronimo- 
client-builder
- remove dependencies from module\tomcat on activecluster, wadi- 
core, and wadi-tomcat55
There are still more dependencies that should be removed but this  
is a start.
These changes reduce the disk footprint of minimal-tomcat-server  
from 27 meg to about 21 meg.



--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he  cannot 
lose."   -- Jim Elliot







--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

[jira] Updated: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size

2006-02-15 Thread Joe Bohn (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1613?page=all ]

Joe Bohn updated GERONIMO-1613:
---

Attachment: RemoveDeps2.patch

Not a very big reduction  just removal of two small jars.  I was going to 
wait until I had something more substantial but I'm a bit stuck on the removal 
of XmlBeans and I didn't want to lose these changes.   The RemoveDeps2 patch 
only removed geronimo-client and geronimo-timer.

> Eliminate unncessary dependencies to reduce assemnbly footprint size
> 
>
>  Key: GERONIMO-1613
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1613
>  Project: Geronimo
> Type: Improvement
>   Components: general
> Versions: 1.1
>  Environment: all
> Reporter: Joe Bohn
> Assignee: David Jencks
>  Fix For: 1.1
>  Attachments: RemoveDeps.patch, RemoveDeps2.patch
>
> Clean up assembly project.xml and eliminate some unnecessary dependencies in 
> various modules and configs.  This will reduce the footprint size (with 
> special attention to the minimal-tomcat-assembly.
> The patch contains the following:
> - clean up minimal-tomcat-server\project.xml to remove commented out sections
> - clean up web-jms-tomcat-server\project.xml to remove commented out sections
> - remove dependencies from config\j2ee_server on xstream, jaxr-api, and 
> geronimo-derby
> - remove dependencies from config\j2ee_deployer on geronimo-client-builder
> - remove dependencies from module\tomcat on activecluster, wadi-core, and 
> wadi-tomcat55
> There are still more dependencies that should be removed but this is a start.
> These changes reduce the disk footprint of minimal-tomcat-server from 27 meg 
> to about 21 meg.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Reopened: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size

2006-02-15 Thread Joe Bohn (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1613?page=all ]
 
Joe Bohn reopened GERONIMO-1613:



Re-opened this issue so that we can continue to attach patches as we reduce the 
size ... per Dave's request.

> Eliminate unncessary dependencies to reduce assemnbly footprint size
> 
>
>  Key: GERONIMO-1613
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1613
>  Project: Geronimo
> Type: Improvement
>   Components: general
> Versions: 1.1
>  Environment: all
> Reporter: Joe Bohn
> Assignee: David Jencks
>  Fix For: 1.1
>  Attachments: RemoveDeps.patch
>
> Clean up assembly project.xml and eliminate some unnecessary dependencies in 
> various modules and configs.  This will reduce the footprint size (with 
> special attention to the minimal-tomcat-assembly.
> The patch contains the following:
> - clean up minimal-tomcat-server\project.xml to remove commented out sections
> - clean up web-jms-tomcat-server\project.xml to remove commented out sections
> - remove dependencies from config\j2ee_server on xstream, jaxr-api, and 
> geronimo-derby
> - remove dependencies from config\j2ee_deployer on geronimo-client-builder
> - remove dependencies from module\tomcat on activecluster, wadi-core, and 
> wadi-tomcat55
> There are still more dependencies that should be removed but this is a start.
> These changes reduce the disk footprint of minimal-tomcat-server from 27 meg 
> to about 21 meg.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Ode Proposal (Sybase BPEL engine donation))


On 15 Feb 2006, at 16:54, Davanum Srinivas wrote:

James,

Thanks for taking the first step. Yes, please add me in as a mentor.
Here's some feedback first about the proposal before we take the next
step.

- AFAIK, Geronimo PMC has not voted on this proposal.


We kinda voted already on G-PMC but the new proposal changes things  
slightly (being a new podling) so to clear things up I've called  
another vote.




- Can we please put out a call to other Open source BPEL engines to
join us with their contributions? (ala, Synapse).


Sure, we're open to other contributions and contributors from  
wherever; they can arrive at any time - lets starting incubating




- Can we please add people in a phased manner as committers? based on
their patches/energy on the list? (ala, Harmony)


All the folks on the committer list are folks who've expressed  
interest in working on the code. The only non-apache committers so  
far are the Sybase folks who've written all the code being  
contributed; the rest are already proven committers in Agila,  
Geronimo or ServiceMix


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

Re: Sample plan bits for configId branch, please review!

Here's a new version to  look at incorporating some feedback.   
General comments are at the end, followed by some specific  
responses.  It looks like most people liked the second example so I  
have only worked on it.


http://geronimo.apache.org/xml/ns/deployment-1.1";>
  

  geronimo
  car
  geronimo-gbean-deployer
  1.0.1-SNAPSHOT


  
base-name
geronimo.maven:J2EEServer=geronimo
  


  < dependency>
geronimo
car
geronimo-system
1.0.1-SNAPSHOT
  
  
geronimo
geronimo-common
1.0.1-SNAPSHOT
class
  
  < dependency>
geronimo
geronimo-deployment
1.0.1-SNAPSHOT

  
  < dependency>
geronimo
car
geronimo-j2ee
1.0.1-SNAPSHOT
service
  




org.apache.commons.logging


java

  
  
  class="org.apache.geronimo.deployment.Deployer">


The previous examples omitted the inverse-classloading, suppress- 
default-environment, and class filter elements.  They  are included  
here.


"scope" has been renamed "load".  A particular artifact can have only  
classes (e.g. jar) or both classes and services (car) associated with  
it.  The default would be to use everything available, so we only  
need restrictive elements for the car files, classes and services.   
I've put include as a separate element.


I've added enclosing elements for the properties and dependencies.

I've taken Bruce's idea of a single name string that can be parsed by  
the naming system.  I think that this further reduces our dependency  
on the naming system chosen, but I am open to arguments the other  
way :-)


As Dain noted with the original, at least the version will normally  
be optional.



Dain:
 I'm not sure about the names of name-keys and name-key.  These are  
really intended for use by the naming system and are rarely used, so  
I prefer to name them that way rather than "properties".  What could  
other properties be used for?  How would we distinguish them from the  
ones for the naming system?


Aaron:
I am very reluctant to have a format with so much overlap with the m2  
dependency without using the same element names.  This way you can  
copy an m2 dependency out of your pom and add the load tag if  
necessary.  I think changing the element names is going to cause too  
much confusion.  I agree that the xml should clearly express our  
function and purpose the problem is figuring out what does  that  
best.  I liked the classloader element and separately named  
dependency-structure elements since I thought it showed the purpose  
more blatantly.  I worry a bit that this structure will not make it  
very clear that car dependencies with services are not  
going on the classpath.


Paul:
I don't quite understand your example.  While configId has the same  
xml structure as a dependency, it is the name of the current  
configuration, not a reference to something outside the current  
configuration.  Do the load/include elements in this example work for  
you in place of the ambiguous scope in the previous example?



Thanks everyone and please keep commenting!
david jencks


On Feb 15, 2006, at 9:45 AM, Aaron Mulder wrote:


On 2/15/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

If we are going with maven style dependencies I think we should
follow their xml (http://maven.apache.org/maven-model/maven.html) as
close as possible.  If we are going to split from their format, I
would like the difference to not be subtle, which would rule out
dropping just the Id and reusing elements named "scope" or "type" for
something other than what they mean in maven.


I hear you, I'm just not that concerned with how close we stick to
maven syntax since what we're doing here is in many cases quite
different from what maven does.  For example, if I want to force the
CORBA ORB to be started before my EJB app is deployed, I don't think
"naturally, I should use Maven for that!", but that's one of the
things these elements are used for.  I would much rather have clear
and easy syntax for what *we* want to do.

Thanks,
Aaron

Re: Migrating to maven 2

2006-02-15 Thread Prasad Kashyap

That's right. I have the deployment plugin in m2. I'm testing each of
the goals one by one as I use them in the itests project. The itests
project is also in m2.

I like Gianny's roadmap. We'll know the potholes and pitfalls only
when we start driving. So either we could randomly take a few modules
to convert or identify the complex ones.

Even with the complex ones, we have 2 options
1) convert them the first, they'll be the prototype for the rest.
2) convert them the last, at which point we drop all m1 and it's
baggage complete and make that final dash to m2.

Cheers
Prasad



On 2/15/06, David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Feb 15, 2006, at 4:49 AM, Jacek Laskowski wrote:
>
> > 2006/2/15, Anders Hessellund Jensen <[EMAIL PROTECTED]>:
> >> We need a m2 version of the geronimo-dependency-plugin. Is anyone
> >> working on this, or perhaps it already exists somewhere?
> >
> > AFAIK, the answers are no and no, appropriately. If you'd start
> > working on it, create a JIRA task item, so it's recorded. The work
> > could be done in sandbox.
>
> I think we need something like plugins2 for the m2 plugins, in
> trunk.  IIUC Prasad has already converted the deployment plugin and
> it needs an accessible place to live.  I see no reason to hide these
> in the sandbox.
>
> Note that this plugin depends on the service-builder module.  It
> might be worthwhile rewriting the logic to avoid using xmlbeans or to
> copy the appropriate schema parts into the plugin to remove this
> dependency.  I imagine that when we have a fully working m2 build we
> can use the m2 poms instead of the geronimo-service.xml files anyway.
>
> I'm not sure if this idea is the same as previous suggestions, but I
> think it would be possible to stage a move to m2 as long as the
> modules built with m2 don't depend on any modules built with m1.  We
> would have a new0.5 goal that would build the m2 modules, and the m1
> goal could have the m2 modules excluded in the call to the reactor.
>
>
> thanks
> david jencks
>
> >
> >> /Anders
> >
> > Jacek
> >
> > --
> > Jacek Laskowski
> > http://www.laskowski.org.pl
>
>

Re: Migrating to maven 2



On Feb 15, 2006, at 4:49 AM, Jacek Laskowski wrote:


2006/2/15, Anders Hessellund Jensen <[EMAIL PROTECTED]>:

We need a m2 version of the geronimo-dependency-plugin. Is anyone
working on this, or perhaps it already exists somewhere?


AFAIK, the answers are no and no, appropriately. If you'd start
working on it, create a JIRA task item, so it's recorded. The work
could be done in sandbox.


I think we need something like plugins2 for the m2 plugins, in  
trunk.  IIUC Prasad has already converted the deployment plugin and  
it needs an accessible place to live.  I see no reason to hide these  
in the sandbox.


Note that this plugin depends on the service-builder module.  It  
might be worthwhile rewriting the logic to avoid using xmlbeans or to  
copy the appropriate schema parts into the plugin to remove this  
dependency.  I imagine that when we have a fully working m2 build we  
can use the m2 poms instead of the geronimo-service.xml files anyway.


I'm not sure if this idea is the same as previous suggestions, but I  
think it would be possible to stage a move to m2 as long as the  
modules built with m2 don't depend on any modules built with m1.  We  
would have a new0.5 goal that would build the m2 modules, and the m1  
goal could have the m2 modules excluded in the call to the reactor.



thanks
david jencks




/Anders


Jacek

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

Re: Sample plan bits for configId branch, please review!

2006-02-15 Thread Aaron Mulder

On 2/15/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> If we are going with maven style dependencies I think we should
> follow their xml (http://maven.apache.org/maven-model/maven.html) as
> close as possible.  If we are going to split from their format, I
> would like the difference to not be subtle, which would rule out
> dropping just the Id and reusing elements named "scope" or "type" for
> something other than what they mean in maven.

I hear you, I'm just not that concerned with how close we stick to
maven syntax since what we're doing here is in many cases quite
different from what maven does.  For example, if I want to force the
CORBA ORB to be started before my EJB app is deployed, I don't think
"naturally, I should use Maven for that!", but that's one of the
things these elements are used for.  I would much rather have clear
and easy syntax for what *we* want to do.

Thanks,
Aaron

Re: Ode Proposal (Sybase BPEL engine donation))


On 15 Feb 2006, at 16:31, Sanjiva Weerawarana wrote:

On Wed, 2006-02-15 at 15:56 +, James Strachan wrote:

Dims & Sanjiva

Given your arguments that the Sybase BPEL donation should be in a new
podling rather than part of ServiceMix - I wonder if you'd like to
join us in the ODE proposal then we can have a united Apache
community with folks from Agila, Geronimo, ServiceMix, & WS involved
to insure plenty of cross pollination.


Wow I feel "special" to get asked liked this ;-).

I was going to ask to join anyway .. so I'll be happy to.


Great! :)



However, I
would like to request some changes:

- Under warning signs, in the "Homogenous developers" category it  
lists

developers from Sybase, IBM & LogicBlaze. Is it the case that the
*current* codebase has contribs from all these companies? If not I
believe the spirit of the question is about the current codebase, not
about the group that'll get it thru incubation. So please indicate who
wrote the current codebase (which I believe is all Synbase).


Good point - fixed.


- The initial committers list is very long. I'm on service-mix dev  
and I

see only 2-3 people committing


Have you tried looking at the SVN logs? The codebase has only been in  
the incubator for 2 months and 12 folks have been hacking the code  
furiously (and we're still waiting for karma for a couple more  
committers).




(and little or no discussion; am I
missing some stuff??).


Maybe you're email filters are hiding email? There's a fair amount of  
discussion...
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/ 
200602.mbox/thread
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/ 
200601.mbox/thread
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/ 
200512.mbox/thread


There's plenty of background chatter on IRC too if you need more chat  
(though important decisions and votes always take place via email)




Can we try to list people who are really going to
write code for this? It doesn't make sense to list *23* committers
unless they will really write code.


They will.



We can always bring people on board
as they start contributing. If all these people are really so hot to
mess with a BPEL impl, damn, I should feel really good about BPEL ;-).


You should as they are. The people listed who are servicemix  
committers have committed substantial code already to ServiceMix and  
are keen to work on the integration of BPEL + ServiceMix along with  
enhancing the core BPEL engine (such as the management & persistence  
piece). The Sybase folks wrote the original code and the Agila  
committer is the guy who wrote all the BPEL code in Agila - so far  
I'm happy with the committer list.



- Given the, um, strong feelings expressed by so many people about  
this
project, how about if we get the Incubator PMC to sponsor this  
poddling?


Why does the sponsor PMC make any difference to whether the BPEL  
engine goes top level or not? e.g. Tuscany is sponsored by WS and is  
gonna be a TLP?


Given the Geronimo PMC did vote to accept the patch into ServiceMix  
(though given the general sentiment to use a separate podling we've  
backed off), we'd rather stick to the same sponsor PMC for the moment.


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

Re: Roadmap, tasks and things to do?

2006-02-15 Thread Calvin Austin


Dain Sundstrom wrote:

Ever since we shipped 1.0, I have been getting a surprising number of  
private emails from old fiends, old Geronimo contributers, companies,  
and just random people telling me that the are excited about Geronimo  
and want to join in.  They all inevitably ask me for advise on what  
to work on, and I really have no idea other than "look at JIRA". So  
I'd like to solicit the community to help me create a roadmap, tasks,  
things to do list, what ever we call it.


Before we get into building this, I'd like to focus the discussion,  
so we don't end up in mailing-list fantasy land :)  Lets agree to not  
talk about the technology used to track the tasks; once we have the  
content we can discuss using JIRA, wiki, html or creating a Gopher  
site.  Secondly, lets focus on things that are reasonable to do in  
the next 9 months.  Finally, don't worry about someone else working  
on something you want to work on.  With open communication on the  
mailing list, I think everyone will be able to work something they  
find interesting without stepping on toes.  Oh, one final thing,  
please don't try to "take a task" until we have this list complete.


Without further delay, here are some things off the top of my head:

o Conversion to Maven 2 - Very important and a huge task

o Ant versions of the Geronimo plugins

o  XDoclet for all configurations

o Integration tests that cover servlets, webservices and jms

o Little-G - Geronimo with a small foot print

o Global non-persistent JNDI implementation

o EJB 2.x - Once I get my refractor committed, it will be obvious  
where the 2.x implementation needs work like better caching


o JEE 5 - There is a ton of stuff under this, but it would be good to  
start with a list of what is required for JEE 5


I don't want to speak for the other ares of Geronimo I don't work on  
regularly, but I am sure that there are good opportunities to help in  
the console, jms, javamail, ejb, clustering, esb/jbi/bpm, tooling,  
performance, build, testing, samples, documentation, so if you are  
more familiar with one of those areas, please post.


I think this is a "once in a project chance" to build a big vibrant  
community of developers, and let's not let it pass us by.


Thanks in advance,

-dain


After following the discussions about project donations over the past 
week and the sometimes difficult questions each donation raises. I think 
its a good time to revisit this wishlist to see how it all fits together 
in a bigger picture.


What would be the top 3 things that would make Geronimo successful and 
the de-facto choice for open source J2EE app developers?


My personal choice would be
1. To make it easy for developers to start or migrate to Geronimo, that 
could be migration tools/deployment, how to documentation (there are 
some good examples so far, Hernan and others are very focused on JBoss 
:*), feature set leveling (obviously in process), testing that your app 
still works!. Some donations may fit here.

2. Make the release/build process more agile, resilient (eg maven2/ant)
3. First place to come for latest J2EE technology.

If anyone else is interesting in 1) migration activities then let me 
know, I think with Hernans great start we can divide the workload up and 
finish this task sooner than later


regards
calvin

[Fwd: Re: Covalent and Geronimo support]


Jim,
check the following link for a sample style on the paragraph to add in the "Geronimo 
News" section

http://people.apache.org/~hogstrom/website/

check the following link for a sample style on the paragraph to add in the "Powered 
By" section

http://people.apache.org/~hogstrom/website/powered_by.html

you may send the paragraphs in html if you prefer to include the link directly.

Cheers!
Hernan

 Original Message 
Subject: Re: Covalent and Geronimo support
Date: Wed, 15 Feb 2006 09:35:09 -0500
From: Jim Jagielski <[EMAIL PROTECTED]>
Reply-To: dev@geronimo.apache.org
To: dev@geronimo.apache.org
References: <[EMAIL PROTECTED]>


On Feb 7, 2006, at 9:21 AM, Rodent of Unusual Size wrote:


http://www.covalent.net/about/news/pressreleases.html?pressid=83

Let's put a link to that in the 'news' section on the
project front page.
- --
#kenP-)}

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

"Millennium hand and shrimp!"



Feeling very uncomfortable asking about this, for
obvious reasons :), but with the updates going on
with the site, could this be added in?

Re: Ode Proposal (Sybase BPEL engine donation))

2006-02-15 Thread Davanum Srinivas

James,

Thanks for taking the first step. Yes, please add me in as a mentor.
Here's some feedback first about the proposal before we take the next
step.

- AFAIK, Geronimo PMC has not voted on this proposal. So can we please
get Incubator PMC to sponsor this?
- Can we please put out a call to other Open source BPEL engines to
join us with their contributions? (ala, Synapse).
- Can we please add people in a phased manner as committers? based on
their patches/energy on the list? (ala, Harmony)

Thanks,
dims

On 2/15/06, James Strachan <[EMAIL PROTECTED]> wrote:
> Dims & Sanjiva
>
> Given your arguments that the Sybase BPEL donation should be in a new
> podling rather than part of ServiceMix - I wonder if you'd like to
> join us in the ODE proposal then we can have a united Apache
> community with folks from Agila, Geronimo, ServiceMix, & WS involved
> to insure plenty of cross pollination.
>
> http://wiki.apache.org/incubator/OdeProposa
>
> James
>
> Begin forwarded message:
>
> > From: "Alan D. Cabrera" <[EMAIL PROTECTED]>
> > Date: 14 February 2006 07:35:33 GMT
> > To: dev@geronimo.apache.org, general@incubator.apache.org,
> > servicemix-dev@geronimo.apache.org
> > Subject: Ode Proposal
> > Reply-To: general@incubator.apache.org
> >
> > Ok.  Here's the proposal http://wiki.apache.org/incubator/
> > OdeProposal.  Please feel free to comment.
> >
> > We need some more mentors.  Anyone?
>
>
> James
> ---
> http://radio.weblogs.com/0112098/
>
>


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

Re: Covalent and Geronimo support

Covalent should also be on this page http://geronimo.apache.org/ 
powered_by.html


-dain

On Feb 15, 2006, at 6:35 AM, Jim Jagielski wrote:



On Feb 7, 2006, at 9:21 AM, Rodent of Unusual Size wrote:


http://www.covalent.net/about/news/pressreleases.html?pressid=83

Let's put a link to that in the 'news' section on the
project front page.
- --
#kenP-)}

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

"Millennium hand and shrimp!"



Feeling very uncomfortable asking about this, for
obvious reasons :), but with the updates going on
with the site, could this be added in?

Re: Sample plan bits for configId branch, please review!


On Feb 14, 2006, at 8:32 PM, Bruce Snyder wrote:


1) It seems like the name-key elements should be wrapped in another
element. Perhaps an element named name-pattern or something similar.


Maybe we just make these generic properties:

  

  domain
  geronimo.maven


  J2EEServer
  geronimo

  


On Feb 15, 2006, at 5:13 AM, Aaron Mulder wrote:


The biggest change I'd request is to take the Id of the end of group
and artifact.  I don't think it adds anything, and it makes it harder
to read and repeat (is that Id or ld, for example).  If we really have
to keep it, I'd prefer artifact-id and group-id, but I really don't
see why we shouldn't just use group, type, artifact, and version.


If we are going with maven style dependencies I think we should  
follow their xml (http://maven.apache.org/maven-model/maven.html) as  
close as possible.  If we are going to split from their format, I  
would like the difference to not be subtle, which would rule out  
dropping just the Id and reusing elements named "scope" or "type" for  
something other than what they mean in maven.


-dain

Re: [continuum] BUILD FAILURE: J2EE

2006-02-15 Thread Kevan Miller



On Feb 14, 2006, at 1:41 PM, David Blevins wrote:



On Feb 14, 2006, at 5:38 AM, Kevan Miller wrote:



On Feb 14, 2006, at 3:52 AM, Jason Dillon wrote:


Woah, this doesn't look good...



Yeah. I tried adding geronimo-spec-j2ee to the continuum builds on  
GBuild. Obviously, it's not too happy there...


I tried recreating locally (checking out geronimo-spec-j2ee,  
only), but the build worked. I wiped out my repos, and the build  
failed, but didn't recreate this infinite loop...


I just tried building the full specs project on the GBuild machine  
(stan). I'm seeing a similar infinite loop. I see stan is using  
maven 2.0. I'm on 2.0.2. So, hopefully that's the cause... I'll  
need to wait for someone with appropriate karma to upgrade the m2  
version on the gbuild machines...



Jason, can you help with this?

Aaron, can you do your machines?

it's just an unzip under /usr/local/  and then redo the symlink.


FYI,
I created a private maven2 install, and was able to build specs  
successfully. This has the additional benefit that geronimo-spec-j2ee  
jar is now, once again, available for download from apache...


So, once we cut over to maven 2.0.2, I think the J2EE spec build will  
be working on Continuum.


--kevan

Re: problem building head

2006-02-15 Thread Kevan Miller



On Feb 15, 2006, at 10:04 AM, Conrad O'Dea wrote:


Hi there,

I am having problems getting a build of Geronimo.  I am following the
instructions at: http://wiki.apache.org/geronimo/Building
I've basically done the following (and several combinations thereof):

  % svn co  https://svn.apache.org/repos/asf/geronimo/trunk geronimo
  % cd geronimo
  % maven m:fresh-checkout
  % maven new -Dmaven.test.skip=true -Dmaven.itest.skip=true

and after a good healthy time of doing stuff it fails with:

"The build cannot continue because of the following unsatisfied
dependency:

geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar"

I've also checked-out geronimo-specs and built it with 'mvn  
install' but

this jar has not been built anywhere in that working copy or either
~/.maven or ~/.m2 repositories.  Nor can I find it in the maven
repository at http://cvs.apache.org/repository/geronimo-spec/jars/.


Conrad,
The spec jar is now in the apache repo:

http://cvs.apache.org/repository/org.apache.geronimo.specs/jars/ 
geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar


It shouldn't be necessary to build specs from source, any longer...

--kevan

Re: Ode Proposal (Sybase BPEL engine donation))

2006-02-15 Thread Sanjiva Weerawarana

On Wed, 2006-02-15 at 15:56 +, James Strachan wrote:
> Dims & Sanjiva
> 
> Given your arguments that the Sybase BPEL donation should be in a new  
> podling rather than part of ServiceMix - I wonder if you'd like to  
> join us in the ODE proposal then we can have a united Apache  
> community with folks from Agila, Geronimo, ServiceMix, & WS involved  
> to insure plenty of cross pollination.

Wow I feel "special" to get asked liked this ;-).

I was going to ask to join anyway .. so I'll be happy to. However, I
would like to request some changes:

- Under warning signs, in the "Homogenous developers" category it lists
developers from Sybase, IBM & LogicBlaze. Is it the case that the
*current* codebase has contribs from all these companies? If not I
believe the spirit of the question is about the current codebase, not
about the group that'll get it thru incubation. So please indicate who
wrote the current codebase (which I believe is all Synbase).

- The initial committers list is very long. I'm on service-mix dev and I
see only 2-3 people committing (and little or no discussion; am I
missing some stuff??). Can we try to list people who are really going to
write code for this? It doesn't make sense to list *23* committers
unless they will really write code. We can always bring people on board
as they start contributing. If all these people are really so hot to
mess with a BPEL impl, damn, I should feel really good about BPEL ;-).

- Given the, um, strong feelings expressed by so many people about this
project, how about if we get the Incubator PMC to sponsor this poddling?
I'm a member of that PMC and I'll be happy to do it. That allows the
poddling to decide, upon graduation, its final resting place: Geronimo,
new TLP or elsewhere. (NO, I'm not even suggesting it go to WS .. as I
said earlier, WS is too damned crowded already.) I see *nothing* to be
gained by saying its going to be part of Geronimo at this point; so you
see my bias already: go for its own TLP. However, if that appears to be
the right thing upon graduation, then so be it. 

Note that this does not preclude ServiceMix, or *anyone else* from
embracing and extending Apache Ode and living happily ever after. In
fact, its *much better* for Apache Ode to be on its own because then its
likely to be pluggable to more container frameworks and not just
Geronimo/ServiceMix.

Bye,

Sanjiva.

Re: problem building head

2006-02-15 Thread Kevan Miller



On Feb 15, 2006, at 10:04 AM, Conrad O'Dea wrote:


Hi there,

I am having problems getting a build of Geronimo.  I am following the
instructions at: http://wiki.apache.org/geronimo/Building
I've basically done the following (and several combinations thereof):

  % svn co  https://svn.apache.org/repos/asf/geronimo/trunk geronimo
  % cd geronimo
  % maven m:fresh-checkout
  % maven new -Dmaven.test.skip=true -Dmaven.itest.skip=true

and after a good healthy time of doing stuff it fails with:

"The build cannot continue because of the following unsatisfied
dependency:

geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar"

I've also checked-out geronimo-specs and built it with 'mvn  
install' but

this jar has not been built anywhere in that working copy or either
~/.maven or ~/.m2 repositories.  Nor can I find it in the maven
repository at http://cvs.apache.org/repository/geronimo-spec/jars/.


Conrad,
I just verified that geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar was  
built and placed in my .maven repository. Can you svn update your  
specs and try again?


FYI -- the spec jar was mistakenly deleted from the apache repo. I'm  
sure it will be back sometime soon.


Also, I believe there was also a problem in the spec build which  
didn't put the jar in your .maven repo. I thought that had been fixed  
over the weekend...


--kevan

Re: Ode Proposal (Sybase BPEL engine donation))


Dims & Sanjiva

Given your arguments that the Sybase BPEL donation should be in a new  
podling rather than part of ServiceMix - I wonder if you'd like to  
join us in the ODE proposal then we can have a united Apache  
community with folks from Agila, Geronimo, ServiceMix, & WS involved  
to insure plenty of cross pollination.


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

James

Begin forwarded message:


From: "Alan D. Cabrera" <[EMAIL PROTECTED]>
Date: 14 February 2006 07:35:33 GMT
To: dev@geronimo.apache.org, general@incubator.apache.org,  
servicemix-dev@geronimo.apache.org

Subject: Ode Proposal
Reply-To: general@incubator.apache.org

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


We need some more mentors.  Anyone?



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

[jira] Commented: (GERONIMO-1625) Remove deprecated m:* goals from the build

2006-02-15 Thread Anita Kulshreshtha (JIRA)

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

Anita Kulshreshtha commented on GERONIMO-1625:
--

Oops! please read that as project.properties (instead of /etc) file.

> Remove deprecated m:* goals from the build
> --
>
>  Key: GERONIMO-1625
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1625
>  Project: Geronimo
> Type: Task
>   Components: buildsystem
> Versions: 1.x
> Reporter: Jacek Laskowski
> Assignee: Jacek Laskowski
> Priority: Minor

>
> Remove everything but the "new" goals, m:co, m:idea and m:eclipse. Most of 
> the m goals are of no use.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1625) Remove deprecated m:* goals from the build

2006-02-15 Thread Anita Kulshreshtha (JIRA)

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

Anita Kulshreshtha commented on GERONIMO-1625:
--

IMHO, the patches available at Geronimo-1317 should be applied. These patches 
essentally  rename newi goals and allow the 'includes' and 'excludes' defined 
in etc/project.properties files to work. Currently things defined in 
etc/project.properties have no effect!
The new names are more user friendly, e.g. 
new3 -   m:geronimo:applications
new4  -  m:geronimo:configs
new5 -   m:geronimo:assemblies

> Remove deprecated m:* goals from the build
> --
>
>  Key: GERONIMO-1625
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1625
>  Project: Geronimo
> Type: Task
>   Components: buildsystem
> Versions: 1.x
> Reporter: Jacek Laskowski
> Assignee: Jacek Laskowski
> Priority: Minor

>
> Remove everything but the "new" goals, m:co, m:idea and m:eclipse. Most of 
> the m goals are of no use.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Migrating to maven 2


Gianny Damour wrote:

Basically, this is how I see a migration module by module working:
1. take one module;
2. write its pom.xml;
3. remove from its project.xml all the external dependencies, i.e. the 
non Geronimo dependencies (they are no more required as they are now 
defined by pom.xml); and

4. update its maven.xml to invoke the relevant M2 build goal.


For this to work, the m2 builds must have the same groupId as the m1 
builds, right? So we need to make a decision about which strategy to use:


1) Use different groupIds for the m1 and m2 build, keep the two build 
systems work simultaneously until migration is completed.
2) Use the same groupId for the m1 and m2 build, replace the m1 builds 
when the m2 builds are completed.


I say we give 2) a shot, and fall back to 1) if it for some reason does 
not work.


/Anders

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


On 15 Feb 2006, at 14:48, Lance Waterman wrote:

In the spirit of nailing down criteria, I would agree with;

... avoid the BPEL
engine having to write a container, a deployment model and a suite of
'binding components' to different SOAP stacks, WS-* policies and
transports - together with all the runtime management.


With regard to "runtime management" I am thinking transactions,  
resource

allocation, etc ... but not BPEL process instance management.


Agreed - the BPEL engine must do its own persistence. Hopefully the  
BPEL engine can also expose a bunch of MBeans for management too. But  
the BPEL engine could rely on an external container such as JBI to  
handle runtime hot-deployment of BPELs etc


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

Re: Covalent and Geronimo support


Hi Jim,
Pls don't feel uncomfortable. Would you have a prepared "speach" for this announcement in the 
"Geronimo News" section (about a paragraph). I'll be glad to add it to the updated site.


Look at the following example for an idea on how the section is structured.

2006-01-05
Geronimo Version 1.0 is now Available

Geronimo Version 1.0 which has passed the J2EE Certification Test Suite is now available for 
download here. This release represents the combined efforts of many engineers from several 
OpenSource projects and individual contributors from around the world. Please download, use the 
product and provide your comments and feedback to [EMAIL PROTECTED]


I'll squeeze this update in the JIRA as soon as I get it from you.

Cheers!
Hernan

Jim Jagielski wrote:


On Feb 7, 2006, at 9:21 AM, Rodent of Unusual Size wrote:



http://www.covalent.net/about/news/pressreleases.html?pressid=83

Let's put a link to that in the 'news' section on the
project front page.
- --
#kenP-)}

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

"Millennium hand and shrimp!"




Feeling very uncomfortable asking about this, for
obvious reasons :), but with the updates going on
with the site, could this be added in?

Re: Sample plan bits for configId branch, please review!

2006-02-15 Thread Paul McMahan

Both options seem pretty equal to me in terms of what they can express
but I like the second option better mostly for stylistic reasons. 
Namely, based on a hunch that typical deployment plans would be less
verbose (and therefore less error prone) using this option.

A few suggestions for the second option:

-   Make the current environment/configId element also be a child of the dependency element.
    This would help make it clear that the "type", "groupId", "version", etc. elements describe
    the target of the dependency and not the dependency itself.
-   "scope" seems a bit of a misnomer to me, I think "dependency-type" might be clearer, or
    you may prefer just "type" if you agree with the previous suggestion
-   For the value of scope (aka dependency-type) I'm concerned that "both" could be
    misleading since it already has more than two potential values and more could be added
    later. So I would suggest listing each scope individually.

Here's an example of what the dependency element could look like based on these suggestions:
    
    

        geronimo

            car

            geronimo-gbean-deployer

            1.0.1-SNAPSHOT
    

        
            service
            classes
 ...
    
   
Best wishes,
Paul

On 2/14/06, David Jencks <[EMAIL PROTECTED]
> wrote:
We need some widespread thought about the new xml schema we'regetting in 1.1.   Dain and I are not particularly thrilled with theelement names but haven't thought of improvements.  We also thoughtof an alternate way of presenting the info and would like opinions on
which is better.The schema currently in svn in the configid branch results in plansthat start like this:  [snip]

[jira] Updated: (GERONIMO-1629) More maven 2 poms

 [ http://issues.apache.org/jira/browse/GERONIMO-1629?page=all ]

Anders Hessellund Jensen updated GERONIMO-1629:
---

Attachment: maven-migration-more-poms.diff

> More maven 2 poms
> -
>
>  Key: GERONIMO-1629
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1629
>  Project: Geronimo
> Type: Sub-task
> Reporter: Anders Hessellund Jensen
>  Attachments: maven-migration-more-poms.diff
>
> I have created some more POMs. The list of modules with POMs is now:
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> 
> [INFO] Geronimo ... SUCCESS 
> [1.781s]
> [INFO] Geronimo :: Activation . SUCCESS 
> [1.000s]
> [INFO] Geronimo :: Util ... SUCCESS 
> [0.453s]
> [INFO] Geronimo :: Kernel . SUCCESS 
> [0.297s]
> [INFO] Geronimo :: Common . SUCCESS 
> [0.125s]
> [INFO] Geronimo :: System . SUCCESS 
> [0.234s]
> [INFO] Geronimo :: Management API . SUCCESS 
> [0.141s]
> [INFO] Geronimo :: Core ... SUCCESS 
> [0.109s]
> [INFO] Geronimo :: J2EE ... SUCCESS 
> [0.110s]
> [INFO] Geronimo :: Security ... SUCCESS 
> [0.328s]
> [INFO] Geronimo :: Transaction  SUCCESS 
> [0.281s]
> [INFO] Geronimo :: Naming . SUCCESS 
> [0.125s]
> [INFO] Geronimo :: Client . SUCCESS 
> [0.187s]
> [INFO] Geronimo :: Deployment . SUCCESS 
> [0.110s]
> [INFO] Geronimo :: Connector .. SUCCESS 
> [0.312s]
> [INFO] Geronimo :: J2EE Schema  SUCCESS 
> [1.407s]
> [INFO] Geronimo :: Service :: Builder . SUCCESS 
> [0.250s]
> [INFO] Geronimo :: Deploy :: Common Config  SUCCESS 
> [0.062s]
> [INFO] Geronimo :: Security :: Builder  SUCCESS 
> [0.266s]
> [INFO] Geronimo :: J2EE :: Builder  SUCCESS 
> [0.281s]
> [INFO] Geronimo :: Test :: DDBeans  SUCCESS 
> [0.109s]
> [INFO] Geronimo :: Connector :: Builder ... SUCCESS 
> [0.563s]
> [INFO] Geronimo :: Configuration Converter  SUCCESS 
> [0.078s]
> [INFO] Geronimo :: Web :: Builder . SUCCESS 
> [0.359s]
> [INFO] Geronimo :: Deploy :: JSR-88 ... SUCCESS 
> [0.578s]
> [INFO] Geronimo :: Deploy :: CLI Tool . SUCCESS 
> [0.391s]
> [INFO] Geronimo :: Derby .. SUCCESS 
> [0.094s]
> [INFO] Geronimo :: JavaMail Transport . SUCCESS 
> [0.140s]
> [INFO] Geronimo :: JMX Remoting ... SUCCESS 
> [0.047s]
> [INFO] Geronimo :: Mail ... SUCCESS 
> [0.125s]
> [INFO] Geronimo :: Scripts  SUCCESS 
> [0.063s]
> [INFO] Geronimo :: Session  SUCCESS 
> [0.094s]
> [INFO] Geronimo :: Spring . SUCCESS 
> [0.796s]
> [INFO] Geronimo :: Timer .. SUCCESS 
> [0.329s]
> [INFO] Geronimo :: Web Services ... SUCCESS 
> [0.125s]
> [INFO] 
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESSFUL
> [INFO] 
> 
> [INFO] Total time: 13 seconds
> [INFO] Finished at: Wed Feb 15 16:01:36 CET 2006
> [INFO] Final Memory: 10M/22M
> [INFO] 
> 
> Some builders uses jelly to assemble j2ee archives for testing purposes. 
> These tests have not been migrated. geronimo-jsr88 and geronimo-deploy-tool 
> are missing manifest files. There are probably other issues and omissions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1629) More maven 2 poms

More maven 2 poms
-

 Key: GERONIMO-1629
 URL: http://issues.apache.org/jira/browse/GERONIMO-1629
 Project: Geronimo
Type: Sub-task
Reporter: Anders Hessellund Jensen


I have created some more POMs. The list of modules with POMs is now:

[INFO] 

[INFO] Reactor Summary:
[INFO] 

[INFO] Geronimo ... SUCCESS [1.781s]
[INFO] Geronimo :: Activation . SUCCESS [1.000s]
[INFO] Geronimo :: Util ... SUCCESS [0.453s]
[INFO] Geronimo :: Kernel . SUCCESS [0.297s]
[INFO] Geronimo :: Common . SUCCESS [0.125s]
[INFO] Geronimo :: System . SUCCESS [0.234s]
[INFO] Geronimo :: Management API . SUCCESS [0.141s]
[INFO] Geronimo :: Core ... SUCCESS [0.109s]
[INFO] Geronimo :: J2EE ... SUCCESS [0.110s]
[INFO] Geronimo :: Security ... SUCCESS [0.328s]
[INFO] Geronimo :: Transaction  SUCCESS [0.281s]
[INFO] Geronimo :: Naming . SUCCESS [0.125s]
[INFO] Geronimo :: Client . SUCCESS [0.187s]
[INFO] Geronimo :: Deployment . SUCCESS [0.110s]
[INFO] Geronimo :: Connector .. SUCCESS [0.312s]
[INFO] Geronimo :: J2EE Schema  SUCCESS [1.407s]
[INFO] Geronimo :: Service :: Builder . SUCCESS [0.250s]
[INFO] Geronimo :: Deploy :: Common Config  SUCCESS [0.062s]
[INFO] Geronimo :: Security :: Builder  SUCCESS [0.266s]
[INFO] Geronimo :: J2EE :: Builder  SUCCESS [0.281s]
[INFO] Geronimo :: Test :: DDBeans  SUCCESS [0.109s]
[INFO] Geronimo :: Connector :: Builder ... SUCCESS [0.563s]
[INFO] Geronimo :: Configuration Converter  SUCCESS [0.078s]
[INFO] Geronimo :: Web :: Builder . SUCCESS [0.359s]
[INFO] Geronimo :: Deploy :: JSR-88 ... SUCCESS [0.578s]
[INFO] Geronimo :: Deploy :: CLI Tool . SUCCESS [0.391s]
[INFO] Geronimo :: Derby .. SUCCESS [0.094s]
[INFO] Geronimo :: JavaMail Transport . SUCCESS [0.140s]
[INFO] Geronimo :: JMX Remoting ... SUCCESS [0.047s]
[INFO] Geronimo :: Mail ... SUCCESS [0.125s]
[INFO] Geronimo :: Scripts  SUCCESS [0.063s]
[INFO] Geronimo :: Session  SUCCESS [0.094s]
[INFO] Geronimo :: Spring . SUCCESS [0.796s]
[INFO] Geronimo :: Timer .. SUCCESS [0.329s]
[INFO] Geronimo :: Web Services ... SUCCESS [0.125s]
[INFO] 

[INFO] 

[INFO] BUILD SUCCESSFUL
[INFO] 

[INFO] Total time: 13 seconds
[INFO] Finished at: Wed Feb 15 16:01:36 CET 2006
[INFO] Final Memory: 10M/22M
[INFO] 


Some builders uses jelly to assemble j2ee archives for testing purposes. These 
tests have not been migrated. geronimo-jsr88 and geronimo-deploy-tool are 
missing manifest files. There are probably other issues and omissions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

problem building head

2006-02-15 Thread Conrad O'Dea

Hi there, 

I am having problems getting a build of Geronimo.  I am following the
instructions at: http://wiki.apache.org/geronimo/Building
I've basically done the following (and several combinations thereof): 

  % svn co  https://svn.apache.org/repos/asf/geronimo/trunk geronimo
  % cd geronimo
  % maven m:fresh-checkout
  % maven new -Dmaven.test.skip=true -Dmaven.itest.skip=true

and after a good healthy time of doing stuff it fails with: 

"The build cannot continue because of the following unsatisfied
dependency:

geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar"

I've also checked-out geronimo-specs and built it with 'mvn install' but
this jar has not been built anywhere in that working copy or either
~/.maven or ~/.m2 repositories.  Nor can I find it in the maven
repository at http://cvs.apache.org/repository/geronimo-spec/jars/.

Any help appreciated.

thanks
Conrad

Re: Covalent and Geronimo support

2006-02-15 Thread Jim Jagielski



On Feb 7, 2006, at 9:21 AM, Rodent of Unusual Size wrote:


http://www.covalent.net/about/news/pressreleases.html?pressid=83

Let's put a link to that in the 'news' section on the
project front page.
- --
#kenP-)}

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

"Millennium hand and shrimp!"



Feeling very uncomfortable asking about this, for
obvious reasons :), but with the updates going on
with the site, could this be added in?

Re: Migrating to maven 2

2006-02-15 Thread Gianny Damour


Anders Hessellund Jensen wrote:


Gianny Damour wrote:


Basically, this is how I see a migration module by module working:
1. take one module;
2. write its pom.xml;
3. remove from its project.xml all the external dependencies, i.e. 
the non Geronimo dependencies (they are no more required as they are 
now defined by pom.xml); and

4. update its maven.xml to invoke the relevant M2 build goal.



Sounds like an excellent solution. My knowledge of jelly is very 
limited, could you show me an example on how to carry out step 4?


My Jelly is also very limited; yet you can call Ant from maven rather 
easily like this:




   
   
   
   
   

   
   
   
   
   



If you replace modules/kernel/maven.xml with the above script, then the 
new1 multiproject will actually build the kernel module with M2.


Thanks,
Gianny



/Anders

Re: Migrating to maven 2


Gianny Damour wrote:

Basically, this is how I see a migration module by module working:
1. take one module;
2. write its pom.xml;
3. remove from its project.xml all the external dependencies, i.e. the 
non Geronimo dependencies (they are no more required as they are now 
defined by pom.xml); and

4. update its maven.xml to invoke the relevant M2 build goal.


Sounds like an excellent solution. My knowledge of jelly is very 
limited, could you show me an example on how to carry out step 4?


/Anders

[jira] Commented: (GERONIMO-1628) [DayTrader] Tweaks to some wsappclient client files to match the WSDL file

2006-02-15 Thread Jesse McConnell (JIRA)

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

Jesse McConnell commented on GERONIMO-1628:
---

btw, these patchs are for if you are using axis to generate the ws code from 
the wsdl, axis generates a different interface then whatever generated the 
initial code

> [DayTrader] Tweaks to some wsappclient client files to match the WSDL file
> --
>
>  Key: GERONIMO-1628
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1628
>  Project: Geronimo
> Type: Bug
>   Components: sample apps
> Versions: 1.0.1
> Reporter: Vincent Massol
>  Attachments: clientApp.diff, clientScenario.diff
>
> Tweaks to the two client files to cover the change in the generated 
> interface, and one change in the actual method signature of an Integer to an 
> int

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1628) [DayTrader] Tweaks to some wsappclient client files to match the WSDL file

2006-02-15 Thread Vincent Massol (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1628?page=all ]

Vincent Massol updated GERONIMO-1628:
-

Attachment: clientApp.diff

> [DayTrader] Tweaks to some wsappclient client files to match the WSDL file
> --
>
>  Key: GERONIMO-1628
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1628
>  Project: Geronimo
> Type: Bug
>   Components: sample apps
> Versions: 1.0.1
> Reporter: Vincent Massol
>  Attachments: clientApp.diff, clientScenario.diff
>
> Tweaks to the two client files to cover the change in the generated 
> interface, and one change in the actual method signature of an Integer to an 
> int

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1628) [DayTrader] Tweaks to some wsappclient client files to match the WSDL file

2006-02-15 Thread Vincent Massol (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1628?page=all ]

Vincent Massol updated GERONIMO-1628:
-

Attachment: clientScenario.diff

> [DayTrader] Tweaks to some wsappclient client files to match the WSDL file
> --
>
>  Key: GERONIMO-1628
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1628
>  Project: Geronimo
> Type: Bug
>   Components: sample apps
> Versions: 1.0.1
> Reporter: Vincent Massol
>  Attachments: clientApp.diff, clientScenario.diff
>
> Tweaks to the two client files to cover the change in the generated 
> interface, and one change in the actual method signature of an Integer to an 
> int

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Migrating to maven 2

2006-02-15 Thread Gianny Damour


Jacek Laskowski wrote:


2006/2/15, Gianny Damour <[EMAIL PROTECTED]>:
 


Hi,

I also think that we should call m2 from m1 and avoid to maintain a dual
build during the migration. As pointed out by Dain, we could easily call
m2 from m1 by redefining the clean and build goals of m1 to invoke m2
clean and m2 install respectively:



   
   
   
   
   

   
   
   
   
   


   



Then I don't understand why it would save us any work *now*? How could
m1 and m2 know about the dependencies if there were no project.xml or
pom.xml, respectively? Once we provide pom.xml's, I understand it
would be the next step to just call off m2 from m1, but it's not
possible now.
 

It save us from the extra work of ensuring that the m2 build works 
properly all along the migration. At this stage, we could call m2 from 
m1 for each module having a pom.xml file and I think that this is 
achievable right now.


Basically, this is how I see a migration module by module working:
1. take one module;
2. write its pom.xml;
3. remove from its project.xml all the external dependencies, i.e. the 
non Geronimo dependencies (they are no more required as they are now 
defined by pom.xml); and

4. update its maven.xml to invoke the relevant M2 build goal.

The M1 reactor still drives the multiproject build. This means that we 
do not update the top level maven.xml file. When all the projects of a 
given multiproject build, e.g. new1, has been migrated, we let M2 drives 
the multiproject build.



BTW, what benefit would give us the above snippet? Why would I call
maven rather than mvn on the command line when pom.xml's are
available?
 

From the top level root source, we call maven which delegates 
transparently to mvn if the module is M2 enabled.


 


BTW, indeed, maven-one-plugin installs a m2 artefact into the local
maven repo.
   



Wait, the local maven repo? I say nothing about the local repo, which
I understood could be drawn from 'indeed' of yours.
 

Sorry - I was sure that you wanted to highlight the fact that a mix 
M1-M2 build was requiring M2 to be able to get some of its dependencies 
from a local M1 repository vice-versa.


Thanks,
Gianny

 


Gianny
   



Jacek

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

[jira] Created: (GERONIMO-1628) [DayTrader] Tweaks to some wsappclient client files to match the WSDL file

2006-02-15 Thread Vincent Massol (JIRA)

[DayTrader] Tweaks to some wsappclient client files to match the WSDL file
--

 Key: GERONIMO-1628
 URL: http://issues.apache.org/jira/browse/GERONIMO-1628
 Project: Geronimo
Type: Bug
  Components: sample apps  
Versions: 1.0.1
Reporter: Vincent Massol


Tweaks to the two client files to cover the change in the generated interface, 
and one change in the actual method signature of an Integer to an int

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1317) Integration of the "new" maven goals with existing goals

2006-02-15 Thread Anita Kulshreshtha (JIRA)

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

Anita Kulshreshtha commented on GERONIMO-1317:
--

Great work! I think this patch should be applied because :
1. It enables 'includes' and  'excudes'  defined in the etc/project.properties 
file. It is very useful for curing build failures.
2. The names are easy to remember as compared to newi's  

> Integration of the "new" maven goals with existing goals
> 
>
>  Key: GERONIMO-1317
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1317
>  Project: Geronimo
> Type: Bug
>   Components: buildsystem
> Versions: 1.0, 1.1
>  Environment: Maven 1.1Beta2 on WinXP
> Reporter: Donald Woods
> Assignee: Jacek Laskowski
> Priority: Critical
>  Fix For: 1.1
>  Attachments: Geronimo-1317.patch, maven.xml, project.properties
>
> For ongoing development builds, we need to get the clean, eclipse, idea and 
> other Maven goals that we used to have working again.
> I have created updated \maven.xml and \project.properties files based on 1.0 
> Rev355316, which renames and integrates the new0-new5 goals into the 
> m:default goal, only tries to build openejb and tranql if those directories 
> exist and enables the usage of the rebuild-all, build-all, build, clean, 
> clean-all, eclipse and idea goals.
> I'll attach the patch files and copies of the updated files for testing 
> before integrating the changes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Sample plan bits for configId branch, please review!

2006-02-15 Thread Aaron Mulder

Bruce,

I'm pretty sure the ObjectName isn't sensitive to ordering, but in any
case the domain is always separated from the rest of the name=value
components, so all together I don't think any ordering is necessary
for the name keys.

David,

I could go either way on the syntax.  I think overall I prefer
distinct elements for things with separate meanings, but it wouldn't
break my heart to do it the other way.  The best I can come up with
for "scope" is "behavior" or "load".  Maybe load is better --
load="classes" or load="gbeans" or load="both"

The biggest change I'd request is to take the Id of the end of group
and artifact.  I don't think it adds anything, and it makes it harder
to read and repeat (is that Id or ld, for example).  If we really have
to keep it, I'd prefer artifact-id and group-id, but I really don't
see why we shouldn't just use group, type, artifact, and version.

Thanks,
Aaron

On 2/14/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On 2/14/06, David Jencks <[EMAIL PROTECTED]> wrote:
> > We need some widespread thought about the new xml schema we're
> > getting in 1.1.   Dain and I are not particularly thrilled with the
> > element names but haven't thought of improvements.  We also thought
> > of an alternate way of presenting the info and would like opinions on
> > which is better.
> >
> > The schema currently in svn in the configid branch results in plans
> > that start like this:
> >
> > http://geronimo.apache.org/xml/ns/deployment-1.1";>
> >
> >  
> >geronimo
> >car
> >geronimo-gbean-deployer
> >1.0.1-SNAPSHOT
> >  
> > 
> >  
> >domain
> >geronimo.maven
> >  
> >  
> >J2EEServer
> >geronimo
> >  
> >  
> >
> >  geronimo
> >  car
> >  geronimo-system
> >  1.0.1-SNAPSHOT
> >
> >
> >  geronimo
> >  geronimo-common
> >  1.0.1-SNAPSHOT
> >
> >
> >  geronimo
> >  geronimo-deployment
> >  1.0.1-SNAPSHOT
> >
> >  
> > 
> >  
> >geronimo
> >car
> >geronimo-j2ee
> >1.0.1-SNAPSHOT
> >  
> >
> >
> > > class="org.apache.geronimo.deployment.Deployer">
> >
> >
> > An alternate layout is more similar to m2 with the idea of different
> > functions for a dependency shown by a "scope" element.  Scope doesn't
> > seem like the right element name for us. (sorry about the lousy
> > indenting)
> >
> > http://geronimo.apache.org/xml/ns/deployment-1.1";>
> >
> >  
> >geronimo
> >car
> >geronimo-gbean-deployer
> >1.0.1-SNAPSHOT
> >  
> > 
> >  
> >domain
> >geronimo.maven
> >  
> >  
> >J2EEServer
> >geronimo
> >  
> >< dependency>
> >  geronimo
> >  car
> >  geronimo-system
> >  1.0.1-SNAPSHOT
> >  full
> >
> >
> >  geronimo
> >  geronimo-common
> >  1.0.1-SNAPSHOT
> >  class
> >
> >< dependency>
> >  geronimo
> >  geronimo-deployment
> >  1.0.1-SNAPSHOT
> >  include
> >
> >  < dependency>
> >geronimo
> >car
> >geronimo-j2ee
> >1.0.1-SNAPSHOT
> >service
> > 
> >
> >
> > > class="org.apache.geronimo.deployment.Deployer">
> >
> > Here, the scopes have meaning as follows:
> >
> > both -- both classes and services (gbeans), like import
> > classes -- only classes, if a car don't start the gbeans for us, like
> > dependency
> > services -- only gbeans, don't add classes to our classpath, like
> > reference (new element shown in first example)
> > include -- copy the artifact into the current configuration.  This
> > seems like a separate dimension not related to the previous scopes.
> >
> > Again, please study these and comment.
>
> Here are my thoughts so far.
>
> I definitely prefer the second example better because it requires
> specifying the scope on a per dependency basis. In fact, I think that
> specifying everything for a given dependency with that dependency is
> far easier to understand. I also think that this is less confusing and
> much more like Maven which many people already understand.
>
> Speaking of dependencies, I'm thinking that an element named
> dependencies should be used as a container element for each dependency
> element. Again, similar to Maven which many people already understand.
>
> I also have some additional suggestions:
>
> 1) It seems like the name-key elements should be wrapped in another
> element. Perhaps an element named name-pattern or something similar.
>
> 2) How is order specified on the name-key elements? It's important to
> assemble these elements in the proper order.
>
> 3) In fact, just allowing a single string pattern would also be a nice
> alternative too.
>
> Here is one example:
>

Re: Migrating to maven 2

2006-02-15 Thread Jacek Laskowski

2006/2/15, Anders Hessellund Jensen <[EMAIL PROTECTED]>:
> We need a m2 version of the geronimo-dependency-plugin. Is anyone
> working on this, or perhaps it already exists somewhere?

AFAIK, the answers are no and no, appropriately. If you'd start
working on it, create a JIRA task item, so it's recorded. The work
could be done in sandbox.

> /Anders

Jacek

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

Re: Migrating to maven 2

We need a m2 version of the geronimo-dependency-plugin. Is anyone 
working on this, or perhaps it already exists somewhere?


/Anders

Re: Migrating to maven 2

2006-02-15 Thread Jacek Laskowski

2006/2/15, Gianny Damour <[EMAIL PROTECTED]>:
> Hi,
>
> I also think that we should call m2 from m1 and avoid to maintain a dual
> build during the migration. As pointed out by Dain, we could easily call
> m2 from m1 by redefining the clean and build goals of m1 to invoke m2
> clean and m2 install respectively:
>
> 
>
> 
> 
> 
> 
> 
>
> 
> 
> 
> 
> 
>
> 

Then I don't understand why it would save us any work *now*? How could
m1 and m2 know about the dependencies if there were no project.xml or
pom.xml, respectively? Once we provide pom.xml's, I understand it
would be the next step to just call off m2 from m1, but it's not
possible now.

BTW, what benefit would give us the above snippet? Why would I call
maven rather than mvn on the command line when pom.xml's are
available?

> BTW, indeed, maven-one-plugin installs a m2 artefact into the local
> maven repo.

Wait, the local maven repo? I say nothing about the local repo, which
I understood could be drawn from 'indeed' of yours.

> Gianny

Jacek

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

Re: Migrating to maven 2

2006-02-15 Thread Gianny Damour


Hi,

I also think that we should call m2 from m1 and avoid to maintain a dual 
build during the migration. As pointed out by Dain, we could easily call 
m2 from m1 by redefining the clean and build goals of m1 to invoke m2 
clean and m2 install respectively:




   
   
   
   
   

   
   
   
   
   



BTW, indeed, maven-one-plugin installs a m2 artefact into the local 
maven repo.


Thanks,
Gianny

Jacek Laskowski wrote:


2006/2/15, Anders Hessellund Jensen <[EMAIL PROTECTED]>:

 


Cool. Is it possible to make m2 deploy the builds to the local m1
repository as part of the build process? That would be very helpful.
   



I haven't tested it, but the specs' pom.xml uses such a plugin -
maven-one-plugin.

 
   maven-one-plugin
   
 
   
 install-maven-one-repository
 deploy-maven-one-repository
   
   
 apache
 
scpexe://cvs.apache.org/www/cvs.apache.org/repository
   
 
   
 

so I'd say it is.

 


/Anders
   



Jacek

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

[jira] Commented: (GERONIMO-1627) LoginKerberosNonGeronimoTest fails

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

Anders Hessellund Jensen commented on GERONIMO-1627:


Unfortunately, 
TEST-org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest.txt is 
empty, the xml report as well.

> LoginKerberosNonGeronimoTest fails
> --
>
>  Key: GERONIMO-1627
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1627
>  Project: Geronimo
> Type: Bug
>   Components: security
> Reporter: Anders Hessellund Jensen

>
> Output when running the junit test suite:
> test:test:
> [junit] Running org.apache.geronimo.security.ContextManagerTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,5 sec
> [junit] Running org.apache.geronimo.security.jaas.ConfigurationEntryTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1,093 sec
> [junit] Running 
> org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest
> [junit] Error calling function Protocol status: 1312
> [junit] FormatMessage failed with 1815
> [junit] [ERROR] Test 
> org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest FAILED
> [junit] Running org.apache.geronimo.security.jaas.LoginKerberosTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,75 sec
> [junit] Running org.apache.geronimo.security.jaas.LoginPropertiesFileTest
> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1,453 sec
> [junit] Running org.apache.geronimo.security.jaas.LoginSQLTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1,687 sec
> [junit] Running org.apache.geronimo.security.jaas.MultipleLoginDomainTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,234 sec
> [junit] Running org.apache.geronimo.security.jaas.NoLoginModuleReuseTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,234 sec
> [junit] Running org.apache.geronimo.security.jaas.TimeoutTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11,625 sec
> [junit] Running 
> org.apache.geronimo.security.jacc.GeronimoPolicyConfigurationFactoryTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,219 sec
> [junit] Running 
> org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1,234 sec
> [junit] Running org.apache.geronimo.security.remoting.jmx.RemoteLoginTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1,187 sec
> BUILD FAILED
> File.. C:\Documents and 
> Settings\ahj\.maven\cache\maven-test-plugin-1.7\plugin.jelly
> Element... fail
> Line.. 183
> Column -1
> There were test failures.
> Total time   : 35 seconds 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Migrating to maven 2

2006-02-15 Thread Jacek Laskowski

2006/2/15, Anders Hessellund Jensen <[EMAIL PROTECTED]>:

> Cool. Is it possible to make m2 deploy the builds to the local m1
> repository as part of the build process? That would be very helpful.

I haven't tested it, but the specs' pom.xml uses such a plugin -
maven-one-plugin.

  
maven-one-plugin

  

  install-maven-one-repository
  deploy-maven-one-repository


  apache
  
scpexe://cvs.apache.org/www/cvs.apache.org/repository

  

  

so I'd say it is.

> /Anders

Jacek

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

[jira] Commented: (GERONIMO-1627) LoginKerberosNonGeronimoTest fails

2006-02-15 Thread Jacek Laskowski (JIRA)

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

Jacek Laskowski commented on GERONIMO-1627:
---

Could you attach the 
target/test-reports/TEST-org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest.txt
 file as well?

> LoginKerberosNonGeronimoTest fails
> --
>
>  Key: GERONIMO-1627
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1627
>  Project: Geronimo
> Type: Bug
>   Components: security
> Reporter: Anders Hessellund Jensen

>
> Output when running the junit test suite:
> test:test:
> [junit] Running org.apache.geronimo.security.ContextManagerTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,5 sec
> [junit] Running org.apache.geronimo.security.jaas.ConfigurationEntryTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1,093 sec
> [junit] Running 
> org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest
> [junit] Error calling function Protocol status: 1312
> [junit] FormatMessage failed with 1815
> [junit] [ERROR] Test 
> org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest FAILED
> [junit] Running org.apache.geronimo.security.jaas.LoginKerberosTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,75 sec
> [junit] Running org.apache.geronimo.security.jaas.LoginPropertiesFileTest
> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1,453 sec
> [junit] Running org.apache.geronimo.security.jaas.LoginSQLTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1,687 sec
> [junit] Running org.apache.geronimo.security.jaas.MultipleLoginDomainTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,234 sec
> [junit] Running org.apache.geronimo.security.jaas.NoLoginModuleReuseTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,234 sec
> [junit] Running org.apache.geronimo.security.jaas.TimeoutTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11,625 sec
> [junit] Running 
> org.apache.geronimo.security.jacc.GeronimoPolicyConfigurationFactoryTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,219 sec
> [junit] Running 
> org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1,234 sec
> [junit] Running org.apache.geronimo.security.remoting.jmx.RemoteLoginTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1,187 sec
> BUILD FAILED
> File.. C:\Documents and 
> Settings\ahj\.maven\cache\maven-test-plugin-1.7\plugin.jelly
> Element... fail
> Line.. 183
> Column -1
> There were test failures.
> Total time   : 35 seconds 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1627) LoginKerberosNonGeronimoTest fails

LoginKerberosNonGeronimoTest fails
--

 Key: GERONIMO-1627
 URL: http://issues.apache.org/jira/browse/GERONIMO-1627
 Project: Geronimo
Type: Bug
  Components: security  
Reporter: Anders Hessellund Jensen


Output when running the junit test suite:

test:test:
[junit] Running org.apache.geronimo.security.ContextManagerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,5 sec
[junit] Running org.apache.geronimo.security.jaas.ConfigurationEntryTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1,093 sec
[junit] Running 
org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest
[junit] Error calling function Protocol status: 1312
[junit] FormatMessage failed with 1815
[junit] [ERROR] Test 
org.apache.geronimo.security.jaas.LoginKerberosNonGeronimoTest FAILED
[junit] Running org.apache.geronimo.security.jaas.LoginKerberosTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,75 sec
[junit] Running org.apache.geronimo.security.jaas.LoginPropertiesFileTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1,453 sec
[junit] Running org.apache.geronimo.security.jaas.LoginSQLTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1,687 sec
[junit] Running org.apache.geronimo.security.jaas.MultipleLoginDomainTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,234 sec
[junit] Running org.apache.geronimo.security.jaas.NoLoginModuleReuseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,234 sec
[junit] Running org.apache.geronimo.security.jaas.TimeoutTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11,625 sec
[junit] Running 
org.apache.geronimo.security.jacc.GeronimoPolicyConfigurationFactoryTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,219 sec
[junit] Running 
org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1,234 sec
[junit] Running org.apache.geronimo.security.remoting.jmx.RemoteLoginTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1,187 sec

BUILD FAILED
File.. C:\Documents and 
Settings\ahj\.maven\cache\maven-test-plugin-1.7\plugin.jelly
Element... fail
Line.. 183
Column -1
There were test failures.
Total time   : 35 seconds 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Migrating to maven 2