> -Original Message-
> From: Bruce Atherton [mailto:[EMAIL PROTECTED]
> What do people think about Ant supporting a way to install
> and remove antlibs from the command line into a standard
> antlib directory that is automatically added to the classpath
> on startup? That would suppo
ith formal documented extension semantics, with scope limited to the system
classloader).
WDYT?
Cheers, Steve.
--
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 30 August 2006 2:20 AM
To: Ant Developers List
Subject: Re: classloader for 1.7
On 8/25/06, Stephen McConnell <[EMAIL PROTECTED]> wrote:
Given that a solution that limits mutation to the system class
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jesse Glick
> Sent: Friday, 1 September 2006 4:56 AM
> To: dev@ant.apache.org
> Subject: Re: Building Ant 1.7beta
>
> Stefan Bodewig wrote:
> > you'd just be asking for classloader problems if you have two
> > dif
n XML data declaring new
classloader creation criteria (i.e. no mutation in the general case) and
where the taskdef task incorporates parallel/equivalent functionality.
Cheers, Steve.
----------
Stephen McConnell
mailto:[EMAIL PROTECTED]
stom handlers). In fact the combination of
system classloader mutation plus support for custom URL handlers would
contribute to a significant potential simplification of Depot's extensions
to the Ant project model and task some task implementations.
Cheers, Steve.
--
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Friday, 22 September 2006 11:44 AM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> > Just for reference I have quite a bit of experience working with
> > custom protocol handlers.
>
> OK,
> -Original Message-
> From: Scott Stirling [mailto:[EMAIL PROTECTED]
> Sent: Friday, 22 September 2006 11:58 PM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> DD asks:
> > > Does that play well with application containers that
&
ink the URLStreamHandlerFactory model fits this description. In effect
it does not provide an API to support runtime customization or multiple
factory declaration/chaining. This is principal reason why I suggested the
approach related to the 'java.protocol.handler.pkgs' property a
at allowed association of a name with a classname and
classpath and exposing an operation to retrieve the target class.
A URLResource could then be created using:
new URLResource( name, uri, handlerClassResourceName );
The upside of this approach is the elimination of the entire subject o
sed restrictions within
the Path implementation but is feasible given the existance
of Resource.getURL() and underlying support for handler
declaration).
Hope this helps!
Cheers, Steve.
--
Ste
able resource implementation should be required to
fully support getURL() and getOutputStream().
Thoughts?
Cheers, Steve.
--
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 26 September 2006 4:28 AM
> To: Ant Developers List
> Subject: RE: Resource.getURL()
>
> --- Stephen McConnell <[EMAIL PROTECTED]> wrote:
> [SNIP]
> >
> > S
uot;?
Are your implying something equivalent to the way a URL can be externalized
to a string (which could be done if all resources are associated with
dedicated url handlers). Some concrete usage examples would be handy.
/Steve.
--
Stephen McConnell
mailto:[EMAIL PROTECTED
ource named reference to classname and
path
handler:[name] HandlerResource named reference to a protocol
handler
Also important to note is that:
* all of the above return URLs that are in fact URIs identifiy
the resource instance
Does that sound correct?
/Steve.
--
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 26 September 2006 12:56 PM
> To: dev@ant.apache.org
> Subject: Re: Resource.getURL()
>
> On Tue, 26 Sep 2006, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> >&
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 27 September 2006 2:00 PM
> To: dev@ant.apache.org
> Subject: Re: Resource.getURL()
>
> On Tue, 26 Sep 2006, Stephen McConnell <[EMAIL PROTECTED]> wrote:
>
> -Original Message-
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 27 September 2006 4:58 PM
> To: 'Ant Developers List'
> Subject: RE: Resource.getURL()
>
>
>
> > -Original Message-
> > From: Ste
t could flow in bother directions (from Depot to ant during project
configuration, and from Ant to Depot during project execution).
URL protocol handlers are simple standard structures and support within Ant
for these structures would have a significant positive impact on the forward
deve
t:
My schedule is free over the next week and I'll be free to field questions,
contribute code examples, prepare testcases, etc.
Cheers, Steve.
------
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
ree with you that new protocol (a.k.a. new ideas) bring new
overheads in understanding.
Cheers, Steve.
--
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ription is not easy to interpret in terms of a concrete question
or assumption. Could you restate the problem, the scope your assuming, and
the issues your concerned about?
Cheers, Steve.
--
Stephen McConnel
cluded with emphasis
this this is a big feature plus and a small code impact
4. that Resource.getURL() is not required given the above
5. that items (1) and (2) require item (3) when we move from
the API to the build file
Hoping that
> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Is it wrong to build an RC that we already know won't be the final?
No - its not wrong, the RC is simply recognized as a near to final
candidate.
/Steve.
The following switch may be helpful:
$ ant -diagnostics
/Steve.
> -Original Message-
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 12 December 2006 12:19 AM
> To: Ant Developers List
> Subject: Re: AW: AW: Triage time
>
> [EMAIL PROTECTED] wrote:
> >
> >
> >> -
> -Original Message-
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 12 December 2006 5:02 AM
> To: 'Ant Developers List'
> Subject: RE: AW: AW: Triage time
>
>
> The following switch may be helpful:
>
> $ ant -diagno
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > For Ant 1.8, I have in mind some refactoring, like maybe
> > splitting the source tree per jar.
+1
>
> Why?
>
> Splitting the source tree by moving things to antlibs is
> fine, but why split the source tree
.
--
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
;d need a metadata tree mapping antlibs to well known
> packages, but that is not too hard. JSON, perhaps.
It would be worth looking at the JSR 277 draft spec - in particular the
topics dealing with repositories, runtime module construction, and service
loading.
7;m not
> sure that it would be really nice to get the latest version
> by default, making the build system automatically updated is
> not necessarily a good idea (at least users have to keep very
> good control over that).
Yep - basically you
ject:
http://jcp.org/en/jsr/detail?id=294
http://jcp.org/en/jsr/detail?id=277
Cheers, Steve.
----------
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
first scenario correctly reflects the offline notion while the second
scenario does not have any relationship to the term. However, the second
scenario does start to recognize that the physical topology of a machine is
not equivalent to the definition of a policy.
Cheers, Steve.
--
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
d got
> this in the output:
>
> [antunit] took 1,178,948,204.551 sec
>
> That's a long time!
Just a touch over 37 years.
/Steve.
--
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
-
Conor MacNeill wrote:
Do we need this in our Wiki? Doesn't seem appropriate.
Besides, I think Netscape developed Javascript - not Sun.
That's my understanding as well.
SJM
--
|---|
| Magic by Merlin |
| Production by Avalon
Is there a way I can test if an ant project is running in verbose mode
or not? Nothing jumped out at me when going over the javadocs. I'm
hoping there's something I can access via the Project class.
Cheers, Steve.
--
|---|
| Magic by Merlin
What if I said that I was only interested in knowing if the ant command
line "-verbose" switch was enabled or not (as opposed to knowing
anything about what log listeners are doing)?
Steve.
Conor MacNeill wrote:
Stephen McConnell wrote:
Is there a way I can test if an ant project is
Just did a build of ant (ant building ant) and that passed without
problem so I took a look at the bootstrap.sh script and noticed that the
package in question is not included in the build:
"${JAVAC}" $BOOTJAVAC_OPTS -d ${CLASSDIR} ${TOOLS}/bzip2/*.java
${TOOLS}/tar/*.java ${TOOLS}/zip/*.java \
Ignore me - it was a missing class in CVS.
Stephen McConnell wrote:
Just did a build of ant (ant building ant) and that passed without
problem so I took a look at the bootstrap.sh script and noticed that the
package in question is not included in the build:
"${JAVAC}" $BOOTJAV
> -Original Message-
> From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 25, 2004 16:54
> To: [EMAIL PROTECTED]
> Subject: Fwd: RE: [EMAIL PROTECTED]: avalon-tools/avalon-tools-magic
failed
>
> I found this on the gump mailing list.
> Can it be that we [ant] broke
http://brutus.apache.org/gump/public/avalon-tools/avalon-tools-magic/gum
p_work/build_avalon-tools_avalon-tools-magic.html
> -Original Message-
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 25, 2004 13:54
> To: 'Gump code and data'
> Subject:
What is the criteria that is use by the Ant project for a major, minor,
and micro version bump?
Stephen.
> -Original Message-
> From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
> Sent: 23 August 2004 22:02
> To: Ant Developers List
> Subject: Ant 1.6.3 [was status report on the PMC
> -Original Message-
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> Sent: 26 October 2004 01:17
> To: Ant Developers List
> Subject: repository
>
>
> I have just committed a repository task. In theory it will support
> repositories other than maven, but there is only maven support r
> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Just out of curiosity, how many people other than Peter and
> myself have ever started to modify to allow non-file
> imports? :)
I've been using an extended import task for a while now. The task basically
takes
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jesse Glick
> Sent: Saturday, 4 March 2006 5:50 AM
> To: dev@ant.apache.org
> Subject: Re: Junut4
>
> Stefan Bodewig wrote:
> > putting even more modifications into the current task (adding a new
> > JUnitResultFo
I would recommend that you forget about the Taskdef and just focus on
instantiating and executing the IzPackTask task instance.
For example:
IzPackTask task = new IzPackTask();
task.setProject( project );
// you customatization of the task
task.init();
task.execute();
/Steve.
gt; Regardless of what we do, we need to decide so that it can go
> into the release, therefore:
>
> Default excludes to include the ASP.Net hack _svn directory
> for the release of Ant 1.7.0 + svn antlib, and documentation
> to be updated to refl
> -Original Message-
> From: Kev Jackson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 22 August 2006 9:59 AM
> To: Ant Developers List
> Subject: Re: Ant 1.7 - ReleaseInstructions - Compiler
>
>
> On 21 Aug 2006, at 21:19, Antoine Levy-Lambert wrote:
>
> > Hello Kev,
> >
> > when you b
erns and need to be addressed - but they need to be address as
integral elements of the antlib task semantics and implementation.
My conclusion is that proposal should not be included in 1.7.
Cheers, Steve.
--
Stephen McConnell
mail
summary of what is in the codebase today - and some
pointers to the classes in question.
Cheers, Steve.
------
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
-
To unsubscribe, e-mail: [EMAIL
e proposed one is totally different.
> >see http://enitsys.sourceforge.net/ant-classloadertask/
>
> Regards,
>
> Antoine
> Original-Nachricht ----
> Datum: Fri, 25 Aug 2006 01:50:54 +0930
> Von: "Stephen McConnell \\(DPML\\)" <[EMAIL PROTECTED]>
> An: "\&#
> -Original Message-
> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
> Sent: Friday, 25 August 2006 9:42 AM
> To: Ant Developers List
> Subject: Re: classloader for 1.7
>
> I'm +1 on having the classloader task and being able to add
> paths to the main Ant classloader. Internally, w
se is as a build tools, not a Java library.
So, the question is "can Ant evolve into a good Java API?"
If the answer is YES - in your opinion .. how?
If the answer is NO - in your opinion .. why not?
Cheers, Steve.
--
Stephen McConnell
mailto:[EMAIL PROTECT
etc.)
generated as a part of formal distribution content
Cheers, Steve.
--
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
codebase per jar file where each
project (a.k.a. ant-sub-project) would have its own build file,
clearly identified dependencies, testcases, and resulting artifacts.
Could this be a feasible post-1.7 objective?
Cheers, Steve.
> -Original Message-
> From: Henri Yandell [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 20 July 2006 10:04 AM
> To: Ant Developers List
> Subject: Re: Abusing the BuildListener
>
> On 7/12/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > I suspect this isn't what was intended for the bu
55 matches
Mail list logo
