On 2007-09-14 19:10:51 +0200, Julia Antonova [EMAIL PROTECTED] said:
I will be out of the office starting 14-09-2007 and will not return until
18-09-2007.
I will respond to your message when I return.
Pls. forward all messages to [EMAIL PROTECTED]
Again. I wish I had as much time off as
On 2007-07-28 23:41:18 +0200, Jason Dillon [EMAIL PROTECTED] said:
On Jul 28, 2007, at 8:52 AM, Jason van Zyl wrote:
On 28 Jul 07, at 8:56 AM 28 Jul 07, Jason Dillon wrote:
Folks, I think this may have come up before, though I've not gone
digging in the jira or mailing list trenches for
On 2007-08-02 12:28:04 +0200, Jason Dillon [EMAIL PROTECTED] said:
On Aug 2, 2007, at 2:57 AM, Jochen Kuhnle wrote:
Couldn't it just be multiple parents, like
parents
parent
...
/parent
parent
...
/parent
/parents
This would
On 2007-07-12 15:47:31 +0200, David Holroyd [EMAIL PROTECTED] said:
Hi,
On Thu, Jul 12, 2007 at 12:08:53PM +0200, Jochen Kuhnle wrote:
I tried out the antlr3 plugin and ran into a dependency problem:
antlr-3.0 depends on stringtemplate-3.0 which depends on antlr-2.7.x.
Since antlr-2 and -3
On 2007-07-10 13:04:50 +0200, Kenney Westerhof [EMAIL PROTECTED] said:
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.
Hi,
I tried out the antlr3 plugin and ran into a dependency problem:
antlr-3.0 depends on stringtemplate-3.0 which depends on antlr-2.7.x.
Since antlr-2 and -3 are fundamentally incompatible (API packages
renamed, grammar file format changed), this does not work.
I propose to change the
an additional annotation for the descriptor we
want to use as prototype.
Regards,
Jochen
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 classes, but not across
On 2007-07-03 19:30:33 +0200, Jochen Wiedmann
[EMAIL PROTECTED] said:
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
On 2007-07-04 03:01:00 +0200, Brett Porter [EMAIL PROTECTED] said:
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 :)
Ok, I'll hold back the other 295 proposals for a while
On 2007-07-04 09:04:10 +0200, Jochen Wiedmann
[EMAIL PROTECTED] said:
On 7/4/07, Jochen Kuhnle [EMAIL PROTECTED] wrote:
Can properties be used in this way in the pom.xml? Since the pom
language has no control structures like loops etc., it should be hard
to use lists. Could you give
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
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
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 = testCompile, phase
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 included
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
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,
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
sync
Hi,
I'd like to put another patch up for discussion. I have attached [1]
and [2] to the Jira issue. These patches provide (yet another :-)
extension to use JDK 1.5+ annotations for Mojos. The consist of the
annotations [1] and a new descriptor extractor [2] that uses QDOX 1.6.3.
The main
On 2007-06-25 17:07:37 +0200, Jason van Zyl [EMAIL PROTECTED] said:
On 25 Jun 07, at 3:41 AM 25 Jun 07, Jochen Kuhnle wrote:
Hi,
I'd like to put another patch up for discussion. I have attached [1]
and [2] to the Jira issue. These patches provide (yet another :-)
extension to use JDK
.
There sure is work to do there...
Regards,
Jochen
Eric
On 6/25/07, Jochen Kuhnle [EMAIL PROTECTED] wrote:
Hi,
I'd like to put another patch up for discussion. I have attached [1]
and [2] to the Jira issue. These patches provide (yet another :-)
extension to use JDK 1.5+ annotations for Mojos
Hi,
how can this be done? In the parameter expression, I only have access
to the plugin descriptor, not the mojo descriptor that contains the
goal.
Regards,
Jochen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
in most cases
(though doesn't sound suitable here). You might also be able to use
the plugin context to share the values instead of an extension (though
not if you are introducing new types, so probably not the case here
also).
- Brett
On 23/04/2007, at 3:43 PM, Jochen Kuhnle wrote:
Hi
On 2007-04-24 15:25:48 +0200, Jason van Zyl [EMAIL PROTECTED] said:
On 24 Apr 07, at 5:48 AM 24 Apr 07, Jochen Kuhnle wrote:
Ok, did some further investigation: What I have is an extension
containing a class (C). This class is referenced in the fields of two
different Mojos, the fields
Hi,
we use several plugins that need to share data. This as done by
creating an extension containing some container classes, and adding
an extension to the project's pom. These container classes are
instantiated in a plugin using Plexus. However, since 2.0.5, this
stopped working, because
a different
id. If you don't specify an execution, then it uses the default one and
will merge the config.
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jochen Kuhnle
Sent: Thursday, November 23, 2006 8:51 AM
To: dev@maven.apache.org
Subject: Merging list properties in plugin
Hi,
I am writing some plugins that have list properties, e.g.:
warnings
warningall/warning
warningspecial/warning
warningetc./warning
/warnings
I now want to have different configurations (through parents, profiles,
etc.), but when merging, Maven2 only keeps entries
Hi,
I need to resolve dependencies in a unit test to get to either the jar
(in a standalone build) or the classes directory (in a reactor build)
in order to set up the test environment. How can this be done? Is there
a way to get to the Reactor or MavenProject of the build?
Regards,
Jochen
Hi,
there is a problem with -X and logging, since loggers created early in
the startup phase will not be switched to debug mode. In [1], there is
a hack for the main logger, but this still leaves all the Plexus
components' loggers untouched.
I would like to propose (and create) a patch
The trunk version preserves the builder's name, but not its triggers
and arguments. Patch http://jira.codehaus.org/browse/MECLIPSE-139
mainly does something else, but also solves this problem (I hope
correctly ;-).
Regards,
Jochen
On 2006-08-23 02:35:39 +0200, Barrie Treloar [EMAIL
dependencies if
there is a need for it (and pass the local repository location to the
extractor API if needed also).
- Brett
On 28/07/2006 10:01 PM, Jochen Kuhnle wrote:
Hi,
I am currenty writing a MojoDescriptorExtractor that needs to resolve
dependencies on its own, since the plugin plugin
I'm working on a patch to bootstrap mini that requires a change to
ModelReader. The current design with all the if...else if... and depth
comparisons looks a bit monolithic. I would like to change this to a
modular handler/stack-based design, where each element has a separate
handler class.
Hi,
I am currenty writing a MojoDescriptorExtractor that needs to resolve
dependencies on its own, since the plugin plugin does not do this (no
@requiredDependencyResolution). For this, I need to get the path to the
local repository (through MavenSettings, MavenExecutionRequest, etc.)
The
Brett Porter wrote:
I'm not sure this is plugin configuration - it should determine it from
the format of the source file?
Should it just do two passes and merge them?
The problem is that QDOX cannot parse JDK 1.5 sources, e.g. it chokes on
MapK, V. IMO, the POM should specify that your
Hi,
since qdox has some problems with JDK 1.5 sources, is there a plugin
descriptor extractor for JDK1.5 sources with annotations?
If not, I'd go ahead and write one. Looks fairly straightforward to me,
except for the choice which extractor to use in a project, or in other
words, how to
Hi,
is there a component that can be used to launch application JARs
generated with maven, i.e. that allows me to run java -jar myapp.jar,
which automatically downloads all dependencies, adds them to the
classpath and runs the application?
Regards,
Jochen
35 matches
Mail list logo
