You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Travis Stevens <Tr...@noaa.gov> on 2004/12/29 20:40:23 UTC
altering war.bundle property at maven runtime
Here the gist:
For various reasons, during development of a web application I use
tomcat's cross context feature. This means that specific jar files need
to be in tomcat's shared lib and not in the WEB-INF/lib directory. I am
trying to write a preGoal to set the war.bundle property to false on a
particular dependency during development.
What I have so far is:
<j:forEach var="lib" items="${pom.artifacts}">
<j:set var="dep" value="${lib.dependency}"/>
<j:if test="${dep.getProperty('war.bundle')=='true' and
dep.artifactId=='bms'}">
<j:expr value="${dep.setProperty('war.bundle','false')}" />
<ant:echo>Found bms</ant:echo>
</j:if>
</j:forEach>
The j:expr line does not work and I'm not sure how one would do this.
Thanks,
-Trav
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: altering war.bundle property at maven runtime
Posted by Thomas Recloux <th...@gmail.com>.
On Thu, 30 Dec 2004 09:54:42 +1100, Brett Porter <br...@gmail.com> wrote:
> You can also do a postGoal on war:webapp and delete it :)
I did it on my project, I it not the cleanest way but works fine. If a
global property is set, the postGoal deletes dependencies marked with
an 'unBundle' property.
> I'm interested in your use case for this. I'm a strong proponent of
> having a WAR work everywhere from dev to production without
> modification (except perhaps to change the compiler flags to remove
> debug, etc).
In my case, It is for having a very productive development platform.
We are using eclipse and the sysdeo tomcat plugin
(http://www.sysdeo.com/eclipse/tomcatPlugin.html) with the devloader
(http://www.sysdeo.com/eclipse/readmeDevLoader.html). Like this, the
changes made to the libraries used in the webapp (utils, business) are
immediatly loaded by tomcat.
--
Thomas Recloux
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: altering war.bundle property at maven runtime
Posted by Brett Porter <br...@gmail.com>.
> >try replacing:
> > <j:expr value="${dep.setProperty('war.bundle','false')}" />
> >with:
> > <j:set var="dummy">${dep.setProperty('war.bundle','false')}</j:set>
> >
> I still couldn't get this to work. Is this the correct syntax to set a
> property? I was guessing the first time. This is confusing to be
> because the Dependency class does not have a setProperty method, so I'm
> not sure how these properties are even being handled by maven (or jelly).
ah, ok. I hadn't checked that. Try
${dep.getProperties().setProperty('war.bundle', 'false')}
> This is a hack and tomcat even notes that the cross context loading
> should not be done in a production environment, so we only do this for
> development.
>
> It's not very interesting and eventually this needs to be refactored,
> but we are stuck with it right now.
I guess hacks beget hacks ;)
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: altering war.bundle property at maven runtime
Posted by Travis Stevens <Tr...@noaa.gov>.
Brett Porter wrote:
>try replacing:
> <j:expr value="${dep.setProperty('war.bundle','false')}" />
>with:
> <j:set var="dummy">${dep.setProperty('war.bundle','false')}</j:set>
>
I still couldn't get this to work. Is this the correct syntax to set a
property? I was guessing the first time. This is confusing to be
because the Dependency class does not have a setProperty method, so I'm
not sure how these properties are even being handled by maven (or jelly).
>
>I'm interested in your use case for this. I'm a strong proponent of
>having a WAR work everywhere from dev to production without
>modification (except perhaps to change the compiler flags to remove
>debug, etc).
>
Well, if you must know ;). We use a proprietary set of java class
libraries. There is a class that needs to be initialized before
anything can be done with the webapp. This initialization longer than a
minute. Can you image waiting a minute when you reloaded the context
just to check out a minor change? So I found that a little tomcat hack
which can get around this by keeping that long loading class in a
separate context which does not get reloaded and the main context can
just grab that instance from the other context. Context reload times
are then normal.
This is a hack and tomcat even notes that the cross context loading
should not be done in a production environment, so we only do this for
development.
It's not very interesting and eventually this needs to be refactored,
but we are stuck with it right now.
-Trav
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: altering war.bundle property at maven runtime
Posted by Brett Porter <br...@gmail.com>.
try replacing:
<j:expr value="${dep.setProperty('war.bundle','false')}" />
with:
<j:set var="dummy">${dep.setProperty('war.bundle','false')}</j:set>
The j:set bit just swallows the output, you could leave it off.
You can also do a postGoal on war:webapp and delete it :)
I'm interested in your use case for this. I'm a strong proponent of
having a WAR work everywhere from dev to production without
modification (except perhaps to change the compiler flags to remove
debug, etc).
- Brett
On Wed, 29 Dec 2004 15:36:31 -0700, Travis Stevens
<Tr...@noaa.gov> wrote:
>
> > Wouldn't it be easier to remove the war.bundle property during
> > development and putting it back later if you need it? Worst case,
> > adding a copy to put it in your WEB-INF/lib before building a WAR also
> > seems more straight-forward...
>
> This is what I will probably end up doing, but Maven is more about
> automation. There are currently three things that must take place
> during development that would not take place in the production
> environment. I think the more straight forward approach is to specify a
> development flag which then copies resources and such into the
> appropriate place instead of supplying a readme file with manual steps
> to take.
>
> -Trav
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: altering war.bundle property at maven runtime
Posted by Travis Stevens <Tr...@noaa.gov>.
> Wouldn't it be easier to remove the war.bundle property during
> development and putting it back later if you need it? Worst case,
> adding a copy to put it in your WEB-INF/lib before building a WAR also
> seems more straight-forward...
This is what I will probably end up doing, but Maven is more about
automation. There are currently three things that must take place
during development that would not take place in the production
environment. I think the more straight forward approach is to specify a
development flag which then copies resources and such into the
appropriate place instead of supplying a readme file with manual steps
to take.
-Trav
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: altering war.bundle property at maven runtime
Posted by Steve Molloy <sm...@convera.com>.
Wouldn't it be easier to remove the war.bundle property during
development and putting it back later if you need it? Worst case, adding
a copy to put it in your WEB-INF/lib before building a WAR also seems
more straight-forward...
Steve Molloy