Module paths for system scope are relative to parent pom instead of its own

this should be won't fix: system scope must be absolute.

Instead, we should validate the systemPath and ensure this is the case.

I see your argument that having systemPath an absolute path enables successful builds both from the standalone module itself for CI as well as in the parent dir to get the multi-module site benefits.

However, in practice, it can't be absolute. The dir can be in different absolute locations on different machines/for different users. Files in the module are relative to its root - to the pom file location in Maven's case.

Perhaps using systemPath is the wrong way to solve the problem then - How does one get the jars in a $

/lib dir on the classpath to build with?

If not possible, then the argument that it "must be absolute" is off base, and makes the systemPath option rather worthless, and Maven 2 fails to handle many common situations.

systemPath was put in place for a couple of use cases which will actually be rendered obsolete in 2.1. For example, using tools.jar. It is meant to be absolute, using properties to determine the correct base directory for this system.

for files in lib/, the previous solution was and should still be to copy them into the repository, otherwise - as you've seen - when they are requested transitively they can not be found.

You could work around this by setting the system path to $

/lib - but I strongly advise against it.

Thanks for the workaround.

I like the repo approach and strong Maven recommendation, especially for the plugins and tools.

I think it is a Maven failing to enforce that on everything and not have a simple supported mechanism to get $

/lib (or whatever dir) on the classpath. It causes headaches for some adopters, including us, and may cause it not to get used (that is IMO worse than supporting the relative system path that deviates from the vision of all artifacts/dependencies in a Maven repo).

> when they are requested transitively they can not be found.

A use case is with 3rd party libs/jars that are source controlled and delivered to the workspace in that manner. They are not housed by any Maven repos (you say "put them in there", the product team's decision is "no"). The repo is the source control repository. The version to use is the one in the referenced directory. In this situation, the dependency is resolved in the process around accepting a new lib version into source control and integrating to the correct product versions. This is part of the reproducible builds best practice - all "source" artifacts are sourced in the codeline. Jars without source are source artifacts when that is the closest original source artifact obtainable.

Not everyone can get away from having jars source controlled and instead having them in Maven repos.

My summary is instead of the tool forcing this particular manner on users, let the user decide when it is correct to put them in a Maven repo and when not to by having the local reference feature. This is flexibility and supports easier Maven adoption.

Need to fail if systemPath is not absolute. This will probably happen in DefaultArtifactResolver, if not in DefaultModelValidator...

Hi. If the specified systemPath is absolute, wouldn't that be machine specific?

Edwin: the value is meant to contain a property that gives the machine specific absolute path, eg:

$

/../..

Got it. Please see attached patch...

Brett, in your comment on 09/Nov/05, you say "systemPath....will acutally be rendered obsolete in 2.1". What is the planned feature that replaces this one?

systemPath was only intended for use in finding system libraries. This was for two specific purposes:

• location of Java system libraries (tools.jar, for example). We hope to have this handled by specification dependencies
• location of system libraries in a native build. This now can be handled by custom resolvers

Aside from that, its use was originally going to be omitted so it will be discouraged going forward.

I would REALLY not like to see systemPath go away. We have no option to store our jars in a maven repository. They must be pulled down from source control and used at build time. Maven 2 is a significant step backwards in terms of being able to dynamically add Jars to the classpath at runtime. Is there any plan to allow using some kind of mask, like .jar;.zip to discover jars in a specified directory ?

I was able to, with an ANT script in 1.x, add Jars to the maven classpath so that each Jar would not need to be referenced manually in the POM.

Any plans to support that kind of flexibility ?

I've been using Maven 1.x for years, and I have to say, I believe that while some things are easier to do now, others have become more inflexible.

f they take systemPath away, as he says, then that'll break me again, for sure.
I'm really contemplating NOT using M2.

In any case, my workaround to make it truly dynamic, is my build.bat file first calls an ANT script that compiles a DependencyBuilder class that I created, which iterates through the jar files in my "lib" directory, and creates a string that has all the <dependency> entries in it. Then, I have a pom that lives in my "lib" project called pom-template.xml, that, while still in ANT, I copy to the same directory renaming to pom.xml. I filter the file using the ANT filter mechanism to ADD the string I just created in the DependencyBuilder class, giving a psuedo-dynamic discovery of dependencies.

Then, I reference the "libs" project in each of the sub-projects.

A little complicated, but then I don't have to manually add JARs to the build when the developers add them.

The whole point of maven is to have your project declaratively specified, and then use that information to build the project artifact, project documentation, etc., etc. Why would you want to remove that safety net?

Aside from this discussion, there is an SCM wagon provider (not sure of what quality it currently is), which can retrieve your dependencies from CVS/SVN/etc. if your scm repository is structured as a normal maven repository. Then, it's just a matter of specifying the correct <repositories/> configuration, and adding a build <extension/> for the scm wagon. Would this work?

It seems as if you've been using Maven 1 as a shell around Ant for some time now, if you're still adding lib/.jar. System dependencies are "broken", in that they don't support transitivity, and can *very easily become non-portable (like, if lib/ exists outside your project directory...it doesn't, does it??). For things like tools.jar, we're planning to support the notion of specification dependencies, where tools.jar might implement some javac POM or something. For native builds, where the dependency is actually installed on the system somewhere, alternative artifact resolver implementations are more appropriate, since specifying the path of these deps on the user-POM side isn't very efficient.

it will just be discouraged, not removed (at least not without a reasonable deprecation period and plenty of discussion of alternatives).

We might need some other resolvers, but the dependenchy mechanism in m2 relies on the repository information to perform. I guess what you are asking for here is to turn off the dependency mechanism and just use local jars - that's a possibility, and a separate feature request.

Hi John,

I think your assessment is correct in that I think my usage model of Maven is a convenience wrapper around ANT, and using the event driven model around compilation, etc. I'm going to stick with Maven 2 and see if there's any other issues that crop up, but I'm going to try and adopt the Maven 2 usage model as closely as possible.

thx all,
mw

John, Matt's may be what you describe, but ours is not. I gleefully shed anything Ant-ish when I began using Maven. My situation is described in my comment on 10/Nov/05 11:48 AM].

Brett's comment on 05/Dec/05 04:45 PM sounds right on for our situation.

You have your third party libraries in SCM, and it's been decided that this should remain the case...how would this preclude your using an SCM-based Maven repository? As I mentioned in my comment to Matthew on 05-Dec, the Maven-Wagon project does have an SCM provider (not sure what the status of it is, though). This, along with a custom artifact repository layout (to adapt to non-m2-ish layout of your /lib), should enable you to resolve those libraries without any custom design on the part of Maven.

While this practice has not been fully realized yet, there is nothing tying users to the default Maven 2.x repository layout for their own repository instances; you only need to have an appropriate ArtifactRepositoryLayout and the right wagon provider in place. These two tasks are still non-trivial, but possible with the current implementation.

Would this solve your problem? Would there be any problem with checking in POMs for those third party libraries, to help make transitive dependencies possible for those? If not, it's still possible to use them.

Applied patch, with small logic fix. This patch will validate that if a systemPath is specified for a dependency, it is absolute. It's possible to use expressions in this path, but by the time it's validated in this step, those expressions will have been resolved.

My change was to add the same validation to managed dependencies.