I don't think this is a satisfactory solution. One big reason I need
the repackaging is so I can debug tomcat and know what jar I'm looking
at. Since AFAICT this keeps all the source in the same file structure
as the original tomcat project I can't figure out what's going on.
There's also a problem that it doesn't build for me, but that is
presumably easy to fix.
I didn't really understand why you didn't use the same solution we
used for tomcat 6.0.x. Are the unix scripts a problem? There's a
possibly not-yet-released antlib that is supposed to let you run svn
commands from ant, maybe we could use that.
thanks
david jencks
On Dec 8, 2009, at 1:35 AM, Ivan wrote:
OK, finally, I still used our way to divide the Tomcat codes, it
seems that Tomcat side did not define those artifacts correctly.
I checked the codes to my sandbox. The way I used now is to create a
"wrapper" project for Tomcat 7. In this way, we do not need to
merge codes regularly, it should be a better solution for temporary
use :-)
The steps are :
1. svn co
https://svn.apache.org/repos/asf/geronimo/sandbox/ivan/geronimo_tomcat_7.0.0
2. svn co https://svn.apache.org/repos/asf/tomcat/trunk
Your_local_folder
3. Edit the root pom file, make the property tomcat.local.directory
pointed to Your_local_folder
4. mvn clean install
I am trying to use maven-scm-plugin to make the build more
automatically, but failed ;-( So need to check out Tomcat codes
manually ....
Currently, there are some compilation errors due to some signature
conflicts with our own servlet api. Will check it later.
2009/12/7 Ivan <[email protected]>
I am trying another way to package and deploy Tomcat 7 artifacts,
since it is just a temporary solution, I think we just need to
create a "wrap" pom file, which means no source codes are copied. In
this way, we could just use scm plugin to update the source codes,
and no need to merge codes by ourselves.
e.g.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<includes>
<include name="org/apache/catalina/**" />
<include name="org/apache/naming/**" />
</includes>
<excludes>
<exclude name="org/apache/catalina/ant/**" />
<exclude name="org/apache/catalina/ha/**" />
<exclude name="org/apache/catalina/mbeans/
JmxRemote*" />
<exclude name="org/apache/catalina/tribes/
**" />
<exclude name="org/apache/catalina/launcher/
**" />
<exclude name="org/apache/catalina/
storeconfig/**" />
<exclude name="org/apache/naming/factory/
webservices/**" />
<exclude>org/apache/naming/factory/
webservices/**</exclude>
</excludes>
</configuration>
</plugin>
Another question is that I found that the way we divided the Tomcat
codes are not the same with its original way.
Tomcat has an artifact named coyote, while we didn't.
Is there any story about it ? If no special reason, I would like
keep the same with Tomcat's.
Thanks !
2009/12/3 Ivan <[email protected]>
OK, I will try to do it in the next week if no one beats to it !
2009/12/3 Kevan Miller <[email protected]>
On Dec 2, 2009, at 11:51 AM, David Jencks wrote:
>
> On Dec 2, 2009, at 1:57 AM, Ivan wrote:
>
>> I am thinking whether there is maven plugin would help us to
repackge the tomcat jar file to include our changes, so that we do
not need to maintain the whole Tomcat source codes, maybe just need
to keep a few files.
>
> AFAIK tomcat is not pushing trunk snapshots into any maven repo,
so I think we'd have to build tomcat ourselves anyway. Given that,
I think that the easiest way is to use the process for constructing
a mavenized build. I'm hoping we won't actually need to modify any
files, at least not for long :-). The first set of changes we
needed that led me to set up the mavenized build have been in tomcat
trunk for years.
Right. So, if the motivation for this process is to make Tomcat
SNAPSHOT's available in maven, I'm ok with this. I would not want to
see this as a way of fixing functional/integration problems with
Tomcat (at least not in the long-term).
--kevan
--
Ivan
--
Ivan
--
Ivan
