On 2007-07-04 03:02:29 +0200, Brett Porter <[EMAIL PROTECTED]> said:
On 04/07/2007, at 5:21 AM, Eric Redmond wrote:
Post-compilation annotation extraction actually handles this case.
http://jira.codehaus.org/browse/MNG-2521
MNG-2521 takes care of it partially. Since at runtime, missing
ann
Same here.
+1 to Javadoc
-1 to download sources
Cheers,
Rahul
- Original Message -
From: "Brett Porter" <[EMAIL PROTECTED]>
To: "Maven Developers List"
Sent: Wednesday, July 04, 2007 1:50 AM
Subject: Re: [VOTE] Configure IDE plugins to download sources by default
within Maven proj
On 04/07/07, Brett Porter <[EMAIL PROTECTED]> wrote:
On 04/07/2007, at 4:16 PM, Arnaud HERITIER wrote:
> Why don't we have a real release process for shared components (I
> didn't see a vote, an explanation about changes in this release, why
> it's an alpha ?, ...)
It's a weird thing about the
On 04/07/2007, at 4:16 PM, Arnaud HERITIER wrote:
Why don't we have a real release process for shared components (I
didn't see a vote, an explanation about changes in this release, why
it's an alpha ?, ...)
It's a weird thing about the way we do releases, but we prepare it
first, then vote
Why don't we have a real release process for shared components (I
didn't see a vote, an explanation about changes in this release, why
it's an alpha ?, ...)
Is there a Jira project for all of them ?
Arnaud
On 04/07/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: brianf
Date: Tue Jul 3
please refer your question to [EMAIL PROTECTED]
On 04/07/2007, at 2:16 AM, bhaskar wrote:
where to place the properties defined in project.properties and
build.properties of maven1,in maven2
-
To unsubscribe, e-mail: [EMAIL
where to place the properties defined in project.properties and
build.properties of maven1,in maven2
I merged all the real documents into the first page (1) and then
deprecated the old one (2) by removing it from home and adding a
comment/link to (1). I also moved everything into a table format to make
it easier to digest.
I feel like we could break some categories down a little further but
only
On 04/07/2007, at 5:21 AM, Eric Redmond wrote:
Post-compilation annotation extraction actually handles this case.
http://jira.codehaus.org/browse/MNG-2521
That sounds much better than requiring additional annotations.
Eric
On 7/3/07, Jochen Kuhnle <[EMAIL PROTECTED] > wrote:
Hi,
here's
Definitely agree here, though I like to see them come to the list too
(preferably staggered, it's going to take a week to find time to read
and respond to all these :)
If there's no responses, that's fine - but it's a better medium for
discussion and we may be able to use that to improve th
Paul,
Yep, throwing an exception sounds reasonable. Can you file an issue
for this?
Thanks,
Brett
On 04/07/2007, at 12:14 AM, Paul Gier wrote:
Hi Everyone,
I noticed that two attached artifacts could end up with the same
name if they have the same classifier and type. Both of these
a
Hi all,
I'm going to work on merging the two existing Taxonomy pages into a
consistent view:
(1) http://docs.codehaus.org/display/MAVEN/Taxonomy
(2) http://docs.codehaus.org/display/MAVEN/Maven+Taxonomy
Any input is welcome, or you can wait until I think I'm done and then
yell at me ;-) I ca
On 3 Jul 07, at 12:21 PM 3 Jul 07, Arnaud HERITIER wrote:
Hi,
(Sorry for the delay)
I agree with the dev process which will clarify our changes in the
code base and give a better visibility for our community. The new Home
page is very pleasant but we'll have to not forget to update it (as
long
Hi,
(Sorry for the delay)
I agree with the dev process which will clarify our changes in the
code base and give a better visibility for our community. The new Home
page is very pleasant but we'll have to not forget to update it (as
long as we don't have something more integrated which could take
Post-compilation annotation extraction actually handles this case.
http://jira.codehaus.org/browse/MNG-2521
Eric
On 7/3/07, Jochen Kuhnle <[EMAIL PROTECTED] > wrote:
Hi,
here's the second one:
With the current Mojo descriptor extractor, it is possible to inherit
Mojo annotations from parent
On 2007-07-03 19:08:00 +0200, Jason van Zyl <[EMAIL PROTECTED]> said:
Hi,
I see that many users are making proposals, and as I've stated before
they will get lost on the mailing lists. Especially if you have a wave
of inspiration and create several proposals. Schedules generally don't
syn
Some plugins can benefit a lot from parallel execution (e.g. native
compilers, javadoc scanners, report generators, etc.). To not have all
plugins do their own task management, a task execution framework is
suggested.
Plugins can build a task tree out of ParallelTaskGroups,
SequentialTaskGrou
currently, Maven does not require declaration of properties used in
the pom, you just use them anywhere you like.
Don't like the proposal. It is suitable for 90% of all cases, but
doesn't match the cases where you don't know the possible property set
in advance. (For example, if you use somethin
Hi,
I see that many users are making proposals, and as I've stated before
they will get lost on the mailing lists. Especially if you have a
wave of inspiration and create several proposals. Schedules generally
don't sync up and it's often days before developers can respond with
more then
On 2007-07-03 18:35:01 +0200, "Brian E. Fox" <[EMAIL PROTECTED]> said:
Is this a proposal on the wiki that is being summarized, or the whole =
Just first thoughts... I'm relatively new to this, so any help or
comments are welcome.
thing? If it's the whole thing, I have some questions:
1.
I don't know if this has been discussed before, so please forgive me if
this is the case.
Many applications of Maven require the use of artifact variants (i.e.
the same version of an artifact built in different ways). Examples are
the native Mojo discussion from [1], which require different va
+1 for both (non binding), but the unavailability of either shouldn't
spam consoles. Small concise warnings would be sufficient, if at all.
Christian.
On Jul 3, 2007, at 9:48 AM, Mark Hobson wrote:
Following the recent thread "Maven POM plugin config", this is a vote
to add downloadSources=
Is this a proposal on the wiki that is being summarized, or the whole thing? If
it's the whole thing, I have some questions:
1. Why a default value and a required flag? If it's required, when would the
default be used?
2. How is the option value activated? Is this implying that these are the only
+1
I think this is a good idea. The next release of the enforcer plugin
(http://maven.apache.org/plugins/maven-enforcer-plugin/) will have some
property verification features, but it would be nice to add the property
verification stuff directly to the pom.
Jochen Kuhnle wrote:
Hi,
current
Hi,
currently, Maven does not require declaration of properties used in the
pom, you just use them anywhere you like. Usually, if a property is
missing, bad things tend to happen because it is replaced with the
string "null". On a good day, resources from "translations-null-null"
aren't inclu
On 7/3/07, Cabasson Denis <[EMAIL PROTECTED]> wrote:
Can you be a little more specific about the behaviour of the IDEA plugin you
would want to port to the eclipse plugin?
It's the other way around. When you generate the project using the
eclise plugin it marks the dependencies that have not b
Can you be a little more specific about the behaviour of the IDEA plugin you
would want to port to the eclipse plugin?
Injection of properties (taken from IdeaModuleMojo) : linkModules should be
pretty straight forward
Injection of properties (taken from IdeaModuleMojo) : downloadSources,
downl
And make this consistent with the IDEA plugin as well.
On 7/3/07, Cabasson Denis <[EMAIL PROTECTED]> wrote:
About this link, why couldn't we have a consistent behaviour for javadoc and
sources jar?
Why not adding a downloadJavadoc property, which, when set to true, would
download and attach t
Jochen Wiedmann wrote:
On 7/3/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
Following the recent thread "Maven POM plugin config", this is a vote
to add downloadSources=true to both the eclipse and idea plugin
configurations in the maven-parent POM:
[ ] +1: I like Javadoc and easy debugging
[ ] +0
-1 (vote) in the way it's handled right now
When you have lots of dependencies, it takes way much time to generate
the project. I would go either into a FAQ explaining how to set this
up in the pluginsManagement section of a super pom.
Aligning the cache system from the eclipse plugin to the IDE
About this link, why couldn't we have a consistent behaviour for javadoc and
sources jar?
Why not adding a downloadJavadoc property, which, when set to true, would
download and attach the javadoc to the dependency.
I don't really see why javadoc should be a fallback if sources are not
availabl
On 7/3/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
ok, I modified fixed version on lot of issues.
Can you check if you're agree?
CONTINUUM-1226 please, this one is really show stopper.
Stéphane
Emmanuel
Brett Porter a écrit :
>
> On 03/07/2007, at 5:54 AM, Emmanuel Venisse wrote:
>
>>
On 03/07/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
-1, As I recently discovered, having this =true messes up the eclipse plugin
tests. I currently set it in my settings.xml because I always want this and
tripped over it. If we can find a way to set it that doesn't break the tests,
then I'm +
On 7/3/07, Fustrated <[EMAIL PROTECTED]> wrote:
Thanks Stephane, I will do the log later. At the moment I'm tight deadline,
I've reverted to version 2.0 and everything is working fine again. I can't
give you the log because it will probably against company rules. But when I
get the time I wil
Design.
1) Create DynamicGetServlet which parses
/get/${getId}/${getResource}
2) Create Maven1GetProvider which has an id "maven1", and serves
artifacts / poms to it.
3) Create Maven2GetProvider which has an id "maven2", and serves
artifacts / poms / metadata to it.
4) Test
5) Done.
Wendy Smoak wrote:
On 7/2/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
* Live documentation. (present in archiva.war)
Can you explain what you want to do here? Does it work off the
existing apt source and get bundled into the .war file, or something
else?
Live documentation.
Shipped in the
I would be +1 except that this will break the current tests in eclipse. We need
to solve that first, and then I'm good. (see my reply to the previous thread)
and http://jira.codehaus.org/browse/MECLIPSE-288
since this will break the eclipse tests, I have to say -1 until we can be sure
it won't
I think we should strive to release more binary options for archiva in
the next set of releases.
apache-archiva-${version}-bin.tar.gz
apache-archiva-${version}-bin.tar.bz2
apache-archiva-${version}-bin.zip
apache-archiva-${version}.war
As I write this I am left with the question ...
Should it b
The first is to force the eclipse plugin to add 1.4 compiler settings
to the project files, otherwise we get 1.5 raw type warnings
everywhere when running eclipse under 1.5.
+1
The second is to saving
typing to get source jars attached in eclipse.
-1, As I recently discovered, having this
Hi Everyone,
I noticed that two attached artifacts could end up with the same name if
they have the same classifier and type. Both of these artifacts can be
added to the list of attached artifacts, and when deploying the project,
both artifacts are deployed, but the second one overwrites the
On 03/07/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
-1 for both, although I like to have sources and javadocs attached to
Eclipse. (Non-binding)
Downloading sources (or javadocs) is an excellent thing, if the
sources (or the javadocs) are available. Unfortunately this isn't the
case in a rea
On 03/07/07, Brett Porter <[EMAIL PROTECTED]> wrote:
+1 to Javadoc
-1 to sources (just a vote, not a veto :)
In the eclipse plugin, the downloadSources flag controls them both:
http://maven.apache.org/plugins/maven-eclipse-plugin/faq.html#import-javadoc
Mark
-
On 7/3/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
Following the recent thread "Maven POM plugin config", this is a vote
to add downloadSources=true to both the eclipse and idea plugin
configurations in the maven-parent POM:
[ ] +1: I like Javadoc and easy debugging
[ ] +0: I'll go with the flow
+1
Mark Hobson wrote:
Following the recent thread "Maven POM plugin config", this is a vote
to add downloadSources=true to both the eclipse and idea plugin
configurations in the maven-parent POM:
[ ] +1: I like Javadoc and easy debugging
[ ] +0: I'll go with the flow
[ ] -1: I like superfluous
+1 to Javadoc
-1 to sources (just a vote, not a veto :)
On 03/07/2007, at 11:48 PM, Mark Hobson wrote:
Following the recent thread "Maven POM plugin config", this is a vote
to add downloadSources=true to both the eclipse and idea plugin
configurations in the maven-parent POM:
[ ] +1: I like J
Following the recent thread "Maven POM plugin config", this is a vote
to add downloadSources=true to both the eclipse and idea plugin
configurations in the maven-parent POM:
[ ] +1: I like Javadoc and easy debugging
[ ] +0: I'll go with the flow
[ ] -1: I like superfluous typing, guessing Javadoc
Thanks Stephane, I will do the log later. At the moment I'm tight deadline,
I've reverted to version 2.0 and everything is working fine again. I can't
give you the log because it will probably against company rules. But when I
get the time I will try and cut it down to a smaller pom which shows
On 03/07/07, Brett Porter <[EMAIL PROTECTED]> wrote:
I've no problem with it, just is usually something I only bring out
on "special occasions".
Maybe we should just do a quick poll on the list and go with that?
Sounds good to me, I'll start a vote.
On 03/07/07, Brett Porter <[EMAIL PROTECTED
On 03/07/2007, at 10:57 PM, Dennis Lundberg wrote:
Well, as the situation is now, you (we) often *have to* debug into
libraries. Mostly plexus stuff, since a lot of calls seems to end
up in some org.codehaus.plexus class.
I don't have all plexus code checked out an my machine, and I
sh
On 03/07/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
I've been meaning to add something similar for the IDEA plugin. So +1
from me to add this. The question is: in which pom do we put it?
I'd say components/pom.xml, since this is then specific to the Maven
project, as opposed to maven-parent
On 03/07/07, Brett Porter <[EMAIL PROTECTED]> wrote:
On 03/07/2007, at 10:42 PM, Mark Hobson wrote:
>
>maven-eclipse-plugin
>
> true
>
>
Would *everyone* want that? (having to debug into libraries isn't
really ideal :) It's quite time consuming to download. I wouldn't
person
Brett Porter wrote:
On 03/07/2007, at 10:42 PM, Mark Hobson wrote:
Hi there,
I'd like to add the following to the Maven POM plugin management block:
maven-compiler-plugin
1.4
1.4
Makes sense.
maven-eclipse-plugin
true
Would *everyone* want t
I've been meaning to add something similar for the IDEA plugin. So +1
from me to add this. The question is: in which pom do we put it?
Mark Hobson wrote:
Hi there,
I'd like to add the following to the Maven POM plugin management block:
maven-compiler-plugin
1.4
1.4
On 03/07/2007, at 10:42 PM, Mark Hobson wrote:
Hi there,
I'd like to add the following to the Maven POM plugin management
block:
maven-compiler-plugin
1.4
1.4
Makes sense.
maven-eclipse-plugin
true
Would *everyone* want that? (having to de
Hi there,
I'd like to add the following to the Maven POM plugin management block:
maven-compiler-plugin
1.4
1.4
maven-eclipse-plugin
true
The first is to force the eclipse plugin to add 1.4 compiler settings
to the project files, otherwise we get 1.5
On 03/07/07, Jochen Kuhnle <[EMAIL PROTECTED]> wrote:
I don't think multiple annotations of the same type are possible, i.e.
@Goal(...)
@Goal(...)
class MyMojo {
}
does not work. At least with Eclipse ;-)
Well I never, good point :) From JLS 9.7:
"It is a compile-time error if a declaration
On 2007-07-03 11:40:06 +0200, "Mark Hobson" <[EMAIL PROTECTED]> said:
On 03/07/07, Jochen Kuhnle <[EMAIL PROTECTED]> wrote:
Hi,
Example for a CompilerMojo
@Goals(
@Goal(goal = "compile", phase = "compile",
requiresDependencyResolution = "compile"),
@Goal(goal = "testCompi
Hi,
here's the second one:
With the current Mojo descriptor extractor, it is possible to inherit
Mojo annotations from parent classes, but not across projects. With
this, it is e.g. not possible to subclass a "built-in" Maven mojo and
inherit the annotations, or to refactor common Mojo code i
On 03/07/07, Jochen Kuhnle <[EMAIL PROTECTED]> wrote:
Hi,
Eric Redmond told me to write up the stuff I posted about MNG-2521 as a
proposal, so here's the first one:
Many Mojos (e.g. the compiler) execute in different phases of the build
lifecycle using different "configurations". With the curre
Hi,
Eric Redmond told me to write up the stuff I posted about MNG-2521 as a
proposal, so here's the first one:
Many Mojos (e.g. the compiler) execute in different phases of the build
lifecycle using different "configurations". With the current JavaDoc
and MNG-2521 annotations, a Mojo cannot
60 matches
Mail list logo
