You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Dennis Lundberg <de...@mdh.se> on 2004/07/15 23:20:42 UTC
[maven ant plugin] Suggested improvement
Hi there
I've been trying out the maven ant plugin and compared the result with
my normal ant build.xml files. It does a good job. However I have found
something that could be improved.
Imagine that you are using your own repo for internal jar-files as well
as a public one by setting something like this in your project.properties:
maven.repo.remote=file://G:/dev/maven,http://www.ibiblio.org/maven
Using this setup and running
> maven ant
produces a build.xml that doesn't work. The reason for this seems to be
that the ant get task doesn't support the file: protocol. To make this
work, I have made some modifications to the generated build.xml file.
The modification is replacing the get tasks with copy tasks.
I browsed through the CVS for the maven ant plugin and discovered the
place to make the change in:
http://cvs.apache.org/viewcvs.cgi/maven-plugins/ant/src/plugin-resources/templates/build.jelly
Unfortunatelly I don't speak jelly, but I'll outline the general idea
here if someone feels that this is something worth adding. The following
java-jelly-pseudo-code would go in where the get-deps target is created.
---Start psedo code---
if(${repo}.startsWith("file://")) {
String filerepo = ${repo}.substring(7);
<j:forEach var="dep" items="${pom.dependencies}">
<!-- note: this is a valid use of artifactDirectory -->
<copy
file="${filerepo}/${dep.artifactDirectory}/${dep.type}s/${dep.artifact}"
tofile="$${libdir}/${dep.artifact}"
preservelastmodified="true"
failonerror="false"
/></j:forEach>
}
else {
// The stuff we do today, i.e. create a bunch of get tasks.
<j:forEach var="dep" items="${pom.dependencies}">
<!-- note: this is a valid use of artifactDirectory -->
<get
src="${repo}/${dep.artifactDirectory}/${dep.type}s/${dep.artifact}"
dest="$${libdir}/${dep.artifact}"
usetimestamp="true"
ignoreerrors="true"
/></j:forEach>
}
---End psedo code---
What do you think?
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [maven ant plugin] Suggested improvement
Posted by Carlos Sanchez <ap...@carlos.cousas.net>.
Hi,
Read http://maven.apache.org/reference/user-guide.html#Using_Proxies
Regards
Carlos Sanchez
A Coruña, Spain
Oness Project
http://oness.sourceforge.net
> -----Original Message-----
> From: Dennis Lundberg [mailto:dennis.lundberg@mdh.se]
> Sent: Sunday, July 18, 2004 12:00 PM
> To: Maven Users List
> Subject: Re: [maven ant plugin] Suggested improvement
>
> Thanks Arnaud
>
> So instead of having a shared directory on a file-server I
> would share a directory on a webserver. That way the
> developers can easily upload new release via the shared
> directory and Maven can easily download releases of company
> products from the webserver. Right?
>
> I assume that the webserver can run https instead of http.
> For added security we could also limit the access of the
> maven directory at our webserver so that only our developers
> can access it.
>
> Does anybody know if Maven understands basic authentication?
> I would rather have username/password access than restrict
> access by dns-name/ip-number.
>
> --
> Dennis Lundberg
>
> Arnaud Heritier wrote:
> > A solution is to create a private repository for your company.
> >
> > To do this you only need to have a web server where you
> publish your company's repository.
> > You can also use maven-proxy
> (http://maven-proxy.codehaus.org/) to cache data from ibiblio.
> >
> > Arnaud.
> >
> >
> >>-----Message d'origine-----
> >>De : Dennis Lundberg [mailto:dennis.lundberg@mdh.se] Envoyé
> : samedi
> >>17 juillet 2004 19:35 À : Maven Users List Objet : Re: [maven ant
> >>plugin] Suggested improvement
> >>
> >>The short answer is - because it works :-)
> >>
> >>But, seriously, what I want is somewhere to put my
> company's internal
> >>jar-files, i.e. framework stuff that other company products
> depend upon.
> >>These files should be shared between the developers inside
> the company.
> >>The products also depend upon publicly available jar-files like
> >>commons-logging and junit, which can be found at ibiblio.
> >>
> >>Correct me if I'm wrong here, since I'm pretty new to Maven. Isn't
> >>maven.local.repo the place in the user's home-directory where Maven
> >>stores downloaded jar-files for use now and later?
> >>
> >>Is there a better way to do this?
> >>
> >>--
> >>Dennis Lundberg
> >>
> >>Carlos Sanchez wrote:
> >>
> >>>Hi,
> >>>
> >>>The question is, why do you need your internal repoin a directory?
> >>>Why don't you use maven local repo?
> >>>
> >>>Regards
> >>>
> >>>Carlos Sanchez
> >>>A Coruña, Spain
> >>>
> >>>Oness Project
> >>>http://oness.sourceforge.net
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Dennis Lundberg [mailto:dennis.lundberg@mdh.se]
> >>>>Sent: Thursday, July 15, 2004 11:21 PM
> >>>>To: users@maven.apache.org
> >>>>Subject: [maven ant plugin] Suggested improvement
> >>>>
> >>>>Hi there
> >>>>
> >>>>I've been trying out the maven ant plugin and compared the result
> >>>>with my normal ant build.xml files. It does a good job. However I
> >>>>have found something that could be improved.
> >>>>
> >>>>Imagine that you are using your own repo for internal
> jar-files as
> >>>>well as a public one by setting something like this in your
> >>>>project.properties:
> >>>>maven.repo.remote=file://G:/dev/maven,http://www.ibiblio.org/maven
> >>>>
> >>>>Using this setup and running
> >>>>
> >>>>>maven ant
> >>>>
> >>>>produces a build.xml that doesn't work. The reason for
> this seems to
> >>>>be that the ant get task doesn't support the file:
> >>>>protocol. To make this work, I have made some
> modifications to the
> >>>>generated build.xml file.
> >>>>The modification is replacing the get tasks with copy tasks.
> >>>>
> >>>>I browsed through the CVS for the maven ant plugin and discovered
> >>>>the place to make the change in:
> >>>>http://cvs.apache.org/viewcvs.cgi/maven-plugins/ant/src/plugin
> >>>>-resources/templates/build.jelly
> >>>>Unfortunatelly I don't speak jelly, but I'll outline the general
> >>>>idea here if someone feels that this is something worth
> adding. The
> >>>>following java-jelly-pseudo-code would go in where the get-deps
> >>>>target is created.
> >>>>
> >>>>---Start psedo code---
> >>>>if(${repo}.startsWith("file://")) {
> >>>> String filerepo = ${repo}.substring(7);
> >>>> <j:forEach var="dep" items="${pom.dependencies}">
> >>>> <!-- note: this is a valid use of artifactDirectory -->
> >>>> <copy
> >>>>file="${filerepo}/${dep.artifactDirectory}/${dep.type}s/${dep.
> >>>
> >>>artifact}"
> >>>
> >>>
> >>>> tofile="$${libdir}/${dep.artifact}"
> >>>> preservelastmodified="true"
> >>>> failonerror="false"
> >>>> /></j:forEach>
> >>>>}
> >>>>else {
> >>>> // The stuff we do today, i.e. create a bunch of get tasks.
> >>>> <j:forEach var="dep" items="${pom.dependencies}">
> >>>> <!-- note: this is a valid use of artifactDirectory -->
> >>>> <get
> >>>>
> >>>>src="${repo}/${dep.artifactDirectory}/${dep.type}s/${dep.a
rtifact}"
> >>>> dest="$${libdir}/${dep.artifact}"
> >>>> usetimestamp="true"
> >>>> ignoreerrors="true"
> >>>> /></j:forEach>
> >>>>}
> >>>>---End psedo code---
> >>>>
> >>>>What do you think?
> >>>>
> >>>>--
> >>>>Dennis Lundberg
> >>>>
> >>>>
> >>>>----------------------------------------------------------
> ----------
> >>>>- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>-----------------------------------------------------------
> ----------
> >>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [maven ant plugin] Suggested improvement
Posted by Dennis Lundberg <de...@mdh.se>.
Thanks Arnaud
So instead of having a shared directory on a file-server I would share a
directory on a webserver. That way the developers can easily upload new
release via the shared directory and Maven can easily download releases
of company products from the webserver. Right?
I assume that the webserver can run https instead of http. For added
security we could also limit the access of the maven directory at our
webserver so that only our developers can access it.
Does anybody know if Maven understands basic authentication? I would
rather have username/password access than restrict access by
dns-name/ip-number.
--
Dennis Lundberg
Arnaud Heritier wrote:
> A solution is to create a private repository for your company.
>
> To do this you only need to have a web server where you publish your company's repository.
> You can also use maven-proxy (http://maven-proxy.codehaus.org/) to cache data from ibiblio.
>
> Arnaud.
>
>
>>-----Message d'origine-----
>>De : Dennis Lundberg [mailto:dennis.lundberg@mdh.se]
>>Envoyé : samedi 17 juillet 2004 19:35
>>À : Maven Users List
>>Objet : Re: [maven ant plugin] Suggested improvement
>>
>>The short answer is - because it works :-)
>>
>>But, seriously, what I want is somewhere to put my company's internal
>>jar-files, i.e. framework stuff that other company products depend upon.
>>These files should be shared between the developers inside the company.
>>The products also depend upon publicly available jar-files like
>>commons-logging and junit, which can be found at ibiblio.
>>
>>Correct me if I'm wrong here, since I'm pretty new to Maven. Isn't
>>maven.local.repo the place in the user's home-directory where Maven
>>stores downloaded jar-files for use now and later?
>>
>>Is there a better way to do this?
>>
>>--
>>Dennis Lundberg
>>
>>Carlos Sanchez wrote:
>>
>>>Hi,
>>>
>>>The question is, why do you need your internal repoin a directory? Why don't
>>>you use maven local repo?
>>>
>>>Regards
>>>
>>>Carlos Sanchez
>>>A Coruña, Spain
>>>
>>>Oness Project
>>>http://oness.sourceforge.net
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Dennis Lundberg [mailto:dennis.lundberg@mdh.se]
>>>>Sent: Thursday, July 15, 2004 11:21 PM
>>>>To: users@maven.apache.org
>>>>Subject: [maven ant plugin] Suggested improvement
>>>>
>>>>Hi there
>>>>
>>>>I've been trying out the maven ant plugin and compared the
>>>>result with my normal ant build.xml files. It does a good
>>>>job. However I have found something that could be improved.
>>>>
>>>>Imagine that you are using your own repo for internal
>>>>jar-files as well as a public one by setting something like
>>>>this in your project.properties:
>>>>maven.repo.remote=file://G:/dev/maven,http://www.ibiblio.org/maven
>>>>
>>>>Using this setup and running
>>>>
>>>>>maven ant
>>>>
>>>>produces a build.xml that doesn't work. The reason for this
>>>>seems to be that the ant get task doesn't support the file:
>>>>protocol. To make this work, I have made some modifications
>>>>to the generated build.xml file.
>>>>The modification is replacing the get tasks with copy tasks.
>>>>
>>>>I browsed through the CVS for the maven ant plugin and
>>>>discovered the place to make the change in:
>>>>http://cvs.apache.org/viewcvs.cgi/maven-plugins/ant/src/plugin
>>>>-resources/templates/build.jelly
>>>>Unfortunatelly I don't speak jelly, but I'll outline the
>>>>general idea here if someone feels that this is something
>>>>worth adding. The following java-jelly-pseudo-code would go
>>>>in where the get-deps target is created.
>>>>
>>>>---Start psedo code---
>>>>if(${repo}.startsWith("file://")) {
>>>> String filerepo = ${repo}.substring(7);
>>>> <j:forEach var="dep" items="${pom.dependencies}">
>>>> <!-- note: this is a valid use of artifactDirectory -->
>>>> <copy
>>>>file="${filerepo}/${dep.artifactDirectory}/${dep.type}s/${dep.
>>>
>>>artifact}"
>>>
>>>
>>>> tofile="$${libdir}/${dep.artifact}"
>>>> preservelastmodified="true"
>>>> failonerror="false"
>>>> /></j:forEach>
>>>>}
>>>>else {
>>>> // The stuff we do today, i.e. create a bunch of get tasks.
>>>> <j:forEach var="dep" items="${pom.dependencies}">
>>>> <!-- note: this is a valid use of artifactDirectory -->
>>>> <get
>>>>
>>>>src="${repo}/${dep.artifactDirectory}/${dep.type}s/${dep.artifact}"
>>>> dest="$${libdir}/${dep.artifact}"
>>>> usetimestamp="true"
>>>> ignoreerrors="true"
>>>> /></j:forEach>
>>>>}
>>>>---End psedo code---
>>>>
>>>>What do you think?
>>>>
>>>>--
>>>>Dennis Lundberg
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [maven ant plugin] Suggested improvement
Posted by Arnaud Heritier <ah...@apache.org>.
A solution is to create a private repository for your company.
To do this you only need to have a web server where you publish your company's repository.
You can also use maven-proxy (http://maven-proxy.codehaus.org/) to cache data from ibiblio.
Arnaud.
> -----Message d'origine-----
> De : Dennis Lundberg [mailto:dennis.lundberg@mdh.se]
> Envoyé : samedi 17 juillet 2004 19:35
> À : Maven Users List
> Objet : Re: [maven ant plugin] Suggested improvement
>
> The short answer is - because it works :-)
>
> But, seriously, what I want is somewhere to put my company's internal
> jar-files, i.e. framework stuff that other company products depend upon.
> These files should be shared between the developers inside the company.
> The products also depend upon publicly available jar-files like
> commons-logging and junit, which can be found at ibiblio.
>
> Correct me if I'm wrong here, since I'm pretty new to Maven. Isn't
> maven.local.repo the place in the user's home-directory where Maven
> stores downloaded jar-files for use now and later?
>
> Is there a better way to do this?
>
> --
> Dennis Lundberg
>
> Carlos Sanchez wrote:
> > Hi,
> >
> > The question is, why do you need your internal repoin a directory? Why don't
> > you use maven local repo?
> >
> > Regards
> >
> > Carlos Sanchez
> > A Coruña, Spain
> >
> > Oness Project
> > http://oness.sourceforge.net
> >
> >
> >
> >>-----Original Message-----
> >>From: Dennis Lundberg [mailto:dennis.lundberg@mdh.se]
> >>Sent: Thursday, July 15, 2004 11:21 PM
> >>To: users@maven.apache.org
> >>Subject: [maven ant plugin] Suggested improvement
> >>
> >>Hi there
> >>
> >>I've been trying out the maven ant plugin and compared the
> >>result with my normal ant build.xml files. It does a good
> >>job. However I have found something that could be improved.
> >>
> >>Imagine that you are using your own repo for internal
> >>jar-files as well as a public one by setting something like
> >>this in your project.properties:
> >>maven.repo.remote=file://G:/dev/maven,http://www.ibiblio.org/maven
> >>
> >>Using this setup and running
> >> > maven ant
> >>produces a build.xml that doesn't work. The reason for this
> >>seems to be that the ant get task doesn't support the file:
> >>protocol. To make this work, I have made some modifications
> >>to the generated build.xml file.
> >>The modification is replacing the get tasks with copy tasks.
> >>
> >>I browsed through the CVS for the maven ant plugin and
> >>discovered the place to make the change in:
> >>http://cvs.apache.org/viewcvs.cgi/maven-plugins/ant/src/plugin
> >>-resources/templates/build.jelly
> >>Unfortunatelly I don't speak jelly, but I'll outline the
> >>general idea here if someone feels that this is something
> >>worth adding. The following java-jelly-pseudo-code would go
> >>in where the get-deps target is created.
> >>
> >>---Start psedo code---
> >>if(${repo}.startsWith("file://")) {
> >> String filerepo = ${repo}.substring(7);
> >> <j:forEach var="dep" items="${pom.dependencies}">
> >> <!-- note: this is a valid use of artifactDirectory -->
> >> <copy
> >>file="${filerepo}/${dep.artifactDirectory}/${dep.type}s/${dep.
> >
> > artifact}"
> >
> >> tofile="$${libdir}/${dep.artifact}"
> >> preservelastmodified="true"
> >> failonerror="false"
> >> /></j:forEach>
> >>}
> >>else {
> >> // The stuff we do today, i.e. create a bunch of get tasks.
> >> <j:forEach var="dep" items="${pom.dependencies}">
> >> <!-- note: this is a valid use of artifactDirectory -->
> >> <get
> >>
> >>src="${repo}/${dep.artifactDirectory}/${dep.type}s/${dep.artifact}"
> >> dest="$${libdir}/${dep.artifact}"
> >> usetimestamp="true"
> >> ignoreerrors="true"
> >> /></j:forEach>
> >>}
> >>---End psedo code---
> >>
> >>What do you think?
> >>
> >>--
> >>Dennis Lundberg
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [maven ant plugin] Suggested improvement
Posted by Dennis Lundberg <de...@mdh.se>.
The short answer is - because it works :-)
But, seriously, what I want is somewhere to put my company's internal
jar-files, i.e. framework stuff that other company products depend upon.
These files should be shared between the developers inside the company.
The products also depend upon publicly available jar-files like
commons-logging and junit, which can be found at ibiblio.
Correct me if I'm wrong here, since I'm pretty new to Maven. Isn't
maven.local.repo the place in the user's home-directory where Maven
stores downloaded jar-files for use now and later?
Is there a better way to do this?
--
Dennis Lundberg
Carlos Sanchez wrote:
> Hi,
>
> The question is, why do you need your internal repoin a directory? Why don't
> you use maven local repo?
>
> Regards
>
> Carlos Sanchez
> A Coruña, Spain
>
> Oness Project
> http://oness.sourceforge.net
>
>
>
>>-----Original Message-----
>>From: Dennis Lundberg [mailto:dennis.lundberg@mdh.se]
>>Sent: Thursday, July 15, 2004 11:21 PM
>>To: users@maven.apache.org
>>Subject: [maven ant plugin] Suggested improvement
>>
>>Hi there
>>
>>I've been trying out the maven ant plugin and compared the
>>result with my normal ant build.xml files. It does a good
>>job. However I have found something that could be improved.
>>
>>Imagine that you are using your own repo for internal
>>jar-files as well as a public one by setting something like
>>this in your project.properties:
>>maven.repo.remote=file://G:/dev/maven,http://www.ibiblio.org/maven
>>
>>Using this setup and running
>> > maven ant
>>produces a build.xml that doesn't work. The reason for this
>>seems to be that the ant get task doesn't support the file:
>>protocol. To make this work, I have made some modifications
>>to the generated build.xml file.
>>The modification is replacing the get tasks with copy tasks.
>>
>>I browsed through the CVS for the maven ant plugin and
>>discovered the place to make the change in:
>>http://cvs.apache.org/viewcvs.cgi/maven-plugins/ant/src/plugin
>>-resources/templates/build.jelly
>>Unfortunatelly I don't speak jelly, but I'll outline the
>>general idea here if someone feels that this is something
>>worth adding. The following java-jelly-pseudo-code would go
>>in where the get-deps target is created.
>>
>>---Start psedo code---
>>if(${repo}.startsWith("file://")) {
>> String filerepo = ${repo}.substring(7);
>> <j:forEach var="dep" items="${pom.dependencies}">
>> <!-- note: this is a valid use of artifactDirectory -->
>> <copy
>>file="${filerepo}/${dep.artifactDirectory}/${dep.type}s/${dep.
>
> artifact}"
>
>> tofile="$${libdir}/${dep.artifact}"
>> preservelastmodified="true"
>> failonerror="false"
>> /></j:forEach>
>>}
>>else {
>> // The stuff we do today, i.e. create a bunch of get tasks.
>> <j:forEach var="dep" items="${pom.dependencies}">
>> <!-- note: this is a valid use of artifactDirectory -->
>> <get
>>
>>src="${repo}/${dep.artifactDirectory}/${dep.type}s/${dep.artifact}"
>> dest="$${libdir}/${dep.artifact}"
>> usetimestamp="true"
>> ignoreerrors="true"
>> /></j:forEach>
>>}
>>---End psedo code---
>>
>>What do you think?
>>
>>--
>>Dennis Lundberg
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [maven ant plugin] Suggested improvement
Posted by Carlos Sanchez <ap...@carlos.cousas.net>.
Hi,
The question is, why do you need your internal repoin a directory? Why don't
you use maven local repo?
Regards
Carlos Sanchez
A Coruña, Spain
Oness Project
http://oness.sourceforge.net
> -----Original Message-----
> From: Dennis Lundberg [mailto:dennis.lundberg@mdh.se]
> Sent: Thursday, July 15, 2004 11:21 PM
> To: users@maven.apache.org
> Subject: [maven ant plugin] Suggested improvement
>
> Hi there
>
> I've been trying out the maven ant plugin and compared the
> result with my normal ant build.xml files. It does a good
> job. However I have found something that could be improved.
>
> Imagine that you are using your own repo for internal
> jar-files as well as a public one by setting something like
> this in your project.properties:
> maven.repo.remote=file://G:/dev/maven,http://www.ibiblio.org/maven
>
> Using this setup and running
> > maven ant
> produces a build.xml that doesn't work. The reason for this
> seems to be that the ant get task doesn't support the file:
> protocol. To make this work, I have made some modifications
> to the generated build.xml file.
> The modification is replacing the get tasks with copy tasks.
>
> I browsed through the CVS for the maven ant plugin and
> discovered the place to make the change in:
> http://cvs.apache.org/viewcvs.cgi/maven-plugins/ant/src/plugin
> -resources/templates/build.jelly
> Unfortunatelly I don't speak jelly, but I'll outline the
> general idea here if someone feels that this is something
> worth adding. The following java-jelly-pseudo-code would go
> in where the get-deps target is created.
>
> ---Start psedo code---
> if(${repo}.startsWith("file://")) {
> String filerepo = ${repo}.substring(7);
> <j:forEach var="dep" items="${pom.dependencies}">
> <!-- note: this is a valid use of artifactDirectory -->
> <copy
> file="${filerepo}/${dep.artifactDirectory}/${dep.type}s/${dep.
artifact}"
> tofile="$${libdir}/${dep.artifact}"
> preservelastmodified="true"
> failonerror="false"
> /></j:forEach>
> }
> else {
> // The stuff we do today, i.e. create a bunch of get tasks.
> <j:forEach var="dep" items="${pom.dependencies}">
> <!-- note: this is a valid use of artifactDirectory -->
> <get
>
> src="${repo}/${dep.artifactDirectory}/${dep.type}s/${dep.artifact}"
> dest="$${libdir}/${dep.artifact}"
> usetimestamp="true"
> ignoreerrors="true"
> /></j:forEach>
> }
> ---End psedo code---
>
> What do you think?
>
> --
> Dennis Lundberg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org