On 27/01/2026 21:44, Fatima Qaisar wrote:
<snip/>
I attempted to continue building the tomcat-maven-plugin locally.
Initially, the build was failing due to JDK compatibility issues. I
experimented with updating some configurations to improve compatibility
with newer JDK versions(jdk 17+), and with those changes I was able to
build 6 of the modules successfully, although the remaining two were
still
failing after I tried changing tomcat8 version to a newer one.
I've been working with Java 8 locally and that seems to be working
reasonably well.
One of the things I haven't looked at yet is how the plug-in handles the
different minimum Java versions. Tomcat 7 has a minimum Java version of
Java 6 and Tomcat 8 has a minimum Java version of Java 7. Looking
forward, is it Java 8 for Tomcat 9, Java 11 for Tomcat 10 and Java 17
for Tomcat 11.
You need to understand how the plug-in handles that in order to plan for
what you need to aim for.
Talking of aims, before you get too far it would be good to set out a
high level set of aims and an outline plan of how to get there. In terms
of aims, updating to support Tomcat 9, 10 & 11 are the obvious ones.
What other aims would you add?
In terms of a plan, there are several ways I can think of to tackle
this. What is your outline plan at this stage (in terms of detail I'm
thinking of no more than 10 short bullet points just to give high level
overview)?
In parallel, I reviewed some recent pull requests and then retried
building the plugin from a clean, synced version of the codebase (without
my local changes). In this case, all modules built successfully except
for
the archetype module, which failed RAT checks for four files. After
skipping those checks, the build progressed further and only the
archetype
module failed to build
Interesting. I didn't see any errors. Everything built for me. You need
to start from a working build so this seems like a good place to focus
attention.
I was using Java 8 from the command line and running "mvn clean package"
which is what I usually use when testing Maven builds locally. That
might not be the best option - I'm no Maven expert - but it has been
working for me for a while.
What did you do to get those errors?
The main issues I’ve observed are:
· Non-resolvable parent POMs due to ${rootArtifactId} placeholders
· Leading backslashes in groupId and artifactId values
My understanding is that those are expected in an archetype so should
not be the source of any errors.
At this point, I wanted to ask for your guidance: would it be more
useful
for me to continue digging into these build and configuration issues
until
I can fully resolve them, or would you recommend focusing on other areas
for now to first build a stronger understanding of the project? Moreover,
should I try adding license headers to the files which are failing the
rat
checks?
Short term I would suggest:
- get the current HEAD building cleanly with Java 8
- work on the high level aims and high level plan
- testing a local build with a simple "Hello World" web application to
confirm that the plug-in works
I've just seen there is a tc8.x branch. It would be good to understand
if that is new work on Tomcat 8 support or if it has already been
integrated into main.
Tomorrow, I plan to start by reviewing the class you suggested and
studying Maven plugin architecture in more detail.
For context, my current setup is:
- OS: Windows 10
- JDK: 25.0.2
- Apache Maven: 3.9.12
All sounds good. Let me know if you have any questions.
Mark
Thank you for your time and guidance.
Best regards,
Fatima
On Tue, Jan 27, 2026, 10:30 PM Mark Thomas <[email protected]> wrote:
On 27/01/2026 08:52, Mark Thomas wrote:
On 27/01/2026 08:32, Fatima Qaisar wrote:
Hi Mark,
Thank you so much for your detailed reply and for offering to mentor.
I’m
genuinely excited about the possibility of contributing to Tomcat
through a
GSoC project.
That is great. Just remember we can't guarantee anything. GSoC is a
competitive process both within the ASF and across all the
organisations. There are only a limited number of slots. I'll do what I
can to support you but I can't make any promises about whether the
project will be accepted or not.
I’ve already cloned the tomcat-maven-plugin repository, fixed a few
typos
in the README, and submitted a pull request. I also tried building the
project, which currently fails — I’ll investigate further and report
my
findings soon.
Great. I'll look at the PR shortly. I'll also check out the repo so I
can follow along with what you are doing.
You'll see that I have been through and enabled dependabot, updated the
dependencies, fixed any issues caused by the updates and merged some of
the PRs.
The PRs I haven't merged fall into one or more of the following
categories:
- needs a test case
- has merge conflicts
- includes unnecessary / unwanted changes
- is an initial implementation Tomcat 9 support (we probably need to
chat about how best to do this)
#44 is particularly interesting as there are a LOT of changes in there.
How to extract useful changes from this another topic for discussion.
Mark
I’m particularly interested in the Maven plugin project. Could you
suggest
which technical areas or skills I should focus on early to prepare
effectively (e.g., Maven internals, plugin architecture, or Tomcat’s
build/deployment process)? I’ll also explore the other project ideas
in the
coming days to understand them better, and then I’ll update you with a
concrete project direction.
I haven't looked at the code so this is only a guess. I'd suggest the
following:
- The o.a.c.startup.Tomcat class. This forms the basis of all embedded
Tomcat uses. There are lots of examples in the unit tests of how to use
it.
- Maven plug-in architecture is likely to be useful.
Beyond that, I suspect you'll find yourself having to learn about lots
of different areas depending on where the bugs are. Something that
might
help is trying to spot groups of similar bugs and tackling them
together
so you don't have to research a completely new area every time you
start
a new bug.
I am committed to a full-time GSoC project this summer. I can
contribute
part-time until mid-June due to university commitments, after which I
will
dedicate myself full-time to the project.
OK full-time has an expectation of ~350 hours work on the project. The
important thing is that you can get at least that much work done in the
GSoC timescales. Exactly when you get it done is less important.
Thank you again for this opportunity; I truly appreciate your guidance
and
support. I’ll follow up soon with an update on my progress.
Sounds good.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
