>
> This might be helpful:
> http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook#MojoDeveloperCookbook-Creatingandresolvinganartifact
>
I think that's all deprecated now. Anybody know what the new way of
creating Artifacts and resolving them is?
>
> Benjamin
>
> --
On 18 February 2011 14:41, Benjamin Bentmann wrote:
> Johannes Ruscheinski wrote:
>
>> private void resolveDendencies(final Artifact artifact) {
>> getLog().info("+++ ProfilerMojo: attempting resolution
>> from " + localRepository.getUrl());
>> final String
Johannes Ruscheinski wrote:
private void resolveDendencies(final Artifact artifact) {
getLog().info("+++ ProfilerMojo: attempting resolution
from " + localRepository.getUrl());
final String localPath = localRepository.getUrl() +
"/" + localRepository.pa
Hi,
I am using the Maven 2 API to write a mojo. (Should I be using the
Maven 3 API?) My problem is that I am trying to retrieve the jar for
an artifact and I have a problem with finding a snapshot jar. I use
the following code:
private void resolveDendencies(final Artifact artifact) {
Why is this particular API of interest?
Trying to the container security inside G to grab plugins from a
remote repository?
On 21-Jul-08, at 2:39 PM, David Jencks wrote:
On Jul 18, 2008, at 12:28 PM, Jesse McConnell wrote:
djencks,
I am not sure what the client side of a jaspi api would
On Jul 18, 2008, at 12:28 PM, Jesse McConnell wrote:
djencks,
I am not sure what the client side of a jaspi api would look like, can
you give an example of what it would be doing?
The basic idea is that, in a client, you'd be calling a authentication
context before sending the message to s
Jesse,
From maven side - I know you've gone through that, but just to
reiterate: we have a server security configuration which by default
includes either name/password or a private key file with a password for it.
We can probably enhance that to include realm name, or can use server id
for t
djencks,
I am not sure what the client side of a jaspi api would look like, can
you give an example of what it would be doing?
from my perspective what we need to wire up in mercury right now is
some generic security api that something like maven can inject with
the goop in setting.xml meshed wit
On Jul 17, 2008, at 4:26 PM, Jesse McConnell wrote:
hey all,
I have been working on the jetty-client in the jetty project over in
codehaus which is the library mercury uses that is doing the
asynchronous retrieval and deployment of artifacts. Greg Wilkins and
I have recently been increasing t
On 18/07/2008, at 10:11 AM, Jason van Zyl wrote:
I'll sync up with Oleg and takes the notes out of SVN and put them
in a proposal. At this point Greg, Jan, Jesse, myself, Oleg and soon
Shane will have their fingers in the pie. This is a pretty
significant effort and should be documented. I
I'll sync up with Oleg and takes the notes out of SVN and put them in
a proposal. At this point Greg, Jan, Jesse, myself, Oleg and soon
Shane will have their fingers in the pie. This is a pretty significant
effort and should be documented. It's mostly the processes and
algorithms that need
hey all,
I have been working on the jetty-client in the jetty project over in
codehaus which is the library mercury uses that is doing the
asynchronous retrieval and deployment of artifacts. Greg Wilkins and
I have recently been increasing the functionality of the jetty-client
and we are getting
12 matches
Mail list logo
