0.6.6 snapshot

[tcheeric]

API: Refactoring of the API.

• Removed obsoleted NIPXXImpl classes. The NIPXX classes are now generating GenericEvent and GenreicTag classes, and not their concrete classes from the event module.
• We introduce the GenericEvent.convert method to convert a GenericEvent to a subclass instance.
• Similarly, GenericTag.convert will return the corresponding subclass instance.

EVENT: Refactoring of the event module.

• The event classes will serve as utility classes, with helper functions to retrieve relevant information from the event class.
• Rewrote the validation methods to be more conform to the specification (kind, tags, and content validations)
• Added LabelNamespaceTag and LabelTag concrete tag classes

[tcheeric]

IMPORTANT: This implementation was tested with SuperConductor revision 882c67e88f8ffb00cb22f13f75cea60303ad0f98 (this is the revision before the VoteTags additions)

I am able to build NJ, but the SC com.prosilion.superconductor.Matching*IT test cases fail with errors similar to the one below:

java.lang.IllegalArgumentException: No value present (through reference chain: nostr.event.impl.GenericEvent["tags"]->java.util.ArrayList[1])
      at com.prosilion.superconductor.MatchingMultipleGenericTagQuerySingleLetterIT.testReqMessagesMatchesGeneric(MatchingMultipleGenericTagQuerySingleLetterIT.java:91)
  Caused by: com.fasterxml.jackson.databind.JsonMappingException: No value present (through reference chain: nostr.event.impl.GenericEvent["tags"]->java.util.ArrayList[1])
      at com.prosilion.superconductor.MatchingMultipleGenericTagQuerySingleLetterIT.testReqMessagesMatchesGeneric(MatchingMultipleGenericTagQuerySingleLetterIT.java:91)
  Caused by: java.util.NoSuchElementException: No value present
      at com.prosilion.superconductor.MatchingMultipleGenericTagQuerySingleLetterIT.testReqMessagesMatchesGeneric(MatchingMultipleGenericTagQuerySingleLetterIT.java:91)

I was not able to fix the errors, and I am hoping you can take a look and hopefully fix them

[tcheeric]

Hi Nick,

Could you please review and reconcile with your recent PR? Hopefully these changes will make the api less confusing and easier to use. NOTE: In addition to the above changes, I have also moved Kind and Marker classes to the base module.

I have not submitted a PR for SC because I was working with a previous SC revision, and with the latest upgrade they are now obsolete. I think it would it be easier just to make the adjustments directly in the current SC develop branch. Thoughts?

[avlo]

IMPORTANT: This implementation was tested with SuperConductor revision 882c67e88f8ffb00cb22f13f75cea60303ad0f98 (this is the revision before the VoteTags additions)

I am able to build NJ, but the SC com.prosilion.superconductor.Matching*IT test cases fail with errors similar to the one below:

java.lang.IllegalArgumentException: No value present (through reference chain: nostr.event.impl.GenericEvent["tags"]->java.util.ArrayList[1])
      at com.prosilion.superconductor.MatchingMultipleGenericTagQuerySingleLetterIT.testReqMessagesMatchesGeneric(MatchingMultipleGenericTagQuerySingleLetterIT.java:91)
  Caused by: com.fasterxml.jackson.databind.JsonMappingException: No value present (through reference chain: nostr.event.impl.GenericEvent["tags"]->java.util.ArrayList[1])
      at com.prosilion.superconductor.MatchingMultipleGenericTagQuerySingleLetterIT.testReqMessagesMatchesGeneric(MatchingMultipleGenericTagQuerySingleLetterIT.java:91)
  Caused by: java.util.NoSuchElementException: No value present
      at com.prosilion.superconductor.MatchingMultipleGenericTagQuerySingleLetterIT.testReqMessagesMatchesGeneric(MatchingMultipleGenericTagQuerySingleLetterIT.java:91)

I was not able to fix the errors, and I am hoping you can take a look and hopefully fix them

ah yes, SC uses the updated nostr.event.tag.GenericTag package namespace (updated from original nostr.event.impl.GenericTag package namespace), which is indeed part of nostr-jav PR submitted last week(ish) and yes- your suggestion to reconcile i think is the way to go. will keep you posted shortly/upon completion.

[avlo]

I have not submitted a PR for SC because I was working with a previous SC revision, and with the latest upgrade they are now obsolete. I think it would it be easier just to make the adjustments directly in the current SC develop branch. Thoughts?

yes- conventional git/branch/PR workflow is for a change submitter (you, in this case) to bring their branch up-to-date with the current target branch (SC develop, in this case) state and ensure their branch (1) merges, (2) compiles (3) unit & integration tests pass with target branch (SC develop) without issue.

only then should a PR get submitted for merging.

if any of the above 3 conditions fail, it is the obligation of the submitter/submitter-agent to update/fix their branch prior to PR submission.

[tcheeric]

Absolutely. I'm on it