[starksm64]

The disconnect for me is that I'm not really interested in the users capable of obtaining the source code and building the latest and greatest. They can setup a project and integrate at the cvs/svn level as you mention.

I'm really considering the docs/tutorial phase of the project lifecycle where these artifacts should evolve given input of users who are not building the cvs tree. It applies to training material as well. It just seems we could come up with a better delivery method which leverages jboss ide more than we do today.

The discussion around strict component versioning is just noise to me at this point. In the end this may kill the usability of the the eclipse update mechanism for this usecase, but for now I'm more interested in the validity of the concept. What are the impacts in terms of project build structure, how docs/tutorials/training has to be done, etc.

[maxandersen]

ok - then lets us assume that versioning and build structure impact is not an issue, how do you see this working ?

What happens when a user points their eclipse to the "JBoss Latest & Greatest" updatesite...what should they see in the eclipse update manager and what should they get when they choose to update something ? (remember the stuff needs to go into a eclipse extensions directory somewhere with /plugins & /features)

[starksm64]

We could have training, docs, "features" with subcateories for the various jems projects publishing this content, or it could be inverted to the jems projects "features" with training, docs subcategories.

As a test, consider the out of date jaas how to that I have been wanting to update. It needs to be updated for 4.0.x, and now ejb3. It does not live in any specific project module. It should be in some generic jems docs module. As a test, how could this be packaged up? Its docbook, two ears, build script and configuration scripts.

It has dependencies on a version of jbossas, and ejb3 if its updated to cover that. We can forget about ejb3 for now, if that is an unnecessary compliation.

[maxandersen]

been away on consulting so did not get time to answer this one.

The "JAAS How To", I assume that is what is located at: http://sourceforge.net/docman/display_doc.php?docid=18240&group_id=22866

As I see that download it contains some docs (jw-0831-jaas_p.html + images/*) and an example project.

For that (documentation) to be distributed via an eclipse update site I would say the only thing that is needed is to add a OSGI MANIFEST.MF which puts a name and version tag in there so it can be distinguished between further updates.

That bundle/plugin could be called org.jboss.doc.jaas.howto_x.y.z where org.jboss.doc.jaas.howto is the name and x.y.z is the version number.

For this to be included in an updatesite one normally create a feature for the parts you want to be included in the update site. This requires a feature.xml that describes what is included.

so you would have something like this (there might also be a build.properties in each plugin/feature, but i'm not sure that is required):

org.jboss.doc.jaas.howto/META-INF/MANIFEST.MF
org.jboss.doc.jaas.howto/jw-0831-jass_p.html
org.jboss.doc.jaas.howto/images/*
org.jboss.doc.jaas.howto/examples/*

org.jboss.doc.feature/feature.xml

The feature.xml is intentionally named org.jboss.doc.feature as it might be a good thing to make a doc feature that included most of JEMS.

So with this (the minimal configuration) you would have the possibility to point your eclipse to the updatesite and get information about what new things that are available.

When you chooses to get the feature it by default will put the meat in [eclipseinstall]/plugins.
The user can choose to put it in some other directory, but it just *has* to be in the form:
/eclipse/ and this directory must have an .eclipseextension file.

The above can pretty easily be extended to have the feature/plugins also depend on a version range of certain plugins. e.g. have the howto depend on you having org.jboss.something.jass.dependent, 3.2.8-4.x.x installed together with it - but i don't know if that is your goal.

If you want the docs to be *inside* the help functionallity of eclipse then the only thing needed is to create it as a help plugin. For that the best isolated example I have is org.hibernate.eclipse.help which converts the hibernate core and tools reference into eclipse help by automatically generating a toc.xml etc. based on the docbook source.

Does this answer some of your questions ?

[starksm64]

Yes, I'll try some of this to get a feel for it.