What is the point of this? It doesn't seem to add much value from my POV.
-- Forwarded message --
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Apr 5, 2007 9:44 PM
Subject: [jira] Subscription: Design & Best Practices
To: dev@maven.apache.org
Issue Subscription
Filter: Desi
Issue Subscription
Filter: Design & Best Practices (37 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
htt
Yes, I've been burned by this before also. I even wrote an issue!
http://jira.codehaus.org/browse/MNG-1992
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dillon
Sent: Thursday, April 05, 2007 7:28 PM
To: Maven Developers List
Subject: Re: -Dmaven.repo.lo
On Apr 5, 2007, at 4:22 PM, Jason van Zyl wrote:
foo
bar
Too complicated.
Then `mvn` would have ${foo} == 'foo', but `mvn -Dfoo=blah` would
have ${foo} == 'blah'. And `mvn -Dbar=fuff` would behave as
properties in poms do now, keeping ${bar} == 'bar'.
This would be very help
On 5 Apr 07, at 6:53 PM 5 Apr 07, Jason Dillon wrote:
On Apr 5, 2007, at 3:23 PM, Jason van Zyl wrote:
Related to -Dfoo=bar stuff though, wouldn't it be better for the
cli to set those in some maven properties which could be attached
to the request and not use system properties at all?
I was trying to setup a profile to allow a custom stage repository to
be used, which its url is specified with the stage.repositoryUrl
property. But this doesn't seem to work at all :-(
This is the profile I created:
8<-
stage-repository
stage.reposit
On Apr 5, 2007, at 3:23 PM, Jason van Zyl wrote:
Related to -Dfoo=bar stuff though, wouldn't it be better for the
cli to set those in some maven properties which could be attached
to the request and not use system properties at all?
That's what I've changed it to do in 2.1. There are prope
On 5 Apr 07, at 5:29 PM 5 Apr 07, Jason Dillon wrote:
On Apr 5, 2007, at 2:21 PM, Jason van Zyl wrote:
On 5 Apr 07, at 4:29 PM 5 Apr 07, Jason Dillon wrote:
A while ago I heard that the -Dmaven.repo.local property was
deprecated and was going to be removed in the future.
The system prop
On Apr 5, 2007, at 2:21 PM, Jason van Zyl wrote:
On 5 Apr 07, at 4:29 PM 5 Apr 07, Jason Dillon wrote:
A while ago I heard that the -Dmaven.repo.local property was
deprecated and was going to be removed in the future.
The system property will not be used, but an option will be
available
Binding: +6(Brian, John, Dennis, Brett, Jason, Emmanuel)
Non-Binding: + 3(Andy,John T, Maria)
I will make the changes and stage the main site before pushing it out.
What are we doing with the links that are present on plugins but not on
the main site? It seems to me that they should be the same i
On 5 Apr 07, at 4:29 PM 5 Apr 07, Jason Dillon wrote:
A while ago I heard that the -Dmaven.repo.local property was
deprecated and was going to be removed in the future.
The system property will not be used, but an option will be available
and is already support in the MavenExecutionReque
A while ago I heard that the -Dmaven.repo.local property was
deprecated and was going to be removed in the future.
This flag is super handy and I think that it should stay... and more
so I think that it is so useful that it should be promoted to a flag
on mvn, like -R, --repository.
I use
Daniel Kulp wrote:
>
> Jörg,
>
> With maven 2.0.5, did you try running:
>
> mvn dependency:analyze
>
> to see if it says there are potential problems with versions or similar?
> That was supposed to flag potential issues.
I'll try it in a week ;-)
- Jörg
---
On 5 Apr 07, at 2:11 PM 5 Apr 07, Jason Dillon wrote:
Was this ever done? I still see links to 2.0.4 versions of the tasks
on the download page.
If you didn't see an announcement it's not done.
--jason
On 4/3/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Ok, I'll release these tonight an
On 5 Apr 07, at 12:56 PM 5 Apr 07, Carlos Sanchez wrote:
On 4/5/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 5 Apr 07, at 12:26 PM 5 Apr 07, Carlos Sanchez wrote:
> I need it the same way the cli would do it, for version ranges,
> snapshots,... I need the metadatasource
>
You still haven
Was this ever done? I still see links to 2.0.4 versions of the tasks
on the download page.
--jason
On 4/3/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Ok, I'll release these tonight and document the stage copying utility.
Jason.
On 2 Apr 07, at 11:22 PM 2 Apr 07, John Tolentino wrote:
> +1
On 4/5/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 5 Apr 07, at 12:26 PM 5 Apr 07, Carlos Sanchez wrote:
> I need it the same way the cli would do it, for version ranges,
> snapshots,... I need the metadatasource
>
You still haven't answered the question as to the specific use case.
it's
Jörg,
With maven 2.0.5, did you try running:
mvn dependency:analyze
to see if it says there are potential problems with versions or similar?
That was supposed to flag potential issues.
Dan
On Thursday 05 April 2007 12:43, Jörg Schaible wrote:
> Piotr Tabor wrote:
> > Hello,
> >
> > It c
Piotr Tabor wrote:
> Hello,
>
> It can be connected with the bug:
> http://jira.codehaus.org/browse/MNG-2871 (it's old bug - since at least
> 2.0.4).
>
> I will try to repeat it/look at it today evening.
Don't know. If I go back to M205 it works perfectly. So something in M206
triggers this now
On 5 Apr 07, at 12:26 PM 5 Apr 07, Carlos Sanchez wrote:
I need it the same way the cli would do it, for version ranges,
snapshots,... I need the metadatasource
You still haven't answered the question as to the specific use case.
It is already abstracted in ArtifactMetadataSource interface
I need it the same way the cli would do it, for version ranges,
snapshots,... I need the metadatasource
It is already abstracted in ArtifactMetadataSource interface, so if
you want to add the index as another source right now you'd just need
to make a new implementation.
On 4/3/07, Jason van Zyl
Jörg Schaible wrote:
Hi folks,
after some hours testing M206 and looking for solutions, I am quite helpless
with our build that is broken if I run a multi-project build. Part of this
build is the creation of an ejb-client jar and another artifact that is
dependend on it. Unfortunately the dep
That is a failure in the packaging <-> file extension mapping facilities
in archiva/trunk
Other examples (from codein archiva branch):
typeToExtensionMap.put( "ejb-client", "jar" );
typeToExtensionMap.put( "ejb", "jar" );
typeToExtensionMap.put( "distribution-tgz", "tar.gz"
yeah, I'm sure I deployed with the wrong version of maven. :(
I'll fix and redeploy.
-john
On 4/5/07, Brett Porter <[EMAIL PROTECTED]> wrote:
I now get:
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-1:single':
Unable to fi
Groovy, JRuby and Jelly language extensions are in the Mojo project... for
consistency I'd say put the Jython plugin in Mojo as well. Just FYI, there
already exists a Jython factory in Plexus, and it would be optimal to use
that as your plugin's base (see the other language extensions for examples
Hello,
It can be connected with the bug:
http://jira.codehaus.org/browse/MNG-2871 (it's old bug - since at least
2.0.4).
I will try to repeat it/look at it today evening.
Piotr Tabor
Jörg Schaible napisał(a):
Hi Jason,
thank for your comment, where do I find the staged version? I'll try t
Hi Brian,
Thanks for the info. I am already an ASF committer (Cayenne project),
but other than the initial message sent to the committers list regarding
the sandbox, I couldn't find much more on it.
I take it I can can just add my contribution to
https://svn.apache.org/repos/asf/maven/sandbox/tr
Hi Jason,
thank for your comment, where do I find the staged version? I'll try to create
a minimal sample, but I'll leaver office now and will be offline next week, so
it will take some time ...
- Jörg
Jason van Zyl wrote on Thursday, April 05, 2007 3:27 PM:
> It's unfortunate you didn't try
I forgot to mention that if your plugin should be run by the command
line, maven by default only looks for org.apache.maven or
org.codehaus.mojo plugins without the user having to add some settings.
This can be a barrier to use as well (this is less troublesome if your
plugin is supposed to be run
Hi Kevin,
The sandbox was created to give existing Apache committers a place to
create plugins that may potentially be brought up to full released
plugins. The benefits to putting them here are that the infrastructure
with all the other plugins will be shared (Jira, Svn,Site etc) and it's
the first
It acts on the artifact of the project it is executed on. So you would
put this in org.codehaus.mojo.goovy.it.
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dillon
Sent: Wednesday, April 04, 2007 11:21 PM
To: Maven Developers List
Subject: Re: depe
It's unfortunate you didn't try this with one of the staged versions
that were available for over a week.
Make me a test project that displays the problem and I will track it
down.
Jason.
On 5 Apr 07, at 5:04 AM 5 Apr 07, Jörg Schaible wrote:
Hi folks,
after some hours testing M206 and
Awesome, nice work!
Jason.
On 4 Apr 07, at 10:40 PM 4 Apr 07, Jason Dillon wrote:
Hi folks, I've just finished up the first draft of support to use
Groovy for Maven plugin development, including Javadoc-based Mojo
descriptor extraction.
I have yet to update the site docs to cover the Mojo
I'm using archiva to proxy http://dist.codehaus.org (maven1-legacy
repository)
This repo contains xdoclet2 maven plugin :
http://dist.codehaus.org/xdoclet/maven-plugins/
Having configured archiva as a mirror, maven tries to download :
http://archiva:8080/repository/maven/xdoclet/maven2-xdoclet2-
Hi all,
I have an immature jython plugin I've been working on that has largely
been used internally. It looks like something that the sandbox could be
useful for, but I'm debating the merits of just hosting it myself. I
guess what would help me is understand what the sandbox provides. Is it
jus
Here are the results of this vote:
+1 Binding: Dennis Lundberg, Emmanuel Venisse, Jason val Zyl
+1 Non-binding: Fabrice Bellingard
I will proceed with the release. Should I use the repository-tools or
try the new maven-stage-plugin?
Dennis Lundberg wrote:
Hi,
I'd like to release jxr 2.1.
Hi folks,
after some hours testing M206 and looking for solutions, I am quite helpless
with our build that is broken if I run a multi-project build. Part of this
build is the creation of an ejb-client jar and another artifact that is
dependend on it. Unfortunately the dependent artifact cannot
+1
Fabrice.
On 3/31/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Hi,
I'd like to release jxr 2.1.
For this release the maven-jxr library and the maven-jxr-plugin has been
put together in svn, similar to what has been done with release and
surefire. They will be released simultaneously.
I
I now get:
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-1:single':
Unable to find the mojo 'org.apache.maven.plugins:maven-assembly-
plugin:2.2-beta-1:single' in the plugin
'org.apache.maven.plugins:maven-assembly-plugi
39 matches
Mail list logo
