You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by anita kulshreshtha <a_...@yahoo.com> on 2006/04/29 01:54:14 UTC
Re: configuration dependencies
Joe,
Thanks! Sending it to the list..
--- Joe Bohn <jo...@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
> > start this server bad things will happen!
> > A similar situation is with remote-deploy-tomcat../car. it
> needs
> > remote-deploy-tomcat..jar but j2ee-tomcat-server does not down load
> it,
> > It depends on the fact that someone will build the configs before
> doing
> > the assembly.
> > The remote-deploy-tomcat config needs jetty-deployer and hence
> > jetty. Why is it so?
> >
> > Thanks
> > Anita
> > --- Joe Bohn <jo...@earthlink.net> wrote:
> >
...........<snip>
> >
>
> --
> 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
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: configuration dependencies
Posted by anita kulshreshtha <a_...@yahoo.com>.
Joe,
Thanks! More inline..
--- Joe Bohn <jo...@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_...@yahoo.com> wrote:
> >
> >
> >>Joe,
> >> Thanks! Sending it to the list..
> >>
> >>--- Joe Bohn <jo...@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
Re: configuration dependencies
Posted by Joe Bohn <jo...@earthlink.net>.
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.
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_...@yahoo.com> wrote:
>
>
>>Joe,
>> Thanks! Sending it to the list..
>>
>>--- Joe Bohn <jo...@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
>>
>>>>start this server bad things will happen!
>>>> A similar situation is with remote-deploy-tomcat../car. it
>>>
>>>needs
>>>
>>>>remote-deploy-tomcat..jar but j2ee-tomcat-server does not down
>>
>>load
>>
>>>it,
>>>
>>>>It depends on the fact that someone will build the configs before
>>>
>>>doing
>>>
>>>>the assembly.
>>>> The remote-deploy-tomcat config needs jetty-deployer and
>>
>>hence
>>
>>>>jetty. Why is it so?
>>>>
>>>>Thanks
>>>>Anita
>>>>--- Joe Bohn <jo...@earthlink.net> wrote:
>>>>
>>
>>...........<snip>
>>
>>>--
>>>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
>>>
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
--
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
Re: configuration dependencies
Posted by anita kulshreshtha <a_...@yahoo.com>.
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_...@yahoo.com> wrote:
> Joe,
> Thanks! Sending it to the list..
>
> --- Joe Bohn <jo...@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
> > > start this server bad things will happen!
> > > A similar situation is with remote-deploy-tomcat../car. it
> > needs
> > > remote-deploy-tomcat..jar but j2ee-tomcat-server does not down
> load
> > it,
> > > It depends on the fact that someone will build the configs before
> > doing
> > > the assembly.
> > > The remote-deploy-tomcat config needs jetty-deployer and
> hence
> > > jetty. Why is it so?
> > >
> > > Thanks
> > > Anita
> > > --- Joe Bohn <jo...@earthlink.net> wrote:
> > >
> ...........<snip>
> > >
> >
> > --
> > 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
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com