http://blog.artifact-software.com/tech/?p=177
more free advice that really helps.
Ron
On 29/11/2013 12:29 PM, Malte Skoruppa wrote:
Hi,
Rather than putting the parent in the repo, try using maven to
install it.
Awesome! That worked just fine! Now it's building... thanks!
(Please note that I had not put the parent in the repo myself, I just
downloaded a repo which already included that parent... and I did not
have the original module to install via Maven, though I now managed to
"simulate" its installation; see below)
Explanation: I think the problem was that this parent POM, which was
only in the local repo
(/home/malte/.repository/com/scytl/maven-generic-conf/1.1.39/maven-generic-conf-1.1.39.pom)
itself specified some repository mirrors from the company that created
the project I was trying to build. The company probably does that
because "it gives them control over the code that is being used, and
isolates them from failure or disappearance of the upstream
repository", as Stephen nicely formulated it in his blog post.
I had removed the sections specifying those mirrors from the parent
POM in the local repo (I didn't mention that in my first mail because
I thought it was not relevant), as I cannot access these mirrors. And
the errors I described in my first mail occurred with or without those
mirror specifications in the parent POM anyway.
However, following your suggestion I simulated "installation" of the
POM by:
1. creating an empty directory /home/malte/maven-generic-conf
2. copying
/home/malte/.repository/com/scytl/maven-generic-conf/1.1.39/maven-generic-conf-1.1.39.pom
to /home/malte/maven-generic-conf/pom.xml
3. typing 'mvn -X -U -Dmaven.repo.local=/home/malte/.repository
install' inside the directory /home/malte/maven-generic-conf
Afterwards, the child module finally compiled successfully!
I was curious about what that "installation simulation" exactly
changed in my local repository, as the parent POM in principle was
already installed there anyway. The thing that made the whole
difference was that the file
/home/malte/.repository/com/scytl/maven-generic-conf/1.1.39/_maven.repositories,
which contained
#NOTE: This is an internal implementation file, its format can be
changed without prior notice.
#Wed Sep 04 19:15:02 CEST 2013
maven-generic-conf-1.1.39.pom>mirror=
...had now been overwritten with the following contents:
#NOTE: This is an internal implementation file, its format can be
changed without prior notice.
#Fri Nov 29 17:52:50 CET 2013
maven-generic-conf-1.1.39.pom>=
maven-generic-conf-1.1.39.pom>mirror=
...and that was it! It was probably because of this file that Maven
insisted on trying to download the file. I found out I do not even
have to simulate "installation" of the parent POM. By just removing
the keyword 'mirror' from
/home/malte/.repository/com/scytl/maven-generic-conf/1.1.39/_maven.repositories
(as well as removing the mirror specifications from
/home/malte/.repository/com/scytl/maven-generic-conf/1.1.39/maven-generic-conf-1.1.39.pom),
everything works fine.
Can someone explain what this _maven.repositories file exactly does? I
know how to get it to work now, but I don't fully understand what
happened here. :)
Maven 3.0+ enforces that downloaded artifacts were resolved from a
repository url/id that matches an url available for the current session.
How does it know where downloaded artifacts were resolved from?
This is one of those cases where the project you are building did not
pay
heed to the blog post I wrote on how to handle non-maven jars:
http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
They thought they had a hack that would work... they are sadly wrong.
That blog post was very interesting and instructive.
However, seeing the above, do you think that this was indeed the problem?
Note that this parent POM installed in the local repo did not include
any non-maven-jars JARs or anything.
It was simply a kind of generic company-internal über-pom that
specified some configuration, like, for some plugins which versions to
use, an <issueManagement>, a <ciManagement>, etc., as well as, of
course, those company-internal <repositories> / <pluginRepositories> /
<distributionManagement> which I had removed.
IIRC there is a CLI option that you can enabled in Maven 3.1.1 that
tells
Maven "I know what I am doing and don't make that check this time" i.e.
--legacy-local-repository
As I'm on Maven 3.0.4 and Ron's solution did it, I didn't get to try
this one (I would have had to update Maven). Would be interesting to
see if that works, though :)
Best,
Malte
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
