[GeoNetwork-devel] schema-profiles not as pluggable as they need to be...

Hi list, in recent projects i've been struggling with the new schema-profiles in GN3.0 and found they are not that pluggable as they are in GN2.0 (and should be imho).

A while back I've added in this page a list of actions to 'plug-a-profile'. http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema

Would it be interesting to see if we can move profiles to a maven repository, so people can include profiles without having to change pom.xml's in several places?

Recently I discovered the above page is not complete, there are other items to update:

- On web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaManagerService.js you have to add each of the schemas you're adding and for each add a procedure to retrieve the proper codelists.
- On web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDirective.js there is an error namespaces[gnCurrentEdit.schema]['gco'] undefined

In the javascripts there is quite some xml snippets hardcoded, which worries me if at some point someone wants to start implementating a totally new schema like Dublin Core, SensorML, GBIF/EML, schema.org/Dataset or DCAT.
Some directives may only be called from the form-config in a certain schema, and thus may be tightly bound to that schema, which could be fine. Altough in that case it would be better to use a naming convention like iso19139-date-picker-directive.js, any profile that is based on iso19139 can then use that directive?

Would be interested to hear your thoughts on this and see if we can define a way to move this forward.

Hi,

What I have been suggesting is to remove all the hard-coded parts in
javascript and have services in GeoNetwork to populate that parts. We
can add beans on each schema project to fill it on the server side. So
once the project is inside maven, it will be automatically populated.

A similar thing can be achieved for the database changes.

I am not so sure about the maven configuration parts.

Regards,
María.

On Wed, Dec 2, 2015 at 9:32 AM, Paul van Genuchten
<paul.vangenuchten@anonymised.com> wrote:

Hi list, in recent projects i've been struggling with the new
schema-profiles in GN3.0 and found they are not that pluggable as they
are in GN2.0 (and should be imho).

A while back I've added in this page a list of actions to
'plug-a-profile'.
http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema

Would it be interesting to see if we can move profiles to a maven
repository, so people can include profiles without having to change
pom.xml's in several places?

Recently I discovered the above page is not complete, there are other
items to update:

- On
web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaManagerService.js
you have to add each of the schemas you're adding and for each add a
procedure to retrieve the proper codelists.
- On
web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDirective.js
there is an error namespaces[gnCurrentEdit.schema]['gco'] undefined

In the javascripts there is quite some xml snippets hardcoded, which
worries me if at some point someone wants to start implementating a
totally new schema like Dublin Core, SensorML, GBIF/EML,
schema.org/Dataset or DCAT.
Some directives may only be called from the form-config in a certain
schema, and thus may be tightly bound to that schema, which could be
fine. Altough in that case it would be better to use a naming convention
like iso19139-date-picker-directive.js, any profile that is based on
iso19139 can then use that directive?

Would be interested to hear your thoughts on this and see if we can
define a way to move this forward.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

At least some of that is done as part of a proposal I'm about to do a pull request for - I have added plugins for ANZLIC, MCP etc to 3.x.x in the ANZMEST fork develop branch so have had to cope with at least some of this.

Cheers,
Simon
________________________________________
From: María Arias de Reyna [delawen@anonymised.com]
Sent: Wednesday, 2 December 2015 7:39 PM
To: Paul van Genuchten
Cc: Devel geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] schema-profiles not as pluggable as they need to be...

Hi,

What I have been suggesting is to remove all the hard-coded parts in
javascript and have services in GeoNetwork to populate that parts. We
can add beans on each schema project to fill it on the server side. So
once the project is inside maven, it will be automatically populated.

A similar thing can be achieved for the database changes.

I am not so sure about the maven configuration parts.

Regards,
María.

On Wed, Dec 2, 2015 at 9:32 AM, Paul van Genuchten
<paul.vangenuchten@anonymised.com> wrote:

Hi list, in recent projects i've been struggling with the new
schema-profiles in GN3.0 and found they are not that pluggable as they
are in GN2.0 (and should be imho).

A while back I've added in this page a list of actions to
'plug-a-profile'.
Managing metadata & template - GeoNetwork Opensource (EN)

Would it be interesting to see if we can move profiles to a maven
repository, so people can include profiles without having to change
pom.xml's in several places?

Recently I discovered the above page is not complete, there are other
items to update:

- On
web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaManagerService.js
you have to add each of the schemas you're adding and for each add a
procedure to retrieve the proper codelists.
- On
web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDirective.js
there is an error namespaces[gnCurrentEdit.schema]['gco'] undefined

In the javascripts there is quite some xml snippets hardcoded, which
worries me if at some point someone wants to start implementating a
totally new schema like Dublin Core, SensorML, GBIF/EML,
schema.org/Dataset or DCAT.
Some directives may only be called from the form-config in a certain
schema, and thus may be tightly bound to that schema, which could be
fine. Altough in that case it would be better to use a naming convention
like iso19139-date-picker-directive.js, any profile that is based on
iso19139 can then use that directive?

Would be interested to hear your thoughts on this and see if we can
define a way to move this forward.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net

GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

Good!!

Let us know as soon as you have more documentation written, so we
don't reinvent the wheel :slight_smile:

On Wed, Dec 2, 2015 at 10:03 AM, <Simon.Pigot@anonymised.com> wrote:

At least some of that is done as part of a proposal I'm about to do a pull request for - I have added plugins for ANZLIC, MCP etc to 3.x.x in the ANZMEST fork develop branch so have had to cope with at least some of this.

Cheers,
Simon
________________________________________
From: María Arias de Reyna [delawen@anonymised.com]
Sent: Wednesday, 2 December 2015 7:39 PM
To: Paul van Genuchten
Cc: Devel geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] schema-profiles not as pluggable as they need to be...

Hi,

What I have been suggesting is to remove all the hard-coded parts in
javascript and have services in GeoNetwork to populate that parts. We
can add beans on each schema project to fill it on the server side. So
once the project is inside maven, it will be automatically populated.

A similar thing can be achieved for the database changes.

I am not so sure about the maven configuration parts.

Regards,
María.

On Wed, Dec 2, 2015 at 9:32 AM, Paul van Genuchten
<paul.vangenuchten@anonymised.com> wrote:

Hi list, in recent projects i've been struggling with the new
schema-profiles in GN3.0 and found they are not that pluggable as they
are in GN2.0 (and should be imho).

A while back I've added in this page a list of actions to
'plug-a-profile'.
http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema

Would it be interesting to see if we can move profiles to a maven
repository, so people can include profiles without having to change
pom.xml's in several places?

Recently I discovered the above page is not complete, there are other
items to update:

- On
web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaManagerService.js
you have to add each of the schemas you're adding and for each add a
procedure to retrieve the proper codelists.
- On
web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDirective.js
there is an error namespaces[gnCurrentEdit.schema]['gco'] undefined

In the javascripts there is quite some xml snippets hardcoded, which
worries me if at some point someone wants to start implementating a
totally new schema like Dublin Core, SensorML, GBIF/EML,
schema.org/Dataset or DCAT.
Some directives may only be called from the form-config in a certain
schema, and thus may be tightly bound to that schema, which could be
fine. Altough in that case it would be better to use a naming convention
like iso19139-date-picker-directive.js, any profile that is based on
iso19139 can then use that directive?

Would be interested to hear your thoughts on this and see if we can
define a way to move this forward.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

Hi Paul,

···

2015-12-02 9:32 GMT+01:00 Paul van Genuchten <paul.vangenuchten@anonymised.com>:

Hi list, in recent projects i’ve been struggling with the new
schema-profiles in GN3.0 and found they are not that pluggable as they
are in GN2.0 (and should be imho).

A while back I’ve added in this page a list of actions to
‘plug-a-profile’.
http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema

Would it be interesting to see if we can move profiles to a maven
repository, so people can include profiles without having to change
pom.xml’s in several places?

Recently I discovered the above page is not complete, there are other
items to update:

  • On
    web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaManagerService.js
    you have to add each of the schemas you’re adding and for each add a
    procedure to retrieve the proper codelists.
  • On
    web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDirective.js
    there is an error namespaces[gnCurrentEdit.schema][‘gco’] undefined

In the javascripts there is quite some xml snippets hardcoded, which
worries me if at some point someone wants to start implementating a
totally new schema like Dublin Core, SensorML, GBIF/EML,
schema.org/Dataset or DCAT.
Some directives may only be called from the form-config in a certain
schema, and thus may be tightly bound to that schema, which could be
fine. Altough in that case it would be better to use a naming convention
like iso19139-date-picker-directive.js, any profile that is based on
iso19139 can then use that directive?

Would be interested to hear your thoughts on this and see if we can
define a way to move this forward.

For new profile, I would recommend to use a dedicated repository like https://github.com/metadata101/ instead of mixing all schemas in schema-plugins repository. It’s then much easier to use submodule to plug a profile in a custom flavour of GeoNetwork.

In 3.x, Java logic for each profiles can be much easier be moved to the plugin. BTW, as we are doing more and more on the client side, we have now more JS logic. Did you (and Maria) made some experiment to extract the JS parts in a separate maven module - for the community module work last year ? I’ve not much ideas on this, but last changes from Simon improve this a little for ISO profiles.

Once you’ve the repository for the plugin, we could probably use Jenkins to build packages for each plugins - but we’ll have to better maintain versions between GN and plugins.

My .2 cents.

Francois


Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140


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

On Mon, Dec 7, 2015 at 8:27 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:

Hi Paul,

2015-12-02 9:32 GMT+01:00 Paul van Genuchten <paul.vangenuchten@anonymised.com>:

Hi list, in recent projects i've been struggling with the new
schema-profiles in GN3.0 and found they are not that pluggable as they
are in GN2.0 (and should be imho).

A while back I've added in this page a list of actions to
'plug-a-profile'.

http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema

Would it be interesting to see if we can move profiles to a maven
repository, so people can include profiles without having to change
pom.xml's in several places?

Recently I discovered the above page is not complete, there are other
items to update:

- On

web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaManagerService.js
you have to add each of the schemas you're adding and for each add a
procedure to retrieve the proper codelists.
- On

web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDirective.js
there is an error namespaces[gnCurrentEdit.schema]['gco'] undefined

In the javascripts there is quite some xml snippets hardcoded, which
worries me if at some point someone wants to start implementating a
totally new schema like Dublin Core, SensorML, GBIF/EML,
schema.org/Dataset or DCAT.
Some directives may only be called from the form-config in a certain
schema, and thus may be tightly bound to that schema, which could be
fine. Altough in that case it would be better to use a naming convention
like iso19139-date-picker-directive.js, any profile that is based on
iso19139 can then use that directive?

Would be interested to hear your thoughts on this and see if we can
define a way to move this forward.

For new profile, I would recommend to use a dedicated repository like
https://github.com/metadata101/ instead of mixing all schemas in
schema-plugins repository. It's then much easier to use submodule to plug a
profile in a custom flavour of GeoNetwork.

In 3.x, Java logic for each profiles can be much easier be moved to the
plugin. BTW, as we are doing more and more on the client side, we have now
more JS logic. Did you (and Maria) made some experiment to extract the JS
parts in a separate maven module - for the community module work last year ?

Hi,

Yes, we have experimented in that field (and we are still!). Not in
extracting the current javascript in different modules, but in being
able to add extra javascript/html maven projects to GeoNetwork having
to modify just a few lines in wro-sources and pom.xml files. I have as
a pending task write a good documentation on how to write your own UI
using as a backup the default one but being able to override whatever
you need. Some steps are still a bit ugly (for example, you have to
use mvn jetty:run-explode instead of jetty:run if you want to override
some files), but it is in an easy working status now.

On the other hand, the only solution we have found for the "hardcoded"
parts in javascript for schemas is to get the code dynamically from a
service. For example, get the array of schemas and their namespaces
from the server. Which probably is the best option... right? And have
a bean on each schemas that loads this definitions on the service.

I've not much ideas on this, but last changes from Simon improve this a
little for ISO profiles.

Once you've the repository for the plugin, we could probably use Jenkins to
build packages for each plugins - but we'll have to better maintain versions
between GN and plugins.

My .2 cents.

Francois

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple
OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple
OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

Hola Maria,

···

2015-12-07 22:22 GMT+01:00 María Arias de Reyna <delawen@anonymised.com>:

On Mon, Dec 7, 2015 at 8:27 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:

Hi Paul,

2015-12-02 9:32 GMT+01:00 Paul van Genuchten <paul.vangenuchten@anonymised.com>:

Hi list, in recent projects i’ve been struggling with the new
schema-profiles in GN3.0 and found they are not that pluggable as they
are in GN2.0 (and should be imho).

A while back I’ve added in this page a list of actions to
‘plug-a-profile’.

http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema

Would it be interesting to see if we can move profiles to a maven
repository, so people can include profiles without having to change
pom.xml’s in several places?

Recently I discovered the above page is not complete, there are other
items to update:

  • On

web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaManagerService.js
you have to add each of the schemas you’re adding and for each add a
procedure to retrieve the proper codelists.

  • On

web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDirective.js
there is an error namespaces[gnCurrentEdit.schema][‘gco’] undefined

In the javascripts there is quite some xml snippets hardcoded, which
worries me if at some point someone wants to start implementating a
totally new schema like Dublin Core, SensorML, GBIF/EML,
schema.org/Dataset or DCAT.
Some directives may only be called from the form-config in a certain
schema, and thus may be tightly bound to that schema, which could be
fine. Altough in that case it would be better to use a naming convention
like iso19139-date-picker-directive.js, any profile that is based on
iso19139 can then use that directive?

Would be interested to hear your thoughts on this and see if we can
define a way to move this forward.

For new profile, I would recommend to use a dedicated repository like
https://github.com/metadata101/ instead of mixing all schemas in
schema-plugins repository. It’s then much easier to use submodule to plug a
profile in a custom flavour of GeoNetwork.

In 3.x, Java logic for each profiles can be much easier be moved to the
plugin. BTW, as we are doing more and more on the client side, we have now
more JS logic. Did you (and Maria) made some experiment to extract the JS
parts in a separate maven module - for the community module work last year ?

Hi,

Yes, we have experimented in that field (and we are still!). Not in
extracting the current javascript in different modules, but in being
able to add extra javascript/html maven projects to GeoNetwork having
to modify just a few lines in wro-sources and pom.xml files. I have as
a pending task write a good documentation on how to write your own UI
using as a backup the default one but being able to override whatever
you need. Some steps are still a bit ugly (for example, you have to
use mvn jetty:run-explode instead of jetty:run if you want to override
some files), but it is in an easy working status now

Ok, so needs more improvements. Not sure what would be best to hook dynamic dependencies to the wro4j mechanism. Maybe one service should create a list of dependencies based on the plugins loaded (similar to what oasis catalogs are doing). To be investigated.

On the other hand, the only solution we have found for the “hardcoded”
parts in javascript for schemas is to get the code dynamically from a
service. For example, get the array of schemas and their namespaces
from the server. Which probably is the best option… right? And have
a bean on each schemas that loads this definitions on the service.

That may cover some other needs that Simon did not covered in his PR.

Francois

I’ve not much ideas on this, but last changes from Simon improve this a
little for ISO profiles.

Once you’ve the repository for the plugin, we could probably use Jenkins to
build packages for each plugins - but we’ll have to better maintain versions
between GN and plugins.

My .2 cents.

Francois


Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple
OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140


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


Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple
OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140


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

Hi,

For new profile, I would recommend to use a dedicated repository like
https://github.com/metadata101/ instead of mixing all schemas in
schema-plugins repository. It's then much easier to use submodule to plug a
profile in a custom flavour of GeoNetwork.

Shall we need to add a notice on
   https://github.com/geonetwork/schema-plugins
telling that the repo is deprecated and the new oneschema-onerepo approach
should be followed?

   Cheers,
   Emanuele

Alle 20:27:49 di Monday 7 December 2015, Francois Prunayre ha scritto:

Hi Paul,

2015-12-02 9:32 GMT+01:00 Paul van Genuchten <paul.vangenuchten@anonymised.com>:
> Hi list, in recent projects i've been struggling with the new
> schema-profiles in GN3.0 and found they are not that pluggable as they
> are in GN2.0 (and should be imho).
>
> A while back I've added in this page a list of actions to
> 'plug-a-profile'.
>
> http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-gu
> ide/managing-metadata-standards/index.html#adding-a-schema
>
> Would it be interesting to see if we can move profiles to a maven
> repository, so people can include profiles without having to change
> pom.xml's in several places?
>
> Recently I discovered the above page is not complete, there are other
> items to update:
>
> - On
>
> web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaM
> anagerService.js you have to add each of the schemas you're adding and
> for each add a procedure to retrieve the proper codelists.
> - On
>
> web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDi
> rective.js there is an error namespaces[gnCurrentEdit.schema]['gco']
> undefined
>
> In the javascripts there is quite some xml snippets hardcoded, which
> worries me if at some point someone wants to start implementating a
> totally new schema like Dublin Core, SensorML, GBIF/EML,
> schema.org/Dataset or DCAT.
> Some directives may only be called from the form-config in a certain
> schema, and thus may be tightly bound to that schema, which could be
> fine. Altough in that case it would be better to use a naming convention
> like iso19139-date-picker-directive.js, any profile that is based on
> iso19139 can then use that directive?
>
> Would be interested to hear your thoughts on this and see if we can
> define a way to move this forward.

For new profile, I would recommend to use a dedicated repository like
https://github.com/metadata101/ instead of mixing all schemas in
schema-plugins repository. It's then much easier to use submodule to plug a
profile in a custom flavour of GeoNetwork.

In 3.x, Java logic for each profiles can be much easier be moved to the
plugin. BTW, as we are doing more and more on the client side, we have now
more JS logic. Did you (and Maria) made some experiment to extract the JS
parts in a separate maven module - for the community module work last year
? I've not much ideas on this, but last changes from Simon improve this a
little for ISO profiles.

Once you've the repository for the plugin, we could probably use Jenkins to
build packages for each plugins - but we'll have to better maintain
versions between GN and plugins.

My .2 cents.

Francois

> -------------------------------------------------------------------------
> ----- Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> GeoNetwork-devel mailing list
> GeoNetwork-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> GeoNetwork OpenSource is maintained at
> http://sourceforge.net/projects/geonetwork

--

GeoServer Professional Services from the experts!
Visit http://goo.gl/NWWaa2 for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

2015-12-08 12:24 GMT+01:00 Emanuele Tajariol <etj@anonymised.com>:

Hi,

> For new profile, I would recommend to use a dedicated repository like
> https://github.com/metadata101/ instead of mixing all schemas in
> schema-plugins repository. It's then much easier to use submodule to
plug a
> profile in a custom flavour of GeoNetwork.

Shall we need to add a notice on
   https://github.com/geonetwork/schema-plugins
telling that the repo is deprecated and the new oneschema-onerepo approach
should be followed?

Sounds good Emanuele and maybe indicating which plugins are still
maintained or not and which one are now on metadata101 or elsewhere.

Francois

   Cheers,
   Emanuele

Alle 20:27:49 di Monday 7 December 2015, Francois Prunayre ha scritto:
> Hi Paul,
>
> 2015-12-02 9:32 GMT+01:00 Paul van Genuchten <
paul.vangenuchten@anonymised.com>:
> > Hi list, in recent projects i've been struggling with the new
> > schema-profiles in GN3.0 and found they are not that pluggable as they
> > are in GN2.0 (and should be imho).
> >
> > A while back I've added in this page a list of actions to
> > 'plug-a-profile'.
> >
> >
http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-gu
> > ide/managing-metadata-standards/index.html#adding-a-schema
> >
> > Would it be interesting to see if we can move profiles to a maven
> > repository, so people can include profiles without having to change
> > pom.xml's in several places?
> >
> > Recently I discovered the above page is not complete, there are other
> > items to update:
> >
> > - On
> >
> >
web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaM
> > anagerService.js you have to add each of the schemas you're adding and
> > for each add a procedure to retrieve the proper codelists.
> > - On
> >
> >
web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDi
> > rective.js there is an error namespaces[gnCurrentEdit.schema]['gco']
> > undefined
> >
> > In the javascripts there is quite some xml snippets hardcoded, which
> > worries me if at some point someone wants to start implementating a
> > totally new schema like Dublin Core, SensorML, GBIF/EML,
> > schema.org/Dataset or DCAT.
> > Some directives may only be called from the form-config in a certain
> > schema, and thus may be tightly bound to that schema, which could be
> > fine. Altough in that case it would be better to use a naming
convention
> > like iso19139-date-picker-directive.js, any profile that is based on
> > iso19139 can then use that directive?
> >
> > Would be interested to hear your thoughts on this and see if we can
> > define a way to move this forward.
>
> For new profile, I would recommend to use a dedicated repository like
> https://github.com/metadata101/ instead of mixing all schemas in
> schema-plugins repository. It's then much easier to use submodule to
plug a
> profile in a custom flavour of GeoNetwork.
>
> In 3.x, Java logic for each profiles can be much easier be moved to the
> plugin. BTW, as we are doing more and more on the client side, we have
now
> more JS logic. Did you (and Maria) made some experiment to extract the JS
> parts in a separate maven module - for the community module work last
year
> ? I've not much ideas on this, but last changes from Simon improve this a
> little for ISO profiles.
>
> Once you've the repository for the plugin, we could probably use Jenkins
to
> build packages for each plugins - but we'll have to better maintain
> versions between GN and plugins.
>
> My .2 cents.
>
> Francois
>
> >
-------------------------------------------------------------------------
> > ----- Go from Idea to Many App Stores Faster with Intel(R) XDK
> > Give your users amazing mobile app experiences with Intel(R) XDK.
> > Use one codebase in this all-in-one HTML5 development environment.
> > Design, debug & build mobile apps & 2D/3D high-impact games for
multiple
> > OSs.
> > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> > _______________________________________________
> > GeoNetwork-devel mailing list
> > GeoNetwork-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> > GeoNetwork OpenSource is maintained at
> > http://sourceforge.net/projects/geonetwork

--

GeoServer Professional Services from the experts!
Visit http://goo.gl/NWWaa2 for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Hi Plugin maintainers :wink:

···

2015-12-08 12:24 GMT+01:00 Emanuele Tajariol <etj@…924…>:

Hi,

For new profile, I would recommend to use a dedicated repository like
https://github.com/metadata101/ instead of mixing all schemas in
schema-plugins repository. It’s then much easier to use submodule to plug a
profile in a custom flavour of GeoNetwork.

Shall we need to add a notice on
https://github.com/geonetwork/schema-plugins
telling that the repo is deprecated and the new oneschema-onerepo approach
should be followed?

Readme updated https://github.com/geonetwork/schema-plugins.

Don’t hesitate to update the plugin’s status depending on your projects to indicate if they’re maintained/deprecated and which version can be used with it.

Cheers.

Francois

Cheers,
Emanuele

Alle 20:27:49 di Monday 7 December 2015, Francois Prunayre ha scritto:

Hi Paul,

2015-12-02 9:32 GMT+01:00 Paul van Genuchten <paul.vangenuchten@anonymised.com>:

Hi list, in recent projects i’ve been struggling with the new
schema-profiles in GN3.0 and found they are not that pluggable as they
are in GN2.0 (and should be imho).

A while back I’ve added in this page a list of actions to
‘plug-a-profile’.

http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-gu
ide/managing-metadata-standards/index.html#adding-a-schema

Would it be interesting to see if we can move profiles to a maven
repository, so people can include profiles without having to change
pom.xml’s in several places?

Recently I discovered the above page is not complete, there are other
items to update:

  • On

web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaM
anagerService.js you have to add each of the schemas you’re adding and
for each add a procedure to retrieve the proper codelists.

  • On

web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDi
rective.js there is an error namespaces[gnCurrentEdit.schema][‘gco’]

undefined

In the javascripts there is quite some xml snippets hardcoded, which
worries me if at some point someone wants to start implementating a
totally new schema like Dublin Core, SensorML, GBIF/EML,
schema.org/Dataset or DCAT.
Some directives may only be called from the form-config in a certain
schema, and thus may be tightly bound to that schema, which could be
fine. Altough in that case it would be better to use a naming convention
like iso19139-date-picker-directive.js, any profile that is based on
iso19139 can then use that directive?

Would be interested to hear your thoughts on this and see if we can
define a way to move this forward.

For new profile, I would recommend to use a dedicated repository like
https://github.com/metadata101/ instead of mixing all schemas in
schema-plugins repository. It’s then much easier to use submodule to plug a
profile in a custom flavour of GeoNetwork.

In 3.x, Java logic for each profiles can be much easier be moved to the
plugin. BTW, as we are doing more and more on the client side, we have now
more JS logic. Did you (and Maria) made some experiment to extract the JS
parts in a separate maven module - for the community module work last year
? I’ve not much ideas on this, but last changes from Simon improve this a
little for ISO profiles.

Once you’ve the repository for the plugin, we could probably use Jenkins to
build packages for each plugins - but we’ll have to better maintain
versions between GN and plugins.

My .2 cents.

Francois


----- Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple
OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140


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

GeoServer Professional Services from the experts!
Visit http://goo.gl/NWWaa2 for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it