Allow referencing non-jarred artefacts (so that compile phase works). #87
Conversation
|
I don't fully understand the idea behind the PR. Can you give an example? |
| if (signaturesArtifacts != null) { | ||
| for (final SignaturesArtifact artifact : signaturesArtifacts) { | ||
| final File f = resolveSignaturesArtifact(artifact); | ||
| if (artifact.path != null) { | ||
| sigUrls.add(createJarUrl(f, artifact.path)); | ||
| if (f.isDirectory()) { | ||
| sigUrls.add(createFileUrl(f, artifact.path)); |
There was a problem hiding this comment.
I think, you could simply add the resolved file to sigFiles. This makes output for plain files nicer (it does not log an url, but a filename). It would simply handle the artifact as a plain file.
Something like: sigFiles.add(new File(f, artifact.path))
I am still confused, how this can work. It returns a directory instead of a file after artifact resolve????
|
The fix is for the following scenario:
You can't just specify a path once because for every subproject the relative folder changes. So you do want to specify an artefact dependency. But the artefact may not be (yet) jarred, in which case Maven resolves to target/classes folder (and this is correct). Don't know how to explain it better. ;) |
|
That is waht I expected. Does this also happen if you specify type=jar (because type is a required parameter for artifacts). To me it is just strange that Maven returns the classes folder... Is there any way to get this information from the resolved artifacts. File#isDirectory looks strange to me. In any case, I can take you patch, I would just change the code to not use an URL (not needed here), instead just add the JAR file, once resolved as standard File signature. I added that as a comment. If you want, you can change it, too. In any case, I would prefer to have some way to check the state "artifact as jar" or just classes directory using the official Maven 2 artifact API. |
|
This has nothing to do with the type, Uwe. Maven always resolves the artefact to classes folder before it's actually jarred (before the build hits package phase). I am not a maven developer, I guess they need resolution of build artefacts to happen for compilers and other tools. Whether this points to a JAR or a folder should be transparent (or so I think). :) Add a breakpoint at this method and try it, you'll see what I mean. I'm not advocating for whether this is correct or not, it's just what Maven does. I didn't look deeply at the code -- you can obviously use the file reference instead of an URL if this is possible (in forbiddenapis code). The point is: a maven project's artefacts can come as a JAR or as unpacked folder. |
|
I will merge your PR to give you the reference and later change it a bit. |
Allow referencing non-jarred artefacts (so that compile phase works).
|
Merged. Thanks Dawid. |
…arred (this makes logging cleaner).
|
I changed you PR a bit, so logging uses filename instead of unreadable URL (unless jarred). |
|
Thanks Dawid for providing insight, the more I get into this Maven stuff, the more I love ANT (the cleanest solution) or Gradle (everything is a FileCollection...) |
|
Just for completeness: https://issues.apache.org/jira/browse/MDEP-259 |
This patch makes it possible to use non-jarred artefacts (for example reference a different project in a multi-module build, without creating a jar for it).