Has anyone raised this in Jira?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Brian Ewins <[EMAIL PROTECTED]> wrote on 24/06/2003
01:17:09 AM:
>
>
> Michal Maczka wrote:
>
> > [...]
> >
> >>(or something like t
Thanks for these two+ suggestions on how to work with
private jars.
While I can't contribute much on the implementation
details, I have some thoughts on the big picture.
You can tell someone that setting up an artifact repository
is the "right" way to do it, but regardless Maven/Ant users
will
bwalding2003/06/23 16:45:54
Modified:xdocsfaq.xml
Log:
Add doco about ignoring test failures
Revision ChangesPath
1.31 +16 -0 maven/xdocs/faq.xml
Index: faq.xml
===
RCS file: /home/cvs/m
bwalding2003/06/23 16:45:40
Modified:src/plugins-build/test/xdocs properties.xml
Log:
Add doco about ignoring test failures
Revision ChangesPath
1.6 +2 -1 maven/src/plugins-build/test/xdocs/properties.xml
Index: properties.xml
===
bwalding2003/06/23 16:40:02
Modified:src/plugins-build/test/xdocs properties.xml
Log:
Add doco about ignoring test failures
Revision ChangesPath
1.5 +7 -0 maven/src/plugins-build/test/xdocs/properties.xml
Index: properties.xml
===
Janne <[EMAIL PROTECTED]> writes:
> * /home/*/tmp/db-torque >maven dist:lite
> __ __
> | \/ |__ Jakarta _ ___
> | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
> |_| |_\__,_|\_/\___|_||_| v. 1.0-beta-9-SNAPSHOT
>
>
> Attempting to download commons-configuration-1.0-dev-3.20030
Sounds good... I've renamed the dependency per your suggestion:
batik
1.5-fop-0.20-5.rc3
As for the fop JAR, you are correct, the -rc3-alpha JAR in Ibiblio seems to be
identical to the one I'm using. I have made that change to the PDF plug-in's
project.xml as well.
The JIRA issue has not
The following comment has been added to this issue:
Author: Charles Chan
Created: Mon, 23 Jun 2003 12:06 PM
Body:
Yes, you're right, it's not coming from maven-new. Sorry for the confusion.
-
View the issue:
htt
Michal Maczka wrote:
[...]
(or something like that) - jelly should always use artifacts, not
dependencies, to construct paths. It doesnt stop you naming jars
whatever you like, if they are in the local repo. I had a look over the
broken plugins a while back and I think there was only one case w
On Fri, 2003-06-20 at 14:57, Jason van Zyl wrote:
> I'm going to keep plugging
> away this weekend on some refactoring. I'm primarily interested in
> eliminating the massive memory leak and some efficiency problems with
> interpolation, plugin loading and inheritance.
thanks a lot in advance
jvanzyl 2003/06/23 08:18:47
Modified:xdocssun-licensing-journey.xml
Log:
o updating
Revision ChangesPath
1.12 +8 -0 maven/xdocs/sun-licensing-journey.xml
Index: sun-licensing-journey.xml
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-515
Here is an overview of the issue:
--
> > Hi all,
> >
> > can someone tell me why the war:war goal builds a WAR file named
> > ${pom.artifactId}.war? I expected ${maven.final.name}.war as name
> > like jar:jar builds JAR files.
>
> Unfortunately war plugin is much unlike jar plugin... Michal
> is working
> ATM to bring the deploy/sn
[...]
>
> (or something like that) - jelly should always use artifacts, not
> dependencies, to construct paths. It doesnt stop you naming jars
> whatever you like, if they are in the local repo. I had a look over the
> broken plugins a while back and I think there was only one case where it
> wasn
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-514
Here is an overview of the issue:
--
Mouttet Christian wrote:
> Hi all,
>
> can someone tell me why the war:war goal builds a WAR file named
> ${pom.artifactId}.war? I expected ${maven.final.name}.war as name
> like jar:jar builds JAR files.
Unfortunately war plugin is much unlike jar plugin... Michal is working
ATM to bring the dep
The following comment has been added to this issue:
Author: Brett Porter
Created: Mon, 23 Jun 2003 9:18 AM
Body:
I don't think this belongs to maven-new?
Anyway, I think I've seen this problem exhibited, but I have a sneaking suspicion that
Jason's recent changes may have fixed t
A 15:47 23/06/2003 +0200, vous avez écrit :
Hi all,
can someone tell me why the war:war goal builds a WAR file named
${pom.artifactId}.war?
I expected ${maven.final.name}.war as name like jar:jar builds JAR files.
In plugin.jelly of the war-plugin there is ${maven.war.final.name}
defined. But i
[...]
> Those plugins are unnecessarily wrong though. The offending code in the
> war plugin:
>
>
>
>
>
>
>
>
> Should read:
>
>
>
>
>
>
>
Hi all,
can someone tell me why the war:war goal builds a WAR file named ${pom.artifactId}.war?
I expected ${maven.final.name}.war as name like jar:jar builds JAR files.
In plugin.jelly of the war-plugin there is ${maven.war.final.name} defined. But its
value equals to ${pom.artifactId}.
cu
-
dion gillard wrote:
Michal Maczka wrote:
This feature probably is not used so often but surly plugins like
war, ear, eclipse are not aware of the fact that artifact can be
overriden!
and what they do is something like:
So basiclly they requ
> -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 wherever you want provided it's under the
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
Otto von Wachter wrote:
What I would like is to specify some "private" jar
dependencies that are stored in a lib dir. Is there a quick
hack that would allow me to do this? If it is, perhaps
documenting it would increase the adoption of maven among
users like me. If not would it be easy to add this
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
I am bit busy at the moment but hope to have time to work a bit on war
plugin soon (hope to have it done before rc1 is out)
There was a request to support "bundling" of TLD files in war archive.
I am going to implement it.
I am planning to set default directory for TLDS files accordingly to:
ht
Michal Maczka wrote:
> So they just override version? Not paths?
> I am surly +1 for allowing overriding version.
> This is also a must from the perspective of "transitive dependencies"
> There must be some way of setting the preferred version or artifacts
> Even if they are not listed as depende
michal 2003/06/23 02:49:38
Modified:src/plugins-build/artifact/src/main/org/apache/maven/artifact/deployer
DefaultArtifactDeployer.java
Log:
Implemented 5 file method.
Revision ChangesPath
1.6 +119 -99
maven/src/plugins-build/artifact/src
Looks good, thanks.
Trygvis
Vincent Massol wrote:
Hi Trygve,
I have applied your patch but haven't tested it. I hope it works! :-)
Can you please verify it?
Thanks
-Vincent
-Original Message-
From: Cocell | Trygve Laugstøl [mailto:[EMAIL PROTECTED]
Sent: 22 June 2003 19:59
To: [EMAIL
> -Original Message-
> From: dion gillard [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 23, 2003 5:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: private jar dependencies
>
> Michal Maczka wrote:
>
>
> > There is one more mean for realizing such scenario which was not
> mentioned
> > he
31 matches
Mail list logo
