Here is what you need to do in order to compile and run your checked out copy of ArgoUML under Unix.

If you change something, running the run target again will build and run.

In certain cases when something is changed in the argouml project you need to use the "clean" target to re-compile everything, since we have not set up dependencies correctly.

If you do this from Cygwin you work just like for Unix.

If you want to customize your build, change the appropriate build.xml or default.properties file.

Don't commit these changes unless you are working with updating the development environment itself.

Remember that if you do this, you have modified your development environment. To be sure that you will not break anything for anyone else when checking in things developed using this modified environment, remove these files temporarily for the compiling and testing you do just before you commit just as you would do before other commits.

By running Ant again using build prepare-docs the Javadoc documentation is generated and put into trunk/src/build/javadocs.

If you want to run ArgoUML with modules enabled the build.xmls are set up to do this in two ways:

The purpose of a subproject to ArgoUML is to develop things that are run within ArgoUML. In ArgoUML we call them modules, in other tools they are called add-ins or plug-ins.

If you want to start working with a module of your own you could do it by letting the ArgoUML project leader set up a subproject to ArgoUML for you. The benefits are:

The draw-backs are:

If you decide not to make your module a argouml subproject, you can still benefit from using a similar set up as described here but since you have your module repository elsewhere, some adaptations are necessary.

The sub-projects are developed close to the ArgoUML project and reside in a similarly-looking subversion repository. We try to provide a working set of tools and instructions to fit the whole set of projects. These tools are sometimes located in the argouml project and sometimes in the subproject. Also, to compile the module, you need the argouml interfaces, and to run it you need argouml in place. In most cases the argouml interfaces is argouml itself so this distinction is mostly formal.

There are two ways to get the argouml in place w.r.t. your module. The ArgoUML source way and the quicker ArgoUML distribution way.

Using the ArgoUML source way you check out the argouml project alongside the subproject you are going to work with and build it. If you are doing development in the argouml project too, if the subproject in question requires a tool from the argouml project, or if your modules is on the bleeding edge of argouml development and you can't wait for distributions, this is the preferred way. You will need to update and rebuild the argouml project regularly.

Using the ArgoUML distribution way, you check out only your module and then download the ArgoUML distribution and work against that. This is the approach described in the beginning of this section. You will need to download and replace the ArgoUML distribution whenever you need a newer version to work against. You could also, at any point, upgrade to the ArgoUML source way to get to the bleeding edge.

The build.xml ant configuration file in the subproject and the argouml main project are set up to allow for both of these ways.

Each subproject has its own web site with documentation and plans of the subproject.

The subproject has its own commits mailing list that you need to join to monitor the commits. It also has its own dev mailing list where the people working within that subproject discusses the subproject. Join both of these mailing list to see what is going on in the subproject!

The sub-projects could use their own Issuezilla database but could also be subcomponents in the ArgoUML Issuezilla. If it is a subcomponent you need to acquire an Observer role in the argouml project to work in a subproject.

The following targets have the same documented meaning in all sub-projects:

It might be that some other developer has made a mistake in checking in things that contain errors, or forgotten to check in some files in a change. Look at the last couple of hours on the developers mailing list! It is probably on fire.

Another reason for problems is an unclean local source tree. This means that if you have updated different parts of your source tree at different times it might contain inconsistencies. If you suspect this, first try to fix it by doing build clean and svn update before trying to build again. If that doesn't work remove your checked out copy completely and get it all again.

Another reason might be that you have an build.properties or argouml.build.properties file that you have been working with earlier and that is doing something. If in doubt, remove those files.

If nothing helps, ask the developers mailing list!

You need to have a developer role in the ArgoUML project or in the subproject you are working with. If you don't, then you cannot do commits yourself. Discuss what you have done and how best to test it on the ArgoUML project developers mailing list or the developers' mailing list for your subproject. Get in contact with the active developers and urge them to commit it for you.

Furthermore the checkout of your copy needs to be done with your Tigris id that has the Developer role. If you for some reason have earlier checked out a copy as guest and then made modifications you may have problems. It is unknown if this is a problem in Subversion. Let the editor know if you find out.