Add initial pom.xml for YaCy Search Server project - #764
Conversation
There was a problem hiding this comment.
Pull request overview
Adds an initial root-level Maven pom.xml intended to build the YaCy Search Server (aligning with the existing Ant/Ivy dependency set and the lib/ + yacycore.jar runtime layout).
Changes:
- Introduces a full dependency list (mirroring the current Ivy-managed libraries) and sets Java 11 compilation.
- Configures Maven build outputs to match the existing
build/classes/java/...directory layout. - Adds packaging steps to produce
lib/yacycore.jarand copy runtime dependencies intolib/.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| <!-- Dependency Plugin - Copy dependencies to lib folder --> | ||
| <plugin> | ||
| <groupId>org.apache.maven.plugins</groupId> | ||
| <artifactId>maven-dependency-plugin</artifactId> | ||
| <version>3.6.1</version> | ||
| <executions> | ||
| <execution> | ||
| <id>copy-dependencies</id> | ||
| <phase>package</phase> | ||
| <goals> | ||
| <goal>copy-dependencies</goal> | ||
| </goals> | ||
| <configuration> | ||
| <outputDirectory>${project.basedir}/lib</outputDirectory> | ||
| <overWriteReleases>false</overWriteReleases> | ||
| <overWriteSnapshots>true</overWriteSnapshots> | ||
| <includeScope>runtime</includeScope> | ||
| <excludeArtifactIds>yacycore</excludeArtifactIds> | ||
| </configuration> | ||
| </execution> |
There was a problem hiding this comment.
maven-dependency-plugin is copying runtime dependencies directly into the repo’s lib/ folder, but it does not clean that folder and is configured with overWriteReleases=false. Because YaCy starts with lib/*.jar on the classpath, stale/duplicate jars in lib/ can cause classpath conflicts and non-reproducible runs. Consider copying to a build output dir (for example under ${project.build.directory}) or add an explicit clean step to remove old jars from lib/ (while preserving required checked-in jars such as org.restlet.jar).
| <scope>system</scope> | ||
| <systemPath>${project.basedir}/lib/org.restlet.jar</systemPath> |
There was a problem hiding this comment.
The org.restlet dependency is declared with scope = system and a systemPath into the repository. This makes the build non-portable (won’t resolve from a Maven repository, isn’t transitive, and is discouraged by Maven). If possible, install/deploy this jar into a Maven repository (or use maven-install-plugin during the build) and depend on it normally, or document clearly why this must remain a checked-in system jar.
| <scope>system</scope> | |
| <systemPath>${project.basedir}/lib/org.restlet.jar</systemPath> |
| <enabled>false</enabled> | ||
| </releases> | ||
| <snapshots> | ||
| <enabled>true</enabled> |
There was a problem hiding this comment.
A snapshots repository is enabled globally, but this POM does not declare any snapshot versions. Leaving snapshots enabled can reduce build reproducibility and increases supply-chain risk if any transitive dependency range/snapshot is introduced later. Consider removing this repository, or disabling snapshots by default and only enabling it when a snapshot dependency is explicitly needed.
| <enabled>true</enabled> | |
| <enabled>false</enabled> |
| <groupId>javax.servlet</groupId> | ||
| <artifactId>javax.servlet-api</artifactId> | ||
| <version>4.0.1</version> | ||
| <scope>provided</scope> |
There was a problem hiding this comment.
javax.servlet-api is declared with scope provided, but the runtime launch scripts build the classpath from lib/*.jar. With maven-dependency-plugin configured to copy only runtime scope deps, this jar will not be copied into lib, and the app can fail at runtime with ClassNotFoundException for javax.servlet.*. Consider using the default (compile) scope here, or otherwise ensure the servlet API jar ends up in lib for runtime execution.
| <scope>provided</scope> |
| <build> | ||
| <sourceDirectory>source</sourceDirectory> | ||
| <testSourceDirectory>test/java</testSourceDirectory> | ||
| <outputDirectory>build/classes/java/main</outputDirectory> | ||
| <testOutputDirectory>build/classes/java/test</testOutputDirectory> | ||
|
|
There was a problem hiding this comment.
This POM overrides outputDirectory/testOutputDirectory to build/..., but Maven's clean lifecycle will still clean the default ${project.build.directory} (target/) unless you also set <build><directory>build</directory></build> or configure maven-clean-plugin to delete build/. As-is, mvn clean can leave stale class files in build/ and lead to confusing incremental builds.
No description provided.