harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Luht" <anton.l...@gmail.com>
Subject Re: [build-test-infra] Build Test Infrastructure
Date Wed, 02 Aug 2006 13:03:35 GMT
Hello,

I'm all open for any suggestions and wishes - I'm not an architect but
a humble coder :)

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
>
>


-- 
Regards,
Anton Luht,
Intel Middleware Products Division

Mime
View raw message