I'd like to apologize for the miscommunication engendered by this
thread. It's very clear to me that what I thought I was communicating
did not get through. This attempt to clarify will probably not fare
any better :-(
I don't expect tomcat to consider changing its build system and
certainly don't want to participate in any discussion of the tomcat
build system.
I don't expect tomcat to release anything from trunk or any branch in
particular.
I do suspect that there are projects that, like geronimo, use maven
and are faced with maintaining a tomcat fork. For such projects, (NOT
TOMCAT ITSELF) the tools we developed at geronimo might be useful.
Once again, this is NOT a proposal for tomcat to use maven. If you
guys happen to decide you want to I'd be happy to give advice, but I'm
not proposing it and don't want to talk about whether it would be a
good idea.
On Jul 11, 2009, at 8:38 AM, Costin Manolache wrote:
I think there are few separate issues:
1, If there is a patch that needs to be applied by geronimo to use
tomcat or they are blocked by missing something from a release - we
should review this again. I think we can do a tomcat-geronimo release
specifically for them as worse case ( well, we did it for j2ee ref
impl in the old days - all we need is a branch ), or make sure it gets
in the next release,
Personally, since geronimo now has a working method of maintaining a
fork of the 6.0 branch including the needed patches from trunk, I
would prefer to see any development effort expended on servlet 3.0
features. If tomcat 7 supports servlet 3.0 and is based on trunk
geronimo won't need a fork any more.
2. For Maven support - if maven can support building tomcat, I don't
see any problem. But moving the code around and changing code just so
we can be built by maven - I don't like that. The current patch is
even worse - it seems to create 2 different source trees for tomat,
and since maven can also checkout the source and people may use the
maven-source...
Once again, this was never intended to be about the tomcat build system.
3. For having maven-like 'modules' with strict build and runtime
dependencies - been there. There are plenty of large projects using
tomcat approach - i.e. allow circular dependencies between packages
and build either one big jar or few jars. I think the benefits of more
reuse and code sharing are bigger than the problems - i.e. mostly not
able to break into many directories and build with maven, and arcane
ways to break circular dependencies.
I'm still mystified by this. I have no problems with circular package
dependencies within a single jar but I really don't understand why
you'd have 2 jars neither of which can be used without the other.
Wouldn't it be simpler for everyone to just have one jar?
Costin
On Fri, Jul 10, 2009 at 11:43 PM, Mladen Turk<mt...@apache.org> wrote:
Filip Hanik - Dev Lists wrote:
If Geronimo needs a better way to download and integrate Tomcat's
JAR's
lets focus on that, and not make this into another Maven vs ANT
topic, cause
I don't think that was the intention.
Agreed.
However we should really find a way to deal with eclipse
repository since they tend to change the download system
quite often (only external dependency).
Since we cannot copy that to the ASF due to license issue
we could reuse the backup system on tomcat.heanet.ie (like we did
for Tomcat Native until ASF resolved the crypto software issues)
to allow the historic builds.
I somehow doubt Maven can solve this problem anyhow, and
downloading a repo with 10+ eclipse JDT's would be insane
just to build eg. 6.0.20 in 5 years from now.
????? maven only downloads the dependencies you require, not entire
repos. Probably I don't understand what you are saying.
Other things is trivial, just testing the dist.apache.org
with archive.apache.org as fallback for the remaining
dependencies.
I didn't mention this before either but I don't understand why tomcat
is rebuilding the eclipse code. The released eclipse jdt jar
available from maven central seems to work fine.
thanks
david jencks
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
