-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
(please CC me on a response to this, or it might be another week before
I check back :)
Nicola earlier pointed me at this thread, and I thought I'd just
reassure you on a point...
How do artifacts get into the remote Maven respository
and how
On Wednesday 27 April 2005 04:23, David Crossley wrote:
How do artifacts get into the remote Maven respository
and how are they guaranteed to be the legitimate file?
AFAIK, this is a topic that Maven is considering to attend to in Wagon.
In my personal opinion, Wagon better than the Maven1
David Crossley wrote:
How do artifacts get into the remote Maven respository
and how are they guaranteed to be the legitimate file?
We don't necessarily have to use Maven's central repository, we can make
our own repository with only the jars that we need and use that. In this
way we would be
Nicola Ken Barozzi wrote:
...
We don't necessarily have to use Maven's central repository, we can make
our own repository with only the jars that we need and use that.
BTW, from an implementation POV IMHO it's better to start this way, as
it's more incremental and solves one problem at a time
-Original Message-
From: Leszek Gawron [mailto:[EMAIL PROTECTED]
Sent: Montag, 25. April 2005 20:54
To: dev@cocoon.apache.org
Subject: Re: [PROPOSAL] Download of jars with Maven ant tasks
quote All of the tasks can optionally take one or more remote
repositories to download
Would it be legally acceptable to link also to non-Apache licensed stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy us much.
...I still don't get why mocks are
a problem - this
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy us much.
...I still don't get why mocks are
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy us much.
...I still
Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and
handling mechanism would greatly help Cocoon, because it makes it easy
to share jars and to download only the ones needed.
Ivy was proposed as a possible solution, but I suggested instead to
use the
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy us much.
Reinhard Poetz wrote:
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
Ralph Goers wrote:
snip/
Please see (if you haven't already)
http://www.gnu.org/licenses/lgpl-java.html.
There's a problem with from the reverse-engineering clause: it requires
the Apache code to be reverse-engineerable in all circumstances, which
goes against the ASL, as it allows any kind
Ralph Goers wrote:
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is -
How do artifacts get into the remote Maven respository
and how are they guaranteed to be the legitimate file?
Surely this concern has been discussed before,
but i cannot find the answer.
The Maven web pages just say something like:
create a Jira issue and tell us what you want to add.
That
Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and
handling mechanism would greatly help Cocoon, because it makes it easy
to share jars and to download only the ones needed.
Ivy was proposed as a possible solution, but I suggested instead to use
the
Daniel Fagerstrom wrote:
Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and
handling mechanism would greatly help Cocoon, because it makes it easy
to share jars and to download only the ones needed.
Ivy was proposed as a possible solution, but I suggested
Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and
handling mechanism would greatly help Cocoon, because it makes it easy
to share jars and to download only the ones needed.
Ivy was proposed as a possible solution, but I suggested instead to use
the
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and
handling mechanism would greatly help Cocoon, because it makes it
easy to share jars and to download only the ones needed.
Ivy was proposed as a possible
19 matches
Mail list logo
