+1
Arnaud
On Mon, Sep 29, 2008 at 4:05 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Some issues have been fixed in the shade plugin but I wanted to get them
> out.
>
> Issues Resolved (5):
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11540&fixfor=14381
>
> Sta
I'm not sure I understand. If I was to implement this I would imagine
that the deployer would want to call resourceExists() to find out
whether to deploy or not. The fact that resourceExists() can check the
metadata vs the actual file would seem to me to be an implementation
choice for the auth
more likely should be something that gets carried over with the
request. That however goes against the component architecture a bit as
it requires the context (request) to be carried along through all the
components. AFAIK workspace attempted to do just that, but I never
took a closer look.
weak r
weakreferences?
2008/9/29 Shane Isbell <[EMAIL PROTECTED]>
> When Jason tested the removal of the workspace, which handles caching of
> MavenProjects, it exposed a lot of bad behaviors within Maven, such
> multiple
> instances of ProjectBuilder, excessive numbers of calls to ProjectBuilder
> (54K
Hi,
Some issues have been fixed in the shade plugin but I wanted to get
them out.
Issues Resolved (5):
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11540&fixfor=14381
Staging Repository:
http://people.apache.org/~jvanzyl/shady-stage
Staging Site:
http://maven.apache.or
Let me clarify what spawned this thread: I am running ITs against
2.2.0-M1 branch with mercury wagon in it, and found an IT that fails,
unless wagon implements optional resourceExists().
I argue here that absence of an optional method should not make an IT
fail - this is all !
As a side effe
When Jason tested the removal of the workspace, which handles caching of
MavenProjects, it exposed a lot of bad behaviors within Maven, such multiple
instances of ProjectBuilder, excessive numbers of calls to ProjectBuilder
(54K in one build of trunk). We put back in some simple caching mechanisms
thank you for you guys warming help.it's because of you, the maven is be
coming more and more popular in the open source world.
2008/9/29 Brian E. Fox <[EMAIL PROTECTED]>
> Yep, it's just dependency injection magic, nothing in the plugin code will
> show you what happens...but the good news is yo
I was about to ask exactly the same question, Milos beat me to it.
Can you elaborate more please?
Thanks,
Brett
On 29/09/2008, at 8:12 AM, Jason van Zyl wrote:
We're just in the middle of ripping some stuff down and building it
back up. All with the end of making it embedder friendly.
On 2
Was anyone suggesting taking the method out, or just using an
alternative in an unrelated test case? It was only the latter I was in
favour of, it seemed to have little to do with
"ExecutionProjectWithRelativePathsTest".
- Brett
On 29/09/2008, at 6:58 AM, Brian E. Fox wrote:
That's implem
We're just in the middle of ripping some stuff down and building it
back up. All with the end of making it embedder friendly.
On 28-Sep-08, at 2:50 PM, Milos Kleint wrote:
Hello Shane,
How will the cache be cleared? Other than dumping and restarting the
container?
That would be a problem
Yep, it's just dependency injection magic, nothing in the plugin code will show
you what happens...but the good news is you don't care if you're using the tree
component. Just do the same as the dependency plugin.
-Original Message-
From: Simone Gianni [mailto:[EMAIL PROTECTED]
Sent: Su
That's implementation specific, we're talking about an interface here. I don't
see why we should take out this method. If someone wants to use it, fine. If
not, also fine.
-Original Message-
From: Oleg Gusakov [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 28, 2008 12:04 PM
To: Maven
Hello Shane,
How will the cache be cleared? Other than dumping and restarting the container?
That would be a problem for embedded project loading.
Milos
On Sun, Sep 28, 2008 at 6:52 AM, <[EMAIL PROTECTED]> wrote:
> Author: sisbell
> Date: Sat Sep 27 21:52:53 2008
> New Revision: 699773
>
> URL:
Hi 陈思淼 ,
I'm not sure about it (never tried to use that specific component), but
since it is a component of the underlying Plexus container, simply
"annotating" it with @component should trigger Plexus to inject the
current instance.
You could take a look at this :
http://plexus.codehaus.org/writi
Stephen - please see my reply to Ralph's question; same use case.
Stephen Connolly wrote:
what about preventing redeployment of non-snapshots?
Sent from my iPod
On 27 Sep 2008, at 23:57, Oleg Gusakov <[EMAIL PROTECTED]>
wrote:
I cannot imagine a use case where you would check that artifact
But this information comes from repository metadata, not from probing
the actual file. If it does - repository integrity is broken, isn't it?
Deploy should read the metadata anyway as it is supposed to update [in a
dumb http/dav repository, Nexus can do it for us], so if version is not
in meta
Im trying to do my own dependence validator,I need to know how the
Maven dependency Tree Organized.I read the dependency:tree source code and I
don't know How This kind of code works,:
> /**
>
* The dependency tree builder to use.
>
*
>
* @component
>
* @required
>
* @re
what about preventing redeployment of non-snapshots?
Sent from my iPod
On 27 Sep 2008, at 23:57, Oleg Gusakov <[EMAIL PROTECTED]>
wrote:
I cannot imagine a use case where you would check that artifact
exists in the remote repository and then don't download it. Can you?
Brian E. Fox wrote
19 matches
Mail list logo
