geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anita kulshreshtha <a_kuls...@yahoo.com>
Subject Re: configuration dependencies
Date Thu, 11 May 2006 13:23:34 GMT
Joe,
   Thanks! More inline..

--- Joe Bohn <joe.bohn@earthlink.net> wrote:

> Anita,
> 
> Sorry for the long delay ... had queued this up to look at later and 
> later finally arrived.  :-)
> 
> On the first change we should probably remove unnecessary
> dependencies 
> such as jetty in rmi-naming and system-database.  I'm sure there are 
> plenty more.
> 
> I'll defer to Aaron on the way versions for dependencies are
> specified 
> in the console geronimo-plugin.xml.  It seems like the best approach
> is 
> to omit the version if possible as with many of the  other
> dependencies 
> listed.   My guess is that there must have been multiple versions 
> available in the system for activemq and some other modules where
> they 
> are "hard coded".  This may be resolved by now and we might be able
> to 
> omit the activemq version entirely.
> 
> Can you describe the second patch some more?  What is the goal?  I 
> recall that you were trying to build the assemblies without building
> the 
> configurations (by just downloading the plugins).  This would provide
> a 
> faster "build" (really assembly creation) if you had no need to build
> 
> any of the contents of any of the configurations.  However, I'm not 
> certain that is a common case.
     The main idea was that if a configuration needs a jar or a war, it
should specify it as a dependency (regular), It should not depend on
the fact that it was already put in the local maven repository by
earlier operations. This would not be an issue if we were allowed to
use only 'maven new' and not 'maven new4'. However considering how many
people would care for that, it is not important. Dain also suggested
the same.

Thanks
Anita

> 
> Joe
> 
> 
> anita kulshreshtha wrote:
> > David J and Joe,
> >    I am attaching two patches: 
> >     The first one configs.patch removes jetty from rmi-naming and
> > system-database configurations. The
> > console-tomcat/..geronimo-plugin.xml is using 
> >
>
<dependency>activemq/activemq-gbean-management/3.2.4-SNAPSHOT/jar</dependency>
> > <dependency>activemq/activemq-gbean/3.2.4-SNAPSHOT/jar</dependency>
> >    and the versions are hardcoded instead of using ${...}. Is this
> > desired? If not there is a patch to fix this. This file does not
> have
> > its eol style set, hence there are so many lines in the patch.
> >     The second patch shortens the build time and makes the server
> > assembly independent of the earlier build stages. Is this useful?
> >     How is geronimo-console...ear being generated? 
> > 
> > Thanks
> > Anita
> > --- anita kulshreshtha <a_kulshre@yahoo.com> wrote:
> > 
> > 
> >>Joe,
> >>    Thanks! Sending it to the list.. 
> >>
> >>--- Joe Bohn <joe.bohn@earthlink.net> wrote:
> >>
> >>
> >>>Anita,
> >>>
> >>>Ahh ... now I see what you were trying to accomplish.  I think
> this
> >>>is a 
> >>>good question for the dev list.
> >>>
> >>>I personally don't think that it is important to ensure that your
> >>>build 
> >>>includes/excludes match what is in geronimo with M1 exactly.  In
> >>>fact, I 
> >>>think what we have in M1 is really just a jumble of things that
> >>>people 
> >>>at one time thought were needed, copied from other configurations,
> >>
> >>or
> >>
> >>>whatever to get things to build.  Sure, there are very specific,
> >>
> >>well
> >>
> >>>placed dependencies that were added as well.  But I don't think
> >>
> >>that
> >>
> >>>the 
> >>>omissions were necessarily deliberate just as not all of the
> >>>additions 
> >>>were deliberate (such as is likely the case with the jetty
> deployer
> >>>in 
> >>>remote-deploy-tomcat).
> >>>
> >>>Also, based upon my recent experience with the
> >>
> >>geronimo.dependencies,
> >>
> >>>even those are often the result of copied code.   I didn't resolve
> >>>all 
> >>>of these geronimo.dependencies by a long shot.  I was specifically
> 
> >>>focused on making changes and validating dependencies to remove 
> >>>unnecessary items from inclusion in the little-G assembly.   So
> I'm
> >>
> >>>fairly sure there are still plenty of bogus geronimo.dependencies
> >>>there too.
> >>>
> >>>Yes, with the M2 transitive dependencies we may very well be able
> >>
> >>to 
> >>
> >>>build and bad things could happen because of a missing 
> >>>geronimo.dependency when you attempt to run the server.  However,
> I
> >>
> >>>consider this no different than today where you must manually add
> >>>both. 
> >>>  It's still very possible to add one and not the other with the
> >>>result 
> >>>being a server that cannot start (in fact I just did it this
> >>
> >>morning
> >>
> >>>on 
> >>>my test machine).   However, I think this typically speaks more to
> >>
> >>a 
> >>
> >>>problem in the building of the configuration rather than the
> >>
> >>building
> >>
> >>>of 
> >>>the assembly.  External dependencies by configuration must be
> added
> >>>to 
> >>>the verified/added to the assemblies when the configurations are
> >>>added 
> >>>to the assemblies.
> >>>
> >>>
> >>>Joe
> >>>
> >>>
> >>>anita kulshreshtha wrote:
> >>>
> >>>>Joe,
> >>>>   Thanks. I was trying to understand the process of assembly. so
> >>
> >>I
> >>
> >>>did
> >>>
> >>>>the following :
> >>>>1. checkout ONLY top level dir, /etc and /assemblies.
> >>>>2. cd j2ee-tomcat-server
> >>>>3. maven
> >>>>    I think I should be able to do this without building
> >>
> >>(modules,
> >>
> >>>>configs, apps) anything else. It worked fine until I got to
> >>>>g/javamail/../car. A jar was missing. 
> >>>>    Now why would someone in the right mind do that... It is for
> >>>
> >>>M2. As
> >>>
> >>>>you said downloading everything is automatic in m2, Trying to
> >>>
> >>>prevent
> >>>
> >>>>one dependency is a nightmare. It will be quite a challenge to
> >>
> >>find
> >>
> >>>>equivalent of g.reference, g.import and g.dependency using only
> >>>>'provided' and 'exclude' and arrive at the same list as m1.
> >>>>    You have answered my question that the
> >>
> >>javamail-transport..jar
> >>
> >>>is 
> >>>
> >>>>needed for j2ee-tomcat-server. So if it gets added by M2 it will
> >>>
> >>>not be
> >>>
> >>>>a bad thing!
> >>>>        I built the server using above 3 step today, the error
> >>>
> >>>message
> >>>
> >>>>is gone. But this jar is not in GERONIMO_HOME/repository/.. When
> >>
> >>I
> >>
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Mime
View raw message