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 in
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
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
+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=truepid=11540fixfor=14381
Staging
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 do
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 can
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] wrote:
Hi,
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:
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
+1
Vincent
2008/9/25 Olivier Lamy [EMAIL PROTECTED]:
Hi,
We solved 21 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14489styleName=HtmlprojectId=11441Create=Create
Staging repo:
http://people.apache.org/~olamy/staging-repo/
Staging site:
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,
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,
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
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 during
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 Simplified
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
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
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:
plugin
groupIdorg.apache.maven.plugins/groupId
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
Hi Jason,
Author: jvanzyl
Date: Sun Sep 28 18:41:51 2008
New Revision: 699955
URL: http://svn.apache.org/viewvc?rev=699955view=rev
Log:
o sample doco for the service resource transformer
Modified:
maven/plugins/trunk/maven-shade-plugin/pom.xml
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.
Go 4 it
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 written in the
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=699955view=rev
Log:
o sample doco for
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.
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 other
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
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
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.
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
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:
Oleg
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
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
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
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 Simplified
Docbook only and in Simplified DocBook the root element is always article.
Correct me if I'm wrong...
Cheers,
-Lukas
[EMAIL PROTECTED] wrote:
Hi,
I'm newbie in Maven. I'd like to checkout svn source. When I tried bellow
command line
svn co svn://my_svn_Ip/Development/execute-workflow
my source code checked out successful.
But I fail when tried mvn scm:checkout. Bellow is my pom.xml file:
project
...
build
plugins
plugin
35 matches
Mail list logo
