Hello Thomas! I am glad that you are now starting to think about these issues. I will first describe how these problems are addressed today for other modules and then add my views on how to do in the future.
1. Should the module be separately downloadable an installable? Currently some modules are downloadable (most prominently argouml-db) and some are provided with every release (cpp, de, fr, ru, ...). In the current, rather static, build of releases, it is convenient to include a set of "stable" and "ready" modules with each release. Way back, around the releases 0.9.6 through 0.16 I think, I tried to work with the File Sharing but I abandoned it because it was impossible to create a script to upload the files automatically and I felt uneasy to do patches in it because there is no version control. Instead we provide all releases from the http://argouml-downloads.tigris.org project so uploads are made by committing to subversion, files are located next to their index files and if updated it is possible to track who did the update and what it was. Some projects like the argoeclipse and argouml-andromda projects have provided their files from their own web pages. So far the amount of releases done in those projects are so few this doesn't affect the checkout size, I guess this is partly because the argoeclipse project is only developed from within Eclipse so regular developers need not check out the www directory. (The http://argouml-downloads.tigris.org uses 4.5G on disk when checked out.) 2. Versioning, how should this be done? This is currently done by synchronizing the releases. When releasing, the source repository of the module is expected to be in synch with the source repository of the core argouml and everything is tagged and built in one go. Modules that are built this way get the same version number as the ArgoUML release number. For the Java Web Start there is then a comparison mechanism that avoids making new files if it is not updated. This is to reduce the need for downloading new files if they are not changed. Now for my personal feelings about this! 1. I think this depends on the maturity, the size, and expected usefulness or impressive-factor of the module. If a module is mature and small, very likely to be used, or very impressive, I would like it to be included in the first download to improve the impression ArgoUML does when first downloaded and tested. If the module is under fast development, then it is better not to include it because of the fact that there is no mechanism in place to update the module. For Java Web Start we could, however, provide new or updated JNLP-files with a custom combination of versions just by providing a new version of the module X and updating the "explore module X" JNLP-file. I suggest that we stick to having all argouml-related downloads in the http://argouml-downloads.tigris.org project creating separate web pages for each separately distributable module and managing the set of pages by updating index.html and other html pages. 2. I don't have any good idea on how to solve this. Sometimes I think we should avoid messing with version numbers on modules and instead let the compatibility of the interfaces solve this for us. The problem is that this reasoning works well to establish that a module does not fit if it requires interfaces that are not compatible with the interfaces provided by the core argouml and other modules but the opposite does hold. I am hoping that changing to the Eclipse way of handling interface i.e. extension points, will somehow strengthen this but I am not sure it will. 3. I am hoping that we will get this from the Eclipse RCP. As mentioned earlier, this would be possible now when running Java Web Start but that requires a great deal of maintenance of the JNLP-files. 4. Interpreting "bloating" as increasing the size, I don't think we should hesitate. Lets include it ASAP! If "bloating", on the other, means jeopardizing the users' appearance of the of ArgoUML I think we should not. But then it should be included in 0.27.1.Not 0.25.* or 0.26.alpha/betas because they are now focused entirely on what will go into 0.26 or not. Once you have understood how the release script works ;-), it should be straight-forward to add a new module. The difficult question is and should be if we shall include it or not. Update the Cookbook immediately though! I don't understand what part of this requires a Cookbook update but that is another matter entirely. /Linus 2008/5/29, Thomas N. <[EMAIL PROTECTED]>: > > Hi, > > I'm reaching a point where the cookbook can't help me anymore. I'm thinking > about how my module in the argouml-java project could be distributed (this > might be of interest for the other module authors, too), so let me come up > with some questions: > > 1. Should the module be separately downloadable an installable? > > OK, in case of argouml-java it is planned to be shipped with ArgoUML > eventually. But there might be need for a patch, or one will provide an > enhanced version. So I think this is highly desirable. I propose to have it > organized in the file sharing section of the subproject homepage. > > 2. Versioning, how should this be done? > > For a module package that goes into the ext directory, I'd expect that > somehow the ArgoUML versions under which it runs should be announced. And > there should be different versions available, to support more ArgoUML > versions or to allow maintainance and further development. How to organize > this? Must the version number of a module follow some rule? Where should it > be diplayed? I propose to handle it in a similar way like eclipse plugins. > > 3. Notifying of available module upgrades in ArgoUML, will we have that? > > I propose to have this not solved by each module, but by the module > subsystem of ArgoUML, and making the use of it optionally for module > developers. I think we can first live without that. > > 4. Can we agree on a roadmap for the distribution of argouml-java? > > OK, I think it will not get into 0.26, because it adds not (enough) user > value and bloats the distribution packages. On the other hand, which > versions of ArgoUML should be supported? Is it possible to run it even with > 0.24? I propose to minimally support 0.26. To get it tested by more people, > should it go into the 0.25.x and 0.27.x releases? And if the answer to > question 1 is yes, then when can I (or must Linus do this) make it available > for download? I propose to make it downloadable as early as possible. > > Maybe the cookbook can later be updated? > > Regards, > Thomas > -- > GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! > Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
