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 wit
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 behavi
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
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 conte
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:
http://old.nabble.com/custom-maven-plugin-default
On 19 February 2010 18:29, 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
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 d
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
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 wrote:
>
>
>
> Stephen C
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 scrip
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
But, couldn't
cd target/it/_name_of_test
mvnDebug -s ../interpolated-settings.xml _goal_
On 19 February 2010 14:21, Karl Heinz Marbaise 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 during
>
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 b
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 updat
I'm talking about in the projects that use your plugin
On 19 February 2010 09:19, tbee 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
>
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
---
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
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 true IIRC) or you need to use
> to
> bind the plugin to the lifecycle of the packaging type you current
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 pain
19 matches
Mail list logo
