151a152,176
>
>
> Those who have worked on EC2 must be familiar with the
deployment issues, due to the dynamic nature of the EC2 environment.This
tool helps you to deploy any java applications downloading from S3 Buckets.
Also this tool has some cool tasks that you can use within the EC2
Thanks for this. I want to clarify few things.
So in clearcase, if I add to ibm-web-ext.xmi
fileServingEnabled="${webapp.fileServingEnabled}" ,
Our war build file looks like this:
This property is used to name the war file. If the war.prefix
setting
i
Name of properties are arbitrary. The location and value attributes are
well documented...
http://ant.apache.org/manual/CoreTasks/property.html
-Rob A
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2008 7:22 AM
To: user@ant.apache.org
Subje
I'm just getting started with Ivy, but one thing that is very
important for me is to easily download source JARs where available.
This runs and places my expected dependencies in lib/
Hi
I suddenly ran into the very same error when my fileset dir attribute was
set to a root path that was just a wee bit longer than before. As a result,
the arguments passed to the javadoc process get truncated, and the error
ensues.
I was able to work around the problem by using the usexterna
When using f.e.
...
you can bundle properties that belong together, many tasks
that deal with properties have a prefix attribute, f.e.
or
or all db related stuff for production
Regards, Gilbert
-Original Message-
From: Burgess, Benjamin [mailto:[EMAIL PROTECTED]
On Wed, Jun 4, 2008 at 7:22 AM, <[EMAIL PROTECTED]> wrote:
> Hi All,
>
>
>
> I was trying to analyze following two lines.
>
>
>
> location="${log.dir}/db_catcs.log"/>
>
>
>
>
>
> Following are my doubts
>
>
>
> 1: is it necessary to write .file in the property name in the first
> line??
This is
Well, this is about pulling down source JARs for existing artifacts,
so I'm not sure this applies. Perhaps later, when I'm generating
artifacts via Ant/Ivy.
On Wed, Jun 4, 2008 at 6:54 AM, Loehr, Ruel <[EMAIL PROTECTED]> wrote:
> I'm not sure of the best practice, but one thing that you can do is
The property names are not significant.
Think of location as properties stored as java.io.File objects and value
as properties stored as java.lang.String objects; locations of
files/directories vs a string of text.
Ben
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Cool. Thanks.
I thought I have searched the bug database :-O.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
Murray, Mike wrote:
>
> Sounds like you are looking for this...
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=34403
> 34403 zipgroupfileset should
Hi All,
I was trying to analyze following two lines.
Following are my doubts
1: is it necessary to write .file in the property name in the first
line??
2: Both are properties then why we are sometime using value and sometime
location??
Request you to please let me know the s
Sounds like you are looking for this...
https://issues.apache.org/bugzilla/show_bug.cgi?id=34403
34403 zipgroupfileset should support a nested pattern
specification
-Original Message-
From: hdockter [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 9:14 AM
To: user@ant.ap
I'm not sure of the best practice, but one thing that you can do is create s a
conf called "src".
And then publish src artifacts to that configuration
You could publish them directly into the same conf, but I don't like to do that
as I auto configure my
13 matches
Mail list logo