Scarab
General
XML Import
Default workflow questions and answers
Scarab has many features and advantages over Bugzilla, which we are not going to get into here, but the primary disadvantages are:
#1. Simple implementation of workflow
Scarab default workflow implementation is simple, and does
not try to provide a full-blown Workflow engine.
This means that Scarab does not have any logic
implemented within it that allows you to say things
like: when the State is changed to closed, change the
resolution to resolved. There is an API for allowing
this to happen, and you can ask in the mailing lists for the
experiences of Scarab's users successfully implementing it.
#2. testing and deployment as wide as Bugzilla
Bugzilla has been deployed far and wide over a number
of years and has undergone a great amount of testing
and visibility on the Mozilla.org website. Scarab has
not had the same level of testing and usage.
We have not heard of any major data integrity issues. In other words, we have not heard of Scarab destroying its own database. However, we have found several bugs along the way where things were not being logged properly or other such annoyances.
We recommend strongly that you make regular backups of your database by doing full dumps. That way, if something does go wrong, not only can you send us a copy of your database (if appropriate) but you can also revert to the previous state.
We provide database upgrade scripts for each revision of Scarab. That way you can be sure that if you start using Scarab now, you will be able to forward migrate your data when there are Scarab updates. Please see the upgrade instructions below for more information.
You may also run into various bugs or missing features within Scarab. It is best to first search our issue database and KNOWN_ISSUES.txt file to see if we know about the issue. If not, please let us know by reporting it to the issue tracker. Whatever you do, please don't send it to the mailing lists.
Remember, Scarab is still pre-1.0 beta software and is still under heavy development.
There is three types of documentation for Scarab.
From the README.txt file:
NOTE: If you get a 'Server configuration denies access to data source' or 'access denied' or 'Invalid authorization' or 'java.lang.NullPointerException: Connection object was null.' error from MySQL in the log files, please read the MySQL documentation on how to fix this error. We will not provide support for this since it is really a MySQL configuration issue.
Hint: On some operating systems, there seems to be a weird interation between the JVM, DNS resolution and the MySQL driver where a JDBC url pointing to 'localhost' will resolve as 'localhost.localdomain' and will prevent the connection to MySQL from authenticating correctly because most people configure MySQL for 'localhost'. One way to get around this is to use IP addresses in both the MySQL ACL as well as in the JDBC url.
At least one person has reported that using '127.0.0.1' instead of 'localhost' resolved a 'Server configuration denies access to data source' connection issue.
In order to setup the right permissions in MySQL, you may wish to try executing this command on a Unix command line (it has been reported to work for one person):
echo "GRANT ALL ON scarab.* to ''@localhost" | mysql mysql
NOTE: Sometimes it may be useful to use "ant create-db" rather than "create-db.sh" to diagnose connection issues since ant uses jdbc and the same URL that Scarab does while running.
Here is a couple links to also help you solve the permissions problem:
How: Please see our Getting involved document.
Why: Because the need for a first class issue tracking system that is open source is badly needed.
Here is my configuration for the Scarab Live Server:
NameVirtualHost 157.22.245.3
<VirtualHost 157.22.245.3>
ServerName scarab.collab.net
RewriteEngine on
RewriteRule /(.+) http://scarab.collab.net:8081/$1 [P]
ProxyPassReverse / http://scarab.collab.net:8081/s/
</VirtualHost>
The above might not be optimal or even correct, but it works for me. You will need to have mod_rewrite and mod_proxy enabled on your server. A 'faster' method of doing the same thing would be to use Tomcat's mod_jk/mod_webapp with some rewrite rules (to get the short url's), but I'm not doing that, so I don't have configuration to show for it. Contributions welcome.
For hiding Scarab behind Apache SSL, a similar setup as above would work, you would just want to make sure to listen to the https port 443 in the VirtualHost declaration.
When you first install Scarab using the ./create-db.sh -e script, you will get an empty database that is only populated with the required data. Therefore, you will need to setup your installation with new Modules, Issue types, Attributes and Attribute options.
Login as the Scarab Administer account that you created/defined in your build.properties when you built Scarab.
#1. Create a new module.
Admin -> Modules -> Manage modules -> Create new module
#2. Select the module by clicking the 'Modules' link in the top-left of the screen.
#3. Now, create a new global issue type.
Admin -> Global -> Global issue types
#4. Add the new issue type to the module.
Admin -> Modules -> Manage issue types -> Create new
#5. Set the issue type to be active and shown in the left hand nav.
(should be the next screen after #4. if not, then it is:
Admin -> Modules -> Manage issue types)
#6. Edit the issue type and create attributes and attribute options.
Admin -> Modules -> Manage issue types (click the issue type name).
#7. Add attributes to an attribute group.
(click the attribute group name on the 'Edit issue type' screen
and then click the 'Add new' button. If there are no global attributes
to add (most likely in this case), click the 'Create new' button to
define a global attribute.)
#8. Defining an attribute and its options.
(Set the name/description/type of the attribute and then save it.
If you have created a Dropdown list, then the ability to create
attribute options will show up below. Simply add options and click
Save. When you are done, click done and it will take you back to
step #7. The attribute should also appear in the group.)
Continue to repeat the steps above until all of your issue types, attributes and attribute options have been defined.
The Scarab developers provide MySQL database upgrade scripts for each new version of Scarab. We also take contributions for other databases. These scripts reside in the scarab/src/sql/upgrade directory. Some of these scripts are .sql files and some are unix shell .sh files. If you are using another database or operating system, we welcome your contributions to port these files.
To execute the .sql scripts you should type something along the lines of:
mysql DATABASE_NAME < mysql-upgrade-1.0b8-1.0b9-1.sql
To execute the .sh scripts you should type something along the lines of:
./mysql-upgrade-1.0b8-1.0b9-3.sh --password
Note that you will need to execute ALL of the scripts in order of upgrade version number and script order. For example, if you are upgrading from 1.0b8 to 1.0b9, then you should execute mysql*b8*b9-1.sql, mysql*b8*b9-2.sql, etc. Also note that the --password argument to the shell script is optional and not required if you do not need to specify a password.
If you have deployed Scarab with the default settings and are running out of the default target directory, then you should download the new version of Scarab, move the target directory into the new version of Scarab, cd into target/webapps/scarab/WEB-INF and backup and remove the following directories: classes, conf, lib, sql, src. You should be careful to not remove the indexes and attachments directories (if they exist). Once you have done that, you can build Scarab again following the directions in the README.txt file. You should take note to create a ~/build.properties file which stores your changes to the Scarab settings so that when you build again, your settings remain intact.
Scarab has an optional feature which is enabled by setting the scarab.register.email.checkRFC2505=true property in your build.properties. This feature uses DNS to check that the domain which is being registered has a valid A or MX record which is the minimum required to send email to a domain name. This feature is enabled to help try to prevent people from creating bogus accounts on the server.
The fix is simple, create an A or MX record for your domain entry.
If you want to use
a Scarab instance for testing, please use this address of the instance which is
rebuilt nightly from the latest source code:
http://www.saxess.com/en/components/scarab/testserver.page.
Please note that, as it's always rebuilt from the HEAD, this instance could show bugs or errors that does not appear in the released versions.
Scarab also has the self-tracker availaible but please, don't use it for testing. It should be used only for reporting of Scarab's issues.
java.lang.VerifyError: (class: org/apache/fulcrum/intake/transform/XmlToAppData, method: parseFile signature: (Ljava/lang/String;Z)Lorg/apache/fulcrum/intake/xmlmodel/AppData;) Incompatible object argument for function call
Tomcat has several directories setup in order to create different 'levels' of classpaths. There is a classpath that is specific to Tomcat and a classpath that is shared by all of the webapplications that Tomcat is running. Since Scarab still depends on Xerces 1.x, we need to make sure that that is the only Xerces available to Scarab at runtime.
In order to make Scarab work with Tomcat 4.1.x, you will need to move the xercesImpl.jar from tomcat/common/endorsed to tomcat/server/lib. This makes it so that the Xerces 2.x that comes with Tomcat is only used by Tomcat. You will also need to make sure that if you have any other webapplications which depend on Xerces (1.x or 2.x), that they include a copy of the .jar file in their WEB-INF/lib directory.
It is sad that this needs to be this way, but due to Xerces incompatibility issues, that is the way it is. Note that we will eventually make Scarab dependent on Xerces 2.x so that this is not an issue, but we are not quite there yet.
In your build.properties, add the line: scarab.copy.templates=true
Right now, the easiest way is to setup one installation of Scarab, then mysqldump the database and import it into the other database. Eventually, we will have the ability to export/import the Scarab 'settings'.
The reason for this is because when you upload a file attachment, the upload system also sends the form data. Because of this, each little bit of data will get a file created for it. You can adjust the size of the memory cache so that more of this data is held in temp memory (and not created as files) with this property:
# The maximum size of a request that will have it's elements cached in # memory by TurbineUploadService class. # services.UploadService.size.threshold=8192
These files should get cleaned up as the object is garbage collected, or the Java Virtual Machine is shutdown. If they persist after a shutdown, you can most likely safely remove them.
In your build.properties, define the following by removing the #:
# This is the timeout in seconds for sessions. If the value is # left commented out, the servlet container's default timeout # will be left as is. scarab.session.timeout = # session.timeout = 1800
If you want to disable logging people off, just set the value to a very high number.
It shouldn't. The way the scarab import works is that it first parses the passed xml to import to ensure all dependencies resolve, and that all modules, users, attributes and attribute options mentioned in the xml exist. If any are missing, then the entire import fails and a report is produced listing the problems found ("No such user 'jon'", etc.). If importing via the UI, the error report shows in the result screen. If importing via ant, check the scarab-xmlimport.log file. If the validation parse runs to the end w/o error, then begins the insertion parse.
Note, the scarab validation parse mentioned above is distinct from an xml validation parse: The latter checks the validity of the xml submitted, the former examines the data contained in the xml making sure its coherent with respect to scarab.
You'd start a new activity-set when:
What may be happening is that the activity-set id in your xml may be that of an already existing activity-set; you may be picking up the 'created-by' of the activity-set that already exists in scarab. Ensure your activity-set id is definetly not that of an already existing activity-set in scarab. This section from the scarab.dtd is pertinent:
The activity-set id passed is checked against the db to see if
this activity-set already exists (The activity-set id
== SCARAB_TRANSACTION.TRANSACTION_ID). If the activity-set id
does not refer to an already-existing activity-set, a new
activity-set id is created by taking the next id off the top of
auto-incrementing sequence; the passed activity-set id is
discarded. If an activity-set w/ the passed id already exists,
then we'll use the already-existing activity-set during import of
this activity-set's activites. To avoid picking up an extant
activity-set unintentionally on import, i.e. in the case where
you are doing an import of all new issues w/ no desire to refer
to already existing activity-sets, do not use a purely numerical
id for your activity-set id: Give the activity-set an alphabetic
prefix. In other words, instead of using numeric ids like
1,2,3,4,5, use ids that run new1, new2, new3, etc. Or simply do not
supply the id element at all. The latter is what the jira import xsl
does.
By default, Scarab will set the generated XML to encoding="UTF-8". You can set other target encoding (for example, iso-8859-1) in the scarab.dataexport.encoding property.
scarab.dataexport.encoding=iso-8859-1
svn co http://scarab.tigris.org/svn/scarab/extensions/excel2scarab
Release 0.8
Release 0.9
Release 1.0
Release 1.1
Release 1.2
Release 1.3
Deferred to future
and I've already released 1.0, I'd define this transitions (Global attribute definition screen) setting the needed role to "Any role"
and defining no conditions,
Any option -> Release 1.1
Any option -> Release 1.2
Any option -> Release 1.3
Any option -> Deferred to future
This will disable non mentioned releases when editing issues.