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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
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.
[email protected] 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:[email protected]]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
