Man, I did not want to talk about this any more .. but cannot help it,
as this is about a second half of the issue.
Ralph Goers wrote:
Perhaps. Except that resourceExists is still NOT an optional method.
If developer follows a stable dev. pattern, in this case: create a new
wagon provider by e
Perhaps. Except that resourceExists is still NOT an optional method. If
you change it so that it is you might as well just remove it entirely.
The whole point of the method is to use a less expensive method to check
if the resource exists. By allowing it to through an exception and force
the c
Brian Fox wrote:
Not all artifacts can be discovered via metadata so it's not safe to
assume you can always check there.
Classifiers? Same argument: GET vs. HEAD, followed by GET. I cannot
imagine a use case where one would check that -sources.jar exists in the
remote repo without downloading i
Not all artifacts can be discovered via metadata so it's not safe to
assume you can always check there.
Sent from my iPhone
On Sep 29, 2008, at 10:08 PM, Oleg Gusakov
<[EMAIL PROTECTED]> wrote:
I implemented this method to pass ITs, it's existence is off the
table.
Brian Fox wrote:
Ole
I implemented this method to pass ITs, it's existence is off the table.
Brian Fox wrote:
Oleg you are mixing the use of this method with the method being
inefficient. Executing head is not ineficient
Agree
so there's no reason to exclude it in the new wagon.
Don't agree - as there still is no
Oleg you are mixing the use of this method with the method being
inefficient. Executing head is not ineficient so there's no reason to
exclude it in the new wagon. Taking it away simply because someone
could be dumb doesn't sense, especially since we already have on valid
use case for it.
See below.
Oleg Gusakov wrote:
Think how resourceExists() could be implemented by http provider:
1. send HEAD and look for 404
2. send GET and look for 404
If resource does not exist, you get one network roundtrip in both.
Yes, but HEAD doesn't return the data so will be more efficient o
On Mon, Sep 29, 2008 at 1:47 PM, Stephen Connolly <
[EMAIL PROTECTED]> wrote:
> Can we not wrap them with unmodifyable wrappers?
It's easy to make the MavenProject/Model immutable, but it would break most
of Maven, which uses MavenProject as a value object, kicking it around and
taking whacks at
Can we not wrap them with unmodifyable wrappers?
2008/9/29 Shane Isbell <[EMAIL PROTECTED]>
> One of the problems with any sort of caching right now is that MavenProject
> and Model are mutable. Passing around the same reference of
> these ubiquitous objects, means that any component can modify o
One of the problems with any sort of caching right now is that MavenProject
and Model are mutable. Passing around the same reference of
these ubiquitous objects, means that any component can modify other
components, changing their behavior internally. This is a pretty serious
encapsulation issue. I
I asked Brian what he used and worked and just did the same.
Monkey see, monkey do.
On 29-Sep-08, at 1:10 PM, Benjamin Bentmann wrote:
Hi Jason,
Author: jvanzyl
Date: Sun Sep 28 18:41:51 2008
New Revision: 699955
URL: http://svn.apache.org/viewvc?rev=699955&view=rev
Log:
o sample doco for th
BTW I am not a docbook expert too :)
Vincent
2008/9/29 Vincent Siveton <[EMAIL PROTECTED]>:
> 2008/9/29 Hervé BOUTEMY <[EMAIL PROTECTED]>:
>> Hi Lukas,
>>
>> Thanks for pointing this out: I'm not a docbook expert neither, and did not
>> know this explanation of *Simple* Docbook.
>> This is not wr
2008/9/29 Hervé BOUTEMY <[EMAIL PROTECTED]>:
> Hi Lukas,
>
> Thanks for pointing this out: I'm not a docbook expert neither, and did not
> know this explanation of *Simple* Docbook.
> This is not written in the docbook Doxia module code (or I didn't find it ;) )
> neither.
> I'll update the doc.
G
Hi Jason,
Author: jvanzyl
Date: Sun Sep 28 18:41:51 2008
New Revision: 699955
URL: http://svn.apache.org/viewvc?rev=699955&view=rev
Log:
o sample doco for the service resource transformer
Modified:
maven/plugins/trunk/maven-shade-plugin/pom.xml
maven/plugins/trunk/maven-shade-plugin/s
Hi Lukas,
Thanks for pointing this out: I'm not a docbook expert neither, and did not
know this explanation of *Simple* Docbook.
This is not written in the docbook Doxia module code (or I didn't find it ;) )
neither.
I'll update the doc.
I got confused by 2 facts in the code:
- these elements a
The Maven team is pleased to announce the release of the Maven Invoker
Plugin, version 1.3.
http://maven.apache.org/plugins/maven-invoker-plugin/
You should specify the version in your project's plugin configuration:
org.apache.maven.plugins
maven-invoker-plugin
1.3
Release Notes - Maven 2.
Ralph Goers wrote:
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 implementatio
Hi folks,
I notified that APT sink escapes all characters (see
AptSink#escapeAPT()), so in this case, the APT sink provides only
UTF-8 writer.
Do we want to escaping characters in all sinks? In this case, UTF-8
will be the default encoding.
Cheers,
Vincent
Hi,
Lukas has right: we handle only Simplified DocBook. Hervé could you revert this?
Cheers,
Vincent
2008/9/29 Lukas Theussl <[EMAIL PROTECTED]>:
> Hi Herve,
>
> I haven't looked at the doxia modules for a while, and I am not a docbook
> expert but IIRC, the doxia docbook module is for Simplifi
Argh. (I will redeploy the site from the tag).
Anyway thanks to YOU for all fixes.
--
Olivier
2008/9/29 Benjamin Bentmann <[EMAIL PROTECTED]>:
> Olivier Lamy wrote:
>
>> I will move artifacts to central repo.
>
> Many thanks for pushing this release Olivier but it seems the site got
> messed up
Olivier Lamy wrote:
I will move artifacts to central repo.
Many thanks for pushing this release Olivier but it seems the site got
messed up during staging/deployment. The index.html says version 1.3 so
I assume the sync has happend by now. However, all the links in the left
navigation bar i
Look now! :-)
On 29-Sep-08, at 5:35 AM, Olivier Lamy wrote:
Hi,
When I look at the stage repo, I see 1.2-SNAPSHOT ?
http://people.apache.org/~jvanzyl/shady-stage/org/apache/maven/plugins/maven-shade-plugin/
--
Olivier
2008/9/29 Arnaud HERITIER <[EMAIL PROTECTED]>:
+1
Arnaud
On Mon, Sep 29
Hi,
The vote has passed with the following result :
3 +1 (binding) : aheritier, vsiveton, olamy.
I will move artifacts to central repo.
Thanks,
--
Olivier
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-ma
+1
Vincent
2008/9/25 Olivier Lamy <[EMAIL PROTECTED]>:
> Hi,
>
> We solved 21 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14489&styleName=Html&projectId=11441&Create=Create
>
> Staging repo:
> http://people.apache.org/~olamy/staging-repo/
>
> Staging site:
> http://maven.ap
The Travel Assistance Committee is taking in applications for those
wanting
to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New
Orleans.
The Travel Assistance Committee is looking for people who would like
to be
able to attend ApacheCon US 2008 who need some financial sup
ping.
Still 1 PMC vote missing.
Thanks,
--
Olivier
2008/9/26 Arnaud HERITIER <[EMAIL PROTECTED]>:
> +1
>
> Arnaud
>
> On Thu, Sep 25, 2008 at 10:14 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> We solved 21 issues:
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14489&
Hi,
When I look at the stage repo, I see 1.2-SNAPSHOT ?
http://people.apache.org/~jvanzyl/shady-stage/org/apache/maven/plugins/maven-shade-plugin/
--
Olivier
2008/9/29 Arnaud HERITIER <[EMAIL PROTECTED]>:
> +1
>
> Arnaud
>
> On Mon, Sep 29, 2008 at 4:05 AM, Jason van Zyl <[EMAIL PROTECTED]> wrot
Have you read the documentation on developing plugins? See [1]:
[quote]
The portion before the annotations is the description of the
parameter. The "parameter" annotation identifies the variable as a
mojo parameter. The "expression" parameter defines the default value
for the variable. This value c
2008/9/29 Milos Kleint <[EMAIL PROTECTED]>
> 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 d
29 matches
Mail list logo
