Problem with phase lifecycle

[Emmanuel Venisse <em...@venisse.net>]

Brett,

I try to create tha war plugin. For it, I need to create 3 mojo that run in
different phases :

war:war-resources in process-resources
war:webapp in process-classes
war:war in package

Only the war:war is handle by phase lifecycle. The two others is never call.
Do you have an idea why I obtain this?

Emmanuel

Re: Problem with phase lifecycle

[Brett Porter <br...@apache.org>]

Emmanuel Venisse wrote:

>>cool - I'll take a look. There may still be bugs.
>>    
>>
>
>Thanks
>  
>
Working now. There were a few bugs I fixed.

>Ok, I'll use this mode.
>  
>
Ok, so "package" is war:war, and how it is packaged is configured: war
file, exploded webapp, inplace exploded webapp. Do you agree?

>No problem.
>I can use an "assemble" phase (between compile phase and test phase) for run
>a "war:inplace" goal.
>  
>
Well, only one of assemble and the configuration above is needed...

Just to be clear what each is in m1 terms (as I introduced something new
halfway)
- war:war produces a war file after first producing an exploded webapp
to war up
- war:webapp produces an exploded webapp in an arbitrary location
- war:inplace produces an exploded webapp in maven.war.src (ie, same
location as sources so no deployment is needed if you point your
appserver at the source, and it copies the classes and libs there).

So war:inplace is really just war:webapp, with the target directory
modified, which can be controlled by the configuration.

Now, we need to determine if war:webapp is a separate goal, an assembly
before war:war, or whether war:war is the only goal and it either
produces a war file, or an exploded webapp depending on the configuration.

I'm loathe to add new phases, but I'd really prefer package actually
wrapped it up into an artifact. Perhaps assemble is a valid new phase.

I'm still not certain. Anyone else have thoughts?

Regardless, it can't be process-classes like now (classes must be
processed before inclusion in the war).

For now, I'd add "assemble" just before "package". As far as Michal's
thoughts about where tests belong - they should either be before
assemble or after package, not in between. I'm leaning towards keeping
them as is for now. This will not run integration tests, and you can
always either
a) disable tests during a dev cycle
b) not put the tests in the webapp (I tended to put all the code in a
JAR, and the war only had integration tests, which will come after package).

>"war:inplace" and "war:war" share some code for copy dependencies in
>WEB-INF/lib...
>What do you think?
>  
>
Definitely, all should share as much as possible.

- Brett

Re: Problem with phase lifecycle

[Emmanuel Venisse <em...@venisse.net>]

----- Original Message ----- 
From: "Brett Porter" <br...@apache.org>
To: "Maven 2 Developers List" <m2...@maven.apache.org>
Sent: Thursday, March 03, 2005 11:57 AM
Subject: Re: Problem with phase lifecycle


> Emmanuel Venisse wrote:
>
> >Done. It's a very sample mojo that doesn't work. I'm certainly missing
> >something.
> >
> >
> cool - I'll take a look. There may still be bugs.

Thanks

>
> >>Ok, so there are two alternatives:
> >>- all archiving mojos extend the jar mojo
> >>- we put this code into a separate maven archiving library (or make it
> >>part of maven-core?).
> >>
> >>
> >
> >I prefer the second solution (maven-archiver). Put it in maven-core isn't
> >the best place.
> >
> >
> I agree.
>
> >
> >
> >>Is addTaggedDependencies selecting everything with a certain set of
> >>properties? Nothing has been completely discussed or agreed yet, but I'm
> >>thinking that can be handled by the artifact handler automatically. So
> >>this function may or may not be necessary.
> >>
> >>
> >
> >Yes like "war.bundle" or "ear.bundle" for add or not a dependencies in
the
> >resultant archive.
> >Add this feaures in artifact handler is certainly the best place for
verify
> >f a dependency has or not a specific property.
> >
> >
> Actually, I'm thinking that the properties won't be needed (except to
> override the default behaviour). Generally you want everything except
> your build and test dependencies, which will be specified differently.

Ok

>
> >>Is war:war pulling in its sources as is (ie jarring from target/classes,
> >>src/main/webapp, etc), or is it building up the exploded war:webapp in
> >>target, then jarring that like m1? I believe it can be more effecient by
> >>pulling them all in, if possible. If it is not posssible - is it
> >>necessary to distinguish?
> >>
> >>
> >
> >Yes, and I'm agree with Michal comment.
> >In a development phase, a lot of user use only the war:webapp for
generate
> >an exploded webapp for test it in their app server without restart it.
> >
> >
> Definitely, all I was wondering was whether we should just war it anyway
> - but as Michal said some people might have 20mb wars.
>
> >>Here's a different thought: what if war:war was the only goal, and a
> >>property controlled whether it was archived or exploded?
> >>
> >><plugin>
> >>  <id>war</id>
> >>  <configuration>
> >>    <exploded>true</exploded>
> >>  </configuration>
> >></plugin>
> >>
> >>The default would be false, but if true, m2 package would be like
> >>war:webapp. m2 -Dwar.exploded=false could be used to change it on the
fly.
> >>
> >>
> I'd still consider this an option - what do you think?

Ok, I'll use this mode.

>
> >>No, I don't like this. What is really different about the pre-compile
> >>and compile stage?
> >>
> >>
> >
> >In a pre-compile phase, we can add a mojo for source modification for
> >example.
> >It's very similar to a pre/post goal but applied to an complete phase.
> >
> >
> Sorry, my question wasn't very good. I just mean that pre/post is very
> arbitrary. If there is a reason to split it because it isn't a packaging
> step, then call it something different (assemble, as Michal said).

No problem.
I can use an "assemble" phase (between compile phase and test phase) for run
a "war:inplace" goal.

"war:inplace" and "war:war" share some code for copy dependencies in
WEB-INF/lib...
What do you think?

Emmanuel

Re: Problem with phase lifecycle

[Brett Porter <br...@apache.org>]

Emmanuel Venisse wrote:

>Done. It's a very sample mojo that doesn't work. I'm certainly missing
>something.
>  
>
cool - I'll take a look. There may still be bugs.

>>Ok, so there are two alternatives:
>>- all archiving mojos extend the jar mojo
>>- we put this code into a separate maven archiving library (or make it
>>part of maven-core?).
>>    
>>
>
>I prefer the second solution (maven-archiver). Put it in maven-core isn't
>the best place.
>  
>
I agree.

>  
>
>>Is addTaggedDependencies selecting everything with a certain set of
>>properties? Nothing has been completely discussed or agreed yet, but I'm
>>thinking that can be handled by the artifact handler automatically. So
>>this function may or may not be necessary.
>>    
>>
>
>Yes like "war.bundle" or "ear.bundle" for add or not a dependencies in the
>resultant archive.
>Add this feaures in artifact handler is certainly the best place for verify
>f a dependency has or not a specific property.
>  
>
Actually, I'm thinking that the properties won't be needed (except to
override the default behaviour). Generally you want everything except
your build and test dependencies, which will be specified differently.

>>Is war:war pulling in its sources as is (ie jarring from target/classes,
>>src/main/webapp, etc), or is it building up the exploded war:webapp in
>>target, then jarring that like m1? I believe it can be more effecient by
>>pulling them all in, if possible. If it is not posssible - is it
>>necessary to distinguish?
>>    
>>
>
>Yes, and I'm agree with Michal comment.
>In a development phase, a lot of user use only the war:webapp for generate
>an exploded webapp for test it in their app server without restart it.
>  
>
Definitely, all I was wondering was whether we should just war it anyway
- but as Michal said some people might have 20mb wars.

>>Here's a different thought: what if war:war was the only goal, and a
>>property controlled whether it was archived or exploded?
>>
>><plugin>
>>  <id>war</id>
>>  <configuration>
>>    <exploded>true</exploded>
>>  </configuration>
>></plugin>
>>
>>The default would be false, but if true, m2 package would be like
>>war:webapp. m2 -Dwar.exploded=false could be used to change it on the fly.
>>    
>>
I'd still consider this an option - what do you think?

>>No, I don't like this. What is really different about the pre-compile
>>and compile stage?
>>    
>>
>
>In a pre-compile phase, we can add a mojo for source modification for
>example.
>It's very similar to a pre/post goal but applied to an complete phase.
>  
>
Sorry, my question wasn't very good. I just mean that pre/post is very
arbitrary. If there is a reason to split it because it isn't a packaging
step, then call it something different (assemble, as Michal said).

- Brett

Re: Problem with phase lifecycle

[Emmanuel Venisse <em...@venisse.net>]

----- Original Message ----- 
From: "Brett Porter" <br...@apache.org>
To: "Maven 2 Developers List" <m2...@maven.apache.org>
Sent: Wednesday, March 02, 2005 11:01 PM
Subject: Re: Problem with phase lifecycle


> Emmanuel Venisse wrote:
>
> >It's correct. I don't know if I'll can commit it for tomorrow.
> >
> >
> Strange that it's not initialised then. Whatever you can check in, I'll
> take a look at. As long as it isn't breaking the ci.sh, there's no
> problem committing it unfinished.

Done. It's a very sample mojo that doesn't work. I'm certainly missing
something.

>
> >
> >Yes and No. In AbstractJarMojo, I wrote a method for create a maven
default
> >manifest, and I'll need to add a addTaggedDependencies method for bundle
in
> >archive some dependency. All this code isn't in Plexus Archiver.
> >
> >
> Ok, so there are two alternatives:
> - all archiving mojos extend the jar mojo
> - we put this code into a separate maven archiving library (or make it
> part of maven-core?).

I prefer the second solution (maven-archiver). Put it in maven-core isn't
the best place.

>
> Is addTaggedDependencies selecting everything with a certain set of
> properties? Nothing has been completely discussed or agreed yet, but I'm
> thinking that can be handled by the artifact handler automatically. So
> this function may or may not be necessary.

Yes like "war.bundle" or "ear.bundle" for add or not a dependencies in the
resultant archive.
Add this feaures in artifact handler is certainly the best place for verify
f a dependency has or not a specific property.

>
> >
> >
> >>Do you agree?
> >>
> >>
> >
> >Not really, war:webapp and war:war are 2 very different tasks.
> >
> >
> I don't agree - war:war is war:webapp + jar:jar, making them quite
> similar :)
>
> A couple of thoughts...
>
> Is war:war pulling in its sources as is (ie jarring from target/classes,
> src/main/webapp, etc), or is it building up the exploded war:webapp in
> target, then jarring that like m1? I believe it can be more effecient by
> pulling them all in, if possible. If it is not posssible - is it
> necessary to distinguish?

Yes, and I'm agree with Michal comment.
In a development phase, a lot of user use only the war:webapp for generate
an exploded webapp for test it in their app server without restart it.

> war:war will build the webapp anyway, so there
> really is no need for just war:webapp. The JAR step is quite small and
> quick.
>
> Here's a different thought: what if war:war was the only goal, and a
> property controlled whether it was archived or exploded?
>
> <plugin>
>   <id>war</id>
>   <configuration>
>     <exploded>true</exploded>
>   </configuration>
> </plugin>
>
> The default would be false, but if true, m2 package would be like
> war:webapp. m2 -Dwar.exploded=false could be used to change it on the fly.
>
> >
> >
> >>I'd prefer to go with what works wrt the lifecycle first, and worry
> >>about proper reuse later.
> >>
> >>If the packaging is a problem, the alternative is to have a "package"
> >>phase (webapp) and an "archive" phase (war) I guess.
> >>
> >>
> >
> >It's a good idea, or if we want to be more flexible, add a pre/post phase
> >for each existent phase :
> >"pre-compile" phase
> >"compile" phase
> >"post-compile" phase
> >"pre-package" phase
> >"package" phase
> >"post-package" phase
> >
> >
> No, I don't like this. What is really different about the pre-compile
> and compile stage?

In a pre-compile phase, we can add a mojo for source modification for
example.
It's very similar to a pre/post goal but applied to an complete phase.

>
> We need to bust out of the m1 pattern of thought about goal ordering and
> make goals not be dependant on each other, but rather dependant on the
> current state of the build only.
>
> Thanks for your patience, but it'll be good to iron out these issues as
> this is a new concept.
>
> Cheers,
> Brett
>
>

Re: Problem with phase lifecycle

[Brett Porter <br...@apache.org>]

Emmanuel Venisse wrote:

>It's correct. I don't know if I'll can commit it for tomorrow.
>  
>
Strange that it's not initialised then. Whatever you can check in, I'll
take a look at. As long as it isn't breaking the ci.sh, there's no
problem committing it unfinished.

>
>Yes and No. In AbstractJarMojo, I wrote a method for create a maven default
>manifest, and I'll need to add a addTaggedDependencies method for bundle in
>archive some dependency. All this code isn't in Plexus Archiver.
>  
>
Ok, so there are two alternatives:
- all archiving mojos extend the jar mojo
- we put this code into a separate maven archiving library (or make it
part of maven-core?).

Is addTaggedDependencies selecting everything with a certain set of
properties? Nothing has been completely discussed or agreed yet, but I'm
thinking that can be handled by the artifact handler automatically. So
this function may or may not be necessary.

>  
>
>>Do you agree?
>>    
>>
>
>Not really, war:webapp and war:war are 2 very different tasks.
>  
>
I don't agree - war:war is war:webapp + jar:jar, making them quite
similar :)

A couple of thoughts...

Is war:war pulling in its sources as is (ie jarring from target/classes,
src/main/webapp, etc), or is it building up the exploded war:webapp in
target, then jarring that like m1? I believe it can be more effecient by
pulling them all in, if possible. If it is not posssible - is it
necessary to distinguish? war:war will build the webapp anyway, so there
really is no need for just war:webapp. The JAR step is quite small and
quick.

Here's a different thought: what if war:war was the only goal, and a
property controlled whether it was archived or exploded?

<plugin>
  <id>war</id>
  <configuration>
    <exploded>true</exploded>
  </configuration>
</plugin>

The default would be false, but if true, m2 package would be like
war:webapp. m2 -Dwar.exploded=false could be used to change it on the fly.

>  
>
>>I'd prefer to go with what works wrt the lifecycle first, and worry
>>about proper reuse later.
>>
>>If the packaging is a problem, the alternative is to have a "package"
>>phase (webapp) and an "archive" phase (war) I guess.
>>    
>>
>
>It's a good idea, or if we want to be more flexible, add a pre/post phase
>for each existent phase :
>"pre-compile" phase
>"compile" phase
>"post-compile" phase
>"pre-package" phase
>"package" phase
>"post-package" phase
>  
>
No, I don't like this. What is really different about the pre-compile
and compile stage?

We need to bust out of the m1 pattern of thought about goal ordering and
make goals not be dependant on each other, but rather dependant on the
current state of the build only.

Thanks for your patience, but it'll be good to iron out these issues as
this is a new concept.

Cheers,
Brett

Re: Problem with phase lifecycle

[Emmanuel Venisse <em...@venisse.net>]

----- Original Message ----- 
From: "Brett Porter" <br...@apache.org>
To: "Maven 2 Developers List" <m2...@maven.apache.org>
Sent: Wednesday, March 02, 2005 3:13 PM
Subject: Re: Problem with phase lifecycle


> Emmanuel Venisse wrote:
>
> >>Did you declare
> >>
> >>@goal war-resources
> >>@phase process-resources
> >>
> >>and
> >>
> >>@goal webapp
> >>@phase process-classes
> >>
> >>in the mojos? That should work.
> >>
> >>
> >
> >It's what I do. It don't work.
> >
> >
> Check that the mojo descriptor (META-INF/maven/plugin.xml) is correct,
> but if so it will take some debugging. I can take a look tomorrow if it
> is committed).

It's correct. I don't know if I'll can commit it for tomorrow.

>
> >
> >
> >>I'm not sure war:webapp is process-classes - do you? I think it is
> >>"package", and war:war extends the mojo (rather than prereq'ing it like
> >>in m1).
> >>
> >>
> >
> >Yes, I prefer to use package phase, but war:war use it too.
> >war:war extends the jar mojo for share some code.
> >I don't think I can add 2 goals in the same phase, and choose the
execution
> >order.
> >
> >
> No, we can't choose execution order. So far, there isn't really a case
> for it.
>
> I don't think the war mojo should extend the JAR mojo - I'd prefer it
> extended the warwebapp mojo. I thought all the code it uses from JAR is
> part of plexus-archiver?

Yes and No. In AbstractJarMojo, I wrote a method for create a maven default
manifest, and I'll need to add a addTaggedDependencies method for bundle in
archive some dependency. All this code isn't in Plexus Archiver.

>
> Do you agree?

Not really, war:webapp and war:war are 2 very different tasks.

>
> I'd prefer to go with what works wrt the lifecycle first, and worry
> about proper reuse later.
>
> If the packaging is a problem, the alternative is to have a "package"
> phase (webapp) and an "archive" phase (war) I guess.

It's a good idea, or if we want to be more flexible, add a pre/post phase
for each existent phase :
"pre-compile" phase
"compile" phase
"post-compile" phase
"pre-package" phase
"package" phase
"post-package" phase

>
> Finally, I think war:exploded is a better name than war:webapp -
> generally exploded is used to refer to an unpacked webapp. What do you
> think?

Yes, I prefer it too. I used war:webapp for clone m1 mechanism and don't
disturb user when they'll migrate to m2.
I rename it.

>
> - Brett
>
>

Re: Problem with phase lifecycle

[Brett Porter <br...@apache.org>]

Emmanuel Venisse wrote:

>>Did you declare
>>
>>@goal war-resources
>>@phase process-resources
>>
>>and
>>
>>@goal webapp
>>@phase process-classes
>>
>>in the mojos? That should work.
>>    
>>
>
>It's what I do. It don't work.
>  
>
Check that the mojo descriptor (META-INF/maven/plugin.xml) is correct,
but if so it will take some debugging. I can take a look tomorrow if it
is committed).

>  
>
>>I'm not sure war:webapp is process-classes - do you? I think it is
>>"package", and war:war extends the mojo (rather than prereq'ing it like
>>in m1).
>>    
>>
>
>Yes, I prefer to use package phase, but war:war use it too.
>war:war extends the jar mojo for share some code.
>I don't think I can add 2 goals in the same phase, and choose the execution
>order.
>  
>
No, we can't choose execution order. So far, there isn't really a case
for it.

I don't think the war mojo should extend the JAR mojo - I'd prefer it
extended the warwebapp mojo. I thought all the code it uses from JAR is
part of plexus-archiver?

Do you agree?

I'd prefer to go with what works wrt the lifecycle first, and worry
about proper reuse later.

If the packaging is a problem, the alternative is to have a "package"
phase (webapp) and an "archive" phase (war) I guess.

Finally, I think war:exploded is a better name than war:webapp -
generally exploded is used to refer to an unpacked webapp. What do you
think?

- Brett

Re: Problem with phase lifecycle

[Emmanuel Venisse <em...@venisse.net>]

----- Original Message ----- 
From: "Brett Porter" <br...@apache.org>
To: "Maven 2 Developers List" <m2...@maven.apache.org>
Sent: Wednesday, March 02, 2005 2:52 PM
Subject: Re: Problem with phase lifecycle


> Did you declare
>
> @goal war-resources
> @phase process-resources
>
> and
>
> @goal webapp
> @phase process-classes
>
> in the mojos? That should work.

It's what I do. It don't work.

>
> I'm not sure war:webapp is process-classes - do you? I think it is
> "package", and war:war extends the mojo (rather than prereq'ing it like
> in m1).

Yes, I prefer to use package phase, but war:war use it too.
war:war extends the jar mojo for share some code.
I don't think I can add 2 goals in the same phase, and choose the execution
order.

>
> - Brett
>
> Emmanuel Venisse wrote:
>
> >Brett,
> >
> >I try to create tha war plugin. For it, I need to create 3 mojo that run
in
> >different phases :
> >
> >war:war-resources in process-resources
> >war:webapp in process-classes
> >war:war in package
> >
> >Only the war:war is handle by phase lifecycle. The two others is never
call.
> >Do you have an idea why I obtain this?
> >
> >Emmanuel
> >
> >
> >
> >
>
>

Re: Problem with phase lifecycle

[Brett Porter <br...@apache.org>]

Did you declare

@goal war-resources
@phase process-resources

and

@goal webapp
@phase process-classes

in the mojos? That should work.

I'm not sure war:webapp is process-classes - do you? I think it is
"package", and war:war extends the mojo (rather than prereq'ing it like
in m1).

- Brett

Emmanuel Venisse wrote:

>Brett,
>
>I try to create tha war plugin. For it, I need to create 3 mojo that run in
>different phases :
>
>war:war-resources in process-resources
>war:webapp in process-classes
>war:war in package
>
>Only the war:war is handle by phase lifecycle. The two others is never call.
>Do you have an idea why I obtain this?
>
>Emmanuel
>
>
>  
>