zmeggyesi/migrator-maven-plugin

Could not locate repo, directives are not complete

wstrange opened this issue · 22 comments

I am using this with a private artifactory repo - which might be causing this issue.

When I run it, I get a lot of warnings:

[WARNING] Could not locate repo

And only a single directive is added to the output directives file (there should be many).

If I run without any config parameters, I do see more output generated in the INFO lines. I am not sure why only a single directive is output when using the file output.

Could you provide a bit more info? Namely:

  • Attach your POM
  • The command line you're using to run
  • Which repo is private

The fact that it's a private repo should not factor into this, given that resolution is done by Maven, not by my plugin, I'm simply requesting the resolution results...

The command line I am using is:

mvn hu.skawa:migrator-maven-plugin:dependencies

All of those deps are in a private repo.

There is only a single artifact generated:

maven_jar(
        name = "org_assertj_assertj_core",
        artifact = "org.assertj:assertj-core:2.4.1",
)

[WARN] Could not locate repo is emitted when the plugin cannot access the _remote.repositories file, which holds the repo information for Maven.

What strikes me as odd from your POM is that almost none of the artifacts have versions, which should not be valid for Maven. I suspect that this is a problem with your private repo.

What does a simple mvn dependency:resolve show, just out of curiosity? Also, can you verify for me that there really isn't a _remote.repositories file next to the individual dependencies?

mvn dependency:resolve works OK - and generates a lot of output (I can paste it if you want).

This is a sub-module - so the versions are specified in the parent pom.

I also tried running this in the parent, and I get similar results: There is only a single artifact output to directives and references.

All of the artifacts are stored in a private maven repo, and the parent pom specifies the <repository>. The credentials for accessing the private repo are in ~/.m2/settings.xml

There is no _remote.repositories

I will continue to do some debugging...

I think it has to do partially with it being a Maven module - I have a modular project that I can test against, I'll add that to the next version. Good catch!

The second thing is that I may have made a potentially incorrect assumption about the presence of the _remote.repositories file. I'll look that separately, so for now, I'm planning to have graceful failure if not found.

Just a guess, but you're not using Eclipse as your IDE, are you? Maven resolution is done from where, CLI at all times?
I'm asking because I use Eclipse, which has an embedded Maven, and the file might be written from there, which would mean additional laps to make server resolution work.

I can reasonably handle modular projects soon(ish), but I'm not sure about the servers if my hunch is correct.

I am using Intellij, but all mvn builds are done from the command line.

I will continue to experiment.

@wstrange Can you try the latest version? I fixed the export file issue but you may need to run the goals per-module, not for the parent.

I'll look into the server export separately, however.

I tried the latest on both the parent pom and in a child module.

I get the same result: Only a single dep is written out.

What is odd is that I can see many maven_jar() statements sent to mvn stdout. They just never make it to the output files

Okay, I think my multi-module project was not sufficiently complex (really, it was just a component library with common deps...), so it didn't reveal a potential iteration problem where the export file was re-opened during the reactor build and its contents replaced.

What I'm going to do is move the entire process one layer down, and operate on the list of collected projects if there's more than one, prefixing the exported file with the project name, at least as a POC. If that works, I'll work on grouping all the exports into a single file. That should let me lock down this problem.

Can you try checking out modular-projects and building/running that? It produced all dependencies for me, but there is one caveat: the MOJO's execute() method is called separately for each project during the reactor build, so the only way I could preserve all the information is by writing a new file for each project.

As of now, I'm afraid I can't really think of a way to bring all that information into one file, since by the time all exports are ready, the plugin no longer has control.

Let me know if the branch worked on your given POM, so I can either merge it back and release or make further changes as needed!

I tried the modular-projects, but I get the same results. Only a single dep written out.

Just out of curiosity, did you replace the plugin version in your POM? I didn't during the first few rounds of testing, so my changes weren't picked up... :)

I did forget to change the version, but I just reran it on both branches, and I get the same result.

That's definitely not correct, the latest branch should be putting out one file per project (since the MOJO is called once for each project). If you're using the latest code, you should be seeing more than one file, so it sounds rather strange that you're still seeing only one dependency in one file...

Does each module need to declare the plugin, or just the parent pom?

No - I placed it in the parent pom

I rebuilt the module branch to be sure. This is what I have in my parent pom

 <plugin>
                        <groupId>hu.skawa</groupId>
                        <artifactId>migrator-maven-plugin</artifactId>
                        <version>1.1.1</version>
                        <configuration>
                            <outputFilePrefix>bz</outputFilePrefix>
                            <outputDirectives>true</outputDirectives>
                            <outputReferences>true</outputReferences>
                        </configuration>

                    </plugin>

Am I correctly specifying the output file prefix and options?

I am not getting any output files at all now when I run mvn hu.skawa:migrator-maven-plugin:dependencies

BTW - lots of these errors still:
[WARNING] Could not locate repository file for joda-time, setting to empty!

And lots of maven_jar output sent to the stdout - but it is not written to the files

I'm focusing on one issue at a time, the server location is a different feature. I want to help you get the dependency export working first :)

Regarding the syntax, it looks okay. I actually went ahead and copied the <configuration> element from you, and the export ran just fine.
This is the relevant section of the parent POM I used for testing:

        <build>
                <plugins>
                        <plugin>
                                <groupId>hu.skawa</groupId>
                                <artifactId>migrator-maven-plugin</artifactId>
                                <version>1.1.1</version>
                                <configuration>
                                    <outputFilePrefix>bz</outputFilePrefix>
                                    <outputDirectives>true</outputDirectives>
                                    <outputReferences>true</outputReferences>
                                </configuration>
                        </plugin>
                </plugins>
        </build>

I also tried using the CLI -D{optionName} way of specifying a Maven VM option.

The biggest hurdle I'm facing is that there is apparently a difference between the two projects (yours and my test project) that I'm not thinking of, and I can't see your project (cloning it would probably not help due to the private repos).
Can you try launching using mvnDebug instead of mvn and attaching a debugger? That might let you see if the files even get created, or if there's something emptying the files during the run...

Are you using Maven 3.0+ or a version from before 3.0 (mvn -v will print out the version)? That's the only reason I can think of for the _remote.repositories files is missing, since prior to Maven 3.0 did not track the source of the artifact, only the fact that it exists in the repo.

maven 3.3.9. I may get some time next week to run mvnDebug. This is not super critical for me right now - so no worries.