Maven separates plugins from "normal" dependencies of a project. A
plugin is "only" used to execute the build-process itself, i.e. your
product has no direct dependencies to plugins.All artifacts that are
used by plugins are resolved from the plugin-repository. That is, if one
of your plugins uses JUnit, junit.jar will be loaded from the
plugin-repository. The same is true, of course, for the plugin-jars
themselves.
All direct dependencies of your product (libraries, frameworks,
whatever) are resolved from the "normal" repository. Personally, I think
this separation is a a good idea. However, it only pays off, if you
don´t use the default remote repositories, but only internal
repositories. IMO this is the only way to guarantee reproducible builds,
so that´s my default setup. If you use separate internal repositories
for plugins and dependencies, you´ve a better chance to control your
build environment. All updates of artifacts in the "normal" repository
have a direct impact on your product and probably must be controlled by
some form of change process. Updates in your internal plugin repository
may have an impact on your build process, so you need to verify that
Maven still runs as expected. If you use just one repository, it´s
difficult handle both scenarios separately.
Sadly, there are some exceptions to the rule. For example, all
<extensions> defined in your POM will be loaded from the "normal", not
the plugin-repository. It´s not a big issue, but somehow disturbing.
If you decide to use internal repositories, you have to fill them
somehow with the required artifacts. The easiest solution is to simply
copy your local repository. However, this will not work out-of-the-box
for plugins. Maven maintains in remote repositories some extra metadata
for plugins in files named maven-metadata.xml. In your local repository,
these files are named differently. For example, if you downloaded the
plugins from the default plugin-repository
(http://repo1.maven.org/maven2), your local metadata files will be named
maven-metadata-central.xml (central is the id of the default
repository). So, after copying your local repository in the directory of
your internal repository, you have to rename all files with the name
maven-metadata-central.xml to maven-metadata.xml. The following
Ant-script will exactly do this for you:
<project name="prepare-repo" basedir="D:\mvn_repos\plugin" default="run">
<target name="run">
<move todir="${basedir}" verbose="true">
<fileset dir="${basedir}">
<include name="**/maven-metadata-central.*"/>
</fileset>
<regexpmapper from="(.*)maven-metadata-central.(.*)"
to="\1maven-metadata.\2"/>
</move>
</target>
</project>
Before running the script, you have to change the directory
d:\mvn_repos\plugins to the path of your internal plugin repository, of
course.
CU,
Gunther
What's the difference between <repository> (like I had defined) and pluginrepository?
-----Original Message-----
From: Rollo, Dan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 11, 2006 12:43 PM
To: EJ Ciramella; Maven Users List
Subject: RE: Internal (intranet) repositories
Have you tried adding "plugin repos" to your pom?
Like:
<pluginRepositories>
<pluginRepository>
<id>central</id>
<name>local-repository</name>
<layout>default</layout>
<url>http://build.corp.upromise.com/mavenrepository</url>
</pluginRepository>
...
</pluginRepositories>
Dan
-----Original Message-----
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 11, 2006 10:42 AM
To: Maven Users List
Subject: RE: Internal (intranet) repositories
Still - I have:
<repositories>
<repository>
<id>central</id>
<name>local-repository</name>
<layout>default</layout>
<url>http://build.corp.upromise.com/mavenrepository</url>
</repository>
<repository>
<id>lty-local</id>
<name>local-repository</name>
<url>file:thirdparty/repository</url>
</repository>
</repositories>
(I tried the reversing the order to no avail)
And I see -
E:\work\foxboro\model>mvn process-resources -P foxboro,model-base [INFO]
Scanning for projects...
[INFO]
----------------------------------------------------------------------------
[INFO] Building LtyModel
[INFO] task-segment: [process-resources]
[INFO]
----------------------------------------------------------------------------
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin-parent/2.0/maven-plugin-parent-2.0.pom
But I can see this:
http://build.corp.upromise.com/mavenrepository/org/apache/maven/plugins/maven-plugin-parent/2.0/maven-plugin-parent-2.0.pom
What am I doing wrong?
-----Original Message-----
From: Gunther Popp [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 08, 2006 7:29 AM
To: Maven Users List
Subject: Re: Internal (intranet) repositories
I´m by far any expert in the Maven source code, but as far as I understand the implementation the
repos defined in your pom will be checked first. If your pom contains no repo with the id
"central", the default repos defined in the "Super-POM" pom-4.0.0.xml will be
searched next. Then all repos defined in parent-poms are considered.
Additionally, the repos are searched in the order you define them in your
pom.xml.
This should be true for resolving dependencies. I´m not sure, if parent-poms
and poms in general are resolved the same way. So maybe this explains the
problems described in the other mails.
Gunther
I think there's a basic misunderstanding here... As far as I know it,
Maven *always* checks Central first. Even if you define another repo
somewhere else.
One way people prevent this is by setting up Maven proxy and then
setting that proxy as a mirror of Central in their settings.xml file.
Then instead of Central, it checks your proxy for the files, and if
your proxy doesn't have it, it goes out to Central on its own and
retrieves them, and then provides them to your Maven process.
Wayne
On 4/7/06, EJ Ciramella <[EMAIL PROTECTED]> wrote:
Yeah, something else is wrong then, I have apache running on another
machine and I have this:
<repositories>
<repository>
<id>lty-local</id>
<name>local-repository</name>
<url>http://build.corp.upromise.com/mavenrepository/</url>
</repository>
</repositories>
And I STILL see it pulling from:
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-javadoc-
plu gin/2.0-beta-3/maven-javadoc-plugin-2.0-beta-3.pom
1K downloaded
I'm able to view this directory from firefox on a different machine
(and I tried with out that trailing / and no luck).
How does this work folks? Nothing seems to work like the
documentation says it does (sorry, but this is getting really frustrating).
-----Original Message-----
From: dan tran [mailto:[EMAIL PROTECTED]
Sent: Friday, April 07, 2006 1:55 PM
To: Maven Users List
Subject: Re: Internal (intranet) repositories
sounds like a bug to me, since I also try to reproduce it and mvn -X
does not give any indication that it references the configured repo
before falling back to to the default ones
Perhaps, you can create a small test case and submit a jira.
-Dan
On 4/7/06, EJ Ciramella <[EMAIL PROTECTED]> wrote:
Yup - and I like the idea, but haven't gotten that far yet.
I'm still disappointed that the file:/// syntax doesn't work.
I _just_ finished installing apache 2 and will try with http://
syntax now.
When I'm satisfied with these developments, I'll move on to trying
out the proxy part of this.
-----Original Message-----
From: Rollo, Dan [mailto:[EMAIL PROTECTED]
Sent: Friday, April 07, 2006 1:29 PM
To: EJ Ciramella; Maven Users List
Subject: RE: Internal (intranet) repositories
Sorry if this have already been suggested and rejected, but: Have
you considered using the maven-proxy to cache the ibiblio repo stuff
on an internal machine?
Dan
-----Original Message-----
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, April 07, 2006 10:32 AM
To: Maven Users List
Subject: RE: Internal (intranet) repositories
Bummer about the potential for a bug. I know that the group working
on
maven 2 things have submitted a "repository" directory in the
perforce project (kinda exactly the opposite to what this feature in
maven is supposed to provide).
But theirs works, but it seems to have to be a local copy.
I'll try to bring up apache on that machine and see what happens. I
kind of don't want to do this to an already complicated build
environment though.
-----Original Message-----
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Friday, April 07, 2006 12:33 AM
To: Maven Users List
Subject: Re: Internal (intranet) repositories
Can you perhaps load that repository on a local Apache server and
modify
the <repository> to reflect the HTTP repo, and see if it still fails
to
attempt to access the local repo?
Might be a bug in how Maven deals with file:/// repos. I know most
of
us
on the list are using simple HTTP repos, so you might have just
stumbled
into a new bug.
Wayne
On 4/6/06, EJ Ciramella <[EMAIL PROTECTED]> wrote:
Here is my pom file. The directory in the url below is a shared
folder
on a different machine.
<project xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
<modelVersion>4.0.0</modelVersion>
<groupId>com.ejstools.tool1</groupId>
<artifactId>tool1</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>EJs Tools</name>
<url>http://build2.corp.upromise.com:8080</url>
<description>This project is simply here to lean about maven and
eventually will be used to build EJs Java tools.</description>
<repositories>
<repository>
<id>local</id>
<name>Upromise Maven Repository</name>
<url>file:///<servernamehere>/mavenrepository</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
</project>
-----Original Message-----
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 06, 2006 6:12 PM
To: Maven Users List
Subject: Re: Internal (intranet) repositories
Where exactly were you putting that repository section? In your
pom.xml? Or in another configuration file?
Wayne
On 4/6/06, EJ Ciramella <[EMAIL PROTECTED]> wrote:
None of this explains why it didn't use my repo and simply ignored
it
completely.
This is the more important part of the puzzle.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------
This e-mail and any files transmitted with it may contain privileged
or
confidential information.
It is solely for use by the individual for whom it is intended, even
if
addressed incorrectly.
If you received this e-mail in error, please notify the sender; do
not disclose, copy, distribute, or take any action in reliance on
the contents of this information;
and
delete it from
your system. Any other use of this e-mail is prohibited.
Thank you for your compliance.
--------------------------------------------------
--------------------------------------------------------------------
- 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------
This e-mail and any files transmitted with it may contain privileged or
confidential information.
It is solely for use by the individual for whom it is intended, even if
addressed incorrectly.
If you received this e-mail in error, please notify the sender; do not
disclose, copy, distribute,
or take any action in reliance on the contents of this information; and delete
it from
your system. Any other use of this e-mail is prohibited.
Thank you for your compliance.
--------------------------------------------------
---------------------------------------------------------------------
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]
