Hi guys,
[SNIP]
I'll ask the maintainer of the plugin, if it is possible to
get an official release of it.
It's done.
You can download it (maven plugin:download -DartifactId=maven-ant-plugin
-DgroupId=maven -Dversion=1.9) and use it (maven ant).
From now, you can use external properties
Arnaud,
is there an up to date list of released plugins for maven 1.0.2? Maybe
a bundle with the latest of each released since the 1.0.2 release?
On Apr 10, 2005 7:58 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote:
Hi guys,
[SNIP]
I'll ask the maintainer of the plugin, if it is possible to
List
Objet : Re: [httpclient] Jars in the repository
Arnaud,
is there an up to date list of released plugins for maven
1.0.2? Maybe a bundle with the latest of each released since
the 1.0.2 release?
On Apr 10, 2005 7:58 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote:
Hi guys,
[SNIP
Ortwin Glück wrote:
Nobody needs Ant when there is Maven. Ant is legacy.
Lots of people, including me, disagree with this.
Lots of people, including me, find maven a pain to work with.
Ant support needs to be maintained
Its also the case that not all commons projects use maven for
everything. On
Martin Cooper wrote:
Let's suppose for a minute that all Commons components stored their
dependencies in SVN. And let's also suppose that they all required
Commons Logging. We would have almost 90 copies of Commons Logging
taking up space in the SVN repository. Even if only half of them use
Mark,
You are making some interesting points.
First, I hear that ibiblio is supposed to be *stable*. That is good to
hear (any guarantees about this, btw?). So this eliminates my reasoning
and I am happy to remove the deps from SVN.
Second, I understand that using Ant or Maven is a matter of
Ortwin Glück [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Mark,
You mentioned the maven ant goal. I had never tried it before and I just
gave it a spin. The result is not really usable though. The build.xml
starts off with all kind of properties that contain local path names and
Brent Worden wrote:
Ortwin Glück [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Mark,
You mentioned the maven ant goal. I had never tried it before and I
just gave it a spin. The result is not really usable though. The
build.xml starts off with all kind of properties that contain
James,
we keep those dependencies in the repository to make them easily
available. So users that want to check out and compile HttpClient don't
have to worry about getting them from somewhere. Yes, there is Maven.
That's fine as long as it works, but we do not like to be dependent on
the
James, could you point me to any ASF document that regulates storage of
dependencies in the repository, please?
There may or may not be such a document. I'm not really interested in
trying to be the binary police. I just noticed it while adding that
project into my latest Eclipse development
James Mitchell wrote:
There may or may not be such a document. I'm not really interested in
trying to be the binary police. I just noticed it while adding that
project into my latest Eclipse development environment.
Asking questions is not a crime, fortunately. Not even in any US state
so
On Tue, Apr 05, 2005 at 11:46:49AM -0400, James Mitchell wrote:
James, could you point me to any ASF document that regulates storage of
dependencies in the repository, please?
There may or may not be such a document. I'm not really interested in
trying to be the binary police. I just
Oleg Kalnichevski wrote:
If you would like me to setup the same download-dependencies for
httpclient, I'd be happy to help. The example above uses ibiblio, but you
can use any url.
We would very much appreciate it
Cheers,
Oleg
Is that *necessary* for GUMP or anything else, Oleg?
If not then
Odi,
I have not looked at the proposed solution, so I may be wrong here, but
I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an
external repository (such as ibiblio). If it is indeed the case I
personally see no problem with removing dependencies from SVN. I will
not insist,
Oleg Kalnichevski wrote:
Odi,
I have not looked at the proposed solution, so I may be wrong here, but
I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an
external repository (such as ibiblio). If it is indeed the case I
personally see no problem with removing dependencies from
On Tue, 2005-04-05 at 18:57 +0200, Ortwin Glück wrote:
Oleg Kalnichevski wrote:
Odi,
I have not looked at the proposed solution, so I may be wrong here, but
I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an
external repository (such as ibiblio). If it is indeed
Ortwin Glück wrote:
Oleg Kalnichevski wrote:
Odi,
I have not looked at the proposed solution, so I may be wrong here, but
I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an
external repository (such as ibiblio). If it is indeed the case I
personally see no problem with
On Apr 5, 2005 9:57 AM, Ortwin Glück [EMAIL PROTECTED] wrote:
Oleg Kalnichevski wrote:
Odi,
I have not looked at the proposed solution, so I may be wrong here, but
I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an
external repository (such as ibiblio). If it is
Martin Cooper wrote:
On Apr 5, 2005 9:57 AM, Ortwin Glück [EMAIL PROTECTED] wrote:
Oleg Kalnichevski wrote:
1. The libs are in the repo for a *reason*: availability and
convenience. If you remove them we loose this availability and
convenience. Replacing them with a stupid download script
Martin Cooper wrote:
On Apr 5, 2005 9:57 AM, Ortwin Glück [EMAIL PROTECTED] wrote:
Oleg Kalnichevski wrote:
1. The libs are in the repo for a *reason*: availability and
convenience. If you remove them we loose this availability and
convenience. Replacing them with a stupid download script
20 matches
Mail list logo
