Mailing-List: contact m2-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven 2 Developers List" <m2-dev@maven.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <01b801c51fe6$59d2e620$211b03c2@cgeyfr.cgey.fr>
From: "Emmanuel Venisse" <emmanuel@venisse.net>
To: "Maven 2 Developers List" <m2-dev@maven.apache.org>
References: <010801c51f2e$9d58db10$211b03c2@cgeyfr.cgey.fr>
 <4225C502.3020009@apache.org> <011001c51f31$1d3ca760$211b03c2@cgeyfr.cgey.fr>
 <4225C9EF.3030601@apache.org> <012801c51f3a$d7035050$211b03c2@cgeyfr.cgey.fr>
 <422637A4.7000309@apache.org> <019601c51fd5$1f569430$211b03c2@cgeyfr.cgey.fr>
 <4226EDA1.7070701@apache.org>
Subject: Re: Problem with phase lifecycle
Date: Thu, 3 Mar 2005 12:44:25 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


----- Original Message ----- 
From: "Brett Porter" <brett@apache.org>
To: "Maven 2 Developers List" <m2-dev@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