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 Thu, 03 Aug 2006 15:19:17 GMT
Hello, Alexei.

> There are many ways in which you can achieve the separation of
> business logic from presentation layer. Have you heard about MVC (or
> Model-View-Controller) paradigm? .....
> However, this is a hand-made variant of
> the MVC-framework. :)

Yes, that's why I've chosen Struts. It's an MVC framework, it's Apache
project and it's very popular (their site says it's 'the most popular
web application framework for Java').

I have a couple of years of experience in development with JSP and
Struts so I've chosen it not because I've heard some buzz in forums
and decided to try it for test application but because I know it's
good. I think that our purpose is not to reinvent the wheel and to
write yet another MVC framework in scope of Harmony project but just
to create rapidly test infrastructure for Harmony.

> About the attached HTMLs: is there any possibility to utilize
> JUnitReport to generate report pages? It will probably look nicer in
> this case.

OK, I'll put a link to this page, too.

> 2006/8/2, Anton Luht <anton.luht@gmail.com>:
> > 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
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>


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


Mime
View raw message