Skip to content

Commit

Permalink
Version 3.10.3-SNAPSHOT
Browse files Browse the repository at this point in the history 
Also consider dependencies as provided

Signed-off-by: Jody Garnett <[email protected]>
  • Loading branch information
@jodygarnett
jodygarnett committed Jun 16, 2020
1 parent c97f949 commit 1106c51
Showing 1 changed file with 19 additions and 8 deletions.
27 changes: 19 additions & 8 deletions pom.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,10 @@
</parent>
<modelVersion>4.0.0</modelVersion>

<groupId>org.geonetwork-opensource</groupId>
<artifactId>schema-iso19139.ca.HNAP</artifactId>
<version>3.10.3-SNAPSHOT</version>

<name>Schema Plugin HNAP ISO19139/119</name>
<description>
GeoNetwork schema plugin for HNAP ISO19139/119 standard
Expand All @@ -19,37 +22,45 @@
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>schema-core</artifactId>
<version>${project.version}</version>
<version>${gn.schemas.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>core</artifactId>
<version>${gn.project.version}</version>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>schema-core</artifactId>
<version>${project.version}</version>
<type>test-jar</type>
<scope>test</scope>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.xmlunit</groupId>
<artifactId>xmlunit-core</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.xmlunit</groupId>
<artifactId>xmlunit-matchers</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>common</artifactId>
<version>${gn.project.version}</version>
<scope>provided</scope>
</dependency>

<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>schema-core</artifactId>
<version>${gn.schemas.version}</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>

</dependencies>
<build>
<resources>
Expand Down

11 comments on commit 1106c51

@ianwallen
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is currently breaking our test build because of the version was changed to ${gn.schemas.version} instead of ${project.version}. It is not a big deaI as we have not merged the commit into our official code. But in the future I believe the schema plugin should only be updated to the next version once gn official release has been done.

@jodygarnett
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may of messed up, but schema-core makes use of the gn.schemas.version in its pom.xml. The value is 3.7 which is terrible practice and something I wish to address with the geonetwork community.

See schema-core/pom.xml

  <parent>
    <artifactId>schemas</artifactId>
    <groupId>org.geonetwork-opensource</groupId>
    <version>3.7</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>

  <artifactId>schema-core</artifactId>
  <name>GeoNetwork schema plugins core</name>

This means that the version of schema-core ends up being the same as from the parent (ie 3.7).

@jodygarnett
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ianwallen could you explain what version number you are expecting for schema-core exactly please? What is the value of ${project.version} for you.

@pvgenuchten
Copy link

@pvgenuchten pvgenuchten commented on 1106c51 Jun 19, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alternatively we move to a new numbering of schema-plugins-core which is not related to the geonetwork version, say 1.0 and keep that number until there is a non backwards compatible change?

what I always wonder about in this area is why we have this cross dependencies (see A in picture). Isn't there some alternative scenario which could improve this, like B (no direct link between web and schema's) or C (all schema's reference schema-core, but web doesn't)

image

@ianwallen
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jodygarnett
I agree. 3.7 is confusing to me. Not sure where that come from. But now that it is used we probably cannot go back to 1.0 as this could just add to the confusion. i.e. 1.0 is newer/better than 3.7!

I don't mind it changing with every gn version as it is easier to match but then we loose the ability to identify what version things will work with.i.e. if the api does not change then a 4.0 may work with 3.8. So we would need to document a compatibility table.

@jodygarnett
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 3.7 tag is in effect being used as a "SNAPSHOT" as it reflects the most recently built schema parent (along with schema-core and iso19139 which schema plugins sometimes depend on).

This is especially tangled as schema-core can bring in dependencies from the "surrounding" geonetwork application.

I have a short term mitigation I recommend, ensuring that schema-core and iso19139 are marked as provided to avoid transitive dependencies. I also experimented with removing schema as a parent, but this resulted in a lot of duplication in each schema plugin.

I marked a topic in the upcoming sprint to make some decisions on these tradeoffs, I am sure we can improve here.

aside: @ianwallen I would still like to know exactly what ${project.version} value you are expecting?

@ianwallen
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jodygarnett I never added ${project.version} - I believe it came from iso19115-3.2018. I don't know what I expect?

@fxprunayre
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It relates to geonetwork/core-geonetwork#2793. The idea was also to not to have to maintain one version of each schema for each GeoNetwork version and more have a plugin that can work with from version X to version Y. We don't have that many people maintaining schemas in https://github.com/metadata101 so I think one idea of Jose's PR was to keep things simple for those of us making releases and taking care of schema on the long run. Maybe there is more elegant ways to do this.

@jodygarnett
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the background @fxprunayre, that helps. I believe we can set us up with an approach that will work with maven concept of snapshots and release artifacts and still be used across geonetwork releases.

@ianwallen
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jodygarnett
As the related changes have not been applied to the 3.10.x branch yet, Our build is still failing.. Would it be possible to revert these changes and apply it in the future when the GN changes have been added. I believe that there has been some discussions that this may be in a 3.12.x release.

Thank you

@jodygarnett
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that is the best course of action, I have no indication when these changes will be accepted, and the suggestion to make a 3.12.x only came up last week.

Please sign in to comment.