harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [build-test-infra] Build Test Infrastructure
Date Thu, 03 Aug 2006 16:48:41 GMT


Anton Luht wrote:
> Hello,
> 
> I'm all open for any suggestions and wishes - I'm not an architect but
> a humble coder :)
> 

An architect is a coder with "architect" on their business card :)

> Regarding Struts: putting logic in JSP looks ugly for me. Puttind
> 'out.println(<html code>' to Java code looks ugly, too. I remember
> from my Web app development experience that Struts worked well. Why
> not use it?
> 
> I've already implemented a small prototype using Perl + cgi - please
> see the screenshots attached. I'm going to make a webapp with similar
> pages.
> 
> The pages are:
> - list of uploaded results (test runs)
> - upload result form
> - list of tests for each test run
> - page with test result for a single test in run
> 
> Sorting, paging, filtering, comparing, etc, to be implemented later.
> 
> On 8/2/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>
>>
>> Alexei Zakharov wrote:
>> > Anton,
>> >
>> > How many pages do you plan to have in your application? I mean that
>> > Struts is probably too heavy solution for couple of pages (if this is
>> > your case). *IMHO*
>>
>> I was thinking the same thing, but was going to keep quiet unless
>> someone else spoke up.
>>
>> However, I think the real problem is scope, not the tool (as I figure
>> one simple page done in Struts is the same amount of time as one w/
>> another technology).
>>
>> Anton, could you give us a brief outline of how you hope to proceed?
>> Right now we're desperate for the basics - somewhere to post info, and
>> somewhere to read a summary across all platforms.
>>
>> geir
>>
>> >
>> > Best Regards,
>> >
>> > 2006/8/2, Anton Luht <anton.luht@gmail.com>:
>> >> Hello,
>> >>
>> >> > > I believe that there are more installations that can execute
>> CGI than
>> >> > > those that can run servlets. I'm sure that for the first time
the
>> >> test
>> >> > > infrastructure will be deployed to an existing installation but
>> >> not to
>> >> > > a dedicated server - that's why I decided that CGI suites better.
>> >> >
>> >> > But we aren't going to deploy the "central service" to
>> everywhere, just
>> >> > to the apache infrastructure.
>> >>
>> >> I don't know Apache infrastructure too well - ok, if there's a
>> >> possibility to deploy a webapp - I'll write server-side in Java, no
>> >> problem.
>> >>
>> >> If anyone objects that the technology should be Java + servlet
>> >> container, please let community know. If nobody objects I'm going to
>> >> get down to coding. I think I'll use Struts for the app.
>> >>
>> >> > > When we have a dedicated host for builds maybe it'll be worth
to
>> >> > > rewrite test infrastructure in Java. But please do not consider
>> the
>> >> > > choice of technology final - I just wanted to pick something that
>> >> fits
>> >> > > for a prototype: fast to develop and easy to deploy.
>> >> >
>> >> > I'm confused.  We'll have a host to receive this info from the
>> >> > distributed build machines.  One host will be recording the info
>> from
>> >> > the all the other distributed build machines...
>> >> >
>> >> > geir
>> >> >
>> >> > >
>> >> > > On 8/1/06, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
>> >> > >> Hi Anton,
>> >> > >>
>> >> > >> > I believe that most
>> >> > >> > common server-side engine is CGI (not PHP or J2EE) so
I'd
>> like to
>> >> > >> > implement this using Perl CGI scripts.
>> >> > >>
>> >> > >> (just thinking about) there are several good Java-oriented
>> >> > >> technologies - servlets, JSP, JSF - why not to use them? I
don't
>> >> like
>> >> > >> to say that servlets are more frequent than perl, but Java
>> itself is
>> >> > >> not the most widely used language. We should advertise it.
:)
>> IMHO
>> >> > >> having Java web/servlets server (not a complete J2EE) for
such
>> >> type of
>> >> > >> tasks with theoretically Harmony JRE inside will do a good
job
>> >> for our
>> >> > >> project.
>> >> > >>
>> >> > >> Regards,
>> >> > >>
>> >> > >> 2006/7/28, Anton Luht <anton.luht@gmail.com>:
>> >> > >> > Hello,
>> >> > >> >
>> >> > >> > I know why this thread is so lazy - it's because everybody
>> >> dislikes QA
>> >> > >> > & testing :)
>> >> > >> >
>> >> > >> > > OK, now let me add my $0.02 about my vision about
reporting
>> >> of test
>> >> > >> > > results. I believe it's better to do this using
HTTP rather
>> >> than mail
>> >> > >> > > because some people may not have access to SMTP
port (for
>> >> example, be
>> >> > >> > > behind proxy with Exchange as mail server - I don't
really
>> >> know if it
>> >> > >> > > provides SMTP service). HTTP is open in most  configurations
>> >> and it
>> >> > >> > > was already decided that HDK and tests will be delivered
via
>> >> HTTP.
>> >> > >> > >
>> >> > >> > > I see the reporting of the results in the following
way:
>> after
>> >> > >> > > executing tests the script packs results and uploads
them (as
>> >> with
>> >> > >> > > browser file upload) to the server. After that data
is
>> >> processed on
>> >> > >> > > server-side - daemons can send periodical e-mails,
draw
>> charts,
>> >> > >> > > reports, lists of top test results contributors,
etc.
>> >> > >> >
>> >> > >> > Nobody criticized this approach so I assume that it's
not too
>> >> bad. I'm
>> >> > >> > going to implement a sketch for server-side bunch of
scripts
>> - one
>> >> > >> > that accepts uploads and puts them to a temp directory
and
>> >> maybe some
>> >> > >> > simple reports. They won't use any database. I believe
that
>> most
>> >> > >> > common server-side engine is CGI (not PHP or J2EE) so
I'd
>> like to
>> >> > >> > implement this using Perl CGI scripts. Since this is
a first
>> >> draft,
>> >> > >> > I'm not going to use advanced templates language like
XSLT.
>> >> Including
>> >> > >> > HTML output in script is bad idea so I'm going to use
something
>> >> like
>> >> > >> > HTML::Template [1] for pages generation and CGI::Lite
[2] for
>> >> requests
>> >> > >> > handling.
>> >> > >> >
>> >> > >> > Perl is chosen just because it suites well for fast prototyping
>> >> > >> development.
>> >> > >> >
>> >> > >> > If nobody objects, I'm going to start coding.
>> >> > >> >
>> >> > >> > [1] http://html-template.sourceforge.net/
>> >> > >> > [2] http://search.cpan.org/~smylers/CGI-Lite-2.02/Lite.pm
>> >> > >> >
>> >> > >> > --
>> >> > >> > Regards,
>> >> > >> > Anton Luht,
>> >> > >> > Intel Middleware Products Division
>> >> > >> >
>> >> > >> >
>> >> ---------------------------------------------------------------------
>> >> > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> > >> > To unsubscribe, e-mail:
>> >> harmony-dev-unsubscribe@incubator.apache.org
>> >> > >> > For additional commands, e-mail:
>> >> harmony-dev-help@incubator.apache.org
>> >> > >> >
>> >> > >> >
>> >> > >>
>> >> > >>
>> >> > >> --
>> >> > >> Alexei Zakharov,
>> >> > >> Intel Middleware Product Division
>> >> > >>
>> >> > >>
>> >> ---------------------------------------------------------------------
>> >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> > >> To unsubscribe, e-mail:
>> harmony-dev-unsubscribe@incubator.apache.org
>> >> > >> For additional commands, e-mail:
>> >> harmony-dev-help@incubator.apache.org
>> >> > >>
>> >> > >>
>> >> > >
>> >> > >
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> > For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Anton Luht,
>> >> Intel Middleware Products Division
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message