[
http://jira.codehaus.org/browse/MNG-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86701
]
Marilyn E. Sander commented on MNG-2684:
----------------------------------------
Problem not solved after all. The only way I can figure out to use the ant
copy task is to have two targets implementing each copy. In one target I would
specify the artifact:dependency for the local repository, using a property
obtained from the environment. In the other I would not specify that
dependency, and let the ant task look for the default repository. Of each
complementary pair of copy tasks , one must run if the property is defined,
while the other must run unless the property is defined.
The reason is that our developers may use settings.xml or just let the
repository default to their home directory. From inside an ant script, I can't
tell what they've done, and there is no way to ask Maven what it thinks the
local repository is. So, I have to query an environment variable to find out
if the default is being overriden. If not, then the copy statement doesn't
have to include the location of the repository. If the default is being
overridden, the overriding definition has to go in each copy task.
It would be so much better if Maven and the ant task could both use an
environment variable.
I've written a test case consisting of six files. One is a driver for the
other five. They're pretty small and ought to be easy to understand. I will
attach them.
> local repository can only be specified per user, not per build, which impacts
> scalability
> -----------------------------------------------------------------------------------------
>
> Key: MNG-2684
> URL: http://jira.codehaus.org/browse/MNG-2684
> Project: Maven 2
> Issue Type: Improvement
> Components: Ant tasks
> Affects Versions: 2.0.4
> Environment: Linux
> Reporter: Marilyn E. Sander
>
> Because the local repository can only be specified in the ~/.m2/settings.xml
> or ~/.m2/ant/settings.xml file, there can be only one local repository per
> user per executing build. Worst case, the repository is on a mounted
> filesystem and thus the user can run only one build at a time. Best case,
> the repository is on the local machine, and the user can run one build per
> machine. This does not scale to an installation with large-capacity build
> servers, where one user might run several builds of different products or
> releases simultaneously, with each build using its own local repository.
> This can be done with Maven alone, but not with Maven ant tasks.
> I would like a mechanism for the ant tasks to pick up the local repository
> from a property, an environment variable, or a file in the base directory for
> the build. Even $M2_HOME/conf/settings.xml would be acceptable, as we could
> jigger $M2_HOME so as to have a unique one for each build. Any mechanism
> would be suitable, as long as it would allow a unique local repostory for
> each build.
> Feel free to lower this from major to minor if you do not agree with the
> impact. For our shop it is a major inconvenience, and we are considering a
> major rewrite to our build in order to avoid the ant tasks. We really need
> to make good use of our build servers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
