aeonic-users — A general discussion list for users that develop OpenSwarm apps.

[Aeonic-users] pyswarm is now Aeonic

[Anastasios H. <an...@ha...>]

Hi everyone!

With the revamped software design of our model-driven dev tool, and the
renaming from pyswarm to Aeonic officially effective today, I want to
let you know, that project resources have been changed, too.

Trac has been added and can be found here:
http://sourceforge.net/apps/trac/aeonic

The old bug and feature trackers have been deleted, and tickets are
managed in Trac now.

The mailing lists only changed their names and addresses.  Subscriptions
are not effected.

Greetings,
Anastasios

[pyswarm-users] UML tool candidates

[Anastasios H. <ah...@ha...>]

Hi,

following you see a list of Free Software UML tools I have found until now. If 
you know any of these tools please help deciding if there are good candidates 
to be the next UML tool(s) supported by pyswarm SDK. Support means uni- or 
bi-directional exchange of XMI files, or in some cases model exchange via a 
Python API).

Of course any other comments are appreciated, e.g. if you know another Free 
Software tool or in case of any questions. If you want you can also add your 
rate.

Best regards,
Anastasios

And here are the candidates in alphabetical order; rating speaks for 
itself ;) -1  -0  +0  +1  [http://httpd.apache.org/dev/guidelines.html]


ArgoUML
http://argouml.tigris.org
Well, I need comments of ArgoUML users. The information I found yet were not 
too positive about ArgoUML. (Poseidon is a commercial product based on 
ArgoUML)
-0


Dia
http://live.gnome.org/Dia
Actually for many kinds of diagrams, including UML. Has also Python plug-in 
API [http://live.gnome.org/Dia/Python], so maybe a candidate for 
UML/Python-tree exchange. No XMI support.
+0


Gaphor
http://gaphor.sourceforge.net/
UML tool written in Python. A pretty good candidate, at least for 
UML/Python-tree exchange.
+1


Kermeta
http://www.kermeta.org/
Modeling and transformation language. Doesn't seem to be the right candidate.
-1


NetBeans IDE
http://www.netbeans.org/kb/articles/flash.html
Seems to be exclusively for Java-flavor apps. Can someone confirm this?
-1


Stani's Python Editor (SPE)
http://pythonide.stani.be/
Well, I don't know why Wikipedia does list SPE as UML tool. Anyone here who 
knows?
??


StarUML
http://staruml.sourceforge.net/en/
Positive user comments regarding usability, but negative regarding commercial 
tools that are needed for further development. Maybe this is the reason why 
this project looks dead.
-0


UML pad
http://web.tiscali.it/ggbhome/umlpad/umlpad.htm
No XMI support.
-1


UMLet
http://www.umlet.com/
No XMI format.
-1


Umbrella
http://uml.sourceforge.net/
I have asked in umbrella-users@ for detail information on UML/XMI. It is XMI 
1.2, but seems to miss TagDefinition/TaggedValue yet. Work-around?
+1

[OpenSwarm-users] Rename OpenSwarm into PYSWARM

[Anastasios H. <ah...@ha...>]

I'm sorry for cross-posting. This note is important.

Please note that OpenSwarm will be renamed soon into PYSWARM. Name change will 
have effect to all URLs and names of resources used by the project. If you 
want to learn what the effects are for you and which reasons caused this step 
please see below.


Project Web-site:
http://pyswarm.sourceforge.net/
The old URL openswarm.sourceforge.net will be auto-forwarded for short 
transition phase, but eventually you may want to update now your bookmarks 
and/or tags, e.g. on blogs, del.ico.us

Mailing-list subscriptions:
Subscribtions of our mailing-lists will be automatically transferred. 
Subscribers may want to update their mail filters.

Web-blog: Behind OpenSwarm
Current URL openswarm.blogspot.com will be replaced by pyswarm.blogspot.com

IRC channel:
On irc.freenode.org #openswarm will become to #pyswarm

File-names, downloads, etc.:
All future file-names (e.g. module names, documentation, the FLA), download 
URLs, and other resources (e.g. PYPI/cheeseshop) which use the 
phrase "openswarm" will be updated to "pyswarm".


My apologizes for any inconviences that this change may cause. This has been a 
heavy-hearted decision, really. But this step was necessary due to many 
confusions with the old name and spam filter issues with "openswarm" 
domains / terms. And better change sooner than later. I think that pyswarm 
additionally emphasizes more the Python focus of our project and is better to 
use in command-lines and in code.

Note that the changes will take effect soon, since SourceForge.net is already 
asked to start migration.

Thank you for your understanding.

Best regards,
Anastasios

Re: [OpenSwarm-users] Who wants to test setup for next release?

[Anastasios H. <ah...@ha...>]

Tryggvi Björgvinsson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Anastasios Hatzis wrote:
>> Tryggvi Björgvinsson wrote:
>>> 2. Create a debian package, install and run test cases
>>>
>> That's great. I never used Debian, but have installed Kubuntu 6.10 this
>> week-end at home.
> 
> Kubuntu is very similar to Debian (actually a derivative), uses the same
> structure and the same package manager.
> 

I agree to continue the package and lay-out discussion on 
openswarm-devs. For now I see the reasons why you consider the current 
configuration file layout as wrong approach and it would be great if 
this could be improved.

> 
>>> * PostgreSQL: ``postgresql-8.1 postgresql-plpython-8.1``
>>> * pgAdminIII: ``pgadmin3``
>>> * mxDateTime: ``python2.4-egenix-mxdatetime`` (Already installed)
>>> * pypgsql: ``python-pgsql`` (Already installed)
>>> * pyxml: ``python2.4-xml`` (Already installed)
>>>
>> I'm confident that the final release won't have some of these
>> dependencies. But it's good to know that all required parts are
>> available via APT.
> 
> I was sceptical that this would work, because PostgreSQL was required to
> use openssl and thread-safety. But it seemed to be work, so no need to
> worry (or maybe we need to create more test-cases).

Actually, PostgreSQL (and pypgsql) can only be tested if a generated app 
is also installed on that computer and called by a client, such as the 
populate.py example script. openssl would be recommended for 
security-relevant final-release production systems, usually where the 
Python app is hosted on a server different from the database server. 
Regarding the thread-safety mode I'm still uncertain, how important it 
is, but I'm rather sure that openssl and thread-safety are not a 
requirement for testing an OpenSwarm application in 0.6.2. The first 
step would be to generate the PetStore example in the projects directory 
and then try running projects/PetStore/clients/populate.py

However, I need to split the Installation Manual into two parts, one for 
installing OpenSwarm SDK (developer machine) and one for installing the 
generated OpenSwarm applications (application server), since the 
dependencies are not the same (well, assuming a developer is not testing 
a generated app on the same box where the SDK is).

I wanted to add distutils-support to the code-generator soon, so a 
developer could deploy generated apps with Python setup (similar to the 
SDK itself). Therefor I didn't split the install doc yet. Well, sounds 
yummy, but I still try figuring out, how removal of an installed 
OpenSwarm app would work (installing the package and initializing a 
database on localhost should be simple, the package removal is also 
simple, but what about the database?).


> 
>>> * Rename sdk-view.py and sdk-edit.py. These names are IMHO bad as they
>>> do not indicate which
>>>   software they belong to. A simple ``os-`` or ``openswarm-`` prefix
>>> should do the trick. I
>>>   would however find that a simple *frontend* program (e.g. openswarm)
>>> should do the trick.
>>>   This program would combine the four different programs which could be
>>> executed as follows.
>>>
>>>   - sdk-view.py: openswarm --sdk --view
>>>   - sdk-edit.py: openswarm --sdk --edit
>>>   - osp-view.py: openswarm --view
>>>   - osp-edit.py: openswarm --edit
>>>
>> Yes, I had a similar idea at the first place, but came to the conclusion
>> that it might make working with the commands very difficult if putting
>> *everything* into one script. The reason is that I want to add a pretty
>> portion of new features to OpenSwarm, especially regarding UML<->XMI and
>> model-to-model transformations (the current lack of support of other UML
>> CASE tools still bites me). And I have the feeling that it would be too
>> much to put them all together in a single command-line script, including
>> a confusing help text and an exploding options list ;)
>>
>> Anyway, I agree that the names should indicate which software they
>> belong to. It surely make sense to use a common prefix and I will change
>> that.
>>
>> In addition, probably it would be a good compromise to bundle some of
>> the commands, (just the pattern, not the concrete names):
>>
>>    - sdk-view.py:     openswarm-sdk --view
>>    - sdk-edit.py:     openswarm-sdk --edit
>>    - osp-view.py:     openswarm --view
>>    - osp-edit.py:     openswarm --edit
>>    - osp-generate.py: openswarm --generate
>>    - (not yet):       openswarm-uml --pim
>>    - startGUI.py:     openswarm-gui
>>
>> What do you think about that?
> 
> That's better. I like yours more than mine actually (mine has
> unnecessary many special options).
> 

Yes, the variety and difference of required/applicable arguments and 
options was what made me covering each task in seperate scripts. 
However, the compromise pattern above at least avoids differences in 
arguments. Hum, I hope I have not been too big-mouthed... will need to 
check how I can get this done with the optparse module. :)

Anastasios

> /Tryggvi
> 
>> Anastasios
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> 
> iD8DBQFF9o+3TfUwC3N5Fj0RAigKAJ93HAQffUZc5oHInkl7osEy0jlAiACfVf4I
> MZCxkBOBRYskCL0CvyETB/8=
> =5jUP
> -----END PGP SIGNATURE-----
> 

Re: [OpenSwarm-users] Who wants to test setup for next release?

[Tryggvi B. <try...@hi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anastasios Hatzis wrote:
> Tryggvi Björgvinsson wrote:
>> 2. Create a debian package, install and run test cases
>>
> 
> That's great. I never used Debian, but have installed Kubuntu 6.10 this
> week-end at home.

Kubuntu is very similar to Debian (actually a derivative), uses the same
structure and the same package manager.

> Last night I tried to create a bdist RPM on openSUSE 10.0/64 with the
> same sdist (rev.#475) you used. At my first RPM creation attempt I
> failed, due to the missing MANIFEST.in file in the sdist. At least it
> worked after I created a new sdist including the MANIFEST.in file. Did
> you experience something similar?

No, I did not try to create an RPM, only a DEB package. The MANIFEST
file tells the package manager which files to include in the
distribution. I think you need to create the MANIFEST file yourself (or
use some tool to help you). I had to create the Makefile by myself.

>> * PostgreSQL: ``postgresql-8.1 postgresql-plpython-8.1``
>> * pgAdminIII: ``pgadmin3``
>> * mxDateTime: ``python2.4-egenix-mxdatetime`` (Already installed)
>> * pypgsql: ``python-pgsql`` (Already installed)
>> * pyxml: ``python2.4-xml`` (Already installed)
>>
> 
> I'm confident that the final release won't have some of these
> dependencies. But it's good to know that all required parts are
> available via APT.

I was sceptical that this would work, because PostgreSQL was required to
use openssl and thread-safety. But it seemed to be work, so no need to
worry (or maybe we need to create more test-cases).

>> Successfully installed OpenSwarm using: ``python setup.py install``
>>
> 
> 
> Did you do the installation as su?

Yes, sorry! This was supposed to say: ``sudo python setup.py install``

>> **$ sdk-edit.py --tips-hide** - Failed!::
>>
>>   Traceback (most recent call last):
>>     File "/usr/bin/sdk-edit.py", line 117, in ?
>>       ScriptHandler().readOpts()
>>     File "/usr/bin/sdk-edit.py", line 113, in readOpts
>>       consoleFormat=self.consoleFormat, logfile=self.logfile,
>> loglevel=self.logLevel, logname=self.logName, logformat=self.logFormat,
>> logtime=self.logTime)
>>     File
>> "/usr/lib/python2.4/site-packages/OpenSwarm/sdklib/cmd_sdk_edit.py",
>> line 118, in run
>>       sdk.save()
>>     File
>> "/usr/lib/python2.4/site-packages/OpenSwarm/sdklib/preferences.py", line
>> 184, in save
>>       oStream = codecs.open(OpenSwarm.SDK_INI_LOC, 'w',
>> OpenSwarm.SDK_UTF)
>>     File "/usr/lib/python2.4/codecs.py", line 666, in open
>>      file = __builtin__.open(filename, mode, buffering)
>>   IOError: [Errno 13] Permission denied:
>> u'/usr/lib/python2.4/site-packages/Open  Swarm/sdk.ini'
>>
> 
> Ouh, I will try to catch all permission denied errors and add a note to
> the doc to do the sdk edit as sudo. I guess this is normal in a default
> installation.

I believe this is normal. However, I think you're taking the wrong
approach with the sdk.ini file. I'll describe what I would consider the
correct approach later, which would not need super user privileges (sudo).

>> 3. Create a top level Makefile::
>>
>>      PACKAGE = openswarmsdk
>>      VERSION = 0.6.2
>>      PYTHON_BIN = /usr/bin/python
>>      INSTALL_BIN = /usr/bin/install -m0644
>>
>>      DEBFILES = \
>>          debian/changelog \
>>          debian/compat \
>>          debian/copyright \
>>          debian/control \
>>          debian/rules \
>>          debian/files \
>>
>>      EXTRA_DIST = \
>>          OpenSwarm/AUTHORS.TXT OpenSwarm/CHANGES.TXT \
>>          OpenSwarm/README.TXT OpenSwarm/LICENSE.TXT
>>
>>      DISTFILES = \
>>          Makefile $(DEBFILES) $(EXTRA_DIST)
>>
>>
>>      all: module
>>
>>      module:
>>              $(PYTHON_BIN) setup.py build
>>
>>      install: module
>>              $(PYTHON_BIN) setup.py install `test -n "$(DESTDIR)" &&
>> echo --root $(DESTDIR)`
>>
>>      clean:
>>              rm -fr build debian/openswarmsdk debian/DEBIAN
>> configure-stamp build-stamp *.pyc
>>
>>      distclean: realclean
>>              rm -f $(PACKAGE)-$(VERSION).tar.gz
>>
>>      dist:   mkdir -p $(PACKAGE)-$(VERSION)
>>              for file in $(DISTFILES); do \
>>                $(INSTALL_BIN) -D $$file $(PACKAGE)-$(VERSION)/$$file; \
>>              done
>>              tar czf $(PACKAGE)-$(VERSION).tar.gz $(PACKAGE)-$(VERSION)
>>              test -d $(PACKAGE)-$(VERSION) && rm -fr
>> $(PACKAGE)-$(VERSION)
>>
>>      deb:
>>              fakeroot dpkg-buildpackage
> 
> I guess, that Python 2.5 bdist_rpm on Debian would create the Makefile
> automatically by using the meta data eventually provided in a setup for
> this purpose,...? (I have almost no expertise with package management)

Yes, I believe you are correct, though the MANIFEST problem you
encountered can indicate problems which might come up with the Debian
bdist (FYI it is created using bdist_debian from what I've read)

>> * Fix spelling error in sdk-view.py: ``tipps`` -> ``tips``
>>
> 
> Done (I have always to pay attention on this word, in German it's
> written with double-p)

That's OK, just something I noticed since I was reading this particular
line.

>> * I do **not** like that the projects folder gets installed into
>> ``/usr``. I propose that it
>>   should not get installed at all, but should be easily accessible from
>> the project's website
>>   instead.
> 
> I understand. Originally I wanted the sdk.ini file to have automatically
> some option values modified to the appropriate path into which the
> "projects" data files are installed on a particular machine. However,
> this works now, but only with the default path for data_files of Python
> packages installed by distutils. On my openSUSE test installation the
> projects directory went by default to /usr/local/projects.
> 
> But users have the option to use alternate installation schemes, e.g.
> the home scheme or prefix scheme, e.g.
> 
>     /usr/bin/python setup.py install --prefix=/usr/local
> 
> or to override data-type files explicitely (which "projects" is):
> 
>     setup.py install install-data="/home/jane/projects"
> 
> in order to alter the location of the projects directory. See:
> http://www.python.org/doc/2.5/inst/alt-install-windows.html
> 
> One downside is that I have no idea how to tell setup that non-default
> path has been applied and which one it is. Therefor a user would need to
> change sdk.ini manually if using non-default path for data files.
> 
> Additionally, I noticed yesterday that software removal feature doesn't
> work on W32 as expected. It tries to remove also the projects directory,
> but only those files there that have been installed at the first place,
> not those files which have been added later.
> 
> Thus, I strongly tend to go with your suggestion and offer a seperate
> download file with the entire projects directory compressed.

I don't believe a global configuration file is the way to go. You have
to think about multiple users, all using the same instance of OpenSwarm.
They don't (at least I wouldn't) want to modify the same project files.
Therefore I recommend using the sdk.ini file as a per user configuration
file. I don't know how it's done on Windows (not my favourite platform),
but on GNU/Linux you would create a special folder or file, e.g.
".openswarm" in the users home directory. I think that would be a better
approach, I believe.

I do however, think that this discussion should be handled elsewhere
(for example openswarm-devs).

>>
>> * Rename OpenSwarmSDK-0.6.2-dev to openswarmsdk-0.6.2 to make deb
>> package creation simpler.
>>
> 
> OK
> 
>> * Most importantly, go through how Debian package was created in this
>> report and comment. The
>>   author has never created a Debian package nor Makefile before so it is
>> wise to get a comment
>>   from an experienced Debian packager.
> 
> OK.
> 
> Unfortunetaly I have no Debian box, but probably I can at least test it
> on my fresh Kubuntu installation as soon as I got its network access
> running? AFAIR, Kubuntu is a Debian-derivate...

That's correct. I am using gNewSense, which is an Ubuntu-derivative
which in turn is a Debian-derivative. That's why I created a Debian package.

>>
>> * Rename sdk-view.py and sdk-edit.py. These names are IMHO bad as they
>> do not indicate which
>>   software they belong to. A simple ``os-`` or ``openswarm-`` prefix
>> should do the trick. I
>>   would however find that a simple *frontend* program (e.g. openswarm)
>> should do the trick.
>>   This program would combine the four different programs which could be
>> executed as follows.
>>
>>   - sdk-view.py: openswarm --sdk --view
>>   - sdk-edit.py: openswarm --sdk --edit
>>   - osp-view.py: openswarm --view
>>   - osp-edit.py: openswarm --edit
>>
> 
> Yes, I had a similar idea at the first place, but came to the conclusion
> that it might make working with the commands very difficult if putting
> *everything* into one script. The reason is that I want to add a pretty
> portion of new features to OpenSwarm, especially regarding UML<->XMI and
> model-to-model transformations (the current lack of support of other UML
> CASE tools still bites me). And I have the feeling that it would be too
> much to put them all together in a single command-line script, including
> a confusing help text and an exploding options list ;)
> 
> Anyway, I agree that the names should indicate which software they
> belong to. It surely make sense to use a common prefix and I will change
> that.
> 
> In addition, probably it would be a good compromise to bundle some of
> the commands, (just the pattern, not the concrete names):
> 
>    - sdk-view.py:     openswarm-sdk --view
>    - sdk-edit.py:     openswarm-sdk --edit
>    - osp-view.py:     openswarm --view
>    - osp-edit.py:     openswarm --edit
>    - osp-generate.py: openswarm --generate
>    - (not yet):       openswarm-uml --pim
>    - startGUI.py:     openswarm-gui
> 
> What do you think about that?

That's better. I like yours more than mine actually (mine has
unnecessary many special options).

/Tryggvi

> Anastasios

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFF9o+3TfUwC3N5Fj0RAigKAJ93HAQffUZc5oHInkl7osEy0jlAiACfVf4I
MZCxkBOBRYskCL0CvyETB/8=
=5jUP
-----END PGP SIGNATURE-----

Re: [OpenSwarm-users] Who wants to test setup for next release?

[Anastasios H. <ah...@ha...>]

Tryggvi Björgvinsson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Anastasios Hatzis wrote:
>> Hi @all,
>>
>> I have changed OpenSwarm installation to distutils setup for the next 
>> release (0.6.2).
>>
>> Anybody here who wants to test if the new setup works on other OS than W32?
>>
>> I can provide source distribution (sdist) and a Windows installer 
>> (bdist_wininst). Would be great, if someone could try to install from 
>> sources or create a bdist for GNU/Linux or other platforms from sources.
>>
>> Anastasios
> 
> I've tested installing OpenSwarm on a GNU/Linux box. I even created a
> binary distribution for Debian based systems. However since I am using
> Python 2.4, I could not create the deb package with bdist (read on the
> web that it has been added in Python 2.5.
> 
> The installation was relatively painless, but I make some suggestions
> which should be taken as _suggestions_!
> 
> I created a report in reStructuredText format (so you can easily create
> a PDF version or whatever using docutils. It is pretty long. Hope you
> like it :)

Tryggvi,

many thanks for taking your time to run the tests and providing this 
report, which helps a lot. Hopefully it's okay, if I email-comment into 
your report :)

> 
> =============================
> OpenSwarm 0.6.2: Setup Report
> =============================
> 
> :Author: Tryggvi Björgvinsson <try...@hi...>
> 
> 
> General
> 
> The purpose of this setup was to try to install OpenSwarm on a gNewSense
> GNU/Linux system, with Python 2.4.3. The following two approaches were
> tested:
> 
> 1. Install directly from source, run test cases
> 2. Create a debian package, install and run test cases
> 

That's great. I never used Debian, but have installed Kubuntu 6.10 this 
week-end at home.

Last night I tried to create a bdist RPM on openSUSE 10.0/64 with the 
same sdist (rev.#475) you used. At my first RPM creation attempt I 
failed, due to the missing MANIFEST.in file in the sdist. At least it 
worked after I created a new sdist including the MANIFEST.in file. Did 
you experience something similar?

> 
> Setup
> 
> 3rd party software
> - ------------------
> 
> As OpenSwarm has not been installed on the test machine before, 3rd
> party software was installed first. Following packages were installed
> using ``APT``:
> 
> * PostgreSQL: ``postgresql-8.1 postgresql-plpython-8.1``
> * pgAdminIII: ``pgadmin3``
> * mxDateTime: ``python2.4-egenix-mxdatetime`` (Already installed)
> * pypgsql: ``python-pgsql`` (Already installed)
> * pyxml: ``python2.4-xml`` (Already installed)
> 

I'm confident that the final release won't have some of these 
dependencies. But it's good to know that all required parts are 
available via APT.

> 
> OpenSwarm Sources
> - -----------------
> 
> Installation
> ............
> 
> Successfully installed OpenSwarm using: ``python setup.py install``
> 


Did you do the installation as su?


> Testing
> .......
> 
> **$ sdk-view.py** - Success!::
> 
>   OpenSwarm SDK Preferences
> 
>   Loaded from INI: /usr/lib/python2.4/site-packages/OpenSwarm/sdk.ini
> 
>   GUI
>   Default *.osp directory   : /usr/projects
>   Default apps directory    : /usr/projects
>   Default *.xml directory   : /usr/projects
>   Show tipps on GUI start-up: True
> 
>   LOGFILE
>   Log-file activated    : True
>   Default log-file      : /usr/projects/logs/generation.log
>   Default log-file level: DEBUG
>   Default log format    : %(asctime)s %(name)-10s %(levelname)-8s
> %(message)s
>   Default log timestamp : %y-%m-%d %H:%M:%S
> 
>   CONSOLE
>   Console logging format : %(name)-10s: %(levelname)-8s %(message)s
> 
> 
> **$ sdk-edit.py --tips-hide** - Failed!::
> 
>   Traceback (most recent call last):
>     File "/usr/bin/sdk-edit.py", line 117, in ?
>       ScriptHandler().readOpts()
>     File "/usr/bin/sdk-edit.py", line 113, in readOpts
>       consoleFormat=self.consoleFormat, logfile=self.logfile,
> loglevel=self.logLevel, logname=self.logName, logformat=self.logFormat,
> logtime=self.logTime)
>     File
> "/usr/lib/python2.4/site-packages/OpenSwarm/sdklib/cmd_sdk_edit.py",
> line 118, in run
>       sdk.save()
>     File
> "/usr/lib/python2.4/site-packages/OpenSwarm/sdklib/preferences.py", line
> 184, in save
>       oStream = codecs.open(OpenSwarm.SDK_INI_LOC, 'w', OpenSwarm.SDK_UTF)
>     File "/usr/lib/python2.4/codecs.py", line 666, in open
>      file = __builtin__.open(filename, mode, buffering)
>   IOError: [Errno 13] Permission denied:
> u'/usr/lib/python2.4/site-packages/Open  Swarm/sdk.ini'
> 

Ouh, I will try to catch all permission denied errors and add a note to 
the doc to do the sdk edit as sudo. I guess this is normal in a default 
installation.

> 
> **$ sudo sdk-edit.py --tips-hide** - Success!::
> 
>   OpenSwarm SDK Preferences
> 
>   Loaded from INI: /usr/lib/python2.4/site-packages/OpenSwarm/sdk.ini
> 
>   GUI
>   Default *.osp directory   : /usr/projects
>   Default apps directory    : /usr/projects
>   Default *.xml directory   : /usr/projects
>   Show tipps on GUI start-up: False
> 
>   LOGFILE
>   Log-file activated    : True
>   Default log-file      : /usr/projects/logs/generation.log
>   Default log-file level: DEBUG
>   Default log format    : %(asctime)s %(name)-10s %(levelname)-8s
> %(message)s
>   Default log timestamp : %y-%m-%d %H:%M:%S
> 
>   CONSOLE
>   Console logging format : %(name)-10s: %(levelname)-8s %(message)s
> 
> 
> **$ osp-view.py /usr/projects/test1.osp** - Success!::
> 
>   OpenSwarm Project Settings
> 
>   OSP file     : /usr/projects/test1.osp
>   OSP version  : 0.6.2-dev
>   Last changed : 2007-03-05 15:08:04
>   OSP generator: OpenSwarm SDK 0.6.2-dev
> 
>   Project name :
> 
>   XMI: D:\OpenSwarm\SVN\src\patterns\models\PetStore\PetStore.xml
>   Application  :
> 
>   Console logging
>   Format       : None
> 
>   Log-file configuration
>   Activated    : True
>   Location     : None
>   Log-level    : None
>   Record format: None
>   Time format  : None
> 
> 
> **$ osp-edit.py /usr/projects/test1.osp -n** - Success!::
> 
>   OpenSwarm Project Settings
> 
>   OSP file     : /usr/projects/test1.osp
>   OSP version  : 0.6.2-dev
>   Last changed : 2007-03-12 12:49:36
>   OSP generator: OpenSwarm SDK 0.6.2-dev
> 
>   Project name :
> 
>   XMI: D:\OpenSwarm\SVN\src\patterns\models\PetStore\PetStore.xml
>   Application  :
> 
>   Console logging
>   Format       : None
> 
>   Log-file configuration
>   Activated    : False
>   Location     : None
>   Log-level    : None
>   Record format: None
>   Time format  : None
> 
> 
> Debian binary file
> - ------------------
> 
> 
> Creation
> ........
> 
> The following steps were needed to create a debian binary package:
> 
> 1. Rename directory from OpenSwarmSDK-0.6.2-dev to openswarmsdk-0.6.2
> 
> 2. ``$ dh_make -n -s -e try...@hi...``::
> 
>      Maintainer name : Tryggvi Björgvinsson
>      Email-Address   : try...@hi...
>      Date            : Mon, 12 Mar 2007 13:25:51 +0000
>      Package Name    : openswarmsdk
>      Version         : 0.6.2
>      License         : blank
>      Type of Package : Single
>      Hit <enter> to confirm:
>      Currently there is no top level Makefile. This may require
> additional tuning.
>      Done. Please edit the files in the debian/ subdirectory now. You
> should also
>      check that the openswarmsdk Makefiles install into $DESTDIR and not
> in / .
> 
> 3. Create a top level Makefile::
> 
>      PACKAGE = openswarmsdk
>      VERSION = 0.6.2
>      PYTHON_BIN = /usr/bin/python
>      INSTALL_BIN = /usr/bin/install -m0644
> 
>      DEBFILES = \
>          debian/changelog \
>          debian/compat \
>          debian/copyright \
>          debian/control \
>          debian/rules \
>          debian/files \
> 
>      EXTRA_DIST = \
>          OpenSwarm/AUTHORS.TXT OpenSwarm/CHANGES.TXT \
>          OpenSwarm/README.TXT OpenSwarm/LICENSE.TXT
> 
>      DISTFILES = \
>          Makefile $(DEBFILES) $(EXTRA_DIST)
> 
> 
>      all: module
> 
>      module:
>              $(PYTHON_BIN) setup.py build
> 
>      install: module
>              $(PYTHON_BIN) setup.py install `test -n "$(DESTDIR)" &&
> echo --root $(DESTDIR)`
> 
>      clean:
>              rm -fr build debian/openswarmsdk debian/DEBIAN
> configure-stamp build-stamp *.pyc
> 
>      distclean: realclean
>              rm -f $(PACKAGE)-$(VERSION).tar.gz
> 
>      dist:   mkdir -p $(PACKAGE)-$(VERSION)
>              for file in $(DISTFILES); do \
>                $(INSTALL_BIN) -D $$file $(PACKAGE)-$(VERSION)/$$file; \
>              done
>              tar czf $(PACKAGE)-$(VERSION).tar.gz $(PACKAGE)-$(VERSION)
>              test -d $(PACKAGE)-$(VERSION) && rm -fr $(PACKAGE)-$(VERSION)
> 
>      deb:
>              fakeroot dpkg-buildpackage

I guess, that Python 2.5 bdist_rpm on Debian would create the Makefile 
automatically by using the meta data eventually provided in a setup for 
this purpose,...? (I have almost no expertise with package management)

> 
> 4. ``rm debian/*.ex debian/*.EX``
> 
> 5. Modify ``debian/control`` and ``debian/copyright``
> 
> 6. ``$ fakeroot debian/rules clean``
> 
> 7. ``debian/rules build``
> 
> 8. ``fakeroot debian/rules binary``
> 
> 
> Installation
> ............
> 
> Successfully installed OpenSwarm using: ``$ sudo dpkg -i
> openswarmsdk_0.6.2_i386.deb``
> 
> 
> Testing
> .......
> 
> 
> **$ sdk-view.py** - Success!::
> 
>   OpenSwarm SDK Preferences
> 
>   Loaded from INI: /usr/lib/python2.4/site-packages/OpenSwarm/sdk.ini
> 
>   GUI
>   Default *.osp directory   : /usr/projects
>   Default apps directory    : /usr/projects
>   Default *.xml directory   : /usr/projects
>   Show tipps on GUI start-up: True
> 
>   LOGFILE
>   Log-file activated    : True
>   Default log-file      : /usr/projects/logs/generation.log
>   Default log-file level: DEBUG
>   Default log format    : %(asctime)s %(name)-10s %(levelname)-8s
> %(message)s
>   Default log timestamp : %y-%m-%d %H:%M:%S
> 
>   CONSOLE
>   Console logging format : %(name)-10s: %(levelname)-8s %(message)s
> 
> 
> **$ sudo sdk-edit.py --tips-hide** - Success!::
> 
>   OpenSwarm SDK Preferences
> 
>   Loaded from INI: /usr/lib/python2.4/site-packages/OpenSwarm/sdk.ini
> 
>   GUI
>   Default *.osp directory   : /usr/projects
>   Default apps directory    : /usr/projects
>   Default *.xml directory   : /usr/projects
>   Show tipps on GUI start-up: False
> 
>   LOGFILE
>   Log-file activated    : True
>   Default log-file      : /usr/projects/logs/generation.log
>   Default log-file level: DEBUG
>   Default log format    : %(asctime)s %(name)-10s %(levelname)-8s
> %(message)s
>   Default log timestamp : %y-%m-%d %H:%M:%S
> 
>   CONSOLE
>   Console logging format : %(name)-10s: %(levelname)-8s %(message)s
> 
> 
> **$ osp-view.py /usr/projects/test1.osp** - Success!::
> 
>   OpenSwarm Project Settings
> 
>   OSP file     : /usr/projects/test1.osp
>   OSP version  : 0.6.2-dev
>   Last changed : 2007-03-05 15:08:04
>   OSP generator: OpenSwarm SDK 0.6.2-dev
> 
>   Project name :
> 
>   XMI: D:\OpenSwarm\SVN\src\patterns\models\PetStore\PetStore.xml
>   Application  :
> 
>   Console logging
>   Format       : None
> 
>   Log-file configuration
>   Activated    : True
>   Location     : None
>   Log-level    : None
>   Record format: None
>   Time format  : None
> 
> 
> **$ osp-edit.py /usr/projects/test1.osp -n** - Success!::
> 
>   OpenSwarm Project Settings
> 
>   OSP file     : /usr/projects/test1.osp
>   OSP version  : 0.6.2-dev
>   Last changed : 2007-03-12 12:49:36
>   OSP generator: OpenSwarm SDK 0.6.2-dev
> 
>   Project name :
> 
>   XMI: D:\OpenSwarm\SVN\src\patterns\models\PetStore\PetStore.xml
>   Application  :
> 
>   Console logging
>   Format       : None
> 
>   Log-file configuration
>   Activated    : False
>   Location     : None
>   Log-level    : None
>   Record format: None
>   Time format  : None
> 
> Proposed TODO list
> 
> - From the setup test, I propose a short TODO list below. Please take the
> list as a suggestions.

Thank you very much, I appreciate your suggestions. In general, I 
consider any suggestion and comment I get is a good chance to improve 
OpenSwarm.

> 
> * Fix spelling error in sdk-view.py: ``tipps`` -> ``tips``
> 

Done (I have always to pay attention on this word, in German it's 
written with double-p)

> * I do **not** like that the projects folder gets installed into
> ``/usr``. I propose that it
>   should not get installed at all, but should be easily accessible from
> the project's website
>   instead.

I understand. Originally I wanted the sdk.ini file to have automatically 
some option values modified to the appropriate path into which the 
"projects" data files are installed on a particular machine. However, 
this works now, but only with the default path for data_files of Python 
packages installed by distutils. On my openSUSE test installation the 
projects directory went by default to /usr/local/projects.

But users have the option to use alternate installation schemes, e.g. 
the home scheme or prefix scheme, e.g.

     /usr/bin/python setup.py install --prefix=/usr/local

or to override data-type files explicitely (which "projects" is):

     setup.py install install-data="/home/jane/projects"

in order to alter the location of the projects directory. See: 
http://www.python.org/doc/2.5/inst/alt-install-windows.html

One downside is that I have no idea how to tell setup that non-default 
path has been applied and which one it is. Therefor a user would need to 
change sdk.ini manually if using non-default path for data files.

Additionally, I noticed yesterday that software removal feature doesn't 
work on W32 as expected. It tries to remove also the projects directory, 
but only those files there that have been installed at the first place, 
not those files which have been added later.

Thus, I strongly tend to go with your suggestion and offer a seperate 
download file with the entire projects directory compressed.

> 
> * Rename OpenSwarmSDK-0.6.2-dev to openswarmsdk-0.6.2 to make deb
> package creation simpler.
> 

OK

> * Most importantly, go through how Debian package was created in this
> report and comment. The
>   author has never created a Debian package nor Makefile before so it is
> wise to get a comment
>   from an experienced Debian packager.

OK.

Unfortunetaly I have no Debian box, but probably I can at least test it 
on my fresh Kubuntu installation as soon as I got its network access 
running? AFAIR, Kubuntu is a Debian-derivate...


> 
> * Rename sdk-view.py and sdk-edit.py. These names are IMHO bad as they
> do not indicate which
>   software they belong to. A simple ``os-`` or ``openswarm-`` prefix
> should do the trick. I
>   would however find that a simple *frontend* program (e.g. openswarm)
> should do the trick.
>   This program would combine the four different programs which could be
> executed as follows.
> 
>   - sdk-view.py: openswarm --sdk --view
>   - sdk-edit.py: openswarm --sdk --edit
>   - osp-view.py: openswarm --view
>   - osp-edit.py: openswarm --edit
> 

Yes, I had a similar idea at the first place, but came to the conclusion 
that it might make working with the commands very difficult if putting 
*everything* into one script. The reason is that I want to add a pretty 
portion of new features to OpenSwarm, especially regarding UML<->XMI and 
model-to-model transformations (the current lack of support of other UML 
CASE tools still bites me). And I have the feeling that it would be too 
much to put them all together in a single command-line script, including 
a confusing help text and an exploding options list ;)

Anyway, I agree that the names should indicate which software they 
belong to. It surely make sense to use a common prefix and I will change 
that.

In addition, probably it would be a good compromise to bundle some of 
the commands, (just the pattern, not the concrete names):

    - sdk-view.py:     openswarm-sdk --view
    - sdk-edit.py:     openswarm-sdk --edit
    - osp-view.py:     openswarm --view
    - osp-edit.py:     openswarm --edit
    - osp-generate.py: openswarm --generate
    - (not yet):       openswarm-uml --pim
    - startGUI.py:     openswarm-gui

What do you think about that?

Anastasios

Re: [OpenSwarm-users] Who wants to test setup for next release?

[Tryggvi B. <try...@hi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anastasios Hatzis wrote:
> Hi @all,
> 
> I have changed OpenSwarm installation to distutils setup for the next 
> release (0.6.2).
> 
> Anybody here who wants to test if the new setup works on other OS than W32?
> 
> I can provide source distribution (sdist) and a Windows installer 
> (bdist_wininst). Would be great, if someone could try to install from 
> sources or create a bdist for GNU/Linux or other platforms from sources.
> 
> Anastasios

I've tested installing OpenSwarm on a GNU/Linux box. I even created a
binary distribution for Debian based systems. However since I am using
Python 2.4, I could not create the deb package with bdist (read on the
web that it has been added in Python 2.5.

The installation was relatively painless, but I make some suggestions
which should be taken as _suggestions_!

I created a report in reStructuredText format (so you can easily create
a PDF version or whatever using docutils. It is pretty long. Hope you
like it :)

=============================
OpenSwarm 0.6.2: Setup Report
=============================

:Author: Tryggvi Björgvinsson <try...@hi...>


General
>>>>>>>

The purpose of this setup was to try to install OpenSwarm on a gNewSense
GNU/Linux system, with Python 2.4.3. The following two approaches were
tested:

1. Install directly from source, run test cases
2. Create a debian package, install and run test cases


Setup
>>>>>

3rd party software
- ------------------

As OpenSwarm has not been installed on the test machine before, 3rd
party software was installed first. Following packages were installed
using ``APT``:

* PostgreSQL: ``postgresql-8.1 postgresql-plpython-8.1``
* pgAdminIII: ``pgadmin3``
* mxDateTime: ``python2.4-egenix-mxdatetime`` (Already installed)
* pypgsql: ``python-pgsql`` (Already installed)
* pyxml: ``python2.4-xml`` (Already installed)


OpenSwarm Sources
- -----------------

Installation
............

Successfully installed OpenSwarm using: ``python setup.py install``

Testing
.......

**$ sdk-view.py** - Success!::

  OpenSwarm SDK Preferences

  Loaded from INI: /usr/lib/python2.4/site-packages/OpenSwarm/sdk.ini

  GUI
  Default *.osp directory   : /usr/projects
  Default apps directory    : /usr/projects
  Default *.xml directory   : /usr/projects
  Show tipps on GUI start-up: True

  LOGFILE
  Log-file activated    : True
  Default log-file      : /usr/projects/logs/generation.log
  Default log-file level: DEBUG
  Default log format    : %(asctime)s %(name)-10s %(levelname)-8s
%(message)s
  Default log timestamp : %y-%m-%d %H:%M:%S

  CONSOLE
  Console logging format : %(name)-10s: %(levelname)-8s %(message)s


**$ sdk-edit.py --tips-hide** - Failed!::

  Traceback (most recent call last):
    File "/usr/bin/sdk-edit.py", line 117, in ?
      ScriptHandler().readOpts()
    File "/usr/bin/sdk-edit.py", line 113, in readOpts
      consoleFormat=self.consoleFormat, logfile=self.logfile,
loglevel=self.logLevel, logname=self.logName, logformat=self.logFormat,
logtime=self.logTime)
    File
"/usr/lib/python2.4/site-packages/OpenSwarm/sdklib/cmd_sdk_edit.py",
line 118, in run
      sdk.save()
    File
"/usr/lib/python2.4/site-packages/OpenSwarm/sdklib/preferences.py", line
184, in save
      oStream = codecs.open(OpenSwarm.SDK_INI_LOC, 'w', OpenSwarm.SDK_UTF)
    File "/usr/lib/python2.4/codecs.py", line 666, in open
     file = __builtin__.open(filename, mode, buffering)
  IOError: [Errno 13] Permission denied:
u'/usr/lib/python2.4/site-packages/Open  Swarm/sdk.ini'


**$ sudo sdk-edit.py --tips-hide** - Success!::

  OpenSwarm SDK Preferences

  Loaded from INI: /usr/lib/python2.4/site-packages/OpenSwarm/sdk.ini

  GUI
  Default *.osp directory   : /usr/projects
  Default apps directory    : /usr/projects
  Default *.xml directory   : /usr/projects
  Show tipps on GUI start-up: False

  LOGFILE
  Log-file activated    : True
  Default log-file      : /usr/projects/logs/generation.log
  Default log-file level: DEBUG
  Default log format    : %(asctime)s %(name)-10s %(levelname)-8s
%(message)s
  Default log timestamp : %y-%m-%d %H:%M:%S

  CONSOLE
  Console logging format : %(name)-10s: %(levelname)-8s %(message)s


**$ osp-view.py /usr/projects/test1.osp** - Success!::

  OpenSwarm Project Settings

  OSP file     : /usr/projects/test1.osp
  OSP version  : 0.6.2-dev
  Last changed : 2007-03-05 15:08:04
  OSP generator: OpenSwarm SDK 0.6.2-dev

  Project name :

  XMI: D:\OpenSwarm\SVN\src\patterns\models\PetStore\PetStore.xml
  Application  :

  Console logging
  Format       : None

  Log-file configuration
  Activated    : True
  Location     : None
  Log-level    : None
  Record format: None
  Time format  : None


**$ osp-edit.py /usr/projects/test1.osp -n** - Success!::

  OpenSwarm Project Settings

  OSP file     : /usr/projects/test1.osp
  OSP version  : 0.6.2-dev
  Last changed : 2007-03-12 12:49:36
  OSP generator: OpenSwarm SDK 0.6.2-dev

  Project name :

  XMI: D:\OpenSwarm\SVN\src\patterns\models\PetStore\PetStore.xml
  Application  :

  Console logging
  Format       : None

  Log-file configuration
  Activated    : False
  Location     : None
  Log-level    : None
  Record format: None
  Time format  : None


Debian binary file
- ------------------


Creation
........

The following steps were needed to create a debian binary package:

1. Rename directory from OpenSwarmSDK-0.6.2-dev to openswarmsdk-0.6.2

2. ``$ dh_make -n -s -e try...@hi...``::

     Maintainer name : Tryggvi Björgvinsson
     Email-Address   : try...@hi...
     Date            : Mon, 12 Mar 2007 13:25:51 +0000
     Package Name    : openswarmsdk
     Version         : 0.6.2
     License         : blank
     Type of Package : Single
     Hit <enter> to confirm:
     Currently there is no top level Makefile. This may require
additional tuning.
     Done. Please edit the files in the debian/ subdirectory now. You
should also
     check that the openswarmsdk Makefiles install into $DESTDIR and not
in / .

3. Create a top level Makefile::

     PACKAGE = openswarmsdk
     VERSION = 0.6.2
     PYTHON_BIN = /usr/bin/python
     INSTALL_BIN = /usr/bin/install -m0644

     DEBFILES = \
         debian/changelog \
         debian/compat \
         debian/copyright \
         debian/control \
         debian/rules \
         debian/files \

     EXTRA_DIST = \
         OpenSwarm/AUTHORS.TXT OpenSwarm/CHANGES.TXT \
         OpenSwarm/README.TXT OpenSwarm/LICENSE.TXT

     DISTFILES = \
         Makefile $(DEBFILES) $(EXTRA_DIST)


     all: module

     module:
             $(PYTHON_BIN) setup.py build

     install: module
             $(PYTHON_BIN) setup.py install `test -n "$(DESTDIR)" &&
echo --root $(DESTDIR)`

     clean:
             rm -fr build debian/openswarmsdk debian/DEBIAN
configure-stamp build-stamp *.pyc

     distclean: realclean
             rm -f $(PACKAGE)-$(VERSION).tar.gz

     dist:   mkdir -p $(PACKAGE)-$(VERSION)
             for file in $(DISTFILES); do \
               $(INSTALL_BIN) -D $$file $(PACKAGE)-$(VERSION)/$$file; \
             done
             tar czf $(PACKAGE)-$(VERSION).tar.gz $(PACKAGE)-$(VERSION)
             test -d $(PACKAGE)-$(VERSION) && rm -fr $(PACKAGE)-$(VERSION)

     deb:
             fakeroot dpkg-buildpackage

4. ``rm debian/*.ex debian/*.EX``

5. Modify ``debian/control`` and ``debian/copyright``

6. ``$ fakeroot debian/rules clean``

7. ``debian/rules build``

8. ``fakeroot debian/rules binary``


Installation
............

Successfully installed OpenSwarm using: ``$ sudo dpkg -i
openswarmsdk_0.6.2_i386.deb``


Testing
.......


**$ sdk-view.py** - Success!::

  OpenSwarm SDK Preferences

  Loaded from INI: /usr/lib/python2.4/site-packages/OpenSwarm/sdk.ini

  GUI
  Default *.osp directory   : /usr/projects
  Default apps directory    : /usr/projects
  Default *.xml directory   : /usr/projects
  Show tipps on GUI start-up: True

  LOGFILE
  Log-file activated    : True
  Default log-file      : /usr/projects/logs/generation.log
  Default log-file level: DEBUG
  Default log format    : %(asctime)s %(name)-10s %(levelname)-8s
%(message)s
  Default log timestamp : %y-%m-%d %H:%M:%S

  CONSOLE
  Console logging format : %(name)-10s: %(levelname)-8s %(message)s


**$ sudo sdk-edit.py --tips-hide** - Success!::

  OpenSwarm SDK Preferences

  Loaded from INI: /usr/lib/python2.4/site-packages/OpenSwarm/sdk.ini

  GUI
  Default *.osp directory   : /usr/projects
  Default apps directory    : /usr/projects
  Default *.xml directory   : /usr/projects
  Show tipps on GUI start-up: False

  LOGFILE
  Log-file activated    : True
  Default log-file      : /usr/projects/logs/generation.log
  Default log-file level: DEBUG
  Default log format    : %(asctime)s %(name)-10s %(levelname)-8s
%(message)s
  Default log timestamp : %y-%m-%d %H:%M:%S

  CONSOLE
  Console logging format : %(name)-10s: %(levelname)-8s %(message)s


**$ osp-view.py /usr/projects/test1.osp** - Success!::

  OpenSwarm Project Settings

  OSP file     : /usr/projects/test1.osp
  OSP version  : 0.6.2-dev
  Last changed : 2007-03-05 15:08:04
  OSP generator: OpenSwarm SDK 0.6.2-dev

  Project name :

  XMI: D:\OpenSwarm\SVN\src\patterns\models\PetStore\PetStore.xml
  Application  :

  Console logging
  Format       : None

  Log-file configuration
  Activated    : True
  Location     : None
  Log-level    : None
  Record format: None
  Time format  : None


**$ osp-edit.py /usr/projects/test1.osp -n** - Success!::

  OpenSwarm Project Settings

  OSP file     : /usr/projects/test1.osp
  OSP version  : 0.6.2-dev
  Last changed : 2007-03-12 12:49:36
  OSP generator: OpenSwarm SDK 0.6.2-dev

  Project name :

  XMI: D:\OpenSwarm\SVN\src\patterns\models\PetStore\PetStore.xml
  Application  :

  Console logging
  Format       : None

  Log-file configuration
  Activated    : False
  Location     : None
  Log-level    : None
  Record format: None
  Time format  : None

Proposed TODO list
>>>>>>>>>>>>>>>>>>

- From the setup test, I propose a short TODO list below. Please take the
list as a suggestions.

* Fix spelling error in sdk-view.py: ``tipps`` -> ``tips``

* I do **not** like that the projects folder gets installed into
``/usr``. I propose that it
  should not get installed at all, but should be easily accessible from
the project's website
  instead.

* Rename OpenSwarmSDK-0.6.2-dev to openswarmsdk-0.6.2 to make deb
package creation simpler.

* Most importantly, go through how Debian package was created in this
report and comment. The
  author has never created a Debian package nor Makefile before so it is
wise to get a comment
  from an experienced Debian packager.

* Rename sdk-view.py and sdk-edit.py. These names are IMHO bad as they
do not indicate which
  software they belong to. A simple ``os-`` or ``openswarm-`` prefix
should do the trick. I
  would however find that a simple *frontend* program (e.g. openswarm)
should do the trick.
  This program would combine the four different programs which could be
executed as follows.

  - sdk-view.py: openswarm --sdk --view
  - sdk-edit.py: openswarm --sdk --edit
  - osp-view.py: openswarm --view
  - osp-edit.py: openswarm --edit


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFF9Y7QTfUwC3N5Fj0RAvw3AJ9lW1QtAtMRsu36UCTYTAzK4w4ovwCgyKdJ
Bis0/xmHRxHI3RZOM5AJZ1k=
=YExF
-----END PGP SIGNATURE-----

Re: [OpenSwarm-users] Who wants to test setup for next release?

[Anastasios H. <ah...@ha...>]

Tryggvi Björgvinsson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Anastasios Hatzis wrote:
>> Hi @all,
>>
>> I have changed OpenSwarm installation to distutils setup for the
>> next release (0.6.2).
>>
>> Anybody here who wants to test if the new setup works on other OS
>> than W32?
>>
>> I can provide source distribution (sdist) and a Windows installer
>> (bdist_wininst). Would be great, if someone could try to install
>> from sources or create a bdist for GNU/Linux or other platforms
>> from sources.
>>
>> Anastasios
> I can try, even though I'm pretty swamped with work (who isn't).
> 

Tryggvi,
thank you for helping. The same here, but it got better --or I just get 
used to it. ;) If you already have the required 3rd-party tools 
installed, this test should go fast.

You can download the sdist zip-file here:
http://openswarm.svn.sourceforge.net/viewvc/openswarm/branches/intermediate/0.6.2/dist/

The W32-installer is also there, in case you want to test that.

I'm still working to update the documentation. However, following a 
summary regarding installation, four test-cases, and how to de-install 
OpenSwarm after that:

GETTING PREPARED:
If you have already installed prior OpenSwarm version, you hopefully 
still have all required 3rd-party software on that computer. Otherwise 
you need to read the installation manual, but this will need time, 
sorry: http://openswarm.sourceforge.net/doc/recent/install-base.html

IMPORTANT: Remove all prior OpenSwarm packages you have, in particular: 
by default in site-packages, the packages "OpenSwarm", "serve", and 
"shared", as well as the OpenSwarm.pth file in site-packages.


INSTALLATION:
W32-installer: Execute and walk through. Nothing special here.

sdist: Unzip. The file of interest is setup.py. Create a bdist in 
command-line, e.g.
$ python setup.py bdist_wininst
   -or-
$ python setup.py bdist_rpm
   -or-
$ python setup.py bdist --formats=rpm

Or directly install from the sources to your local machine:
$ python setup.py install
(AFAIK, installing from sdist excludes auto-removal feature of the 
operating system)


INSTALLED DIRS:
These two directories are created by default:
OpenSwarm:
     the full package, by default into the site-packages

projects:
     a data file directory, with some work samples and the master file,
by default directly in Python directory (and skd.ini is configured this 
way. You may need to edit sdk.ini to tweak options to your actual path.

And this directory gets some py files added:
Scripts:
     a copy of all eight (8) command scripts of OpenSwarm SDK, by 
default in the Python/Scripts directory: osp-*.py, sdk-*.py, startGUI.py
Eventually with according .pyc and .pyo files.


TEST-CASES:
After installation, just call some of them as following (all of them do 
support option --help or -h):

(A)
$ sdk-view.py
     should print current sdk.ini configuration. (If OK: executable 
script; sdk.ini found, OpenSwarm package found)

(B)
$ sdk-edit.py --tips-hide
     should change the "tips_show" option in sdk.ini to "False". If OK: 
same as in (A), plus: write access to sdk.ini

(C)
$ osp-view.py OSPFILE
    OSPFILE (such as test1.osp) is in the projects directory. By 
default: ../projects/test1.osp
Prints configuration of the sample project file, likely with paths not 
appropriate for you. If OK: as in (A), plus: read access to projects 
directory

(D)
$ osp-edit.py OSPFILE -n
    same as before. the "-n" option changes configuration in project 
file If OK: as in (C), plus: write access to project files

No need to check Scripts/startGUI.py. Although it should run without 
errors, it is still incomplete and will not be part of the next release. 
However, it reqires wxPython 2.8.

REMOVAL:
If you have used a bdist for installation, you should have an 
comfortable way to de-install the entire program automagically. If this 
is not given, just manually remove the two directories that have been 
created ("OpenSwarm", "projects") and the 8 command scripts (.py, .pyc, 
.pyo) in "Scripts" (not the entire Scripts directory, which belongs to 
Python itself).


I'm looking forward to learn your test results. If you have any 
questions or you do experience any difficulties, I would be glad to help.

Thanks again,
Anastasios

Re: [OpenSwarm-users] Who wants to test setup for next release?

[Tryggvi B. <try...@hi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anastasios Hatzis wrote:
> Hi @all,
>
> I have changed OpenSwarm installation to distutils setup for the
> next release (0.6.2).
>
> Anybody here who wants to test if the new setup works on other OS
> than W32?
>
> I can provide source distribution (sdist) and a Windows installer
> (bdist_wininst). Would be great, if someone could try to install
> from sources or create a bdist for GNU/Linux or other platforms
> from sources.
>
> Anastasios
I can try, even though I'm pretty swamped with work (who isn't).

/Tryggvi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF7/5yTfUwC3N5Fj0RAn7DAJ4n/1x0dZaAJnZY6eyfEvyIGO1O3QCg0zI6
buUGceCP4Q8Nykml+dTasTI=
=wEPH
-----END PGP SIGNATURE-----

[OpenSwarm-users] Who wants to test setup for next release?

[Anastasios H. <ah...@ha...>]

Hi @all,

I have changed OpenSwarm installation to distutils setup for the next 
release (0.6.2).

Anybody here who wants to test if the new setup works on other OS than W32?

I can provide source distribution (sdist) and a Windows installer 
(bdist_wininst). Would be great, if someone could try to install from 
sources or create a bdist for GNU/Linux or other platforms from sources.

Anastasios

[OpenSwarm-users] The license of your choice

[Anastasios H. <ah...@ha...>]

Hi @all,

as you likely have noticed, OpenSwarm sources are currently published 
under the GNU GPL, including the runtime libraries and the code-templates.


I would like to learn which licenses you would choose for your own 
applications you could build with an OpenSwarm 1.0 tool (or other 
software tools).

I guess, you would appreciate if you would have as less restrictions as 
possible in the choice of your application license, right? Or would you 
want to use, as example, the GPL for legally easier exchange of 
components between projects?

Anastasios

[OpenSwarm-users] User-interfaces & transactions

[Anastasios H. <ah...@ha...>]

Hi,

last two weeks at work were tough ones. I had less time as usual to work 
on the next release. Hopefully I can finish it in February and that 
OpenSwarm's usability will be improved significantly (including the 
graphical user-interface for the SDK and easier installation procedures 
for the SDK itself, as well as for the generated apps).

Beside that I started to think of the address management example covered 
by the newbie tutorial. IMO this AdM would be also a nice example when 
considering the user-interface components of OpenSwarm apps. Addresses 
are a widely known domain and I guess anyone has already coded the one 
or other addressbook software :)

While thinking about user-interfaces for OpenSwarm apps yesterday, I had 
some ideas for the UI concept (e.g. having notebooks/tabs for each 
object detail view, virtual files containing objects and notes on them), 
as I came to the question how the transaction concept could be supported 
by an UI. This, of course, is not just a technical issue, but much more 
it is an issue of good usability.

I put some background information here:
http://openswarm.blogspot.com/2007/02/transactions-in-user-interfaces.html

Probably you have any suggestions or comments, how to get this done in 
an elegant way.

Thank you.

Anastasios

Re: [OpenSwarm-users] SDK with GUI

[Anastasios H. <ah...@ha...>]

Since changing the menu structure should not be a problem, I want in the 
dummy to go with a hierarchy as described below. Suggestions are welcome 
for different hierarchy and/or labeling.

(The numbers in brackets are related to the use cases in my OP)

File
    New Project	[1]
    New Project Wizard [1]
    Open [6]
    Save [3]
    Save As... [4]
    Close [5]
    -----
    My project [7]
    ..... recently opend project names, repeats, e.g. up to 5 entries)
    -----
    Exit [11]

Project
    Project Settings [2]
    Generate Application [9]
Options
    SDK Preferences [8]
    Check for Updates [new]
Help [10]
    Welcome
    Help Contents
    Getting Support
    License (Code)
    License (Documentation)
    About

Anastasios

[OpenSwarm-users] SDK with GUI

[Anastasios H. <ah...@ha...>]

I suggest to go with the SDK GUI as a small finger exercise for the work 
on generated UIs in custom OpenSwarm apps :-)

In my opinion primary purpose of the SDK GUI is to ease the 
cross-platform usage of the generator particularily for first-time 
users. In the best case only Python installation is needed (no 
PostgreSQL whatever) just to be able to generate an application. Of 
course running an application with-out anything else is unlikely to 
happen :-)


As following some ideas for a minimalistic SDK GUI:

(1) User is creating a new project, includes initial specification of:
- place to store project file (*.osp)
- project name
- XMI file which contains a custom OpenSwarm application model (*.xml)
- output directory (place where generated app code is stored)

(probably with step by step guided by a "new project assistant"?)


(2) User is changing settings of a project:
- project name
- XMI file
- output directory


(3) User is saving recent changes in a project


(4) User saves project as new project
- place to store project file
- project name
- XMI file which contains a custom OpenSwarm application model
- output directory (place where generated app code is stored)


(5) User is closing a project
(prior check if there is a project opened already and if this current 
project is "dirty" = changes in project settings since last save)


(6) User is opening a project
(prior check if there is a project opened already and if this current 
project is "dirty" = changes in project settings since last save)
- select project file


(7) User is opening a recently opened project
(prior check if there is a project opened already and if this current 
project is "dirty" = changes in project settings since last save)
- select one of project history list in menue (each entry knows its 
project file)


(8) User is editing SDK preferences
- Default path/directory to look for project files (*.osp)
- Default path/directory to look for XMI files (*.xml)
- Default path/directory to look for output directory
- Save or Cancel


(9) User is generating application
- requires XMI file + output directory defined in project settings
- optional: liberal mode? (check box)
note: probably the generate.py should be called from SDK-GUI in a 
seperate thread


(10) User is using help features
- Welcome dialog, some kind of HTML help for SDK-GUI + OpenSwarm (e.g. 
DocBook generated HTMLHelp?), Getting support, License, About)


(11) User exits the SDK
(prior check if there is a project opened already and if this current 
project is "dirty" = changes in project settings since last save)


(12)
An additional idea would be to have sets of SDK's logging configurations 
for console logging and file logging. In the SDK preferences user could 
define default configurations for both logs, including:
- log-level
- format
- date-time format
and for log-file:
- path/filename of log-file

The values can be just passed through to the generate.py and from the 
generate.py to the Python logging module.

The user would have the option to overwrite default logging 
configurations for each project (would need additional widgets in the 
project settings dialog).



I think this can help diving into OpenSwarm (combined with automatic 
setup procedure of SDK package and some pattern XMI files such as the 
PetStore example).

What is your opinion?

Anastasios

[OpenSwarm-users] Added PIM and PSM example to online doc

[Anastasios H. <ah...@ha...>]

Hi @all

I updated the online documentation. Most important change: One example 
has been added which shows an application model (PIM) and how OpenSwarm 
SDK transforms this to a PSM that is used to generate the source codes. 
I think this will help to better understand what's happening in the SDK 
and why it is a light-weight MDA :-)

http://openswarm.sourceforge.net/doc/recent/intro-changes.html#intro-changes-doc-0.6.1-20070107

Anastasios

[OpenSwarm-users] IRC channel

[Anastasios H. <ah...@ha...>]

Hi @all

You probably already noticed in the recently documentation update that I 
started the IRC channel #openswarm on irc.freenode.net.

Naturally there is no-one except of the uneloquent buddy ChanServ 
working at Freenode - hehe. My nick is AniHatzis.

I try to be in channel whenever I can, although I'm sometimes AFK or my 
IRC client is minimized.

However, you probably want to try and join me (well, and Chan!). It is a 
good chance asking me something and knowing that I'm forced to give 
shorter answers ;-)

Anastasios


PS: Sorry for some email delays. I had a dead-line project since 
christmas which I finally accomplished yesterday night!

Re: [OpenSwarm-users] serve and shared install script

[Anastasios H. <ah...@ha...>]

Terrence

Currently I prepare the next release which I wanted to be more 
convenient to use - beside important bug-fixes[1]. I added a 
debugging/logging support based on Python logging module. Hopefully this 
will help people to better understand what the SDK is doing during 
generation and particularily which issues occur during parse phase which 
should make it easier to fix bugs in a custom UML model. I also fixed 
the SDK so it should work now with Python's default encoding 'ascii' 
instead of the 'utf-8' patch that earlier OpenSwarm releases required. 
It seems that also the generated apps work fine on 'ascii', but I will 
test this more intense later.

However, I wanted also to make installation easier for the next release. 
My Linux server (OpenSUSE 10.0 x64) is now set up with the basic stuff 
(Python, PostgreSQL, Apache, mod_python), so I will be finally able to 
test your install script. Thanks again.

I also planned to have a closer look into Python's distutils. I guess 
your suggestion implied distutils as you wrote:

Terrence Brannon wrote:
 > This makes the install process a bit easier. If this product gains
 > users, I could rewrite this in Python to work across architectures and
 > various compression formats.
 >

Do you think this is worth for you to contribute to next release 
already? I would really appreciate some help since I'm currently very 
busy with transformation of all documentation from OOo/ODT to DocBook 
(it became too much content especially in the tutorial and I need to 
restructure the doc anyway).

Anastasios


[1] Particularily improved the support of explicite and implicite import 
dependencies introduced in last release and which was rather buggy as I 
learned later.


> #!/bin/bash -x
> 
> PYTHONDIR=Python-2.4
> LIBDIR=$PYTHONDIR/lib/python2.4
> SP=$LIBDIR/site-packages
> O=OpenSwarm
> OA=$O-apps
> MD=$SP/$OA
> OP=$SP/$O.pth
> 
> DL=/Users/tbrannon/Downloads
> ZIP_SERVE=$DL/OpenSwarm_serve-0.6.0.zip
> ZIP_SHARE=$DL/OpenSwarm_shared-0.6.0.zip
> 
> 
> mkdir -p $MD
> echo  $OA > $OP
> 
> unzip $ZIP_SERVE -d $MD
> unzip $ZIP_SHARE -d $MD
> 
> 
> ------------------------------------------------------------------------

Re: [OpenSwarm-users] grammar correction - "Create A Zone Class"

[Anastasios H. <ah...@ha...>]

Terrence Brannon wrote:
> If talking about the zone class concept it is worth to mention also a 
> special object
> which should be available in any logic-component: the primary object.
> 
> rewrite as
> 
> While discussing the zone class concept it is worthwhile to mention 
> another special object
> which should be available in any logic-component: the primary object.
> 

Terrence,
many thanks for your valuable feedback regarding both, content and 
language! :-)

I commited all the corrections to the SVN trunk and added the updated 
documents to the release package later this day, since they contain some 
additional important notes now.

Anastasios

Re: [OpenSwarm-users] typo: "TIPP" is not a word

[Anastasios H. <ah...@ha...>]

Terrence Brannon wrote:
> "TIPP" is properly spelled "TIP" in English :)
> 

OK :)))

[OpenSwarm-users] typo in "Client-Specific Implementation Concepts"

[Terrence B. <met...@gm...>]

Instancation of an logic-component object

Instantiation


Instanciation of an Operation object

Instantiation

see this website as reference - http://foldoc.org/?instantiation

[OpenSwarm-users] typo: "TIPP" is not a word

[Terrence B. <met...@gm...>]

"TIPP" is properly spelled "TIP" in English :)

[OpenSwarm-users] grammar correction - "Create A Zone Class"

[Terrence B. <met...@gm...>]

If talking about the zone class concept it is worth to mention also a
special object
which should be available in any logic-component: the primary object.

rewrite as

While discussing the zone class concept it is worthwhile to mention
anotherspecial object
which should be available in any logic-component: the primary object.

Re: [OpenSwarm-users] please specify the owner for diagram when documenting how to create a diagram

[Anastasios H. <ah...@ha...>]

Terrence Brannon wrote:
> TutorialNewbies never specifies which element of the model is supposed 
> to own the diagram, but this is an important factor.
> 
> Thus the instructions for creating  system diagrams and class diagrams 
> and others should be revised with this information.
> 

Thanks for the notice. I added the missing information to the tutorial. 
In short: Parent element of both diagrams is the top-level node of the 
model tree, named "Data", AFAIK MagicDraw selects this node by default.

Driven by curiosity I made some simple tests how the SDK will work if I 
move the diagrams to another parent node, e.g. the system node or a 
component node. I could not experience any problems. AFAIR the diagrams 
are for visualization purpose only and not parsed by the SDK. Please 
tell me if you experienced a problem though.

Probably the diagrams should reside as direct child nodes of Data on 
behalf of usability. The reason is that if creating a new class inside a 
diagram --e.g. by using the tool bar's "Class" button-- the new class 
will be placed in the element tree parallel to the diagram. At the 
preferred way the classes will be placed by MD as direct child nodes of 
Data and can be than moved to the appropriate place by the user. But if 
the diagram is in some package it would not be clear any more if the 
class really belongs to that place - and this could really cause problems.

Anastasios

Re: [OpenSwarm-users] serve and shared install script

[Anastasios H. <ah...@ha...>]

Terrence Brannon wrote:
> This makes the install process a bit easier. If this product gains 
> users, I could rewrite this in Python to work across architectures and 
> various compression formats.
> 
> #!/bin/bash -x
> 
> PYTHONDIR=Python-2.4
> LIBDIR=$PYTHONDIR/lib/python2.4
> SP=$LIBDIR/site-packages
> O=OpenSwarm
> OA=$O-apps
> MD=$SP/$OA
> OP=$SP/$O.pth
> 
> DL=/Users/tbrannon/Downloads
> ZIP_SERVE=$DL/OpenSwarm_serve-0.6.0.zip
> ZIP_SHARE=$DL/OpenSwarm_shared-0.6.0.zip
> 
> 
> mkdir -p $MD
> echo  $OA > $OP
> 
> unzip $ZIP_SERVE -d $MD
> unzip $ZIP_SHARE -d $MD
> 
> 

Wonderful! I need to try the script myself on a Linux server. I will do 
after some installations I have still to do on this machine this week. 
I'm trying installing Apache from source on 64 bit and was close to 
become nuts... I'm not sure if I even found somewhere a posting of you 
describing the same problem as I had. :-O

However, thank you very much for your feedback!

Regards,
Anastasios

Re: [OpenSwarm-users] typo: p.10 TutorialNewbies

[Anastasios H. <ah...@ha...>]

Terrence Brannon wrote:
> <QUOTE>
> 10.Now we need to specify the system in more detail. This is done by 
> using so
> called tag-values. Some of the supported OpenSwarm stereotypes has tag-
> definitions. If you apply a stereotype to an appropriate element you may 
> use
> tag-values to provide additional information to the Generator, depending on
> the element. Therefor let us have a look on the left panel of the 
> specification
> dialog of our system element. There you will see Tags in the tree.
> </QUOTE>
> 
> Change the bold to Therefore
> 

Oops, I made everywhere the same error :-) I corrected in all documents. 
Thanks.

Anastasios