RE: Using file://../../path for maven.repo.remote
In other things I found the following, if I erase the /repository directory from my local repository I get a java.lang.ClassNotFoundException: velocity at the middle of the jar dependencies copying, if I run maven again, everything works fine :-\. I erased that directory when I was trying to have a new local repository but just the jar files. I don't know if this new or not, I'll post it into JIRA anyway. This is a known bug - I think there are actually 2 issues in JIRA for it at the moment :) Clearing your ~/.maven/plugins directory will fix it. Cheers, Brett
Re: Using file://../../path for maven.repo.remote
Colin,
which is the bug report?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Colin Sampaleanu [EMAIL PROTECTED] wrote on 12/08/2003 10:48:37 PM:
You can definitely use file: references to set up remote repos. I use
this definition for maven.repo.remote in some projects:
maven.repo.remote=\
file:${basedir}/../../shared/repository,\
http://www.ibiblio.com/maven
Try using 'file:' instead of 'file://', the latter is not really kosher.
Also, you probably need to go relative off ${basedir}.
However, note that there are some _severe_ issues with repo overrides
and plugins. Plugins don't seem to be able to pick up remote and local
repo overrides from a project's property files. This is why when I do my
builds, all the dependencies the plugins themselves need come from
ibiblio, and only my own dependencies come from my filesystem remote
repo. Even then, everything totally breaks when I use the multiproject
plugin, as it gets even more confused.
This issue is incredibly annoying and makes maven unusable in a number
of situations... I filed a bug report about 7-8 months ago about this,
but the functionality is still broken, and unfortunately I've not had
the time to fix it myself, which has prevented me from moving a bunch of
stuff to maven...
Robles, Rogelio wrote:
I need to support a closed building/deployment environment because the
production releases are built and deployed by our SCM admin team. They
use a
clean and closed build box, using only officially approved tools: jdk,
ant
and soon Maven ;-).
'remote' repositories are stored in our SCM server and project
stakeholders
(developers and SCM admin team) get them through snapshots when is
worth to
do it.
The structure that I have is this:
/root
/scm-user-id
/projectX
/component1
/component2
/component3
/thirdparty
/maven
/repo
/internal
/repo
As you can see the scm-user-id is different for all the stakeholders
of
the project so I can't use hard coded absolute directory names for the
repositories location. Then I use relative URLs for references:
In component1's project.properties file I have:
maven.repo.remote=file://../../thirdparty/maven/repo,
file://../../internal/repo
This produces:
Attempting to download commons-lang-1.0.1.jar.
WARNING: Failed to download commons-lang-1.0.1.jar.
And I don't get the artifacts installed in my local repository.
At the beginning I was under the impression that I can't use relative
URLs,
but I tested moving the 'remote' repositories as siblings of my
components,
under projectX, and everything works fine, with this:
maven.repo.remote=file://../thirdparty/maven/repo,
file://../internal/repo
Is there a possible solution for this static properties-file-only
solution?
do I need to create a dynamic solution? I have thought of instead of
relative URL's generate absolute URLS at runtime using jelly, is this
possible?
Rogelio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using file://../../path for maven.repo.remote
It's Maven-224.
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-224
I would have attempted a fix myself, but my feeling is that this
involves potentially fairly heavy duty changes, more than my limited
knowledge of Maven internals allows me to tackle...
[EMAIL PROTECTED] wrote:
Colin,
which is the bug report?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Colin Sampaleanu [EMAIL PROTECTED] wrote on 12/08/2003 10:48:37 PM:
You can definitely use file: references to set up remote repos. I use
this definition for maven.repo.remote in some projects:
maven.repo.remote=\
file:${basedir}/../../shared/repository,\
http://www.ibiblio.com/maven
Try using 'file:' instead of 'file://', the latter is not really kosher.
Also, you probably need to go relative off ${basedir}.
However, note that there are some _severe_ issues with repo overrides
and plugins. Plugins don't seem to be able to pick up remote and local
repo overrides from a project's property files. This is why when I do my
builds, all the dependencies the plugins themselves need come from
ibiblio, and only my own dependencies come from my filesystem remote
repo. Even then, everything totally breaks when I use the multiproject
plugin, as it gets even more confused.
This issue is incredibly annoying and makes maven unusable in a number
of situations... I filed a bug report about 7-8 months ago about this,
but the functionality is still broken, and unfortunately I've not had
the time to fix it myself, which has prevented me from moving a bunch of
stuff to maven...
Robles, Rogelio wrote:
I need to support a closed building/deployment environment because the
production releases are built and deployed by our SCM admin team. They
use a
clean and closed build box, using only officially approved tools: jdk,
ant
and soon Maven ;-).
'remote' repositories are stored in our SCM server and project
stakeholders
(developers and SCM admin team) get them through snapshots when is
worth to
do it.
The structure that I have is this:
/root
/scm-user-id
/projectX
/component1
/component2
/component3
/thirdparty
/maven
/repo
/internal
/repo
As you can see the scm-user-id is different for all the stakeholders
of
the project so I can't use hard coded absolute directory names for the
repositories location. Then I use relative URLs for references:
In component1's project.properties file I have:
maven.repo.remote=file://../../thirdparty/maven/repo,
file://../../internal/repo
This produces:
Attempting to download commons-lang-1.0.1.jar.
WARNING: Failed to download commons-lang-1.0.1.jar.
And I don't get the artifacts installed in my local repository.
At the beginning I was under the impression that I can't use relative
URLs,
but I tested moving the 'remote' repositories as siblings of my
components,
under projectX, and everything works fine, with this:
maven.repo.remote=file://../thirdparty/maven/repo,
file://../internal/repo
Is there a possible solution for this static properties-file-only
solution?
do I need to create a dynamic solution? I have thought of instead of
relative URL's generate absolute URLS at runtime using jelly, is this
possible?
Rogelio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using file://../../path for maven.repo.remote
Thanks for info.
My comments inside your message:
-Original Message-
From: Colin Sampaleanu [mailto:[EMAIL PROTECTED]
You can definitely use file: references to set up remote repos. I use
this definition for maven.repo.remote in some projects:
maven.repo.remote=\
file:${basedir}/../../shared/repository,\
http://www.ibiblio.com/maven
Try using 'file:' instead of 'file://', the latter is not
really kosher.
Also, you probably need to go relative off ${basedir}.
This worked to get some of my dependencies, not all of them.
However, note that there are some _severe_ issues with repo overrides
and plugins. Plugins don't seem to be able to pick up remote
and local
repo overrides from a project's property files. This is why
when I do my
builds, all the dependencies the plugins themselves need come from
ibiblio, and only my own dependencies come from my filesystem remote
repo. Even then, everything totally breaks when I use the
multiproject
plugin, as it gets even more confused.
Yes, now I'm stuck at the same place as you (I'm using maven-beta-10), some
plugins
dependencies are not being copied over from the remote repositories.
I need to find out which plugins are and how they are getting their
dependencies.
Rogelio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using file://../../path for maven.repo.remote
Under this circumstances, relative file URLs, Maven is unable to supply jar dependencies to its plugins. I'm using the jar:install goal in my component, and the first plugin to be loaded it seems that is maven-artifact-plugin-1.0-SNAPSHOT and Maven couldn't find its dependencies. If I use an absolute file URL for maven.repo.remote everything works fine, but I cannot use this as a solution since other developers will have different SCM work directories. In other things I found the following, if I erase the /repository directory from my local repository I get a java.lang.ClassNotFoundException: velocity at the middle of the jar dependencies copying, if I run maven again, everything works fine :-\. I erased that directory when I was trying to have a new local repository but just the jar files. I don't know if this new or not, I'll post it into JIRA anyway. Rogelio -Original Message- From: Robles, Rogelio [mailto:[EMAIL PROTECTED] -Original Message- From: Colin Sampaleanu [mailto:[EMAIL PROTECTED] However, note that there are some _severe_ issues with repo overrides and plugins. Plugins don't seem to be able to pick up remote and local repo overrides from a project's property files. Yes, now I'm stuck at the same place as you (I'm using maven-beta-10), some plugins dependencies are not being copied over from the remote repositories. I need to find out which plugins are and how they are getting their dependencies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using file://../../path for maven.repo.remote
You can definitely use file: references to set up remote repos. I use
this definition for maven.repo.remote in some projects:
maven.repo.remote=\
file:${basedir}/../../shared/repository,\
http://www.ibiblio.com/maven
Try using 'file:' instead of 'file://', the latter is not really kosher.
Also, you probably need to go relative off ${basedir}.
However, note that there are some _severe_ issues with repo overrides
and plugins. Plugins don't seem to be able to pick up remote and local
repo overrides from a project's property files. This is why when I do my
builds, all the dependencies the plugins themselves need come from
ibiblio, and only my own dependencies come from my filesystem remote
repo. Even then, everything totally breaks when I use the multiproject
plugin, as it gets even more confused.
This issue is incredibly annoying and makes maven unusable in a number
of situations... I filed a bug report about 7-8 months ago about this,
but the functionality is still broken, and unfortunately I've not had
the time to fix it myself, which has prevented me from moving a bunch of
stuff to maven...
Robles, Rogelio wrote:
I need to support a closed building/deployment environment because the
production releases are built and deployed by our SCM admin team. They use a
clean and closed build box, using only officially approved tools: jdk, ant
and soon Maven ;-).
'remote' repositories are stored in our SCM server and project stakeholders
(developers and SCM admin team) get them through snapshots when is worth to
do it.
The structure that I have is this:
/root
/scm-user-id
/projectX
/component1
/component2
/component3
/thirdparty
/maven
/repo
/internal
/repo
As you can see the scm-user-id is different for all the stakeholders of
the project so I can't use hard coded absolute directory names for the
repositories location. Then I use relative URLs for references:
In component1's project.properties file I have:
maven.repo.remote=file://../../thirdparty/maven/repo,
file://../../internal/repo
This produces:
Attempting to download commons-lang-1.0.1.jar.
WARNING: Failed to download commons-lang-1.0.1.jar.
And I don't get the artifacts installed in my local repository.
At the beginning I was under the impression that I can't use relative URLs,
but I tested moving the 'remote' repositories as siblings of my components,
under projectX, and everything works fine, with this:
maven.repo.remote=file://../thirdparty/maven/repo, file://../internal/repo
Is there a possible solution for this static properties-file-only solution?
do I need to create a dynamic solution? I have thought of instead of
relative URL's generate absolute URLS at runtime using jelly, is this
possible?
Rogelio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
