Ok, I'm on vacation next week, but when I get back in the beginning of
Feb, I will check back here to see if you have reached some conclusion
about the best approach to take.
Thanks,
Neeme
Stephane Nicoll wrote:
There are a set of pending issues in the war plugin that really should be
address
Stephane Nicoll wrote at Dienstag, 19. Januar 2010 08:49:
> The old behavior can be re-worked in a way it is mostly backward
> compatible. Regarding the naming issues, we can change it in a way the
> bundled jar file follows the same convention as the "attached" jar file
> (this is purely automate
The old behavior can be re-worked in a way it is mostly backward compatible.
Regarding the naming issues, we can change it in a way the bundled jar file
follows the same convention as the "attached" jar file (this is purely
automated so it shouldn't make a single difference unless people are hackin
I honestly don't have time to look right now, but I would be fine with 2
provided there were tests. You can't break the old behavior even if you think
it's wrong. Document it, let people try it and if folks agree we can make it
the default in the next major release.
On 2010-01-18, at 8:35 AM, N
I wrote the following comment in JIRA, but there is no response, so I
will send it also here.
--- quote ---
I can rework the patch, I just need to know, what the behavior should be:
1. by default turn on the consistent behavior (as the old behavior
seems quite broken to me) and the user can en
Thanks, created issue:
http://jira.codehaus.org/browse/MWAR-215
Stephane Nicoll wrote:
Please create a Jira issue[1] if none has been created already and attach
your patch.
The inconsistency is coming from the way those settings were implemented and
to preserve backward compatibility. The check
Please create a Jira issue[1] if none has been created already and attach
your patch.
The inconsistency is coming from the way those settings were implemented and
to preserve backward compatibility. The checksum issue was overlooked truth
be told.
Thanks,
Stéphane
[1] http://jira.codehaus.org/br
Hi again,
It's now been 6 days since I wrote this e-mail and no response so far.
Does anybody care about the WAR plugin or is it homeless and abandoned? :-P
Or, maybe someone can form an opinion, based on some sort of gut feeling
or some best-practice for Maven plugins?
I would love to get
WEB-INF/lib sorry.
Just back from vacation, hope ApacheCon was good. I've worked on it
during the week and I'll send a mail later, probably tomorrow.
Stéphane.
On 3/30/07, Andrew Williams <[EMAIL PROTECTED]> wrote:
On 21 Mar 2007, at 07:04, Stephane Nicoll wrote:
> Hi,
>
> On 3/21/07, Brian
On 21 Mar 2007, at 07:04, Stephane Nicoll wrote:
Hi,
On 3/21/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
Will the use of this new overlay cause the transitive dependencies
of the overlayed wars to be resolved and included? I currently
construct wars that I intend to be used as overlays by
OK, good to hear, we'll have a look.
One of the very first step I would like to achieve is to share the
following functionalities:
* Ability to filter data *with* interpolation (just like what's inside
the resources plugin)
* Ability to unpack archives with includes/excludes filter *and* the
abi
If you're looking for a solution to resolving transitive dependencies from
WARs, you can use the maven-warpath-plugin. We (at the AppFuse project)
would *love* to see the functionality from this plugin added to the
maven-war-plugin.
http://static.appfuse.org/plugins/maven-warpath-plugin/
Matt
Hi,
On 3/21/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
Stephane, Piotr,
Thanks for taking this on and putting together this proposal. As we discussed
previously, I have significant issues with the current war plugin, so much that
we have been stuck using a patched version of 2.0-beta-2 becaus
Stephane, Piotr,
Thanks for taking this on and putting together this proposal. As we discussed
previously, I have significant issues with the current war plugin, so much that
we have been stuck using a patched version of 2.0-beta-2 because anything newer
breaks my build. I believe that your pro
We are currently switching over to Maven from Ant, so I hope my comments are
too newbie-ish.
I like these ideas...especially #3. We have a hiearchy of libraries that
are actually wars because we need to do jspc in order to test things
completely. Also, we had been using xdoclet directly on the
Mike:
How responsive were the "war-plugin" folks when you made suggestions about
the overlays? I've been on and off the other lists so I lost the history so
to speak. I feel like you deeply understand the needs of "todays" web
packaging and some umph.. in diplomacy might help things. I'm beginn
Michael,
These sound like handy enhancements to have. I also have issues with the
ordering of the overlay because of the timestamps. I documented some of
it and the way we do it (with a very old war plugin version) here:
http://jira.codehaus.org/browse/MWAR-66
I would eventually like to enhance w
On 8/21/06, Brett Porter <[EMAIL PROTECTED]> wrote:
I'm missing the context on this - I'm not sure what primaryArtifact is
set to, but it sounds like you've got the right idea there (though it
should be artifact.getType(), ie war, not aar)
Thank you, I've filed MWAR-69.
Jochen
--
My wife Mar
I'm missing the context on this - I'm not sure what primaryArtifact is
set to, but it sounds like you've got the right idea there (though it
should be artifact.getType(), ie war, not aar)
On 17/8/06 5:38 PM, Jochen Wiedmann wrote:
Hi,
the maven-war-plugin contains the following code snipped:
Sounds like a good idea to me.
- Brett
Quoting Carlos Sanchez <[EMAIL PROTECTED]>:
> Hi,
>
> Sorry about disturbing with work in this moment of happiness ;)
>
> I need to make some improvements to the war plugin, at least splitting the
> war:webapp in war:war-resources (to be run before tests)
+1 I think it would be a great idea to have the war plugin handle packaging
of webstart applications. I deal with this myself my manually copying the
jars within my maven.xml.
Another bonus would be for the war plugin to include Sun's webstart servlet
(maybe not possible due to licensing confli
> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 06, 2003 3:02 PM
> To: Maven Developers List
> Subject: RE: [war plugin] - Proposition by default include instead
> ofexclude
>
>
> On Sun, 2003-07-06 at 06:32, Micha
sus the AspectJ compiler
versus Javac.
> But I was also convinced by Vincent.
>
> regards
>
> Michal
>
> > -Original Message-
> > From: Juergen Heidak [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, July 05, 2003 11:51 PM
> > To: Maven Developers L
> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 05, 2003 11:52 PM
> To: Maven Developers List
> Subject: RE: [war plugin] - Proposition by default include instead
> ofexclude
>
>
> On Sat, 2003-07-05 at
; From: Juergen Heidak [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 05, 2003 11:51 PM
> To: Maven Developers List
> Subject: RE: [war plugin] - Proposition by default include instead
> ofexclude
>
>
> Hi
>
> Breaking API's or configuration settings is always
On Sat, 2003-07-05 at 17:50, Juergen Heidak wrote:
> Hi
>
> Breaking API's or configuration settings is always bad. The much better
> way is to keep compatibility and make the new feature configurable so
> that it can be turned on easily.
>
> I dont use the war plugin I just wanted to say that I
On Sat, 2003-07-05 at 17:24, Michal Maczka wrote:
> > -Original Message-
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, July 05, 2003 10:57 PM
> > To: 'Maven Developers List'
> > Subject: RE: [war plugin] - Proposition b
Hi
Breaking API's or configuration settings is always bad. The much better
way is to keep compatibility and make the new feature configurable so
that it can be turned on easily.
I dont use the war plugin I just wanted to say that I agree with
Vincent.
Regards
> > >
> > >
> > > I think I'm -1
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 05 July 2003 23:24
> To: Maven Developers List
> Subject: RE: [war plugin] - Proposition by default include instead of
> exclude
>
>
>
> > -Original Message-
> &
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 05, 2003 10:57 PM
> To: 'Maven Developers List'
> Subject: RE: [war plugin] - Proposition by default include
> instead of exclude
>
>
> I think I'm -1 fo
I think I'm -1 for making this change now. As you say there are just too
many who are using it the other way.
I'm +0 if you want to introduce a war plugin property such as:
maven.war.dependency.behavior=exclude|include
so that the current behavior is the default.
-Vincent
> -Original Mess
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 23, 2003 2:18 PM
> To: 'Maven Developers List'
> Subject: RE: War plugin
>
> Tld bundling is supported right now by the war plugin. You can even put
> them whe
Tld bundling is supported right now by the war plugin. You can even put
them wherever you want provided it's under the webapp/ source directory.
I'm not sure adding a tld property helps a lot. I personally think it
makes this simple plugin more complex. Person who want more flexibility
(i.e. custo
> The location you've suggested is sensible, but personally I'd prefer if
> the tlds were delivered inside their jars. It seems more of a 'best
> practice' thing to do (eg it avoids problems with jars mismatching tlds)
>
How nice! So you are suggesting that best practice is to use tag libs
only in
The location you've suggested is sensible, but personally I'd prefer if
the tlds were delivered inside their jars. It seems more of a 'best
practice' thing to do (eg it avoids problems with jars mismatching tlds)
"When deployed inside a JAR file, the tag library descriptor files must
be in the
35 matches
Mail list logo
