The list of phases is defined in maven... you cannot define your own phases
without building your own custom maven. (Notice the full stop is after
maven... I'm not talking about your own maven plugin, or any of that i'm
talking about forking maven and building your own fork... with all the
Stephen Connolly-2 wrote:
If you want to bind your plugin to pre-existing phases, then you must
either
create your own packaging type (will will require you to add your plugin
with extensionstrue/extensions IIRC) or you need to use executions
to
bind the plugin to the lifecycle of the
It turns out that the biggest blocker in achieving /any/ reliable
concurrent building within maven is the java file system, which is
basically seems limited to single threaded visibility of file updates;
I'm still trying to figure out what the rules /are/ in this context and
I'm hoping someone
Stephane Nicoll wrote:
Staging repo:
https://repository.apache.org/content/repositories/maven-007/
Staging site:
http://maven.apache.org/plugins/maven-ear-plugin-2.4.1/
+1, the source bundle contains some target/* stuff but otherwise looks good.
Benjamin
I'm talking about in the projects that use your plugin
On 19 February 2010 09:19, tbee t...@tbee.org wrote:
Stephen Connolly-2 wrote:
If you want to bind your plugin to pre-existing phases, then you must
either
create your own packaging type (will will require you to add your plugin
On Fri, Feb 19, 2010 at 11:29 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
It turns out that the biggest blocker in achieving /any/ reliable
concurrent building within maven is the java file system, which is basically
seems limited to single threaded visibility of file updates;
Hi,
based on my development for a plugin i now reached the state of working on
my integration tests...but now i would like to investigate a problem during
a particular integration-test
I'm searching for a way to run the integration under debug output like mvn
-X ...that means in result the
cd target/it/_name_of_test
mvnDebug -s ../interpolated-settings.xml _goal_
On 19 February 2010 14:21, Karl Heinz Marbaise k...@soebes.de wrote:
Hi,
based on my development for a plugin i now reached the state of working on
my integration tests...but now i would like to investigate a problem
The list of phases is defined in maven... you cannot define your own phases
without building your own custom maven. (Notice the full stop is after
I haven't done my due diligence and looked at the maven code, or tried it
out - so I am talking from general impressions and doc /qualifier
Stephen Connolly-2 wrote:
I'm talking about in the projects that use your plugin
Seeing how these build file are growing and growing, and the amount of lines
that are required to include a plugin, I'm starting to doubt if Maven is
the way to go. Maybe Ant with some default build scripts
what maven gives you is a consistent set of phases that any developer only
has to learn once.
and it is easy to see what is bound to what phase.
With ant build files it's a rats nest of interconnected targets.
Go with what works for you
On 19 February 2010 17:30, tbee t...@tbee.org wrote:
Stephen Connolly-2 wrote:
what maven gives you is a consistent set of phases that any developer only
has to learn once.
Agree and that is the lure of Maven. But if you look at the plugins,
execution tags and the weird behavior of per default compiling against java
1.3 (in stead of the
Hi,
This bug has been marked as fixed but i have defined in parent pom
pluginManagement element the plugin with version, dependencies and
configurations. They are inherited correctly to child pom build element
plugin but everything fails to inherit to plugin in profiles element.
Now i must
On 19 February 2010 18:29, tbee t...@tbee.org wrote:
Stephen Connolly-2 wrote:
what maven gives you is a consistent set of phases that any developer
only
has to learn once.
Agree and that is the lure of Maven. But if you look at the plugins,
execution tags and the weird behavior
Stephen Connolly-2 wrote:
There is only one person I have ever seen who crafts well setup ant
builds... Peter Reilly
And unless you are Peter Reilly...
Well, you haven't seen mine, have you :-)
--
View this message in context:
Kristian Rosenvold wrote:
It turns out that the biggest blocker in achieving /any/ reliable
concurrent building within maven is the java file system, which is
basically seems limited to single threaded visibility of file updates;
I'm still trying to figure out what the rules /are/ in this
Reopen the issue with a sample project expressing the problem. Telling us
something doesn't work without a way to easily reproduce the problem and not
referencing, or updating, the JIRA means there's a good chance we'll never look
at it.
We'll try and be better on our side as well by providing
On Feb 19, 2010, at 1:29 PM, tbee wrote:
Stephen Connolly-2 wrote:
what maven gives you is a consistent set of phases that any developer only
has to learn once.
Agree and that is the lure of Maven. But if you look at the plugins,
execution tags and the weird behavior of per
jvanzyl wrote:
Sure, if you're dealing with a single module there's no benefit of
inheritance. If you really find you want goals of certain plugins to be
executed automatically then yes, you make a custom packaging and make it
transparent by referring to the packaging. This is all with
19 matches
Mail list logo
