packages facility

[cleberjamaral]

mechanisms, tools, servers, … so that developers can publish modules and reuse modules of others (like Java developers do with maven/gradle). The initial issue is what constitutes a module? Is it a "mini" MAS? A partial MAS? "Pieces" of code (asl files, artifacts, set of norms/orgs)?
Example: a "Planning Module", the user writes something like "import planning:1.2.1" in the jcm the agents have planning support. Here, I guess, some artifacts are available (maybe already instantiated in some workspace). Example: a "ROS Module" the user writes "import ros:1.3.13" and agent architectures, internal action, … are available.

Flexible frameworks and Libraries, Packaging/reimagining the JaCaMo platform as a flexible set of frameworks and libraries [proposed by Andrei] a platform provides more features out-of-the-box compared to a framework, but it also imposes more design decisions on developers platforms are great for research prototyping but harder to push to the industry the trade-off we would explore with this proposal: less functionality out-of-the-box but more freedom of design choices [Nardin, comment] Align the presentation of JaCaMo in the website similar to how it is presented in the book. Instead of presenting it as a combination of three frameworks (i.e., Jason, Cartago, and Moise), present it as a single tightly coupled framework implementing the Agent, Environment, and Organization dimensions. [Samuele, comment] I see this as very well aligned with what Alessandro was proposing about identifying together a “JaCaMo kernel” as the first possible step towards open-sourcing. This of course implies also to find easy ways to plug-in other “modules”. [Olivier, comment] Keep the essential feature of extensibility and openness: to let the possibility to enrich JaCaMo with other agents’ architectures (e.g. 2APL, GOAL, …), other organization’s models (e.g. AGR, EIDE, …)Align the JaCaMo platform with the unified vision of the JaCaMo book (no more a set of platforms) while keeping the possibility to add other agent architectures, organization models, …

More details: https://docs.google.com/document/d/1Oec6zTgQvlHtSQqFxU3NPWtynDzRBFJJcD0kCCkQWuQ/edit https://docs.google.com/document/d/1suyGB7ujA9mS6o2lZTfaxGvAb9B2lomGPJiUe4A7tYo/edit

[jomifred]

I wrote some initial notes of a proposal at https://docs.google.com/document/d/1Oec6zTgQvlHtSQqFxU3NPWtynDzRBFJJcD0kCCkQWuQ/edit?usp=sharing

[jomifred]

initial manual for the first implementation at https://github.com/jacamo-lang/jacamo/blob/packages/docs/devs/creating-packages/index.adoc

[jomifred]

presentation for the group https://drive.google.com/file/d/1-Gp2HcIQ08m1tSXLwL5TOALgNxr42R0F/view?usp=sharing

[vcharpenay]

I'm trying to publish some .asl files from Hypermedea in a package. Working files are in branch update-jacamo:

• reusable Jason plans are in hypermedea-lib/src/main/resources/asl
• an example agent importing these plans can be found in examples/fayol

At the moment, I have the following error:

[JaCaMoLauncher] the jar file for package 'hypermedea' is not found (based on org.hypermedea:hypermedea:0.3.1)

Is there some problem you can spot in the way I configured the package? I used MavenLocal to publish the library instead of Jitpack.

[vcharpenay]

By the way, for the record: last week, we had ~20 summer school participants use Gradle to import Hypermedea as a JaCaMo 0.9 library (see build.gradle).

So far, Hypermedea is only a collection of Java classes, so no particular packaging is necessary.

[jomifred]

Hi Victor, sorry for the delay and thanks for reporting the problem.

Local Maven stores files a little different, so the problem you are facing. It is fixed in jacamo 1.2.2.