Re: ProjectHelper improvements

add more magic to the ant and subant tasks. >>>>> I am not sure the people you are talking about. The end user that >>>>> will >>>>> write the build file or the user of the Ant ProjectHelper API ? >>>> The people writing the build file. &g

Re: ProjectHelper improvements

build.xml. To be honest I'd rather have people specify the build file names explicitly rather than add more magic to the ant and subant tasks. I am not sure the people you are talking about. The end user that will write the build file or the user of the Ant ProjectHelper API ? The people wr

Re: ProjectHelper improvements

t; build.xml. >>>> To be honest I'd rather have people specify the build file names >>>> explicitly rather than add more magic to the ant and subant tasks. >>> I am not sure the people you are talking about. The end user that >>> will >>&g

Re: ProjectHelper improvements

ather than add more magic to the ant and subant tasks. I am not sure the people you are talking about. The end user that will write the build file or the user of the Ant ProjectHelper API ? The people writing the build file. Then thoses people have already the choice to set or not set the

Re: ProjectHelper improvements

n add more magic to the ant and subant tasks. > I am not sure the people you are talking about. The end user that will > write the build file or the user of the Ant ProjectHelper API ? The people writing the build file. Stefan --

Re: ProjectHelper improvements

Le 21 oct. 09 à 21:35, Stefan Bodewig a écrit : On 2009-10-21, Stefan Bodewig wrote: On 2009-10-17, Nicolas Lalevée wrote: In Ant 1.8 we introduced the ProjectHelperRepository which is maintaining the list of available ProjectHelper in the classpath. And we use it to find the project

Re: ProjectHelper improvements

lking about. The end user that will write the build file or the user of the Ant ProjectHelper API ? Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org

Re: ProjectHelper improvements

On 2009-10-21, Stefan Bodewig wrote: > On 2009-10-17, Nicolas Lalevée wrote: >> In Ant 1.8 we introduced the ProjectHelperRepository which is >> maintaining the list of available ProjectHelper in the classpath. And >> we use it to find the project helper that wi

Re: ProjectHelper improvements

On 2009-10-17, Nicolas Lalevée wrote: > In Ant 1.8 we introduced the ProjectHelperRepository which is > maintaining the list of available ProjectHelper in the classpath. And > we use it to find the project helper that will be able to parse a > specified build file with P

ProjectHelper improvements

I worked a little bit more on the Groovy frontend, and I have some suggestions again on the ProjectHelper. In Ant 1.8 we introduced the ProjectHelperRepository which is maintaining the list of available ProjectHelper in the classpath. And we use it to find the project helper that will be

Re: Contribute for ANT a new format script with a new ProjectHelper

On 2008-11-19, 向雅 <[EMAIL PROTECTED]> wrote: > after patch ProjectHelper with a method accept(buildFile), if file > is xml, ONProjectHelper not accept, so all control transfer to ant > with xml. else if file is on, ONProjectHelper do it. This change to ProjectHelper sounds pret

Re: Contribute for ANT a new format script with a new ProjectHelper

Thanks Stefan. Current I implemented an ONProjectHelper, and Patch ProjectHelper and ant.Main for the 2 problems. I employe sevice magic way, so now I just run ant like before. If there has a build.xml, run ant with xml style. else if has build.on, run ant with on style. if -f or -s arguments

Re: Contribute for ANT a new format script with a new ProjectHelper

On 2008-11-18, 向雅 <[EMAIL PROTECTED]> wrote: > Besides this, I have 2 problems: > 1,I want take care of some xml format file, but current ProjectHelper > implementation just do one helper. I hope the newInstance failed so > ant can make use origin ant instead of anton. if

Contribute for ANT a new format script with a new ProjectHelper

sses; include: {name:**/ONProjectHelper2.class;} } fileset{dir: src; includes: "META-INF/**";} } } Besides this, I have 2 problems: 1,I want take care of some xml format file, but current ProjectHelper implementation just do one helper. I hope the newInsta

Re: JavFront ProjectHelper

On Thu, 30 Oct 2008, Kevin Jackson <[EMAIL PROTECTED]> wrote: >> I'm not doing OO stuff, the build file is a Java source. > > I suppose it would be possible to do the same using JavaScript as > the language? Not by taking the same approach, but probably similar. > All you would need is a depend

Re: ProjectHelper

On Thu, 30 Oct 2008, Jeffrey E. Care <[EMAIL PROTECTED]> wrote: > For my DiagnosticsProvider/VersionProvider patch I wrote a > ServiceLoader class that mimics the API of the supported > ServiceLoader class that comes with JDK 6. I'm still trying to get > that patch cleared through IBM legal though

Re: ProjectHelper

IBM WebSphere Application Server WAS Release Engineering From: "Xavier Hanin" <[EMAIL PROTECTED]> To: "Ant Developers List" Date: 10/30/2008 09:02 AM Subject: Re: ProjectHelper On Thu, Oct 30, 2008 at 1:01 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: >

Re: ProjectHelper

On Thu, Oct 30, 2008 at 2:12 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Thu, 30 Oct 2008, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 30, 2008 at 1:01 PM, Stefan Bodewig <[EMAIL PROTECTED]> > wrote: > > > > > As for the Projec

Re: JavFront ProjectHelper

> I'm not doing OO stuff, the build file is a Java source. I suppose it would be possible to do the same using JavaScript as the language? All you would need is a dependency on Rhino +BSF or Java6. - It would be interesting to see how hard HelloWorld is (/me puts on huge list of things todo..) >

Re: ProjectHelper

On Thu, 30 Oct 2008, Xavier Hanin <[EMAIL PROTECTED]> wrote: > On Thu, Oct 30, 2008 at 1:01 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > > > As for the ProjectHelper, there is a services facility, so all it > > takes is putting the correct services entry into ME

Re: ProjectHelper

On Thu, Oct 30, 2008 at 1:01 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Wed, 29 Oct 2008, Matt Benson <[EMAIL PROTECTED]> wrote: > > --- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > > > Okay, what say we move the Project instantiation to &g

Re: ProjectHelper

On Wed, 29 Oct 2008, Matt Benson <[EMAIL PROTECTED]> wrote: --- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > Okay, what say we move the Project instantiation to > ProjectHelper then, so that custom ProjectHelpers can > influence the Project class used if needed? we proba

Re: ProjectHelper

On Thu, 30 Oct 2008, Jan Materne <[EMAIL PROTECTED]> wrote: > Looks like Leafcutter: https://leafcutter.dev.java.net/ I haven't been aware of it. If you look at the other thread I've started, it approaches things from a different angle. Also I'd prefer to use the builder pattern and a fluent in

JavFront ProjectHelper

On Wed, 29 Oct 2008, Matt Benson <[EMAIL PROTECTED]> wrote: --- Stefan Bodewig <[EMAIL PROTECTED]> wrote: >> My "build file" is going to look like this (I'm >> making up half of it): >> > > This looks like it's friends with my concept of an Ant > DSL except mine is pretty much just a de-XMLizat

AW: ProjectHelper (was Re: EasyAnt project)

>My "build file" is going to look like this (I'm making up half of it): > >@Project(Name="example", DefaultTarget="echo") >public class BuildFile extends JavaFrontBuildFile { >public BuildFile(Project p) { >super(p); >} > >@Target >public void echo() { >getProject().

Re: ProjectHelper (was Re: EasyAnt project)

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > hijacking a thread. > > On Wed, 29 Oct 2008, Matt Benson > <[EMAIL PROTECTED]> wrote: > > > I see; however let me ask you this: which is more > straightforward, > > creating a custom ProjectHelper or exte

ProjectHelper (was Re: EasyAnt project)

hijacking a thread. On Wed, 29 Oct 2008, Matt Benson <[EMAIL PROTECTED]> wrote: > I see; however let me ask you this: which is more straightforward, > creating a custom ProjectHelper or extending Project and/or Target? > I guess the answer depends on how comfortable you are with

Re: ProjectHelper : parsing from InputStream

Hi all, Matt Benson a écrit : One concept that I had discussed with someone here (Kev? Alexey?) was some kind of resource that would deliver a tempfile for another resource. This might work in simple situations. I didn't expect that my question would re-open this discussion. I think that it

Re: AW: ProjectHelper : parsing from InputStream

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > <[EMAIL PROTECTED]> writes: > > >> -Ursprüngliche Nachricht- > >> Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > >> The problem is a bit more complex than just > allowing a different > >> source. The main problem are build files that

Re: AW: ProjectHelper : parsing from InputStream

<[EMAIL PROTECTED]> writes: >> -Ursprüngliche Nachricht- >> Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] >> The problem is a bit more complex than just allowing a different >> source. The main problem are build files that do not specify a >> basedir attribute on the project tag since A

Re: ProjectHelper : parsing from InputStream

> -Ursprüngliche Nachricht- > > > Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > > Gesendet: Donnerstag, 10. Januar 2008 06:10 > > > An: dev@ant.apache.org > > > Betreff: Re: ProjectHelper : parsing from > InputStream > > > &g

Re: ProjectHelper : parsing from InputStream

, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > > -Ursprüngliche Nachricht- > > Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > Gesendet: Donnerstag, 10. Januar 2008 06:10 > > An: dev@ant.apache.org > > Betreff: Re: ProjectHelper : parsing from InputStre

AW: ProjectHelper : parsing from InputStream

> -Ursprüngliche Nachricht- > Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 10. Januar 2008 06:10 > An: dev@ant.apache.org > Betreff: Re: ProjectHelper : parsing from InputStream > > "Benjamin de Dardel" <[EMAIL PROTECTED]>

Re: ProjectHelper : parsing from InputStream

"Benjamin de Dardel" <[EMAIL PROTECTED]> writes: > 1: Should I copy and rewrite ProjectHelperImpl for my personal use > ? You can do that, if you want to 8-) > Or is there another way No, there isn't. See below. > 2: Do you need my contribution for refactoring helpers to accept > multiple sou

ProjectHelper : parsing from InputStream

Hi all, I need to package ant files in a jar archive and then call these ant files from the jar. The ProjectHelperImpl class only uses an instance of File to parse a file. Project project = new Project(); ProjectHelperImpl helper = new ProjectHelperImpl(); => helper.parse

DO NOT REPLY [Bug 38844] - ProjectHelper implementation that avoids re-parsing build.xml files

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 38844] - ProjectHelper implementation that avoids re-parsing build.xml files

gzilla/show_bug.cgi?id=38844 --- Additional Comments From [EMAIL PROTECTED] 2006-03-03 19:29 --- Created an attachment (id=17830) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17830&action=view) An implementation of ProjectHelper that avoids parsing of build.xml files

DO NOT REPLY [Bug 38844] New: - ProjectHelper implementation that avoids re-parsing build.xml files

gzilla/show_bug.cgi?id=38844 Summary: ProjectHelper implementation that avoids re-parsing build.xml files Product: Ant Version: 1.6.5 Platform: Other OS/Version: other Status: NEW Keywords: PatchAva

DO NOT REPLY [Bug 32216] - Using parse method of ProjectHelper causes import to fail

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32216] New: - Using parse method of ProjectHelper causes import to fail

gzilla/show_bug.cgi?id=32216 Using parse method of ProjectHelper causes import to fail Summary: Using parse method of ProjectHelper causes import to fail Product: Ant Version: 1.6.2 Platform: PC OS/Version: Windows NT/2K

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

> From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > > > > > Hummm, this looks like a foreach to me. Or more exactly > > using the new task of antcontrib (which I think it should be > > candidate to the 3rd party task of the yea

Re: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

ah, yes... even better. :) hard to keep all the permutations straight. When is all that stuff going to be apparent from the ant-contrib site? -Matt --- Peter Reilly <[EMAIL PROTECTED]> wrote: > Matt Benson wrote: > > >>>Actually the new task uses a > type > >>>approach to avoid the . > >>>

Re: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

Matt Benson wrote: Actually the new task uses a type approach to avoid the . Maybe Matt, but remember I want to call a target after all. That's what the depends attribute does, albeit without creating a new project. There still is the thingy, but I'm not fond of it... Not sure what

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

> I understand that Matt ;-) > BUT, what do I put inside the ? The goal is to > call > a number of targets whose name match a regexp > pattern. > > Calling a target means either , with the > caveat > I listed, or Ant-Contrib's task inherited > from > Antelope I think, that call's a target without

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

> From: Matt Benson [mailto:[EMAIL PROTECTED] > > Not sure what thingy you're talking about... > again, from what Peter tells me, the new works > like except without creating a new project. I understand that Matt ;-) BUT, what do I put inside the ? The goal is to call a number of targets whose

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

> > Actually the new task uses a type > > approach to avoid the . > > Maybe Matt, but remember I want to call a target > after all. > That's what the depends attribute does, albeit > without > creating a new project. > > There still is the thingy, but I'm not fond > of it... Not sure what th

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

> From: Matt Benson [mailto:[EMAIL PROTECTED] > > Actually the new task uses a type > approach to avoid the . Maybe Matt, but remember I want to call a target after all. That's what the depends attribute does, albeit without creating a new project. There still is the thingy, but I'm not fond

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

Actually the new task uses a type approach to avoid the . -Matt --- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > From: Jose Alberto Fernandez > [mailto:[EMAIL PROTECTED] > > > > > From: Dominique Devienne > [mailto:[EMAIL PROTECTED] > > > > > > For maybe a little use case, we have differe

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > > From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > > > For maybe a little use case, we have different types of > > tests, UNIT tests, GUI tests, DB tests, etc... each in its own target. > > > > The test target calls them all, by ex

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

> From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > For maybe a little use case, we have different types of > tests, UNIT tests, GUI tests, DB tests, etc... each in its own target. > > The test target calls them all, by explicitly listing all the > test types. I'd happily write depends="t

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

No, the "second category" I referred to was enhancements in general, and I was alluding to the idea of "his enhancement made it into 1.6.1, why not mine?" and so on. Or to make a long story short, my weightless vote would be a -1. -Matt --- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > From

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

> From: Matt Benson [mailto:[EMAIL PROTECTED] > > That was my point. Doesn't the RE patch fall into the > second category? Do you mean to say allowing regexp in target's depends attribute is a compelling-enough enhancement to warrant putting in Ant 1.6.1? Stefan probably doesn't think so, and I

Re: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

That was my point. Doesn't the RE patch fall into the second category? -Matt --- Steve Loughran <[EMAIL PROTECTED]> wrote: > Matt Benson wrote: > > Then that gets into the question of what goes into > > 1.6.1, bug fixes only or enhancements? > > > > -Matt > > > bug fixes, unless the enhanceme

Re: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

Matt Benson wrote: Then that gets into the question of what goes into 1.6.1, bug fixes only or enhancements? -Matt bug fixes, unless the enhancements are really compelling. We want to make moving from 1.6.0 to 1.6.1 easy, and like build file compatibility across major releases as much as possibl

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > > and I think it would be useful. > > This I'm not sure of. I wouldn't oppose the patch, but am not > convinced that it is really needed. Do you have an example that will > let me throw my hands up shouting "of course, we need this!"? OK, I

Re: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

Then that gets into the question of what goes into 1.6.1, bug fixes only or enhancements? -Matt --- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Wed, 7 Jan 2004, Dominique Devienne > <[EMAIL PROTECTED]> wrote: > > > Did you see the patch to allow regexp in the > depends attribute > > Stefan. >

Re: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

On Wed, 7 Jan 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote: > Did you see the patch to allow regexp in the depends attribute > Stefan. Yes. > This one on the other hand doesn't break the static dependency > checking, True. > and I think it would be useful. This I'm not sure of. I would

RE: [PATCH] Support for default ProjectHelper to expand propertie s in attributes to project/target tags

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > people would expect xyzzy to get executed (it won't with your patch, > Ant will fail because no target ${baz} exists instead). This would > break the static target dependency analysis for Ant. Did you see the patch to allow regexp in the depend

RE: [PATCH] Support for default ProjectHelper to expand properties in attributes to project/target tags

> people would expect xyzzy to get executed (it won't with your patch, > Ant will fail because no target ${baz} exists instead). This would > break the static target dependency analysis for Ant. Ah. Ok, got it. Theoretically, the patch could be applied to the tag only then - but considering the

Re: [PATCH] Support for default ProjectHelper to expand properties in attributes to project/target tags

On Sun, 4 Jan 2004, Kenneth Olving <[EMAIL PROTECTED]> wrote: > Hoping that I've managed to navigate all the etiquette for posting a > patch, here goes: I think you have. > Change made in brief: The default ProjectHelper > (ProjectHelper2.java) has had two lines

RE: [PATCH] Support for default ProjectHelper to expand properties in attributes to project/target tags

> I feel unconfortable about this change. It introduces some sort of > dynamic programming with I do notknow which consequences. What happens > when people use ?, what happens when depends lists contain > such variables? I think it is a very bad can or worms, unless we first > have a rational for i

Re: [PATCH] Support for default ProjectHelper to expand properties in attributes to project/target tags

Kenneth Olving wrote: Hoping that I've managed to navigate all the etiquette for posting a patch, here goes: Change made in brief: The default ProjectHelper (ProjectHelper2.java) has had two lines changed so when parsing attributes for the project/target tags, values will be passed th

RE: [PATCH] Support for default ProjectHelper to expand properties in attributes to project/target tags

> From: Kenneth Olving [mailto:[EMAIL PROTECTED] > > Hoping that I've managed to navigate all the etiquette for > posting a patch, here goes: > > Change made in brief: > The default ProjectHelper (ProjectHelper2.java) has had two > lines changed so when parsing

Re: [PATCH] Support for default ProjectHelper to expand properties in attributes to project/target tags

Kenneth Olving wrote: Hoping that I've managed to navigate all the etiquette for posting a patch, here goes: You might want to consider logging a bug (with [PATCH] at the front of the subject) to track this. I can see it getting lost in the noise, otherwise. I think there are a lot more peop

[PATCH] Support for default ProjectHelper to expand properties in attributes to project/target tags

Hoping that I've managed to navigate all the etiquette for posting a patch, here goes: Change made in brief: The default ProjectHelper (ProjectHelper2.java) has had two lines changed so when parsing attributes for the project/target tags, values will be passed through Project.replaceProp