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 <[EMAIL PROTECTED]> wrote:
Joe,
Thanks! Sending it to the list..
--- Joe Bohn <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
