<snip/>
In order to be able to create tools for the AI, we have to define a specification on how the Component Author (CA) is to package the component(s), and it is my intention with this RT to kick off such a discussion.
I believe this is an important feature, and it is of interest.
Eventually, once this specification is nailed down, I and/or others can start on powerful tools, not only for the AI but also for the CA. We will kill two flies in one go, so to speak.
:) Kool.
So, what is the problem??
Avalon today is 100% about CODE and METADATA.
Avalon shy away from all kind of RESOURCES, whether they are pertinent to the Avalon context or not. I don't know if this intentional or not.
In any event, a COMPONENT consists of all of the above, and if one or the other is completely missing, it is not a component anymore.
True, we do need a more wholistic view of the Component world, and we should be farther along on this than we are.
From my perspective I see the following resources and metadata (some metadatacould be considered a resource and vice versa, so I klump them together), being fairly central to most components;
1. Naming and Identification 2. Versioning 3. Dependencies 4. LifeStyle 5. Container/Environment Requirements 6. Third-Party Requirements 7. Javadoc and other documentation. 8. Internationalization & Localization 9. Management Interface
I don't intent to elaborate on these at this point in time, but would like to mention that item 2-5 is pretty much nailed down as it is today.
Also, item 6, refers to stuff like jars/classes and resources have to be packaged into WAR file in a particular way.
Ok. With 1, how do you think it should work? Right now we have the ServiceManager to access the components we need, and we map it via the @avalon.dependency tag. Or are you thinking of something else?
Also, 6-8 are not really addressed either. We have support for i18n/l10n, but not in the sense of being able to provide one way to support the resources in a consistent way. IOW, it is up to the component author to know the keys for the i18n messages, and in no way can an application integrator override what is packaged in the JAR. It would be very important to export the i18n keys in a component JAR so that we can also tool that. We would provide the values of the keys as well so that we can turn it over to translators to do their jobs.
JavaDocs and other docs should be pointed to, not stored in the JAR itself. That would require an internet connection (or fileshare connection) to download the info (possibly JARed itself) and plug it in to the help system. Perhaps this is something I should suggest to the JSR 198 team.
Item 9, I am a little bit split over myself. Sometimes I feel that the container should be able to provide a Management Interface automatically, but how would it know what is part of management, and what is part of the components normal function. TBD.
It depends on the type of management we are exposing I suppose. One of the thoughts on this was the JMX integration with Phoenix. The container used metadata to construct the JMX interface, and the proxy to manage the component in question.
First of all, I would like people to recognize that we actually have 3 different packages to deal with;
1. Component APIs 2. Component Implementations 3. Support Implementations. 4. Assembled Applications 5. Container Extensions
How would these five things map to the three packages?
Existing examples; Example of a Component API = Generator Example of an Implementation = FileGenerator Example of an Application = A configured Cocoon instance
Imaginary Examples; Example of Support Implementation = Web interface to Calendar Example of Container Extension = JINI based lookup
I always get the objection that, for instance, the Generator is so simple that we don't need to separate it out.
Not to get too deep into that discussion again, let me just say, yes the code is simple, but look at the list above.
I think that for the Avalon team, API/Implementation separation is an accepted good practice (even at the JAR level). The Cocoon team would need some convincing though.
Component API
============
The Component API specifies the programmatic interfaces and sometimes provides some value objects, but very little else code.
It should (must), however, provide extensive documentation, javadoc and others, about the semantics, explicit or implied, of the API.
It should probably contain I18N and L10N resources where appropriate.
Agreed to a point. If there are I18N and L10N resources that are specific to the API, then yes. However the implementation will have a host of other resources that are necessary for that implementation. There is no way the API can or even should anticipate the needs of the implementations.
I still think JavaDoc/other Docs should be pointed to, possibly a separate JAR that can be incorporated into the help system--or if need be a separate help system for the plugin.
The API portion of the JAR is fairly small typically. If the documentation is included in the API jar, then that JAR should be compressed (not required, but definitely a plus if we have low bandwidth). I do have to worry about low bandwidth clients and I am looking at a good way to manage deployment in this environment.
Component Implementations
=====================
A lot of code typically goes into creating a component.
An implementation can often reuse chunks of the Component API documentation. In fact, it feels almost like documentation should be inherited, albeit we don't have such a mechanism.
I18N and L10N are big issues.
Implementations will support one, few or all LifeStyles.
They Depend on at least its own Component API (but this dependency is different from the dependency in Avalon), but often on many other Component APIs and sometimes Component Implementations. This also refers back to Identification and Versioning.
Often the Component Implementation have many specific requirements from the Container/Environment and often 3rd Party requirements as well, such as JDBC drivers, external config file entries, user authentications and what not.
JavaDocs automatically inherit from interfaces or superclasses if they can be found in the "doc path". So the JavaDocs side of things should be easily inherited.
Docs for a particular implementation of a component should be specific to how to configure it, or some of the advanced features that the implementation allows.
The component implementation typically has meta info which identified component level dependencies, identification, and versioning. As to other types of 3rd party requirements, they are somewhat specified in the Context meta info, but could use some real-world examples to make it better.
Support Implementations
==================
The Support Implementation does not implement the Component API, but provides some explicit additional service to a particular Component API.
An example of a support implementation is a Web User Interface to a particular Component API (or even Component Implementation).
IOW, it is a component of a different type. It can specify alternative interfaces to the system.
Container Extensions
================
In rare occassions a Component Implementation may require a particular Container Extension to be present.
Container Extensions are slightly outside the scope of this RT, so I leave it as a special dependency case.
:) We will keep it in mind, but we will hammer it out at a later time.
Assembled Applications
==================
I have been struggling with the question "Does an Assembled Application have its own code?" The argument is that you need some level of GLUE between the Components to make them work.
The counter-argument would be that, that GLUE is in itself a Component Implementation, that implements an "Application Component API".
The more I have investigated the "counter-argument", the stronger I believe in it. One would establish a few "Application Component API"s for different similar applications.
That would then mean that an Assembled Application is ONLY the components, and the "configuration" and "wiring" of these components (Merlin terms; block.xml, Phoenix terms; configuration.xml + assembly.xml ).
I can see some truth to that. The GUIApp Swing framework I work on typically has the same interface to startup and use the application. Things do work well together, so once it is set up it works wonderfully.
So where does all of this bring us??
==========================
I strongly believe that for each of the above sub-system, we need to SPECIFY a packaging format that are tool-friendly.
I have a vision, using Eclipse/Netbeans;
Don't forget their corporate cousins: JBuilder and IDEA. When JSR 198 is released to the world, we should support it directly. It will be only a matter of time before the JSR is supported directly.
<snip/>
This is just the beginning of such a vision. I hope everyone can see the elegance if/when we could reach such a state.
Excellent.
I have started on such a tool several time, and I think others have also thought about it, and I bet the reason why it doesn't exist by now is the lack of packagin specifications. It is not possible to start on such a IDE plug-in, since there is no standard on what constitutes a component.
I hope we can spend a little bit of time defining exactly that.
1. How is a Component API packaged?
2. How is a Component Implementation packaged?
3. How is an Assembled Application packaged?
This will already give us plenty of room for fantastic tools to be developed.
:P The greatest vote on how it is to be done goes to the doer, and not the adviser. So we can start with your vision of how to package things, and move from there. So far the only requirements on packaging come from Merlin and Phoenix. Merlin is a bit looser in that it specifies the MANIFEST.MF entries that should be specified (agreed to standard packaging from Java), and then ther are things like block.xconf and the Phoenix packaging things.
Answering the 3. question first should be the easiest, since that is related to the Container where we deploy.
Well, that is not entirely true, because the container is only interested in the runtime aspect of the Application, and doesn't care about installation, versioning (of entire app), documentation and to some extent configuration handling.
Phoenix was more explicit about the packaging than Merlin is, but we need to nail this one down more precisely. Not because we need to satisfy Merlin, but to satisfy tools' need for a specification in this area.
I would like not to go into specifics about what _I_ believe to be a good packaging specification for the above 3 (I haven't been thinking too much about Container Extensions and Support Implementations), but let everyone digest what I have just written.
I think that is as good a place to start as any. The hardest part in a project is the first step. I recall the first (and only) time I went repelling. The first step was the hardest, but once it was taken, it was all downhill from there. ;P Seriously though, I would rather start with the ideas of someone who put some thought into it, and refine and refactor from there.
At the end of this discussion, I would like to see the following exit-conditions;
1. Packaging specifications for at least the 3 core packages (api, impl and app).
Sounds reasonable.
or
2. The community decides that this is not a concern and should not be part of Avalon core.
I prefer 1.
And in the event of 1., the follow-up question would then be, Is it in Avalon's interest to host IDE tools for Avalon development?
Yes. However, unless it is eclipse, I think the licensing of the IDE APIs are unclear, so building them would be tricky.
I hope I have provided some food for thought.
You sure did.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
