As a side note:
Scenario: you want to make a dependency available to your build but
said artifact does not live in any remote Maven repo, rather it is
"supplied" from the Git repo.
In this case - as an alternative to what you are currently doing - you
can also simply install it locally, using the Maven Install Plugin's
"install-file" goal.
For example:
<plugin> <groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId> <version>3.1.4</version>
<executions> <execution> <id>foo-install-in-local-repo</id>
<phase>initialize</phase> <goals><goal>install-file</goal></goals>
<configuration> <groupId>self.private</groupId> <artifactId>foo</artifactId>
<version>LOCAL-IN-GIT</version> <packaging>jar</packaging>
<file>${project.basedir}/libs/foo.jar</file> </configuration> </execution>
</executions> </plugin>
It is a bit cleaner in the sense that you don't have to construct a POM
file, maintain maven-metadata.xml file, etc.
Also, when drive-by developers look at your <dependencies> section:
because the dependency's version is 'LOCAL-IN-GIT' it should obvious to
such developer that it is supplied by the Git repo itself.
There are pros and cons of both solutions, I guess.
/L
On 10/03/2025 21.41, Bob Marinier wrote:
> I was able to replace file://${project.baseUri} with ${project.basedir} and
> it worked. Still not clear if/why baseUri isn't allowed here, but not a big
> deal for me. Also, a very minor nit, but "basedir" isn't camelCase like
> baseUri and rootDirectory (and the "dir" vs. "Directory" inconsistency). I'm
> assuming this can't be changed for compatibility reasons but pointing it out
> just in case!
>
> Bob
>
> -----Original Message-----
> From: Bob Marinier <[email protected]>
> Sent: Monday, March 10, 2025 11:25 AM
> To: [email protected]
> Subject: [EXTERNAL]maven 4 RC3 possible issue
>
> Hi all,
>
> I recently saw the jfokus talk on maven 4 and heard the desire for more
> people to try it out and report back, so here goes. I tried RC2 and RC3 on an
> open source project I maintain (https://github.com/soartech/jsoar) and ran
> into two issues (note this works fine with maven 3.9.8, which is what I
> currently have on my machine otherwise). I did not modify the poms at all to
> try to take advantage of any new features. I ran "mvn clean verify" with Java
> 17 on windows 11.
>
> I got the following output for RC3 (RC2 is similar):
>
> PS D:\git\jsoar> mvn clean verify
> [INFO]
> [INFO] 1 problem was encountered while building the effective settings (use
> -e to see details) [INFO] [INFO] Scanning for projects...
> [ERROR] Some problems were encountered while processing the POMs [ERROR] The
> build could not read 1 project -> [Help 1] [ERROR]
> [ERROR] The project com.soartech:jsoar-soarunit:5.1.2-SNAPSHOT
> (D:\git\jsoar\jsoar-soarunit\pom.xml) has 1 error
> [ERROR] 'repositories.repository.[repo].url' contains an unsupported
> expression (only expressions starting with 'project.basedir' or
> 'project.rootDirectory' are supported). @ line 75, column 13
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
> switch [ERROR] Re-run Maven using the '-X' switch to enable verbose output
> [ERROR] [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
>
> The part it is complaining about is this block in one of the submodule (or I
> should say subproject now) poms:
>
> <!-- local repo for sml dependencies -->
> <repositories>
> <repository>
> <id>repo</id>
>
> <url>file://${project.baseUri}/sml-setup/repo</url<file://$%7bproject.baseUri%7d/sml-setup/repo%3c/url>>
> <releases>
> <updatePolicy>always</updatePolicy>
> </releases>
> </repository>
> </repositories>
>
> I'm using a variable here to point to a directory that contains a dependency
> that isn't published (I had to make it myself). I don't know if this is a
> maven 4 bug, or something that is no longer supported, or something that was
> never supposed to be supported but happened to work anyway in maven 3. I
> could use a relative path instead, unless there is some other official way to
> do this?
>
> Thanks,
> Bob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
