ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Kirkpatrick <rob...@eridan.net>
Subject Re: AW: http request handling
Date Tue, 30 Mar 2010 07:53:32 GMT
Thank you Wolfgang for your useful insights.

Your definition of a configuration is indeed the result of the user 
request: an http form submission translated into a set of ant properties.
The dedicated web client makes sure a consistent set is produced.

In my use case, the build is directly triggered, while in a CI context 
this is achieved asynchronously via automatic change detection. In 
either case the missing bit remains: mapping http form to ant properties.

Robert.

wolfgang haefelinger a écrit :
> Robert,
>
>   
>> Don't be confused: I only miss a tiny extension to antServer that could map
>> incoming http requests to ant properties.
>> The GUI is standard html/css, no help needed!
>>     
>
> Have not used antServer. Perhaps you just patch antServer's source
> code to get going? Had to do the same with Ant to make it behave the
> way I want it.
>
>   
>> Many applications could benefit from this, don't you think so?
>>     
>
> Well .., I believe I understand what you want but I have trouble to
> understand the benefit that it would bring to us. Perhaps you should
> publish the benefits (ant user list) so that users get hooked up.
>
> One problem attacked by your approach is that there is a distributed
> Ant. I could just visit a web site to initiate a build instead of
> login to a remote machine. However, here I am using a CI tool
> (CruiseControl) which handles not only Ant but also Maven or other
> build tools. I also don't need to trigger a build. It's done
> automatically whenever something changes.
>
> The other problem area you are attacking is property handling. In
> batch mode it is easy to use a wrong set of properties. I would attack
> this problem differently. I would write a web application allowing a
> user to define a valid set of properties - which I would call a
> configuration. Such a configuration would be stored in a DB, on a http
> server, within SVN ..
>
> Then there could be various "package" targets, i.e   package-c1,
> package-c2, ... If a user runs
>
>  $ ant package-c2
>
> then target "package" would checkout configuration "c2" and "load" it.
> Then it would run "package".
>
> Ok, that would be me while you have a different goal to achieve.
>
> // Wolfgang.
>
>
>
>
>
>
>
>
> On Sun, Mar 28, 2010 at 10:36 PM, Robert Kirkpatrick <robert@eridan.net> wrote:
>   
>> Wolfgang,
>>
>> Don't be confused: I only miss a tiny extension to antServer that could map
>> incoming http requests to ant properties.
>> The GUI is standard html/css, no help needed!
>>
>> Many applications could benefit from this, don't you think so?
>> Robert.
>>
>> wolfgang haefelinger a écrit :
>>     
>>> Robert,
>>>
>>> so I assume you are looking for some kind of "graphical" user
>>> interface to let you users make proper choices about "build options"
>>> (i.e. property values).
>>>
>>> Anyway, something like this does not exist in Ant - and probably never
>>> will. CI tools would be an overkill -- agreed -- but worse, property
>>> handling is not supported to my knowledge.
>>>
>>> I'm afraid to say that you have to start hacking yourself ;-)
>>>
>>> // Wolfgang
>>>
>>> On Sun, Mar 28, 2010 at 6:26 PM, Robert Kirkpatrick <robert@eridan.net>
>>> wrote:
>>>
>>>       
>>>> Wolfgang,
>>>>
>>>> Thank you for your attention.
>>>> Please find the use case in attachment - I get a spam error when attached
>>>> to
>>>> a mail to the ant user list.
>>>>
>>>> Basically you have got it: I have a build which runs like your 3.b and I
>>>> would like to call it like your 3.a.
>>>>
>>>> Currently I use a work-around (in Windows) via an ActiveX shell script,
>>>> but
>>>> this solution is awful.
>>>>
>>>> I believe that CI servers do similar jobs very well, but to me it is an
>>>> overkill.
>>>>
>>>> Robert.
>>>>
>>>> wolfgang haefelinger a écrit :
>>>>
>>>>         
>>>>> Robert,
>>>>>
>>>>> to get a decent response, it would be wise to elaborate in your own
>>>>> words what you would like to (a) achieve and (b) how this could be
>>>>> done with ant.
>>>>>
>>>>> To me, it looks like this:
>>>>>
>>>>> 1. You have a project that you can build with Ant; so there is a
>>>>> build.xml with some targets (clean, compile, test, package, ..)
>>>>> 2. Then someone would startup ant in "server mode" for this particular
>>>>> project: A "http" server gets started and lists on a particular port
>>>>> (say 5000) for incoming requests.
>>>>> 3. Now the project can be compiled by saying something like
>>>>>
>>>>>   $ curl http://localhost:5000/compile?p1=v1&p2=v2
>>>>>
>>>>>  which would be essentially the same as doing a "batch" compilation like
>>>>>
>>>>>    $ ant -Dp1=v1 -Dp2=v2 compile
>>>>>
>>>>> 4. Eventually you would shutdown the server via
>>>>>
>>>>>    $ curl http://localhost:5000/shutdown
>>>>>
>>>>>
>>>>> However, perhaps you have something totally different in mind?
>>>>>
>>>>> Btw, CruiseControl, Hudson, Anthill, Teamcity and all other continuous
>>>>> integration servers are well suited for triggering builds via http
>>>>> requests...
>>>>>
>>>>> // Wolfgang.
>>>>>
>>>>>
>>>>> On Sun, Mar 28, 2010 at 2:30 PM, Robert Kirkpatrick <robert@eridan.net>
>>>>> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> I initially submitted my use case to the antForm guys - see the spec
>>>>>> and
>>>>>> discussion in attachment.
>>>>>>
>>>>>> An ant-embedded http server looks to me as a natural extension to
the
>>>>>> ant-contrib AntServer task.
>>>>>>
>>>>>> Of course the purpose is not to play the role of a classical Web
>>>>>> server,
>>>>>> but
>>>>>> well to drive a build process via a http monitoring client.
>>>>>> So the http inbound requests should IMO be handled by some ant target
>>>>>> with
>>>>>> form input values assigned to ant properties.
>>>>>> >From the build process side, this is very similar to command-line
>>>>>> properties, but from the user/client point of view, it is very
>>>>>> different.
>>>>>>
>>>>>> In this use case, the server would startup and shutdown together
with
>>>>>> the
>>>>>> build process, replying to the monitoring console requests working
as
>>>>>> an
>>>>>> exclusive client. So it should not wait for incoming requests during
>>>>>> execution of  the top-level targets.
>>>>>> One could conceive a wider scope: serving multiple simultaneous clients
>>>>>> for
>>>>>> independent builds, then a separate http listener would be required!
>>>>>> but
>>>>>> this is far off my needs.
>>>>>>
>>>>>> I don't know Hudson, I will check.
>>>>>>
>>>>>> Robert.
>>>>>>
>>>>>> Jan.Materne@rzf.fin-nrw.de a écrit :
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Ant is a buildtool.
>>>>>>> Letting the build waiting for incoming HTTP requests will slow
down
>>>>>>> the
>>>>>>> build and I dont see any reason why.
>>>>>>>
>>>>>>> So could you please elaborate about your use case?
>>>>>>> - who will create the http request
>>>>>>> - what kind of request is it
>>>>>>> - what data in the requests
>>>>>>> - what should the 'handler' (Ant/something else?) do with that
>>>>>>>
>>>>>>> Maybe Ant is not the right tool for that ... E.g. if a request
should
>>>>>>> start a build, the use of a CI server like Hudson is the better
>>>>>>> choice.
>>>>>>>
>>>>>>>
>>>>>>> Jan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>> Von: Robert Kirkpatrick [mailto:robert.kirkpatrick@skynet.be]
>>>>>>>> Gesendet:
>>>>>>>> Mittwoch, 24. März 2010 19:17
>>>>>>>> An: Ant Users List
>>>>>>>> Betreff: Re: http request handling
>>>>>>>>
>>>>>>>> I imagined that the ant plugin fulfilled the Jetty slogan
"Don't
>>>>>>>> deploy
>>>>>>>> your application in Jetty, deploy Jetty in your application".
>>>>>>>> I still believe this has a potential.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Robert.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>>>>>> For additional commands, e-mail: user-help@ant.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>
>>>>>           
>>>
>>>
>>>       
>
>
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message