Re: Improvements on SmartFrog
Gustavo Mendes <[email protected]>
| Newsgroups | gmane.comp.java.smartfrog.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello Steve, How are you? Discussion below. On Thu, 03 Mar 2005 11:23:00 +0000, Steve Loughran <[email protected]> wrote: > Gustavo Mendes wrote: > > Hi people! > > > > We have developed some SmartFrog components last year such as > > JBoss and MySQL. Related the process of developing in SmartFrog, we > > have some doubts and suggestions: > > Hello, > Hello Steve, how are you? > I'm Steve, one of the SmartFrog team. I'm looking at > Jboss/tomcat/geronimo tomcat deployment too; thinking of a way to make > it easy to configure and host all of these alongside resin (already > available), and to make it easy to deploy war and ear files to deployed > instances. > > > > - Are you planning to improve the Eclipse plugin to allow to > > click in the component names and its declaration appear as the Eclipse > > does with Java files? We think that it is an important feature to the > > developers/administrators to navigate in the hierarchy of their > > components. For example, when the developer click on the attribute > > that is defined as "comp ATTRIB ext" the eclipse plugin has to show > > the attributte that comp is related to. > > I think that is one for the enhancement list. > Very good. I Think that this feateure will help the developers to be more productive. > > > > - Are you planning to improve the error messages that are showed > > in the process of compilation? We think that the error messages and > > the way that they are showed are not intuitive. > > If there are any specific places where you were unhappy with the > messages, tell us and we will do our best to fix them. Its always > important for error messages to be intuitive, especially with tools > users are not familiar with. > Perhaps the problem is not only the messages that are displayed, but also the way they are formatted. Perhaps if the error message was showed like that: [Error Message: The attribute "xyz" in the component "wz" is not being referenced on the correct way in component "z"] was more intuitive to system administrators. Perhaps the messages that are showed today is more intuitive for programmers, technicians on the computer science area. From now, we will police ourselves to error messages and feedback you (the SmartFrog team). > > > > - Build.xml file: We think that the build.xml that is > > distributed with SmartFrog is extremely dependent on the SmartFrog > > directories hierarchy. For example, if a developer want to develop a > > new component in SmartFrog, the easiest way is creating a subdirectory > > in $SMARTFROG/examples/ to use the build.xml to build his project. We > > think that via the Eclipse plugin or via a new build.xml for > > developers/administrators is a good idea. > > which build.xml are you using? $SMARTFROG/build.xml > > We have been reworking the build file(s), so that you build components > in a separate tree, called components, > Each component lives in a separate source tree, and can have its own > unit test suite. We also have a set of Ant tasks to deploy, undeploy and > control SmartFrog daemons as part of the source process. The build files > related to this should be a foundation to do stuff outside the main > source tree -you just need to set a few properties to point to where the > core directory tree is to aid integration. > Great! > Even so, I will have to be the first to point out that the build process > is complex. One of my colleagues, Kumar, has been busy improving the > build process for doing product releases, and he has added a lot of > stuff, such as forrest-based documentation. With all this stuff in place > you *can* do standalone component development, with integrated > deployment. One of the components we have is a JUnit component, which > could act as a foundation for integrating testing with deployment. We > need to work in this more, but it should start. This will help us enormously. > > Another components in the 'ongoing' state is one to generate/manipulate > XML documents. This should make it easier to autogenerate XML > descriptors for deploying stuff, and Julio is planning on bringing the > JMX support back in sync with the current codebase. Both of these are in > the components tree, and are self-contained JAR files. If you check out > core/components/junit or core/components/xml, you will see examples of > our current build/test process. I would recommend you use the junit > component as the example of what to do. > > I suspect we are going to have to look at maven-based builds before > long, as we seem to be reaching some of the limits of Ant's scalability. > With the <import> feature of Ant 1.6 we can share template build files, > but you end up very sensitive to directory placements (you need the > shared files in the expected locations), and changes to our common.xml > file can have adverse consequences everywhere. > > Would you be interested in maven support? We already run some of its > reporting services on an internal server, under cruise control. > Not yet. We will develop some components that will help the system administrator to deal with services and data from april. We are interested on the way that SmartFrog deal with distributed communication (currently via RMI) and the CDDLM language. About that, how is the work on SOAP/webservices and CDDLM notation as XML? > -steve > []s Gustavo -- ############################################# # GUSTAVO WAGNER DINIZ MENDES # # www.dsc.ufcg.edu.br/~gustavo # # Graduado pela UFCG # # Curso: Ciência da Computação # # Mestrando pela COPIN-UFCG # # * Integrante do projeto OurGrid # # www.ourgrid.org # Fones: 88063013 / 310-1365 Ramal 32 # # 2358355 # ############################################# ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click