This seems to make sense (though the concurrency issues are
concerning, especially considering difficulty to test)
- Brett
On 31/08/2007, at 2:56 AM, Joakim Erdfelt wrote:
In the past 2 weeks I've made tremendous progress on the Metadata
issues within Archiva.
So far in trunk, the
Without sql command:
1- with data-management: export the db
java -Xmx512m -jar data-management-cli-1.1-beta-2-app.jar -buildsJdbcUrl
jdbc:derby:path_continuum_old_db -mode EXPORT
2- start Continuum to create an empty db (with the good schema)
3- stop Continuum
4- import datas with
+1
Wendy, can you file an issue?
Olivier, do you want to work on it?
Emmanuel
Wendy Smoak a écrit :
I think the form for adding a new Installation should be split up into
one form for environment variables, and another for the Ant/Maven/JDK
installations.
The current web UI is confusing, we
Hi,
Displaying the field (Environment Variable name bla bla ...) only when the
user choose the type environnemt variable in the list box ?
--
Olivier
-Message d'origine-
De : Wendy Smoak [mailto:[EMAIL PROTECTED]
Envoyé : mardi 4 septembre 2007 05:07
À : continuum-dev@maven.apache.org
Maybe like notifier screens, we can have a process an installation in two steps:
screen1: choose the installation type (tool or environment variable)
screen2(tool): version, path, parameters...
screen2(env var): name, value
Emmanuel
LAMY Olivier a écrit :
Hi,
Displaying the field
On 9/4/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
+1
Wendy, can you file an issue?
Olivier, do you want to work on it?
http://jira.codehaus.org/browse/CONTINUUM-1430
I'm not really a fan of the two-step process, but it's already being
used for notifiers so we might as well be consistent.
Hi,
Doxia is near to be released and I would like to promote doxia-book
and doxia-maven-plugin. They will be moved to doxia/doxia/trunk/
Please vote [+1,0,-1], vote is open for 72 hrs.
Thanks,
Vincent
Wendy Smoak wrote on Monday, September 03, 2007 7:41 PM:
On 9/1/07, Brett Porter [EMAIL PROTECTED] wrote:
Like the other poll, I'd like to hear from as many people as possible
their opinion this topic (even if you just want to say '0' so we
know where you stand).
[ ] (A) Having a way to
Andrew Williams pisze:
E)
Specifying a a list of plugin versions in a pom snippet (better than
plugin packs) is (as I see it) adding maintenance overhead that could
become intrusive in some organisations.
Why can we not just have a plugin (that maven suggests running if it
seems missing
Brett Porter pisze:
[X] (A) All plugin versions must be specified by the project or its
parent hierarchy somewhere, at the cost of some verbosity (though we
should look at ways to make this easier/smaller/etc per the current
discussion)
[ ] (B) Retain the current behaviour, but make using
- invalid lifecycle phase (maybe same as bad CLI param, though you
were talking about embedder too)
- module specified is not found
- POM doesn't exist for a goal that requires one
- goal not found in a plugin (probably could list the ones that are)
- parent POM missing (in both the repository
Reading more responses, it seems like a lot of people want A so Maven
can help people with their builds. In the long-run (post 2.1), I
also like A, but we can't jump there overnight.
Today I prefer B, but I am OK with A if we do the following:
1. Have a tag in the pom, which is also available on
- calling a goal that does not need a POM in the current dir in a multi-project
root
Examples:
mvn install:install-file args
mvn archetype:create args
Maven walks down the complete project hierarchy ...
Brett Porter wrote on Tuesday, September 04, 2007 10:15 AM:
- invalid lifecycle phase
On 04/09/2007, at 11:52 AM, Brian E. Fox wrote:
I have a few problems I need to work through before the next enforcer
release.
First is that the enforce-once mojo declares @aggregator but still
executes for all children. (MENFORCER-12) Is this a bug in maven or
are
aggregators still
On 4 Sep 07, at 1:15 AM 4 Sep 07, Brett Porter wrote:
- invalid lifecycle phase (maybe same as bad CLI param, though you
were talking about embedder too)
Yup, this is caught with some validation code I added the other day
but it needs to filter up nicely. It doesn't currently.
- module
On 04/09/2007, at 6:24 PM, Jörg Schaible wrote:
- calling a goal that does not need a POM in the current dir in a
multi-project root
Examples:
mvn install:install-file args
mvn archetype:create args
Maven walks down the complete project hierarchy ...
But Maven can't tell the difference
Hi Jason,
I'll try to find some time this afternoon to have a go at merging my
branch into maven-artifact. It'd be good to get the code in before
the branch gets stale.
Cheers,
Mark
On 03/09/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Hi,
We need to collect all outstanding fixes done on the
On 4 Sep 07, at 1:52 AM 4 Sep 07, Mark Hobson wrote:
Hi Jason,
I'll try to find some time this afternoon to have a go at merging my
branch into maven-artifact. It'd be good to get the code in before
the branch gets stale.
Indeed, when I wake up I'll take a look. Tomorrow evening I'll try
Forgot to add my 2c :)
for the record - I'm in favour.
Two things I want to ensure happen, though:
- I'd like to see scope limited to just improving the API, packaging
and usage (as was proposed) - many of the comments touch on how to
change/improve/fix the resolution mechanism itself. That
Hi all
I am trying to deploy ejb using maven and websphere application server? Can
anybody please tell me which cargo plugin is required? I know there are
cargo jboss and weblogic plugins available but does anybody know whether
any Cargo Maven plugin is available for websphere?
Also when I run
After trying to chase down a problem with extensions it became very
clear to me that we have mixed concerns with extensions and it just
makes the core crappy.
The biggest offender are providers posing as extensions: wagon-webdav
is not an extension, it is a dependency required by the
Brett Porter wrote on Tuesday, September 04, 2007 10:31 AM:
On 04/09/2007, at 6:24 PM, Jörg Schaible wrote:
- calling a goal that does not need a POM in the current dir in a
multi-project root Examples:
mvn install:install-file args
mvn archetype:create args
Maven walks down the
On 04/09/2007, at 7:40 PM, Jörg Schaible wrote:
Brett Porter wrote on Tuesday, September 04, 2007 10:31 AM:
On 04/09/2007, at 6:24 PM, Jörg Schaible wrote:
- calling a goal that does not need a POM in the current dir in a
multi-project root Examples:
mvn install:install-file args
mvn
Hi,
Hemant Ved schrieb:
Hi all
I am trying to deploy ejb using maven and websphere application server? Can
anybody please tell me which cargo plugin is required? I know there are
cargo jboss and weblogic plugins available but does anybody know whether
any Cargo Maven plugin is available for
Hi
I am using Maven2 in my project to build the target.
I am trying to use ant task in my pom.xml using the maven-antrun-plugin
plugin
Following is the snippet of my pom.xml
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
- Classloader problems: often difficult to debug them when artifacts are coming from different
transitive sources. Would be great to have a better way to display a trace of the dependency
tree, without being swamped by all the non-dependency noise. Maybe a new debug flag (different
from -X
Hi
Which version of WebSphere is this?
Hermod
-Original Message-
From: Hemant Ved [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 04, 2007 11:07 AM
To: dev@maven.apache.org
Cc: [EMAIL PROTECTED]
Subject: Problem with ejb deployment
Hi all
I am trying to deploy ejb using maven and
I always want to remove System.out.println! Thanks Dennis for this.
Cheers,
Vincent
2007/9/2, Dennis Lundberg [EMAIL PROTECTED]:
Thanks Jason!
Jason van Zyl wrote:
Patched and released.
You just need to wait for the sync.
On 2 Sep 07, at 5:18 AM 2 Sep 07, Dennis Lundberg wrote:
On 04/09/2007, at 7:34 PM, Jason van Zyl wrote:
After trying to chase down a problem with extensions it became very
clear to me that we have mixed concerns with extensions and it just
makes the core crappy.
The biggest offender are providers posing as extensions: wagon-
webdav is not an
was6.0
On 9/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi
Which version of WebSphere is this?
Hermod
-Original Message-
From: Hemant Ved [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 04, 2007 11:07 AM
To: dev@maven.apache.org
Cc: [EMAIL PROTECTED]
Subject: Problem
On Sep 4, 2007, at 5:34 AM, Jason van Zyl wrote:
The biggest offender are providers posing as extensions: wagon-
webdav is not an extension, it is a dependency required by the
deploy plugin. In the exact same way you would specify an SCM
provider as dependency of the release plugin if you
+1, sounds like a great idea.
-john
On Sep 4, 2007, at 8:53 AM, Vincent Siveton wrote:
Hi,
Doxia is near to be released and I would like to promote doxia-book
and doxia-maven-plugin. They will be moved to doxia/doxia/trunk/
Please vote [+1,0,-1], vote is open for 72 hrs.
Thanks,
Vincent
+1
-Original Message-
SNIP
For 2.1 I would like to use providers stated as dependencies which
they are (easy to do in corporate builds), and the rest are core
components. John has been working on some active collections, and I
think they can be finished so that we could clarify how
On Sep 4, 2007, at 5:03 AM, Brett Porter wrote:
- I would like to see changes done entirely within the artifact
trunk in a self-contained way, and Maven updated as it stabilises -
not a constant chasing of snapshots (or even alphas), especially
with the troubles we've seen with the
On Sep 1, 2007, at 10:53 PM, Brett Porter wrote:
[ X] (A) Having a way to include a set of plugins in one small POM
fragment would be a useful feature to have (if you have a use case
other than the already stated standard plugins, please specify)
[ ] (B) Pasting a snippet in from the web
Don't forget that successive versions of some plugins may break
backward compatibility and other such bad practices. Locking everyone
in a large organization down to one version of such a plugin could be
very limiting, since these things have to be phased in.
Also, I don't think we can
+1
-j
On Sep 3, 2007, at 9:20 PM, Brian E. Fox wrote:
Now that we're getting close to a 2.1 alpha-1 release, it's time to
really look closely at what is going to be included in the final
release. In my opinion, it's been far too long between 2.0 and 2.1
(almost 2 years) and we need to get a
Hi,
Jason took care of 2.1-alpha-1, and Brian has kicked off a proposal
deadline, so that just leaves 2.1.x from the list I made earlier.
So I'll start spending some time tomorrow trying to pick the top ~100
highest priority / most addressable / related issues from 2.1.x to
keep, then
On 04/09/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Indeed, when I wake up I'll take a look. Tomorrow evening I'll try to
integrate it into the daily build I'm doing for 2.1.x and see how
that goes.
Okay, I've branched maven-artifact and 2.1.x for MNG-612 and merged in
the changes from the
Hey,
Blast from the past :) I had this flagged in my design issues folder
(Thanks, mailtags!) and noticed we don't have it in the proposals.
Full thread: http://mail-archives.apache.org/mod_mbox/maven-dev/
200608.mbox/[EMAIL PROTECTED]
Jason - is this another one to write up, or did this
+1
Stéphane
On 9/3/07, Brian E. Fox [EMAIL PROTECTED] wrote:
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for distribution and
should be moved to the maven project.
Please vote {+1,0,-1], vote is open for 72
What are the impacts of plugins with use extensions as a way to override
the default build lifecycle? ie ( pde-maven-plugin, native-maven-plugin )
-D
On 9/4/07, Brian E. Fox [EMAIL PROTECTED] wrote:
+1
-Original Message-
SNIP
For 2.1 I would like to use providers stated as
On 4 Sep 07, at 11:55 AM 4 Sep 07, Dan Tran wrote:
What are the impacts of plugins with use extensions as a way to
override
the default build lifecycle? ie ( pde-maven-plugin, native-maven-
plugin )
There's another use case and that should also be made more clear, but
ideally plugin
On 4 Sep 07, at 8:37 AM 4 Sep 07, Mark Hobson wrote:
On 04/09/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Indeed, when I wake up I'll take a look. Tomorrow evening I'll try to
integrate it into the daily build I'm doing for 2.1.x and see how
that goes.
Okay, I've branched maven-artifact and
On 4 Sep 07, at 8:32 AM 4 Sep 07, Brett Porter wrote:
Hi,
Jason took care of 2.1-alpha-1, and Brian has kicked off a proposal
deadline, so that just leaves 2.1.x from the list I made earlier.
So I'll start spending some time tomorrow trying to pick the top
~100 highest priority / most
On 4 Sep 07, at 9:15 AM 4 Sep 07, Brett Porter wrote:
Hey,
Blast from the past :) I had this flagged in my design issues
folder (Thanks, mailtags!) and noticed we don't have it in the
proposals.
Full thread: http://mail-archives.apache.org/mod_mbox/maven-dev/
200608.mbox/[EMAIL
On 4 Sep 07, at 2:03 AM 4 Sep 07, Brett Porter wrote:
Forgot to add my 2c :)
for the record - I'm in favour.
Two things I want to ensure happen, though:
- I'd like to see scope limited to just improving the API,
packaging and usage (as was proposed) - many of the comments touch
on how to
I'll email the user list.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 04, 2007 5:41 AM
To: Maven Developers List
Subject: Re: Gathering proposals for 2.1
On 3 Sep 07, at 6:30 PM 3 Sep 07, Brian E. Fox wrote:
I'm leaning that way as well.
On 05/09/2007, at 5:29 AM, Jason van Zyl wrote:
How are you going to decide priority before all the proposals are
in? And I would pick features to implement not a 100 arbitrary issues.
New features account for about 10-15%, and improvements about 25%
(I'm just guessing these from a pie
On 05/09/2007, at 5:30 AM, Jason van Zyl wrote:
On 4 Sep 07, at 9:15 AM 4 Sep 07, Brett Porter wrote:
Hey,
Blast from the past :) I had this flagged in my design issues
folder (Thanks, mailtags!) and noticed we don't have it in the
proposals.
Full thread:
You should not be sending these emails to Maven Dev list. This has
nothing to do with the development of Maven software.
Instead you should be sending these emails to the Maven Users list:
[EMAIL PROTECTED]
See more info: http://maven.apache.org/mail-lists.html
Wayne
On 9/4/07, Hemant Ved
As we are approaching an alpha release of 2.1, the Maven Team would like
to make a final call for proposals. The cutoff date for new proposals
will be Friday 9/21. During this time, we will review and discuss new
proposals and make a final cut at scheduling the 2.1 release. The
current aim is to
http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode
Make like build behavior mode
Maven currently has a top down build approach where you start at the top
of a reactor and build all children. One of the most common requests I
get from my developers is an easy way to build certain
Mauro is an existing Apache Committer on the Excalibur project
(http://excalibur.apache.org/team-list.html) as well as the mojo project
at Codehaus. He has recently been working on the shade plugin currently
up for vote to be moved to Apache. As he has demonstrated ability and we
can use the help
+1
On 05/09/2007, at 11:35 AM, Brian E. Fox wrote:
Mauro is an existing Apache Committer on the Excalibur project
(http://excalibur.apache.org/team-list.html) as well as the mojo
project
at Codehaus. He has recently been working on the shade plugin
currently
up for vote to be moved to
Component not found
Missing goal in plugin (probably the wrong version)
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Monday, September 03, 2007 7:58 PM
To: Maven Developers List
Subject: What can possibly go wrong with Maven
Hi,
I'm trying to collect
+1
Mauro is one of the most rigourous, dedicated and respectful
developers I know. We would definitely be a better team with Mauro here.
On 4 Sep 07, at 6:35 PM 4 Sep 07, Brian E. Fox wrote:
Mauro is an existing Apache Committer on the Excalibur project
+1
Arnaud
On 05/09/07, Jason van Zyl [EMAIL PROTECTED] wrote:
+1
Mauro is one of the most rigourous, dedicated and respectful
developers I know. We would definitely be a better team with Mauro here.
On 4 Sep 07, at 6:35 PM 4 Sep 07, Brian E. Fox wrote:
Mauro is an existing Apache
Hi,
I would like to make a single module for plugin execution and this is
the first step. The motivator is being able to isolate a version of a
plugin apis runtime. These modules do not vary independently in
practice and they are not useful separately. I really would like
people to look
+1
--
Olivier
-Message d'origine-
De : Brian E. Fox [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 5 septembre 2007 03:35
À : Maven Developers List
Objet : [vote] Mauro Talevi committer access
Mauro is an existing Apache Committer on the Excalibur project
60 matches
Mail list logo
