To prevent spam users, you can only post on this forum after registration, which is by invitation. If you want to post on the forum, please send me a mail (h DOT m DOT w DOT verbeek AT tue DOT nl) and I'll send you an invitation in return for an account.

Where to place a newly defined package in my local ProM installation?

I have set up a local installation of ProM, within Eclipse, as per the instructions at (and some assistane from Eric Verbeek -- thank you for that !!).

I am now attempting to create a package in my local environment, following

My question is: where should I put the new class "gettingstarted"?

My first attempt was to put it into Workshop/src/org.prcoessmining.plugins.gettingstarted.  When I launched UITopia I saw the Hello World plugin, and thought everything was good.  However, when I made a minor tweak to my gettingstarted file and re-launched UITopia, the tweak did not show up.  Then I fully deleted getting started plugin, but it still shows up when I restart UITopia.

I believe that when UITopia is launched it is not looking at the files in Workshop/src.  How can I get UITopia to look there, or, where should I put a home-made package so that my local UITopia will find it?

I am wondering if the solution includes setting the PROM_USER_FOLDER in ProM.ini to local directory holding some xml files similar to and also, e.g.,  If this is true, then are there any tools available to auto-generate the needed xml files?

(BTW, my current interest is to be able to make minor tweaks to a couple of existing packages (e.g., the Fuzzy mining and the Local Process Mining packages). At a minimum, I am wanting to get my hands on the outputs from the packages, and possibly modify some of the configuration parameter settings.  I am not currently planning on creating a fully new package, although who knows what the future will bring.)



  • Hi Rick,

    I'm sorry, I'm a bit slow on this, but it has been some time, and some knowledge has drifted into the background... Therefore, it is good that you ask and that I try to answer it now.

    The problem is the class loader. Again. To be more precise: The problem is that we do not know the class path that goes into the boot class loader, unless that boot class loader is a URL class loader. As a result of this, if the boot class loader is not a URL class loader, we cannot scan the classes on the provided class path for plugins as we do not know what the provided class path is.

    On Java 8 and earlier, we know that the boot class loader is a URL class loader, which we can simply extend, and from which we can get the URLs on the class path.

    On Java 9 and later, we instantiate a ProM URL class loader as the system class loader. However, this class loader has no access to the class path provided to the boot class loader :-(.

    Bottom line: On Java 9 and later, we cannot scan the package itself for plugins, we can only scan installed packages for plugins.

    A workaround could be have the package you're working on installed, to export your project as a (plain) jar file, and to write that jar file over the jar file of the installed package.

    Note that you only need to do this if you need ProM to scan for plugins again. The class loader will in fact load the classes from your project, as they precede any packages in the class path. So, if you only change the implementation of existing plugins, then you need not export the jar file.

    Hope this helps you a bit.

    Kind regards,

  • Hi - ok, good, I will try that approach.  Do you have instructions on the web somewhere about how to "install" a ProM package? 

    Should I attempt to do that locally, or should I get an account with the ProM SVN, and be installing it there?  (All other things being equal, I lean towards installing in the SVN, so that I will continue to be up-to-date by being hooked into the nightly builds that you-all are doing).

  • Hi Rick,

    You can run the "ProM Package Manager" in Eclipse, and install the package using that tool. The package will then (typically) be installed in the .ProM/packages folder in your user folder.

    You cannot use this workaround for the Workshop package, as the Workshop package is not included in the packages which can be installed. If need be, export the Workshop jar file over the installed ApacheUtils.jar file instead. The ApacheUtils.jar file only contains a plugin that shows the Apache 2.0 license, I guess you can do without that one.

    Kind regards,
  • Hi - thanks for your patience with this.  I have tried to follow your instructions.  Specifically, I found the folder /Users/rick/.ProM/packages/apacheutils-6.9.122, and replaced the ApacheUtils.jar in there with a new exported .jar file.  I relaunched UITopia, found the "Show Apache License, Version 2.0" action, and launched.  But it still shows the Apache license, sigh. 

    (I did not modify the directory "lib" in there.)

    I also noticed a directory /Users/rick/.ProM69 which is similar to ~/.ProM, so I replaced the ApacheUtils.jar file in there also -- but same behavior.

    I have tried different variations, eg., killing my eclipse and restarting, etc.

    In case it is useful, I am attaching the console output from Eclipse, in which I
    a) launch UITopia, and then
    b) invoke the Apache License action

    In the Eclipse log I see many lines with "Plugins found in cache".  Is it possible that the original ApacheUtils.jar is in a cache somewhere?  Is there a way to delete the cache contents?  (Or is the cache simply ~/.ProM/packages?)

    Other suggestions?

  • Hi Rick,

    Yes, there is a cache, and there is a way to clear it. If you start the Package Manager, you will see a "Clear" button in the right bottom corner (section labeled "Manage Plugin Cache". If you press that button, the cache is cleared, which causes ProM to scan all jar files in the next run. Will take a bit longer to start then.

    I'm sorry that you're having all these issues. I guess, this is why we still advocate to use ProM 8 for ProM development, although it has been replaced now many times over. This avoids all these issues, and it also prevents developers from using features that are not supported anyway on our continuous build server (which also uses Java 8).

    Kind regards,
  • Hi Eric - thanks for all of your help.  I did switch over to java 8 and have been able to start tweaking some of the code.  I also imported the LocalProcessModelDiscovery codebase into my eclipse environment, and can modify that.

    As a small point, I do not remember seeing the recommendation to use Java 8 in any of the documentation I had been working with (e.g., the Getting Started area nor the Workshop area).  You may want to add a comment about using Java 8 into the page (and perhaps also somewhere in the Workshop area, in case people download from there).

    Many thanks again.

Sign In or Register to comment.