Re: jetspeed 2 build organization suggestions

2004-08-23 Thread David Sean Taylor 
On Aug 22, 2004, at 12:00 PM, David Jencks wrote:
I have been reviewing the jetspeed 2 build process and believe it 
could be improved in several areas.

1. using maven features appropriately within the current project 
structure.  For instance, it appears to me that using the multiproject 
plugin instead of the reactor can replace about 236 lines with 2 in 
the top level maven.xml file.

+1 we've been meaning to look into that.
2. restructuring the project to eliminate conditionals and clarify 
dependencies.  Currently the build appears to be oriented entirely 
toward deploying on tomcat, and from my brief review this appears to 
permeate many areas of the project.  I suggest removing all such 
dependencies from  current build files and creating a new set of 
modules for each installation environment,

installation/tomcat
installation/weblogic
installation/geronimo
...
that will customize as appropriate for the target environment and 
provide appropriate installation tools.

Sounds good to me. Might want to include JBoss in there too ;-)
Similarly, I think it might be advisable to factor out the database 
setup support into separate modules such as

installation/database/hsqldb
installation/database/oracle
...
We generate the scripts with Torque. So the installation is generic 
across all databases. Thus Im -1 on this one

I have not yet discovered to what extent the persistence support is 
pluggable, but if for instance you are using ojb via its jdo support 
the choice of jdo vendor and appropriate setup could also be isolated 
in separate modules.

The persistence plugin allows you to swap out OJB with another 
persistence framework such as Hibernate or Castor DB.
IMO JDO would lessen the need for a persistence plugin, since we would 
always write to the JDO APIs and then JDO would function much like the 
plugin.
Unfortunately open source JDO implementations are still lagging behind 
the Hibernate and OJB non-standard implementations
Is Geronimo going to support JDO?

I'd like to know if there are objections to this approach before I 
spend a significant amount of time experimenting with it.

No objections to multi-project, target environments
However Im -1 on the installation/database/* proposal unless you can 
improve on the current process

Many thanks,
david jencks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
[office]   +01 707 773-4646
[mobile] +01 707 529 9194

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

Re: jetspeed 2 build organization suggestions

2004-08-23 Thread Massimiliano Dessì 
Ok, 
"BUILD SUCCESSFUL
Total time: 8 minutes 35 seconds"
at the second build of the "reactor" on my turtle pc.

p.s.
In the instruction for the build "getting started"
with maven, i don't see the keys 

maven.proxy.host = xxx
maven.proxy.port = xxx

It's a facilitation write this stupid settings (in a
comment) for a new developer of jetspeed and maven.


 --- "Scott T. Weaver"
<[EMAIL PROTECTED]> ha scritto: 
> The longest I have ever seen, with unit tests
> running, is about 5-6 
> minutes, and that is on a fairly old P3.  I have a
> feeling this long 
> delay was caused by downloading the dependencies.  
> If you run it again 
> I am sure it will be MUCH faster, probably a couple
> of orders of 
> magnitude faster.  I generally see build times
> around 3.5 minutes on my 
> P4 2.4GHz 1GB Ram running Mandrake Community 10.0.
> 
> Massimiliano Dessì wrote:
> 
> >"BUILD SUCCESSFUL
> >Total time: 35 minutes 7 seconds"
> >
> >Little ? :-)
> >
> >p.s. It's a build time from a clean installation of
> >maven.
> >
> >
> > --- "Scott T. Weaver"
> ><[EMAIL PROTECTED]> ha
> scritto: 
> >  
> >
> >>Anything that'll organize the little Maven monster
> >>we have created will 
> >>get a +1 from me ;)
> >>
> >>David Jencks wrote:
> >>
> >>
> >>
> >>>I have been reviewing the jetspeed 2 build
> process
> >>>  
> >>>
> >>and believe it 
> >>
> >>
> >>>could be improved in several areas.
> >>>
> >>>1. using maven features appropriately within the
> >>>  
> >>>
> >>current project 
> >>
> >>
> >>>structure.  For instance, it appears to me that
> >>>  
> >>>
> >>using the multiproject 
> >>
> >>
> >>>plugin instead of the reactor can replace about
> >>>  
> >>>
> >>236 lines with 2 in 
> >>
> >>
> >>>the top level maven.xml file.
> >>>
> >>>2. restructuring the project to eliminate
> >>>  
> >>>
> >>conditionals and clarify 
> >>
> >>
> >>>dependencies.  Currently the build appears to be
> >>>  
> >>>
> >>oriented entirely 
> >>
> >>
> >>>toward deploying on tomcat, and from my brief
> >>>  
> >>>
> >>review this appears to 
> >>
> >>
> >>>permeate many areas of the project.  I suggest
> >>>  
> >>>
> >>removing all such 
> >>
> >>
> >>>dependencies from  current build files and
> >>>  
> >>>
> >>creating a new set of 
> >>
> >>
> >>>modules for each installation environment,
> >>>
> >>>installation/tomcat
> >>>installation/weblogic
> >>>installation/geronimo
> >>>...
> >>>
> >>>that will customize as appropriate for the target
> >>>  
> >>>
> >>environment and 
> >>
> >>
> >>>provide appropriate installation tools.
> >>>
> >>>Similarly, I think it might be advisable to
> factor
> >>>  
> >>>
> >>out the database 
> >>
> >>
> >>>setup support into separate modules such as
> >>>
> >>>installation/database/hsqldb
> >>>installation/database/oracle
> >>>...
> >>>
> >>>I have not yet discovered to what extent the
> >>>  
> >>>
> >>persistence support is 
> >>
> >>
> >>>pluggable, but if for instance you are using ojb
> >>>  
> >>>
> >>via its jdo support 
> >>
> >>
> >>>the choice of jdo vendor and appropriate setup
> >>>  
> >>>
> >>could also be isolated 
> >>
> >>
> >>>in separate modules.
> >>>
> >>>
> >>>I'd like to know if there are objections to this
> >>>  
> >>>
> >>approach before I 
> >>
> >>
> >>>spend a significant amount of time experimenting
> >>>  
> >>>
> >>with it.
> >>
> >>
> >>>Many thanks,
> >>>david jencks
> >>>
> >>>
> >>>
> >>>  
> >>>
>
>-
> >  
> >
> >>>To unsubscribe, e-mail:
> >>>  
> >>>
> >>[EMAIL PROTECTED]
> >>
> >>
> >>>For additional commands, e-mail:
> >>>  
> >>>
> >>[EMAIL PROTECTED]
> >>
> >>
> >>>  
> >>>
> >>-- 
> >>***
> >>*   Scott T. Weaver   *
> >>* <[EMAIL PROTECTED]> *
> >>* *
> >>* --  *
> >>*   Apache Jetspeed Enterprise Portal *
> >>* Apache Pluto Portlet Container  *
> >>* *
> >>* OpenEditPro, Website Content Management *
> >>* *
> >>***
> >>
> >>
> >>
> >>
> >>
>
>-
> >  
> >
> >>To unsubscribe, e-mail:
> 
=== message truncated === 






___
Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
http://companion.yahoo.it

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

Re: jetspeed 2 build organization suggestions

2004-08-23 Thread Scott T. Weaver 
The longest I have ever seen, with unit tests running, is about 5-6 
minutes, and that is on a fairly old P3.  I have a feeling this long 
delay was caused by downloading the dependencies.   If you run it again 
I am sure it will be MUCH faster, probably a couple of orders of 
magnitude faster.  I generally see build times around 3.5 minutes on my 
P4 2.4GHz 1GB Ram running Mandrake Community 10.0.

Massimiliano Dessì wrote:
"BUILD SUCCESSFUL
Total time: 35 minutes 7 seconds"
Little ? :-)
p.s. It's a build time from a clean installation of
maven.
--- "Scott T. Weaver"
<[EMAIL PROTECTED]> ha scritto: 
 

Anything that'll organize the little Maven monster
we have created will 
get a +1 from me ;)

David Jencks wrote:
   

I have been reviewing the jetspeed 2 build process
 

and believe it 
   

could be improved in several areas.
1. using maven features appropriately within the
 

current project 
   

structure.  For instance, it appears to me that
 

using the multiproject 
   

plugin instead of the reactor can replace about
 

236 lines with 2 in 
   

the top level maven.xml file.
2. restructuring the project to eliminate
 

conditionals and clarify 
   

dependencies.  Currently the build appears to be
 

oriented entirely 
   

toward deploying on tomcat, and from my brief
 

review this appears to 
   

permeate many areas of the project.  I suggest
 

removing all such 
   

dependencies from  current build files and
 

creating a new set of 
   

modules for each installation environment,
installation/tomcat
installation/weblogic
installation/geronimo
...
that will customize as appropriate for the target
 

environment and 
   

provide appropriate installation tools.
Similarly, I think it might be advisable to factor
 

out the database 
   

setup support into separate modules such as
installation/database/hsqldb
installation/database/oracle
...
I have not yet discovered to what extent the
 

persistence support is 
   

pluggable, but if for instance you are using ojb
 

via its jdo support 
   

the choice of jdo vendor and appropriate setup
 

could also be isolated 
   

in separate modules.
I'd like to know if there are objections to this
 

approach before I 
   

spend a significant amount of time experimenting
 

with it.
   

Many thanks,
david jencks

 

-
 

To unsubscribe, e-mail:
 

[EMAIL PROTECTED]
   

For additional commands, e-mail:
 

[EMAIL PROTECTED]
   

 

--
***
*   Scott T. Weaver   *
* <[EMAIL PROTECTED]> *
* *
* --  *
*   Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container  *
* *
* OpenEditPro, Website Content Management *
* *
***

   

-
 

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



	
		
___
Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
http://companion.yahoo.it

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


--
***
*   Scott T. Weaver   *
* <[EMAIL PROTECTED]> *
* *
* --  *
*   Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container  *
* *
* OpenEditPro, Website Content Management *
* *
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jetspeed 2 build organization suggestions

2004-08-23 Thread Massimiliano Dessì 
"BUILD SUCCESSFUL
Total time: 35 minutes 7 seconds"

Little ? :-)

p.s. It's a build time from a clean installation of
maven.


 --- "Scott T. Weaver"
<[EMAIL PROTECTED]> ha scritto: 
> Anything that'll organize the little Maven monster
> we have created will 
> get a +1 from me ;)
> 
> David Jencks wrote:
> 
> > I have been reviewing the jetspeed 2 build process
> and believe it 
> > could be improved in several areas.
> >
> > 1. using maven features appropriately within the
> current project 
> > structure.  For instance, it appears to me that
> using the multiproject 
> > plugin instead of the reactor can replace about
> 236 lines with 2 in 
> > the top level maven.xml file.
> >
> > 2. restructuring the project to eliminate
> conditionals and clarify 
> > dependencies.  Currently the build appears to be
> oriented entirely 
> > toward deploying on tomcat, and from my brief
> review this appears to 
> > permeate many areas of the project.  I suggest
> removing all such 
> > dependencies from  current build files and
> creating a new set of 
> > modules for each installation environment,
> >
> > installation/tomcat
> > installation/weblogic
> > installation/geronimo
> > ...
> >
> > that will customize as appropriate for the target
> environment and 
> > provide appropriate installation tools.
> >
> > Similarly, I think it might be advisable to factor
> out the database 
> > setup support into separate modules such as
> >
> > installation/database/hsqldb
> > installation/database/oracle
> > ...
> >
> > I have not yet discovered to what extent the
> persistence support is 
> > pluggable, but if for instance you are using ojb
> via its jdo support 
> > the choice of jdo vendor and appropriate setup
> could also be isolated 
> > in separate modules.
> >
> >
> > I'd like to know if there are objections to this
> approach before I 
> > spend a significant amount of time experimenting
> with it.
> >
> > Many thanks,
> > david jencks
> >
> >
> >
>
-
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
> 
> 
> -- 
> ***
> *   Scott T. Weaver   *
> * <[EMAIL PROTECTED]> *
> * *
> * --  *
> *   Apache Jetspeed Enterprise Portal *
> * Apache Pluto Portlet Container  *
> * *
> * OpenEditPro, Website Content Management *
> * *
> ***
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
>  






___
Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! 
http://companion.yahoo.it

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

Re: jetspeed 2 build organization suggestions

2004-08-23 Thread Scott T. Weaver 
Anything that'll organize the little Maven monster we have created will 
get a +1 from me ;)

David Jencks wrote:
I have been reviewing the jetspeed 2 build process and believe it 
could be improved in several areas.

1. using maven features appropriately within the current project 
structure.  For instance, it appears to me that using the multiproject 
plugin instead of the reactor can replace about 236 lines with 2 in 
the top level maven.xml file.

2. restructuring the project to eliminate conditionals and clarify 
dependencies.  Currently the build appears to be oriented entirely 
toward deploying on tomcat, and from my brief review this appears to 
permeate many areas of the project.  I suggest removing all such 
dependencies from  current build files and creating a new set of 
modules for each installation environment,

installation/tomcat
installation/weblogic
installation/geronimo
...
that will customize as appropriate for the target environment and 
provide appropriate installation tools.

Similarly, I think it might be advisable to factor out the database 
setup support into separate modules such as

installation/database/hsqldb
installation/database/oracle
...
I have not yet discovered to what extent the persistence support is 
pluggable, but if for instance you are using ojb via its jdo support 
the choice of jdo vendor and appropriate setup could also be isolated 
in separate modules.

I'd like to know if there are objections to this approach before I 
spend a significant amount of time experimenting with it.

Many thanks,
david jencks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
***
*   Scott T. Weaver   *
* <[EMAIL PROTECTED]> *
* *
* --  *
*   Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container  *
* *
* OpenEditPro, Website Content Management *
* *
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jetspeed 2 build organization suggestions

2004-08-23 Thread David Le Strat 
This makes sense to me.

Regards,

David.
--- David Jencks <[EMAIL PROTECTED]> wrote:

> I have been reviewing the jetspeed 2 build process
> and believe it could 
> be improved in several areas.
> 
> 1. using maven features appropriately within the
> current project 
> structure.  For instance, it appears to me that
> using the multiproject 
> plugin instead of the reactor can replace about 236
> lines with 2 in the 
> top level maven.xml file.
> 
> 2. restructuring the project to eliminate
> conditionals and clarify 
> dependencies.  Currently the build appears to be
> oriented entirely 
> toward deploying on tomcat, and from my brief review
> this appears to 
> permeate many areas of the project.  I suggest
> removing all such 
> dependencies from  current build files and creating
> a new set of 
> modules for each installation environment,
> 
> installation/tomcat
> installation/weblogic
> installation/geronimo
> ...
> 
> that will customize as appropriate for the target
> environment and 
> provide appropriate installation tools.
> 
> Similarly, I think it might be advisable to factor
> out the database 
> setup support into separate modules such as
> 
> installation/database/hsqldb
> installation/database/oracle
> ...
> 
> I have not yet discovered to what extent the
> persistence support is 
> pluggable, but if for instance you are using ojb via
> its jdo support 
> the choice of jdo vendor and appropriate setup could
> also be isolated 
> in separate modules.
> 
> 
> I'd like to know if there are objections to this
> approach before I 
> spend a significant amount of time experimenting
> with it.
> 
> Many thanks,
> david jencks
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 




___
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

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