Classpath during compilation of Zaproxy and Zap-extensions

[Eddy Vanlerberghe]

Hi,

After watching the video on how to setup a Zap development environment I started dabling around a little bit. I am pretty well versed in Java, but gradle is completely new to me. What I am trying to do right now is to add one utility class to Zaproxy, containing mostly static methods, and use that class from an addon. However, gradlew always complains about missing the utility class that I added to the zaproxy tree.

At first I used a completely new top-level package (utility/Fubar.java) but that did not work when I tried to add the extension to Zap (using simpleexample for now) So, I moved the utility class to the same package as ZAP.java. Also did not work.

I assumed that one of the zap-extension gradle configuration files links the extension to the main Zap code, but if so, I did not recognize it as such.

I also tried to figure out how gradle handles its configuration, but frankly, I got lost quickly in the vast sea of documentation.

In the end I even tried "strace -f" (working on linux) in the hope of finding where the actual java compile command is executed (and learn which classpath settings may be used), but that failed to.

Can anyone direct me to a short description on how to setup classpath settings for adding source code to the main zaproxy tree, as well as to a new addon?

Thanks.

[psiinon]

Hiya,

The ZAP extensions will get built with the current ZAP release, right now thats 2.16.1.

So any changes you make the the zaproxy repo will not be available to the zap-extensions repo until after we have released ZAP.

This is very deliberate - if you want to share your add-on via the ZAP marketplace then it wont work for anyone else until the new version of ZAP is available to them.

Why not just add the utility methods to your add-on?

If you really want to just maintain your own custom version of ZAP then there are workarounds of course :)

Cheers,

Simon

[thc202]

Also, answering your question about the classpath.

You can use Gradle's Composite Builds feature to pick changes done in
your local zaproxy project, e.g.:
./gradlew --include-build=../zaproxy :aO:myaddon:build

https://docs.gradle.org/current/userguide/composite_builds.html#command_line_composite


But as Simon said, most likely your utility class should live in your
add-on (or if generally useful in commonlib) not core.

Best regards.

[Eddy Vanlerberghe]

Thanks for the quick response.

As to why the utility functions live in Zap itself: I am using static variables and want to (temporarily) add code to Zap that interacts with the addons.

The code is meant to be temporary: I try to figure out why my context popup menu is disabled when more than one http request is selected. I found  several locations in Zap where menu items are disabled and wanted to insert some conditional debugging code there (conditional on the menuitem being from my addon, not any other origin)

Anyway, thanks again for the helpful responses.

--
ZAP by Checkmarx: https://www.zaproxy.org/
---
You received this message because you are subscribed to the Google Groups "ZAP Developer Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-devel...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/zaproxy-develop/78c5bd40-e6c8-48f8-98d0-8e274cbbf664%40gmail.com.

--

_______________________________________________________________
  Eddy Vanlerberghe

  "The secret to enjoying a good wine is:

   1 - Open the bottle to allow it to breathe.
   2 - When it does not breathe, give it mouth-to-mouth."
  (rec.humor.funny - som...@microsoft.com )
_______________________________________________________________

[thc202]

Makes sense but I'd suggest use of an IDE, you can debug core code and
add-ons at the same time (even hot code replace).

Best regards.