[GeoNetwork-devel] Proposal to change schema plugin artifact identifiers

GeoNetwork GeoNetwork Developer
1

Hi

Currently metadata schemas use the same versioning for the artifact identifiers as the other modules.

While this is ok for schemas bundled in GeoNetwork, it’s really a pain for third party schemas for example from https://github.com/metadata101/ when adding them as submodules (you can add them as a copy in your project, but then you loose the advantages of submodules)

You need to keep them aligned with the related latest branch in GeoNetwork: 3.4.1-SNAPSHOT, 3.4.2-SNAPSHOT, etc.

Also means that when updated to the latest branch in GeoNetwork, the schemas can’t be used easily in a
previous releases for the same branch.

I want to make the following proposal:

To use the the release number for schemas module, so for GeoNetwork 3.4.x branch we use for shemas the artifactId 3.4. In the future, when released GeoNetwork 3.6, the schemas in 3.6.x branch will use artifactId 3.6 and so on.

This is only for schemas module, the rest of the modules will be managed as actually. This will as indicated facilitate the integration of schemas that are hosted in other repositories like metadata1010 as submodules.

Any opinion in about this?

Possibly there’re better alternatives to handle this, so any comment or alternative proposal to improve it is very well welcome.

Thanks and regards,
Jose García

···

Vriendelijke groeten / Kind regards,

Jose García


Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664

Please consider the environment before printing this email.

2

Hi,

···

On Tue, Mar 13, 2018 at 11:03 AM, Jose Garcia <jose.garcia@anonymised.com37…> wrote:

To use the the release number for schemas module, so for GeoNetwork 3.4.x branch we use for shemas the artifactId 3.4. In the future, when released GeoNetwork 3.6, the schemas in 3.6.x branch will use artifactId 3.6 and so on.

You mean, only major versions, nothing like 3.4.1 and 3.4.2?

It is a good idea to be at least backwards compatible. So the latest schema works with all the previous GeoNetworks… or at least for major versions. In fact, there should be nothing on the pom.xml of the schema pointing to GeoNetwork. Why does it need a parent project? Some indication of the version it works with, that’s fine. But a pom.xml parent project? I vote to remove it.

Any opinion in about this?

Possibly there’re better alternatives to handle this, so any comment or alternative proposal to improve it is very well welcome.

I have an utopic dream where no schema is a git module but they are all downloaded in GeoNetwork directly from a git repository. So when you open the admin interface, you see a list of all schemas available for your GN version in metadata101 (or any other url you configure for custom schemas) and you click and then it downloads the schema and works seamlessly…

But we will need someone to invest on this :smiley:

3

Good idea Jose. I think we should even not make reference to GN version in schema plugin as they may have their own version number. Maybe we should introduce a compatibility number in schema-ident for the app to check if it’s ok or not to load the plugin.

Thanks.

Francois

···

2018-03-13 11:03 GMT+01:00 Jose Garcia <jose.garcia@anonymised.com>:

Hi

Currently metadata schemas use the same versioning for the artifact identifiers as the other modules.

While this is ok for schemas bundled in GeoNetwork, it’s really a pain for third party schemas for example from https://github.com/metadata101/ when adding them as submodules (you can add them as a copy in your project, but then you loose the advantages of submodules)

You need to keep them aligned with the related latest branch in GeoNetwork: 3.4.1-SNAPSHOT, 3.4.2-SNAPSHOT, etc.

Also means that when updated to the latest branch in GeoNetwork, the schemas can’t be used easily in a
previous releases for the same branch.

I want to make the following proposal:

To use the the release number for schemas module, so for GeoNetwork 3.4.x branch we use for shemas the artifactId 3.4. In the future, when released GeoNetwork 3.6, the schemas in 3.6.x branch will use artifactId 3.6 and so on.

This is only for schemas module, the rest of the modules will be managed as actually. This will as indicated facilitate the integration of schemas that are hosted in other repositories like metadata1010 as submodules.

Any opinion in about this?

Possibly there’re better alternatives to handle this, so any comment or alternative proposal to improve it is very well welcome.

Thanks and regards,
Jose García

–

Vriendelijke groeten / Kind regards,

Jose García


Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664

Please consider the environment before printing this email.

Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

GeoNetwork-devel mailing list
GeoNetwork-devel@…537…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork