Problems to build a new plugin from the XNAT template plugin

[Santiago Timón]

Hi!

We are developing a new plugin to store ASHS results as image assessors (pretty much like the FS plugin does) and plan to release it to the community, but we cannot get it to work. This is the repo (I just updated it). However, we are experiencing issues when building and with XNAT not recognizing the data type and version. 

The plugin is pretty simple, a custom data type to store region volumes, a display file, and a report screen (we don't need to edit). 

The first obvious issue I see is that the version variable in build.graddle doesn't work correctly/as expected. If one changes it, it breaks the dependency chain. I suspect because the reference to mavenBom uses project.version instead of vXnat.

mavenBom "org.nrg:parent:${project.version}"

If I change that line to mavenBom "org.nrg:parent:${vXnat}" the builder does finish, but then XNAT doesn't recognize the version (I guess it is not carried to Manifest or something like that) and leaves "Plugin Version: unknown" in the Site Administration/Installed plugins screen.

The real problem is that XNAT is not picking up these new data types (not even from a built XNAT template plugin), although they are listed in the JSON (4 times, I don't know if that is right), and I don't see anything related in the logs. 

In my dev setup, I'm using the docker-compose with v1.8.2.2

Thanks!

Santi

[Moore, Charlie]

Hi Santi,

I get a 404 when clicking on your github link. Is the repo private maybe?

Thanks,

Charlie

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of Santiago Timón <santiago...@gmail.com>
Sent: Monday, September 27, 2021 5:12 AM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [XNAT Discussion] Problems to build a new plugin from the XNAT template plugin

 

* External Email - Caution *

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/5ea22d38-c66c-413a-8f91-43f5b8af7761n%40googlegroups.com.

 

---

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[Santiago Timón]

Hi Charlie,

You are right, I left that private, now it should be public. Thanks!

You received this message because you are subscribed to a topic in the Google Groups "xnat_discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xnat_discussion/WjJCKeBLEFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/DM6PR02MB671570C37DE2678E457E1196FEA79%40DM6PR02MB6715.namprd02.prod.outlook.com.

[Herrick, Rick]

How are you building the plugin, i.e. how are you invoking Gradle to actually create the plugin jar?

 

Does your plugin jar contain the file META-INF/xnat/ASHS-Plugin-plugin.properties or at least something matching the pattern META-INF/xnat**/*-plugin.properties?

 

That properties file is generated from @XnatPlugin-annotated classes and is used by XNAT at run-time to identify installed plugins. If that’s not there, you’d see behavior like you’re describing.

 

The reason ${project.version} doesn’t work to resolve the XNAT dependencies is because project refers to the current project (i.e. your plugin) and its version, which is set to 1.0.0-BETA*. In the template plugin the version is tied to the XNAT version, so that works. We should probably change that because I see how it’s misleading, but the issue isn’t because there’s some inherent difference between ${project.version} and ${vXnat} in terms of how Gradle interprets the values.

 

* The dependency resolution mechanisms for Gradle and Maven don’t really understand BETA as a suffix for version numbers. The standard practice is to use SNAPSHOT instead, which Maven/Gradle/Ivy treat in a special way during publishing (tl;dr artifacts get published with a timestamp like 1.0.0-20210927101427-10, with a metadata file mapping 1.0.0-SNAPSHOT to a particular artifact by timestamp). This probably doesn’t matter too much for local development purposes on an in-house development project, but if/when you make the plugin publicly available it could become an issue.

 

-- 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

Phone: +1 (314) 273-1645

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/CACdbfcGdXsbcsfSddgrM_VaZCNXoV%2BgZCghmKF9mqoFqNgOOew%40mail.gmail.com.

[Santiago Timón]

Hi Rick, 

Have tried both with ./gradle jar and build.

We don’t have any properties file for the plug-in.

I will try dropping the beta suffix. 

Would any of this affect the data type detection? I find odd that the template project doesn’t work either once deployed.

Thanks,

Santi

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/SN6PR02MB511837A0CC72AD07F88812F5BDA79%40SN6PR02MB5118.namprd02.prod.outlook.com.

[Herrick, Rick]

Try using xnatDataBuilder:

 

./gradlew clean xnatDataBuilder

 

The lack of a properties file in the plugin wouldn’t prevent XNAT from finding the data types–as long as the schema files are on the classpath, XNAT should find them–but they won’t be configured and made available automatically: that requires the @XnatDataModel annotations in the plugin class, e.g. from xnat-template-plugin:

 

@XnatPlugin(value = "templatePlugin", name = "XNAT Template Plugin",

            entityPackages = "org.nrg.xnat.plugins.template.entities",

            dataModels = {@XnatDataModel(value = TemplateSampleBean.SCHEMA_ELEMENT_NAME,

                                         singular = "Template",

                                         plural = "Templates",

                                         code = "TM")})

 

Without that annotation (or whatever values are appropriate for your data type), the data type gets loaded by XNAT, but you’ll need to go to Administer -> Data Types on the site admin menu to set up the data type manually.

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/CACdbfcHr_XHsGaY9umb3MikpoBVrZD%2BrnN4%2Bs1acX5G%2BgDuWNA%40mail.gmail.com.

[Santiago Timón]

Hi Rick, 

I tried, and then I didn't get a jar to deploy into XNAT. But dropping the -BETA works to get the version into the manifest. 

Still, XNAT doesn't detect the new data types (either from our plugin or the template project). Always states "database up to date" after rebooting. 

We do provide the data type annotations in the plugin class. And the builder generates the necessary classes from the schema. 

The only failure I see is from SLF4J:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

I'm attaching the output of both ./gradlew clean xnatDataBuilder and jar.

On a side note, for our main plugin that contains a good number of custom data types, screens, and views, I kept using the old graddle settings (even keeping vXnat = '1.7.6'), and everything works fine. It builds, and XNAT detects the changes (I made some like a week ago). 

This one is fundamental for our implementation and, since I didn't manage to get the current template working, I didn't dare to tweak it further. 

So I guess one option, at least for us, is to build this new plugin with the same project template. 

Thanks again,

Santi

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/SN6PR02MB51182DA7064AB65B35FD7460BDA79%40SN6PR02MB5118.namprd02.prod.outlook.com.

[Santiago Timón]

Hi again,

I'm still investigating this problem and I think I found the reason XNAT doesn't see the data types: they are not being packaged in the jar. This seems to be caused by an excluded block in build.graddle.

Graddle is missing the resources folders for schemas and template-related files. 

Compared to our other plugin jar:

Its sourceSet definition looks like this:

sourceSets {
    main {
        java {
            srcDir 'src/main/java'
            srcDir 'build/xnat-generated/src/main/java'
        }
        resources {
            srcDir 'src/main/resources'
            srcDir 'build/xnat-generated/src/main/resources'
        }
    }
}

While the new plugin template:

// TODO: This tells the compiler where to find source code. This isn't required in a
//       standard build, but the XNAT data builder generates code from XNAT data-type
//       schemas that the compiler needs to know about.
sourceSets {
    main {
        java {
            srcDir "build/xnat-generated/src/main/java"
        }
        resources {
            srcDir "build/xnat-generated/src/main/resources"
            exclude {
                // TODO: Schema files get copied over to the generated source folder, which
                //       results in duplicate entries for those files in the plugin jar file.
                //       This exclusion filters those duplicates out.
                "build/xnat-generated/src/main/resources/schemas/**/*.xsd"
            }
        }
    }
}

These folders are referenced correctly and contain the files

Once removed the exclude block, the resources are correctly packaged and XNAT is aware of the datatypes. 

Does this make any sense?

Santi

[Herrick, Rick]

Yes, that was going to be my next suggestion. The fact that the database wasn’t updated is the tip-off: like I said earlier, XNAT will find the schema files without any help from the plugin at all, provided the schema files are actually there! 😊 That excluded configuration was there to resolve an issue where the jar task would fail because it found two copies of the same file path to be added to the jar file. That fixed the issue at that point, but the other change of removing src/main/resources (which is included automatically without configuring it) caused it to exclude even the copies of the schema files.

 

Have a look at the latest version of the template plugin: https://bitbucket.org/xnatx/xnat-template-plugin/src/master

 

The sourceSets configuration has actually been removed altogether (although it is referenced in the sourcesJar configuration).

 

-- 

Rick Herrick

XNAT Architect/Developer

Computational Imaging Laboratory

Washington University School of Medicine

 

 

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of Santiago Timón <santiago...@gmail.com>
Date: Tuesday, September 28, 2021 at 6:04 AM
To: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] Problems to build a new plugin from the XNAT template plugin

* External Email - Caution *

Hi again,

 

I'm still investigating this problem and I think I found the reason XNAT doesn't see the data types: they are not being packaged in the jar. This seems to be caused by an excluded block in build.graddle.

 

Graddle is missing the resources folders for schemas and template-related files. 

Compared to our other plugin jar:

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/CACdbfcGAQORjrqOmnG6htd%3Dj%3DWRF295P0m5ScwLSxiRWEV-frw%40mail.gmail.com.

[Santiago Timón]

Thank you Rick,

I will update with the changes from the repo then. I hope I get everything in order and, eventually, update the build set up in our main plugin. 

Best,

Santi

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/SN6PR02MB5118E828592FA1F5FB39736ABDA89%40SN6PR02MB5118.namprd02.prod.outlook.com.