Re: Allowing antlibs to contribute diagnostics version info
Stefan Bodewig [EMAIL PROTECTED] wrote on 09/02/2008 12:14:15 AM: OTOH at least the -diagnostics part may need more logic than can be (conveniently) placed into an antlib descriptor but could be more easily expressed in Java so really using the service API may benefit us here. FYI, I've completed this feature so know I'm just waiting for our legal folks to clear the contribution. To test this you pretty much need to start a new Ant instance I wasn't sure the best way to do that in the automated tests (or if it's even possible there). Any advice would be appreciated on this topic. Are there any people that handle updating the docs, or should I attempt to tackle that as well?
Re: Allowing antlibs to contribute diagnostics version info
On Thu, 4 Sep 2008, Jeffrey E. Care [EMAIL PROTECTED] wrote: To test this you pretty much need to start a new Ant instance I wasn't sure the best way to do that in the automated tests (or if it's even possible there). The easiest way may be exec inside an AntUnit test. Are there any people that handle updating the docs, or should I attempt to tackle that as well? We appreciate it if people include documentation and tests with their contributions. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
Jeffrey E Care wrote: I haven't looked at the code in question, but I would think the hardest part of this whole effort would be providing the means for Ant to look up antlib version info. I'm actually fairly enthusiastic about using the combination of existing arguments, mostly just because of the number of requests I've seen for the proliferation of arguments to Ant. Surely one of the existing committers could hook that up if you don't want to tackle that part, Jeff... again, the rest is the tricky part IMHO! I'm using META-INF/services from the JAR spec, so the discovery is actually pretty easy so long as the Antlibs are available via the classloader that oata.launch.Launcher configures. Note that this approach does not need a project: it will discover anything that's available from the classloader. I already have a similar function working in the extensions we use to build WebSphere, so I've just been adapting that. I had to reverse engineer the ServiceLoader class from JDK 6, since I know that I can't depend on a JDK 6 runtime. I could have used sun.misc.Service, but I figured that would be problematic on opensource JDKs. You could also run through all antlibs defined in the root of the project, list which are there and diagnose them. Since they are the ones that matter if they are missing... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
On Mon, 01 Sep 2008, Steve Loughran [EMAIL PROTECTED] wrote: You could also run through all antlibs defined in the root of the project, list which are there and diagnose them. Since they are the ones that matter if they are missing... I think there is a good case for a ant -version -v listing all antlibs found in ANT_HOME/lib without having any build file at all. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
Stefan Bodewig [EMAIL PROTECTED] wrote on 09/01/2008 11:00:55 AM: On Mon, 01 Sep 2008, Steve Loughran [EMAIL PROTECTED] wrote: You could also run through all antlibs defined in the root of the project, list which are there and diagnose them. Since they are the ones that matter if they are missing... I think there is a good case for a ant -version -v listing all antlibs found in ANT_HOME/lib without having any build file at all. Right: I want this to work even if there's no build.xml anywhere in sight. Think of it as what's available for me to use? instead of what have I already declared that I'm using?.
Re: Allowing antlibs to contribute diagnostics version info
Stefan Bodewig [EMAIL PROTECTED] wrote on 08/28/2008 11:28:40 AM: OK. Maybe the antlib would just point to the antlib.xml file(s) there and we add the description and versioning stuff into the antlib descriptor? I think you meant that the service file would point to the antlib.xml? The way the service APIs work it really wouldn't make sense to do that. To do it you'd need to have a class that did the pointing to the antlib.xml file; since you already have to do that why not just have that class do the work you want to do? If you've never used the service stuff before I can point you to the docs - it might clear some things up for you as to how it works.
Re: Allowing antlibs to contribute diagnostics version info
On Mon, 1 Sep 2008, Jeffrey E. Care [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] wrote on 08/28/2008 11:28:40 AM: OK. Maybe the antlib would just point to the antlib.xml file(s) there and we add the description and versioning stuff into the antlib descriptor? I think you meant that the service file would point to the antlib.xml? In a way, yes. The way the service APIs work it really wouldn't make sense to do that. I know. I was thinking about not directly using the service API but really just do something similar by using a pointer placed somewhere under META-INF. OTOH at least the -diagnostics part may need more logic than can be (conveniently) placed into an antlib descriptor but could be more easily expressed in Java so really using the service API may benefit us here. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
On Tue, 26 Aug 2008, Tony Sweeney [EMAIL PROTECTED] wrote: Why not use '-V' for version, and '-v' for verbose (or vice versa)? Because we already have command line switches for both and we probably don't want to confuse our users by changing the existing CLI. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
On Tue, 26 Aug 2008, Jeffrey E. Care [EMAIL PROTECTED] wrote: I'm using META-INF/services from the JAR spec, would it be possible to somehow use antlib.xml instead? Right now antlibs don't need to do anything to META-INF at all. If someone else is willing to work on the command line stuff that would be appreciated: should be done in trunk. Both Main.printVersion and Diagnostics.doReport now get the current loglevel passed in as an (additional) argument. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
Stefan Bodewig [EMAIL PROTECTED] wrote on 08/27/2008 09:29:02 AM: I'm using META-INF/services from the JAR spec, would it be possible to somehow use antlib.xml instead? Right now antlibs don't need to do anything to META-INF at all. I would have preferred this but to my knowledge there's no standard location for antlib.xml that I could use to load it from. I want this function to work without there needing to be a project, so relying on Antlib namespace declarations is out. I don't want to go searching through every entry in every JAR on the classpath just to find antlib.xml files. I agree that it's a little clumsy to be using META-INF/services here but this is exactly the kind of application that the services stuff was added to support. Moreover, Ant does have the capability of using META-INF/services for other things (I think ProjectHelper is one example) so this isn't entirely without precedent in the Ant codebase. If someone else is willing to work on the command line stuff that would be appreciated: should be done in trunk. Both Main.printVersion and Diagnostics.doReport now get the current loglevel passed in as an (additional) argument. Awesome, thanks!
Re: Allowing antlibs to contribute diagnostics version info
Gilles Scokart [EMAIL PROTECTED] wrote on 08/19/2008 02:01:53 PM: Why not using the same logic that we have with ant -p and ant -p -v.? We could have ant -v -version and ant -v -diagnostics. Having started working on this now, I've discovered there are a few issues with this approach. 1) With the current argument handling logic, this would only work if the user specifies -v first: if user specifies -version first then argument handling stops immediately, the version is shown Ant exits. 2) When -v -version is specified by the user, the current argument handling logic actually shows the Ant version twice. I would prefer not to do a major rewrite of the argument handling logic just to implement this feature. Is anyone opposed to adding a new -fullversion argument?
Re: Allowing antlibs to contribute diagnostics version info
On Tue, 26 Aug 2008, Jeffrey E. Care [EMAIL PROTECTED] wrote: Gilles Scokart [EMAIL PROTECTED] wrote on 08/19/2008 02:01:53 PM: Why not using the same logic that we have with ant -p and ant -p -v.? We could have ant -v -version and ant -v -diagnostics. Having started working on this now, I've discovered there are a few issues with this approach. 1) With the current argument handling logic, this would only work if the user specifies -v first: if user specifies -version first then argument handling stops immediately, the version is shown Ant exits. 2) When -v -version is specified by the user, the current argument handling logic actually shows the Ant version twice. I would prefer not to do a major rewrite of the argument handling logic just to implement this feature. Understood, even though it shouldn't be too complex to fix. Is anyone opposed to adding a new -fullversion argument? Fine with me, but please open a bugzilla issue for the second case. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
Why not use '-V' for version, and '-v' for verbose (or vice versa)? Perl and Python both do this (opposite ways round, as it happens). Ruby uses '-v' for both (see man page); make and cc use '-v' for version, awk and grep use '-V'; there's no existing 'standard', so it's just a question of which way round. If we're voting, my +1 would be for '-V' - version. Tony. On Aug 26, 2008, at 2:32 PM, Jeffrey E Care wrote: Gilles Scokart [EMAIL PROTECTED] wrote on 08/19/2008 02:01:53 PM: Why not using the same logic that we have with ant -p and ant -p -v.? We could have ant -v -version and ant -v -diagnostics. Having started working on this now, I've discovered there are a few issues with this approach. 1) With the current argument handling logic, this would only work if the user specifies -v first: if user specifies -version first then argument handling stops immediately, the version is shown Ant exits. 2) When -v -version is specified by the user, the current argument handling logic actually shows the Ant version twice. I would prefer not to do a major rewrite of the argument handling logic just to implement this feature. Is anyone opposed to adding a new -fullversion argument? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
Tony Sweeney [EMAIL PROTECTED] wrote on 08/26/2008 11:24:47 AM: Why not use '-V' for version, and '-v' for verbose (or vice versa)? Perl and Python both do this (opposite ways round, as it happens). Ruby uses '-v' for both (see man page); make and cc use '-v' for version, awk and grep use '-V'; there's no existing 'standard', so it's just a question of which way round. If we're voting, my +1 would be for '-V' - version. Ant already uses -v for verbose logging and -version to show it's own version information. Gilles proposed that combining -v and -version (i.e. verbose version) should trigger showing the Antlib version information in addition to Ant's version. I thought that was a great idea, but having started working on this feature I've found that it's not feasible to combine these two switches without a major rewrite of the command line argument handling logic. I think using -V for the Antlib version switch would be terribly confusing, especially that -v means verbose, not version. I'm flexible on the name, but I think that the option to show Antlib version info should have it's own switch.
Re: Allowing antlibs to contribute diagnostics version info
--- Jeffrey E Care [EMAIL PROTECTED] wrote: Tony Sweeney [EMAIL PROTECTED] wrote on 08/26/2008 11:24:47 AM: Why not use '-V' for version, and '-v' for verbose (or vice versa)? Perl and Python both do this (opposite ways round, as it happens). Ruby uses '-v' for both (see man page); make and cc use '-v' for version, awk and grep use '-V'; there's no existing 'standard', so it's just a question of which way round. If we're voting, my +1 would be for '-V' - version. Ant already uses -v for verbose logging and -version to show it's own version information. Gilles proposed that combining -v and -version (i.e. verbose version) should trigger showing the Antlib version information in addition to Ant's version. I thought that was a great idea, but having started working on this feature I've found that it's not feasible to combine these two switches without a major rewrite of the command line argument handling logic. I think using -V for the Antlib version switch would be terribly confusing, especially that -v means verbose, not version. I'm flexible on the name, but I think that the option to show Antlib version info should have it's own switch. I haven't looked at the code in question, but I would think the hardest part of this whole effort would be providing the means for Ant to look up antlib version info. I'm actually fairly enthusiastic about using the combination of existing arguments, mostly just because of the number of requests I've seen for the proliferation of arguments to Ant. Surely one of the existing committers could hook that up if you don't want to tackle that part, Jeff... again, the rest is the tricky part IMHO! -Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
I haven't looked at the code in question, but I would think the hardest part of this whole effort would be providing the means for Ant to look up antlib version info. I'm actually fairly enthusiastic about using the combination of existing arguments, mostly just because of the number of requests I've seen for the proliferation of arguments to Ant. Surely one of the existing committers could hook that up if you don't want to tackle that part, Jeff... again, the rest is the tricky part IMHO! I'm using META-INF/services from the JAR spec, so the discovery is actually pretty easy so long as the Antlibs are available via the classloader that oata.launch.Launcher configures. Note that this approach does not need a project: it will discover anything that's available from the classloader. I already have a similar function working in the extensions we use to build WebSphere, so I've just been adapting that. I had to reverse engineer the ServiceLoader class from JDK 6, since I know that I can't depend on a JDK 6 runtime. I could have used sun.misc.Service, but I figured that would be problematic on opensource JDKs. If someone else is willing to work on the command line stuff that would be appreciated: I don't feel comfortable enough with the codebase to be making major changes in that part of the code.
Re: Allowing antlibs to contribute diagnostics version info
On Tue, 19 Aug 2008, Gilles Scokart [EMAIL PROTECTED] wrote: Why not using the same logic that we have with ant -p and ant -p -v.? We could have ant -v -version and ant -v -diagnostics. works for me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
On Mon, 18 Aug 2008, Jeffrey E. Care [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] wrote on 08/18/2008 10:52:50 AM: I've been thinking about ways that installed antlibs could contribute diagnostic modules and version information. Is there anything like this in the works already that I've missed? I don't thinks so, but I agree that it would be a good idea. Assuming other committers agree, We might see. what are your thoughts on the behavior of the existing -version -diagnostics switches? For best backward compatibility we'd have to leave the existing switches as-is add new switches to show info from the antlibs, though that may be overkill in this situation. I wouldn't expect anybody to rely on the exact output of either, but I'd love to keep -version as short as it is right now and add a new switch here, while I'd be happy to just add more output to -diagnostics.. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
Why not using the same logic that we have with ant -p and ant -p -v.? We could have ant -v -version and ant -v -diagnostics. 2008/8/19 Stefan Bodewig [EMAIL PROTECTED]: On Mon, 18 Aug 2008, Jeffrey E. Care [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] wrote on 08/18/2008 10:52:50 AM: I've been thinking about ways that installed antlibs could contribute diagnostic modules and version information. Is there anything like this in the works already that I've missed? I don't thinks so, but I agree that it would be a good idea. Assuming other committers agree, We might see. what are your thoughts on the behavior of the existing -version -diagnostics switches? For best backward compatibility we'd have to leave the existing switches as-is add new switches to show info from the antlibs, though that may be overkill in this situation. I wouldn't expect anybody to rely on the exact output of either, but I'd love to keep -version as short as it is right now and add a new switch here, while I'd be happy to just add more output to -diagnostics.. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
On Sun, 17 Aug 2008, Jeffrey E. Care [EMAIL PROTECTED] wrote: I've been thinking about ways that installed antlibs could contribute diagnostic modules and version information. Is there anything like this in the works already that I've missed? I don't thinks so, but I agree that it would be a good idea. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
Stefan Bodewig [EMAIL PROTECTED] wrote on 08/18/2008 10:52:50 AM: I've been thinking about ways that installed antlibs could contribute diagnostic modules and version information. Is there anything like this in the works already that I've missed? I don't thinks so, but I agree that it would be a good idea. Assuming other committers agree, what are your thoughts on the behavior of the existing -version -diagnostics switches? For best backward compatibility we'd have to leave the existing switches as-is add new switches to show info from the antlibs, though that may be overkill in this situation. Thoughts?
Allowing antlibs to contribute diagnostics version info
I've been thinking about ways that installed antlibs could contribute diagnostic modules and version information. Is there anything like this in the works already that I've missed? If not I'd be happy to submit a patch if there's sufficient interest. Regards, JEC Jeffrey E. (Jeff) Care [EMAIL PROTECTED] IBM WebSphere Application Server WAS Release Engineering
