Re: Geronimo ORB progress

[Alan D. Cabrera]

Lars Kühne wrote, On 11/17/2005 3:19 PM:


Kevan Miller wrote:



On 11/17/05, *Dain Sundstrom* <[EMAIL PROTECTED] > 
wrote:


+1 Using JIRA for tracking progress of the ORB would be great.

We already have a CORBA component, so I suggest you create an 
"Add an

ORB implementation" issue that can be the parent of all the tasks.



Done, GERONIMO-1198



Lars,

I think that we should make focused jira issues rather than a single 
umbrella issue that tracks all work on the CORBA server.  Ideally, 
people would put their stake in the ground by writing about the 
architectural bit that they are going to implement in the wiki.  Then 
follow up with a a single Jira issue that basically marks the bit that 
you are going to implement.   File sub-tasks for the patches that you 
are submitting.


WDYT?


Regards,
Alan

Re: SchemaConversionUtils/GenericToSpecificPlanConverter woes continue?

[Jian Liao]

Hi dj,I am sorry to mention this again.The namespace defined in modules\tomcat-builder\src\schema\geronimo-tomcat-config-1.0.xsd is different with the namespace you used in your unit test case modules\web-builder\src\test\org\apache\geronimo\web\deployment\GenericToSpecificPlanConverterTest.java.
In the runtime,server will creat the GenericToSpecificPlanConverter instance like this:XmlObject webPlan = new GenericToSpecificPlanConverter(GerTomcatDocument.type.getDocumentElementName().getNamespaceURI(),    
TomcatWebAppDocument.type.getDocumentElementName().getNamespaceURI(), "tomcat").convertToSpecificPlan(rawPlan);The configNamespace member variable value in GenericToSpecificPlanConverter instance will come from 
GerTomcatDocument.type.getDocumentElementName().getNamespaceURI(), which GerTomcatDocument class is generated by modules\tomcat-builder\src\schema\geronimo-tomcat-config-1.0.xsd, therefore I think geronimo-tomcat-config-1.0.xsd
 is out of sync with your unit test code. Which one should I use?- Jian LiaoOn 11/18/05, Jacek Laskowski <
[EMAIL PROTECTED]> wrote:David Jencks wrote:> Your original namespace should now work, see latest change on
> GERONIMO-1175It worked. Thanks!> david jencksJacek

Re: AMD Opteron Equipment for Development/Testing

[Alan D. Cabrera]

David Blevins wrote, On 11/16/2005 4:16 PM:


On Nov 16, 2005, at 2:25 PM, Winston Damarillo wrote:


Kyle,

Very cool !

If the machines need to live in a datacenter with some admin  
support. we would be glad to host it at Simula's cage along with  the 
other gbuild servers.




That would actually be extremely convenient.  Nice to have a fast  
switch between the boxes rather than a large span of internet.


Do they come with rails?


Regards,
Alan

Re: SchemaConversionUtils/GenericToSpecificPlanConverter woes continue?

[David Jencks]

After pointing it out to me so many times, I finally found what you are  
talking about and fixed the test (I hope).


thanks again
david jencks

On Nov 17, 2005, at 6:25 PM, Jian Liao wrote:


Hi dj,
I am sorry to mention this again.
The namespace defined in  
modules\tomcat-builder\src\schema\geronimo-tomcat-config-1.0.xsd is  
different with the namespace you used in your unit test case  
modules\web- 
builder\src\test\org\apache\geronimo\web\deployment\GenericToSpecificPl 
anConverterTest.java.


In the runtime,server will creat the GenericToSpecificPlanConverter  
instance like this:
XmlObject webPlan = new  
GenericToSpecificPlanConverter(GerTomcatDocument.type.getDocumentElemen 
tName().getNamespaceURI(),     
TomcatWebAppDocument.type.getDocumentElementName().getNamespaceURI(),  
"tomcat").convertToSpecificPlan(rawPlan);


The configNamespace member variable value in  
GenericToSpecificPlanConverter instance will come from  
GerTomcatDocument.type.getDocumentElementName().getNamespaceURI(),  
which GerTomcatDocument class is generated by  
modules\tomcat-builder\src\schema\geronimo-tomcat-config-1.0.xsd,  
therefore I think geronimo-tomcat-config-1.0.xsd  is out of sync with  
your unit test code. Which one should I use?


- Jian Liao

On 11/18/05, Jacek Laskowski < [EMAIL PROTECTED]> wrote:David  
Jencks wrote:

> Your original namespace should now work, see latest change on
> GERONIMO-1175

It worked. Thanks!

> david jencks

Jacek

Re: AMD Opteron Equipment for Development/Testing

[Jeff Genender]

Alan D. Cabrera wrote:


Do they come with rails?


Alan, I hate to break it to you, but Geronimo is written in Java, not 
Ruby ;-)





Regards,
Alan

[jira] Updated: (GERONIMO-1197) Geronimo Console Look and Feel installement #2 - icons in navigation, improved images/layout.

[Joe Bohn (JIRA)]

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

Joe Bohn updated GERONIMO-1197:
---

Attachment: NewLookIcons.patch
applications.zip

This adds improvements to the look and feel, icons in the navigation area, an 
improved login page, and an improved about page.

The patch includes svn add commands for the icons (not sure if I'm supposed to 
do that for binary files or not).  The icons themselves are in the 
applications.zip and should be extracted from %geronimo_root%.   Likewise, the 
patch should also be applied to %geronimo_root%.

> Geronimo Console Look and Feel installement #2  - icons in navigation, 
> improved images/layout.
> --
>
>  Key: GERONIMO-1197
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1197
>  Project: Geronimo
> Type: Improvement
>   Components: console
> Versions: 1.0
>  Environment: all
> Reporter: Joe Bohn
> Assignee: Joe Bohn
>  Fix For: 1.0
>  Attachments: NewLookIcons.patch, applications.zip
>
> This is the next refinement in the look and feel to make the Geronimo Console 
> look more professional.
> This includes:
>  - Icons in navigation area
>  - improved shading
>  - improved login page with about link
>  - slightly improved about page
>  - overall improvements to match Epiqs mock-ups better.

-- 
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-1197) Geronimo Console Look and Feel installement #2 - icons in navigation, improved images/layout.

[Joe Bohn (JIRA)]

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

Joe Bohn updated GERONIMO-1197:
---

Geronimo Info: [Patch Available]

Patch is now available.

> Geronimo Console Look and Feel installement #2  - icons in navigation, 
> improved images/layout.
> --
>
>  Key: GERONIMO-1197
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1197
>  Project: Geronimo
> Type: Improvement
>   Components: console
> Versions: 1.0
>  Environment: all
> Reporter: Joe Bohn
> Assignee: Joe Bohn
>  Fix For: 1.0
>  Attachments: NewLookIcons.patch, applications.zip
>
> This is the next refinement in the look and feel to make the Geronimo Console 
> look more professional.
> This includes:
>  - Icons in navigation area
>  - improved shading
>  - improved login page with about link
>  - slightly improved about page
>  - overall improvements to match Epiqs mock-ups better.

-- 
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: - Tomcat Examples in Geronimo - needed for v1

[Dave Colasurdo]

Jeff Genender wrote:

Ok...

I have placed the following files:

geronimo-jsp-examples-TOMCAT5.5.12.war
geronimo-servlet-examples-TOMCAT5.5.12.war

They should be picked up and a part of ibiblio in a few hours.  They 
will be in the geronimo repository in the war directory.




Jeff,

The file name in ibiblio is geronimo-servlet-examples-TOMCAT5.5.12.war

The property "tomcat_version" has a value of 5.5.12

Using the following:

   
 geronimo
 geronimo-servlet-examples-TOMCAT
 ${tomcat_version}
 war
 
   true
 
   


Results in an extra "dash" (geronimo-servlet-examples-TOMCAT-5.5.12.war)

Of course, I can define a new property with the value "TOMCAT-5.5.12"..

Though, I suspect it may be better to rename the file to 
geronimo-servlet-examples-5.5.12 or 
geronimo-servlet-examples-TOMCAT-5.5.12 so that we can use the existing 
property.


What do you think?


Thanks
-Dave-

Re: - Tomcat Examples in Geronimo - needed for v1

[Jeff Genender]

Aww shoot...you are right.  My mistake...Ok...I will get it fixed.

Thanks,

Jeff

Dave Colasurdo wrote:

Jeff Genender wrote:

Ok...

I have placed the following files:

geronimo-jsp-examples-TOMCAT5.5.12.war
geronimo-servlet-examples-TOMCAT5.5.12.war

They should be picked up and a part of ibiblio in a few hours.  They 
will be in the geronimo repository in the war directory.




Jeff,

The file name in ibiblio is geronimo-servlet-examples-TOMCAT5.5.12.war

The property "tomcat_version" has a value of 5.5.12

Using the following:

   
 geronimo
 geronimo-servlet-examples-TOMCAT
 ${tomcat_version}
 war
 
   true
 
   


Results in an extra "dash" (geronimo-servlet-examples-TOMCAT-5.5.12.war)

Of course, I can define a new property with the value "TOMCAT-5.5.12"..

Though, I suspect it may be better to rename the file to 
geronimo-servlet-examples-5.5.12 or 
geronimo-servlet-examples-TOMCAT-5.5.12 so that we can use the existing 
property.


What do you think?


Thanks
-Dave-

Re: - Tomcat Examples in Geronimo - needed for v1

[Jeff Genender]

Ok fixed...on next sync the files will be:

geronimo-jsp-examples-tomcat-5.5.12.war
geronimo-servlet-examples-tomcat-5.5.12.war

Jeff

Dave Colasurdo wrote:

Jeff Genender wrote:

Ok...

I have placed the following files:

geronimo-jsp-examples-TOMCAT5.5.12.war
geronimo-servlet-examples-TOMCAT5.5.12.war

They should be picked up and a part of ibiblio in a few hours.  They 
will be in the geronimo repository in the war directory.




Jeff,

The file name in ibiblio is geronimo-servlet-examples-TOMCAT5.5.12.war

The property "tomcat_version" has a value of 5.5.12

Using the following:

   
 geronimo
 geronimo-servlet-examples-TOMCAT
 ${tomcat_version}
 war
 
   true
 
   


Results in an extra "dash" (geronimo-servlet-examples-TOMCAT-5.5.12.war)

Of course, I can define a new property with the value "TOMCAT-5.5.12"..

Though, I suspect it may be better to rename the file to 
geronimo-servlet-examples-5.5.12 or 
geronimo-servlet-examples-TOMCAT-5.5.12 so that we can use the existing 
property.


What do you think?


Thanks
-Dave-

validators

[Sachin Patel]

Could someone point me to where validation is being done on the 
deployment plans prior to deployment? Is there a single entry point for 
validation or is it being done within each of the builders?


Thanks

Re: AMD Opteron Equipment for Development/Testing

[Erin Mulder]

Jeff Genender wrote:
>> Do they come with rails?
> 
> Alan, I hate to break it to you, but Geronimo is written in Java, not
> Ruby ;-)

I'd be happy to help you remedy that. ;)

Cheers,
Erin (who's doing more Ruby than Java these days!)

Re: validators

[Aaron Mulder]

I think each builder does it separately, just by passing a flag to the
XmlBeans objects when loading them from the deployment plan
file/stream.  But I don't have the source code in front of me, so I
can't be more specific at the moment.

Aaron

On 11/18/05, Sachin Patel <[EMAIL PROTECTED]> wrote:
> Could someone point me to where validation is being done on the
> deployment plans prior to deployment? Is there a single entry point for
> validation or is it being done within each of the builders?
>
> Thanks
>

Re: Constructing deployment plans from Configuration GBeanData

[Vamsavardhana Reddy]

On 11/17/05, David Jencks <[EMAIL PROTECTED]> wrote:
On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:> If deployment plans are inside the archive (ear, war, etc.) they can> be obtained from config-store. If the deployment plan is supplied as
> an external file to the deployer and if the original file is not> available, the only way to get any information on the configuration is> from the Configuration GBeanData obtained from the kernel at runtime
> or from deserializing config.ser files under config-store. For> analyzing any problems after an application is deployed, deployment> plans will certainly be helpful.If you think this is really valuable information, I think a better
approach is to store the plan(s) in a known location in theconfiguration so they may be retrieved directly.
I thought of this as an option because it will really simplify a lot of
things, and I can avoid writing a configuration decompiler :o). 
But, then will there be any instances where the user will not want the
deployment plan to be stored in the server as is?  Will "not want
to store the deployment plan in the config-store" be ever a users'
reason for supplying deployment plan as an external file to the
deployer?
 thanksdavid jencks

Re: Geronimo ORB progress

[Lars Kühne]

Alan D. Cabrera wrote:


Lars Kühne wrote, On 11/17/2005 3:19 PM:



On 11/17/05, *Dain Sundstrom* <[EMAIL PROTECTED] > 
wrote:


+1 Using JIRA for tracking progress of the ORB would be great.

[...] I suggest you create an "Add an
ORB implementation" issue that can be the parent of all the tasks.



Done, GERONIMO-1198



I think that we should make focused jira issues rather than a single 
umbrella issue that tracks all work on the CORBA server.  Ideally, 
people would put their stake in the ground by writing about the 
architectural bit that they are going to implement in the wiki.  Then 
follow up with a a single Jira issue that basically marks the bit that 
you are going to implement.   File sub-tasks for the patches that you 
are submitting.


WDYT?



Alan,

as Dain suggested this issue is meant to serve as a parent issue for 
individual subtasks (or rather "incorporates" links?). This, together 
with using the CORBA component, is meant to serve as a simple method for 
filtering for individual work items that are open. Inidividual 
sub-issues would be stuff like "implement 
ORB.resolve_initial_reference", "allow JMX monitoring of property xyz", 
"add unit tests for ValueType mashalling" or "document configuration 
properties".


I have never used a Wiki as a collaboration tool, so maybe I don't know 
what I'm missing. Right now I wouldn't know what to write about the 
above sub-issues, as most of it isn't really "architectural" - it's 
described in the CORBA spec and somebody just has to do it.


For the trickier parts of an ORB a Wiki would certainly be a good idea 
to achieve some high level implementation idea before actual coding 
starts. However, I typically write an implementation overview 
(responsibility of each package and how they work together) in javadoc 
overview and package docs.


Do you use javadoc in geronimo land or do you write everything in the 
Wiki? What about end user docs, would they belong in src/xdocs, so they 
are easy to distribute with releases, or would that go into the Wiki, so 
they are easier to edit for non-committers?


Regards,
Lars

Re: validators

[David Jencks]

On Nov 17, 2005, at 9:06 PM, Sachin Patel wrote:

Could someone point me to where validation is being done on the 
deployment plans prior to deployment? Is there a single entry point 
for validation or is it being done within each of the builders?


Thanks


Process goes something like this:

builder determines through some black magic that the stuff you are 
asking about is something it can deploy


builder finds some files in likely places for the spec dd (if 
appropriate) and geronimo plan (if present)


builder reads xml files into xmlbeans XmlObjects

builder applies a lot of transformations to change pre-j2ee1.4 dds to 
1.4 dds, and to update geronimo plans in various ways in an attempt to 
preserve backwards compatibility even when we upgrade schemas.


builder asks xmlbeans to validate against the schema.  The usual method 
to call is SchemaConversionUtils.validateDD.


The process for web module plans is a little different since you can 
supply either a generic schema with container specific stuff or a 
container specific plan.  A generic plan is converted into a plan for a 
specific web container (currently jetty or tomcat).


Hope  this explains something :-)

david jencks

Loose end #1 -- tomcat configuration files

[David Jencks]

I now have servers for jetty and for tomcat built using the packaging 
and assembly plugins.  For the second time I've spent 2 days trying to 
figure out why tomcat is broken only to realize that some required 
configuration files are missing.  The server built in modules/assembly 
copies the files from the tomcat module, whereas I have simply included 
them in the geronimo-tomcat-j2ee assembly.  Both of these solutions are 
really unsatisfactory.


How about writing a gbean that copies resources out of its classpath 
and into a specified location (in var)?  This would let us package 
these files in the geronimo-tomcat car so they would be available for 
any tomcat server.  Can anyone see a problem with this approach?


thanks
david jencks

Re: Constructing deployment plans from Configuration GBeanData

[David Jencks]

On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:




On 11/17/05, David Jencks <[EMAIL PROTECTED]> wrote:

On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:

> If deployment plans are inside the archive (ear, war, etc.) they can
> be obtained from config-store. If the deployment plan is supplied as
 > an external file to the deployer and if the original file is not
> available, the only way to get any information on the configuration 
is

> from the Configuration GBeanData obtained from the kernel at runtime
> or from deserializing config.ser files under config-store. For
> analyzing any problems after an application is deployed, deployment
> plans will certainly be helpful.

If you think this is really valuable information, I think a better
approach is to store the plan(s) in a known location in the
configuration so they may be retrieved directly.
 I thought of this as an option because it will really simplify a lot 
of things, and I can avoid writing a configuration decompiler :o).  
But, then will there be any instances where the user will not want the 
deployment plan to be stored in the server as is?  Will "not want to 
store the deployment plan in the config-store" be ever a users' reason 
for supplying deployment plan as an external file to the deployer?


Well, I think there will be few cases where the original deployment 
plan will be unavailable from other sources, and I don't particularly 
like including it in the configuration.  However, I don't think this 
has much to do with the desirability of keeping the plan separate from 
the module you are deploying: I think this is always a good idea.  I do 
think that some people will want to conceal their plan and if we do 
provide a way to include it in the configuration this choice must be 
optional.


thanks
david jencks

Loose end #2: sql scripts

[David Jencks]

Sometimes an application needs some database tables in order to run.  
We don't have much support for helping with this.  We have the juddi 
server, with a script that is run from jelly code in modules/assembly, 
and we have some work to generate scripts for cmp entity beans, but no 
automated way of creating the tables when the app is deployed.


I would prefer that we find a way to package the sql with the app that 
needs it.  One possibility is to write a gbean that will, using a 
datasource deployed in geronimo, do some sort of test to see if the 
script should be run, and if so execute statements from a script.  I 
would think this would be fairly simple to write.


Can anyone see any problems with this idea?  Does it seem like a good 
idea?  Is there a better way to do this?


thanks
david jencks

Re: Loose end #1 -- tomcat configuration files

[Aaron Mulder]

I don't have any problems with your approach.   But I also am not the
biggest fan fo the var/catalina structure that Tomcat wants Geronimo
to have.  Is there some way to get Tomcat to use our directories
directly (log, work, whatever) instead of doing everything under a
Catalina directory?

Aaron

On 11/18/05, David Jencks <[EMAIL PROTECTED]> wrote:
> I now have servers for jetty and for tomcat built using the packaging
> and assembly plugins.  For the second time I've spent 2 days trying to
> figure out why tomcat is broken only to realize that some required
> configuration files are missing.  The server built in modules/assembly
> copies the files from the tomcat module, whereas I have simply included
> them in the geronimo-tomcat-j2ee assembly.  Both of these solutions are
> really unsatisfactory.
>
> How about writing a gbean that copies resources out of its classpath
> and into a specified location (in var)?  This would let us package
> these files in the geronimo-tomcat car so they would be available for
> any tomcat server.  Can anyone see a problem with this approach?
>
> thanks
> david jencks
>
>

Re: Loose end #1 -- tomcat configuration files

[Jeff Genender]

Many of the Tomcat components seem to need the concept of a "Catalina 
Home".  But this is not to say, that a majority of the components allow 
for overrides to particular directory structures and locations.  So 
without looking at the code, I would probably say its doable...but this 
is speculation.


Aaron Mulder wrote:

I don't have any problems with your approach.   But I also am not the
biggest fan fo the var/catalina structure that Tomcat wants Geronimo
to have.  Is there some way to get Tomcat to use our directories
directly (log, work, whatever) instead of doing everything under a
Catalina directory?

Aaron

On 11/18/05, David Jencks <[EMAIL PROTECTED]> wrote:

I now have servers for jetty and for tomcat built using the packaging
and assembly plugins.  For the second time I've spent 2 days trying to
figure out why tomcat is broken only to realize that some required
configuration files are missing.  The server built in modules/assembly
copies the files from the tomcat module, whereas I have simply included
them in the geronimo-tomcat-j2ee assembly.  Both of these solutions are
really unsatisfactory.

How about writing a gbean that copies resources out of its classpath
and into a specified location (in var)?  This would let us package
these files in the geronimo-tomcat car so they would be available for
any tomcat server.  Can anyone see a problem with this approach?

thanks
david jencks

Re: Loose end #2: sql scripts

[Aaron Mulder]

My only concern is that executing SQL scripts not be the default
behavior for an application.  As a developer I generally prefer to be
the master of the SQL and not have the server doing things for me, and
I think that's especially important as you look at non-developer uses.
 But if we have a flag the user can set in their plan to automatically
execute some SQL, or if the routine is that you add a canned
SQL-Executor GBean definition to your plan and just point it at the
SQL script and database pool, that's fine with me (because you have to
do something to turn it on).  It does sound like a handy feature if
you're into that kind of thing.  :)

Thanks,
Aaron

On 11/18/05, David Jencks <[EMAIL PROTECTED]> wrote:
> Sometimes an application needs some database tables in order to run.
> We don't have much support for helping with this.  We have the juddi
> server, with a script that is run from jelly code in modules/assembly,
> and we have some work to generate scripts for cmp entity beans, but no
> automated way of creating the tables when the app is deployed.
>
> I would prefer that we find a way to package the sql with the app that
> needs it.  One possibility is to write a gbean that will, using a
> datasource deployed in geronimo, do some sort of test to see if the
> script should be run, and if so execute statements from a script.  I
> would think this would be fairly simple to write.
>
> Can anyone see any problems with this idea?  Does it seem like a good
> idea?  Is there a better way to do this?
>
> thanks
> david jencks
>
>

Re: Constructing deployment plans from Configuration GBeanData

[Aaron Mulder]

Note that JSR-77 requires us to expose the J2EE DD through our module
beans, and it may make sense to provide a similar hook for the
Geronimo plan.  That would make it easy to implement nicely in the
console, certainly.

However, I agree that it's important to be able to suppress showing
plans, particular for connectors where they're likely to have
passwords in them.  Sure, you only see that if you got into the
console/MEJB/whatever to begin with, but still...  I'm not sure what
to say about the default behavior.  I thought this was such a cool
idea until I thought about the password issue, but if we make hiding
the plans the default, then it's not all that useful a feature.  I'm
waffling.

Aaron

On 11/18/05, David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:
>
> >
> >
> > On 11/17/05, David Jencks <[EMAIL PROTECTED]> wrote:
> >> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
> >>
> >> > If deployment plans are inside the archive (ear, war, etc.) they can
> >> > be obtained from config-store. If the deployment plan is supplied as
> >>  > an external file to the deployer and if the original file is not
> >> > available, the only way to get any information on the configuration
> >> is
> >> > from the Configuration GBeanData obtained from the kernel at runtime
> >> > or from deserializing config.ser files under config-store. For
> >> > analyzing any problems after an application is deployed, deployment
> >> > plans will certainly be helpful.
> >>
> >> If you think this is really valuable information, I think a better
> >> approach is to store the plan(s) in a known location in the
> >> configuration so they may be retrieved directly.
> >  I thought of this as an option because it will really simplify a lot
> > of things, and I can avoid writing a configuration decompiler :o).
> > But, then will there be any instances where the user will not want the
> > deployment plan to be stored in the server as is? Will "not want to
> > store the deployment plan in the config-store" be ever a users' reason
> > for supplying deployment plan as an external file to the deployer?
>
> Well, I think there will be few cases where the original deployment
> plan will be unavailable from other sources, and I don't particularly
> like including it in the configuration.  However, I don't think this
> has much to do with the desirability of keeping the plan separate from
> the module you are deploying: I think this is always a good idea.  I do
> think that some people will want to conceal their plan and if we do
> provide a way to include it in the configuration this choice must be
> optional.
>
> thanks
> david jencks
>
>

Warning of change in configId format

[David Jencks]

I have been working on assembling geronimo using the packaging and 
assembly plugins.  This gives us the ability to put together versions 
of geronimo with different capabilities without duplication.  For 
instance, we now have a jetty-only and a tomcat-only version of 
geronimo.  To build these,


cd configs;maven -o multiproject:install; cd ..
cd assemblies/j2ee-jetty-server;maven -o;
cd ../j2ee-tomcat-server:maven -o

This relies on using the packaging plugin, which builds configurations 
and puts them into the local maven repository.  As such, it uses the 
maven id as the configId: they typically look like


${groupId}/cars/${artifactId}-${pom.currentVersion}.car

I think this is a big improvement over the unsystematic hand-invented 
ids we have been relying on up to now, but it is a backwards 
incompatible change that will require changing any plan that mentions a 
parentId  (many plans do not need to: the builders include default 
parents sufficient for the geronimo classes needed for the app to 
load).  It will also require changing the  element in gbean 
references that include them.


I think we should just go ahead with the change, and announce it 
loudly.  We could provide "adapter plans" with no content  of any kind 
that have e.g. a configId of org/apache/geronimo/rmi-naming and a 
parentId of geronimo/cars/geronimo-rmi-naming-1.0-SNAPSHOT.car.  This 
would allow plans that have only old-style parentIds to deploy 
successfully, but would not help with the gbean references.


I beileve in a slightly related development we are planning to change 
the groupId to org.apache.geronimo before v1.  Doing these changes more 
or less at once might reduce confusion.



Comments?  Objections?

thanks
david jencks

Re: [VOTE] Matt Hogstrom as Release Manager (Re: Getting V1.0 out the door - first step ;-P)

[Gianny Damour]

+1

Gianny

Davanum Srinivas wrote:


+1 for Matt as the Release Manager. Let's do it :)

Matt,
Please familiarize yourself with how other projects do it and how prev
releases were done. First step would be a release plan.

thanks,
dims

On 10/19/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
 


All,

We got a couple of +1's about getting G out the door by ApacheCon.  I'd like to
start formalizing our thinking about it and I think the first step is getting
someone to step up and volunteer to lead the effort.

I'll throw my hat in the ring as, at least for me, it will be a good learning
experience in pulling everything together.  And for everyone else as well so
they can see how badly I suck at all things administrative :)

For those more experienced and knowledgable ones out there that don't want to
miss out on this great opportunity here is your opportunity to say, "No, Matt, I
would love to do it!!!"

In the unlikely event that I end up with the opportunity I'll start preparing by
reviewing what we did last time when Jeff lead the team to Release victory.

Don't be shy

- Matt


   




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