You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Thomas Sundberg <ts...@kth.se> on 2013/04/08 09:53:03 UTC
Handle XSDs with Maven and Nexus?
Hi!
We seem to want to publish XSDs (XML Schema Definitions) in a project.
I have been told that we want to make XSDs available at a well known
url.
We are using Maven and I tried to sell the idea that we create a jar
that contains the XSD and add this as a dependency in a Maven build.
This wasn't a good enough solution.
How would you publish a XSD for a project and make it available for
other Maven builds?
We are using Nexus so publishing there is an option.
/Thomas
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://thomassundberg.wordpress.com/
Twitter: @thomassundberg
Better software through faster feedback
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Handle XSDs with Maven and Nexus?
Posted by Stephen Connolly <st...@gmail.com>.
I thought I had written that down... but it would appear that I didn't!
Be a good idea for somebody (hint, if you are reading this, that somebody
is you) to contribute such a packaging type plugin over at mojo... remove a
lot of people's confusion though
On 8 April 2013 10:18, Anders Hammar <an...@hammar.net> wrote:
> One could even create a custom packaging type "xsd" to use. That's what
> I've done for wsdl files for a customer. It's meta data and having a
> specific packaging type instead of a general (and incorrect) "pom"
> packaging type is good.
>
> /Anders
>
>
> On Mon, Apr 8, 2013 at 10:06 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > There are many ways to skin this cat...
> >
> > If I were doing this I would take the following slant...
> >
> > 1. I like to keep to publishing 1 build-consumable artifact per GAV... (I
> > don't see javadoc or sources as artifacts in this regard as they are
> > *typically* consumed by people and not builds)
> > 2. I really don't mind having lots of modules.
> >
> > The XSD can be generated in one of two ways:
> >
> > a) The XSD is generated by hand
> > b) The XSD is generated from code
> >
> > With the generated by hand, I would just create a separate module for the
> > XSD only. Unless I was doing a lot of XSDs I would hijack
> > <packaging>pom</packaging> and use buildhelper-m-p to attach the XSD to
> the
> > reactor that would result in the XSD being downloadable directly over
> > http(s) from the Maven repo that the project gets deployed to at
> >
> >
> http(s)://{hostname}/{context-path}/{groupIdwithdotsreplacedbyslashes}/{artifactId}/{version}/{artifactId}-{version}.xsd
> > I would very much try to avoid doing anything else in that module, IOW
> when
> > generating code against the XSD I would do that in a different module
> that
> > depends on the XSD and uses dependency:copy-dependencies to copy the XSD
> > into a location where it can be fed to the code generation tools.
> >
> > With the generating from code, things get a tad trickier... my goal would
> > be to be able to produce the XSD from the .jar by e.g. parsing
> annotations,
> > or perhaps even by unpacking the .jar and pulling out the XSD that was
> > embedded in the .jar if the code generation strategy puts the XSD inside
> > the .jar as a necessary side-effect of the code generation process... all
> > those would allow me to basically treat as before... *but* reality may
> > hit... e.g. annotations may not be retained in the compiled code, the XSD
> > could be generated from the javadoc comments in the source code and not
> > java1.5 annotations, etc... in those cases I would just attach the XSD
> as a
> > side artifact to the .jar module using buildhelper-m-p as, while it is a
> > noble goal to keep to 1 artifact per module, sometimes you need to do
> what
> > you need to do
> >
> > On 8 April 2013 08:53, Thomas Sundberg <ts...@kth.se> wrote:
> >
> > > Hi!
> > >
> > > We seem to want to publish XSDs (XML Schema Definitions) in a project.
> > > I have been told that we want to make XSDs available at a well known
> > > url.
> > >
> > > We are using Maven and I tried to sell the idea that we create a jar
> > > that contains the XSD and add this as a dependency in a Maven build.
> > > This wasn't a good enough solution.
> > >
> > > How would you publish a XSD for a project and make it available for
> > > other Maven builds?
> > >
> > > We are using Nexus so publishing there is an option.
> > >
> > > /Thomas
> > >
> > > --
> > > Thomas Sundberg
> > > M. Sc. in Computer Science
> > >
> > > Mobile: +46 70 767 33 15
> > > Blog: http://thomassundberg.wordpress.com/
> > > Twitter: @thomassundberg
> > >
> > > Better software through faster feedback
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
Re: Handle XSDs with Maven and Nexus?
Posted by Anders Hammar <an...@hammar.net>.
One could even create a custom packaging type "xsd" to use. That's what
I've done for wsdl files for a customer. It's meta data and having a
specific packaging type instead of a general (and incorrect) "pom"
packaging type is good.
/Anders
On Mon, Apr 8, 2013 at 10:06 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> There are many ways to skin this cat...
>
> If I were doing this I would take the following slant...
>
> 1. I like to keep to publishing 1 build-consumable artifact per GAV... (I
> don't see javadoc or sources as artifacts in this regard as they are
> *typically* consumed by people and not builds)
> 2. I really don't mind having lots of modules.
>
> The XSD can be generated in one of two ways:
>
> a) The XSD is generated by hand
> b) The XSD is generated from code
>
> With the generated by hand, I would just create a separate module for the
> XSD only. Unless I was doing a lot of XSDs I would hijack
> <packaging>pom</packaging> and use buildhelper-m-p to attach the XSD to the
> reactor that would result in the XSD being downloadable directly over
> http(s) from the Maven repo that the project gets deployed to at
>
> http(s)://{hostname}/{context-path}/{groupIdwithdotsreplacedbyslashes}/{artifactId}/{version}/{artifactId}-{version}.xsd
> I would very much try to avoid doing anything else in that module, IOW when
> generating code against the XSD I would do that in a different module that
> depends on the XSD and uses dependency:copy-dependencies to copy the XSD
> into a location where it can be fed to the code generation tools.
>
> With the generating from code, things get a tad trickier... my goal would
> be to be able to produce the XSD from the .jar by e.g. parsing annotations,
> or perhaps even by unpacking the .jar and pulling out the XSD that was
> embedded in the .jar if the code generation strategy puts the XSD inside
> the .jar as a necessary side-effect of the code generation process... all
> those would allow me to basically treat as before... *but* reality may
> hit... e.g. annotations may not be retained in the compiled code, the XSD
> could be generated from the javadoc comments in the source code and not
> java1.5 annotations, etc... in those cases I would just attach the XSD as a
> side artifact to the .jar module using buildhelper-m-p as, while it is a
> noble goal to keep to 1 artifact per module, sometimes you need to do what
> you need to do
>
> On 8 April 2013 08:53, Thomas Sundberg <ts...@kth.se> wrote:
>
> > Hi!
> >
> > We seem to want to publish XSDs (XML Schema Definitions) in a project.
> > I have been told that we want to make XSDs available at a well known
> > url.
> >
> > We are using Maven and I tried to sell the idea that we create a jar
> > that contains the XSD and add this as a dependency in a Maven build.
> > This wasn't a good enough solution.
> >
> > How would you publish a XSD for a project and make it available for
> > other Maven builds?
> >
> > We are using Nexus so publishing there is an option.
> >
> > /Thomas
> >
> > --
> > Thomas Sundberg
> > M. Sc. in Computer Science
> >
> > Mobile: +46 70 767 33 15
> > Blog: http://thomassundberg.wordpress.com/
> > Twitter: @thomassundberg
> >
> > Better software through faster feedback
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Handle XSDs with Maven and Nexus?
Posted by Stephen Connolly <st...@gmail.com>.
There are many ways to skin this cat...
If I were doing this I would take the following slant...
1. I like to keep to publishing 1 build-consumable artifact per GAV... (I
don't see javadoc or sources as artifacts in this regard as they are
*typically* consumed by people and not builds)
2. I really don't mind having lots of modules.
The XSD can be generated in one of two ways:
a) The XSD is generated by hand
b) The XSD is generated from code
With the generated by hand, I would just create a separate module for the
XSD only. Unless I was doing a lot of XSDs I would hijack
<packaging>pom</packaging> and use buildhelper-m-p to attach the XSD to the
reactor that would result in the XSD being downloadable directly over
http(s) from the Maven repo that the project gets deployed to at
http(s)://{hostname}/{context-path}/{groupIdwithdotsreplacedbyslashes}/{artifactId}/{version}/{artifactId}-{version}.xsd
I would very much try to avoid doing anything else in that module, IOW when
generating code against the XSD I would do that in a different module that
depends on the XSD and uses dependency:copy-dependencies to copy the XSD
into a location where it can be fed to the code generation tools.
With the generating from code, things get a tad trickier... my goal would
be to be able to produce the XSD from the .jar by e.g. parsing annotations,
or perhaps even by unpacking the .jar and pulling out the XSD that was
embedded in the .jar if the code generation strategy puts the XSD inside
the .jar as a necessary side-effect of the code generation process... all
those would allow me to basically treat as before... *but* reality may
hit... e.g. annotations may not be retained in the compiled code, the XSD
could be generated from the javadoc comments in the source code and not
java1.5 annotations, etc... in those cases I would just attach the XSD as a
side artifact to the .jar module using buildhelper-m-p as, while it is a
noble goal to keep to 1 artifact per module, sometimes you need to do what
you need to do
On 8 April 2013 08:53, Thomas Sundberg <ts...@kth.se> wrote:
> Hi!
>
> We seem to want to publish XSDs (XML Schema Definitions) in a project.
> I have been told that we want to make XSDs available at a well known
> url.
>
> We are using Maven and I tried to sell the idea that we create a jar
> that contains the XSD and add this as a dependency in a Maven build.
> This wasn't a good enough solution.
>
> How would you publish a XSD for a project and make it available for
> other Maven builds?
>
> We are using Nexus so publishing there is an option.
>
> /Thomas
>
> --
> Thomas Sundberg
> M. Sc. in Computer Science
>
> Mobile: +46 70 767 33 15
> Blog: http://thomassundberg.wordpress.com/
> Twitter: @thomassundberg
>
> Better software through faster feedback
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Handle XSDs with Maven and Nexus?
Posted by Ben Caradoc-Davies <Be...@csiro.au>.
Even once XSDs are published at a well-known location (necessary for
non-Maven validating parsers), I still like bundling XSDs for offline
Maven builds (why should your CI go down when a web server is offline?).
JAR bundling is great. Defeat the jar-haters by turning it around:
publish static XSDs and then bundle them into JARs for Maven.
For example, GeoSciML is published as a bunch of static files on an
apache instance:
http://www.geosciml.org/geosciml/2.0/
But I needed tests that worked offline, so for GeoTools I bundled some
artifacts that I pushed onto a Maven repo:
https://github.com/geotools/geotools/tree/master/modules/extension/app-schema/app-schema-packages
These do not get run as part of the standard build; publication is a
manual process because the schemas are outside GeoTools governance.
Then the code has some wrappers:
https://github.com/geotools/geotools/tree/master/modules/extension/app-schema/app-schema-resolver
around a resolver that maps the original HTTP URL onto a classpath
(avoiding jar:file: URLs and enabling relative imports):
https://github.com/geotools/geotools/blob/master/modules/library/xml/src/main/java/org/geotools/xml/resolver/SchemaResolver.java
Test dependencies on online resources are bad news; JARs are so much better.
Your bigger problems are governance: versioning and change control of
your XSDs. How does this occur? Are these static committee/ISO-governed
XSDs, or the representation of a local changeable information model?
If your XSDs change often, you will quickly tire of updating poms and
repackaging artifacts. Please automate the process and tell me how. :-)
Kind regards,
Ben.
On 08/04/13 15:53, Thomas Sundberg wrote:
> Hi!
>
> We seem to want to publish XSDs (XML Schema Definitions) in a project.
> I have been told that we want to make XSDs available at a well known
> url.
>
> We are using Maven and I tried to sell the idea that we create a jar
> that contains the XSD and add this as a dependency in a Maven build.
> This wasn't a good enough solution.
>
> How would you publish a XSD for a project and make it available for
> other Maven builds?
>
> We are using Nexus so publishing there is an option.
>
> /Thomas
>
> --
> Thomas Sundberg
> M. Sc. in Computer Science
>
> Mobile: +46 70 767 33 15
> Blog: http://thomassundberg.wordpress.com/
> Twitter: @thomassundberg
>
> Better software through faster feedback
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ben Caradoc-Davies <Be...@csiro.au>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Handle XSDs with Maven and Nexus?
Posted by Martin Gainty <mg...@hotmail.com>.
I'll package custom XSDs and XSD extensions into the resources folder of my distro..for safekeeping
ISO XSDs I'll leave alone and assume the client can contact the site directly for the XSD
http://www.liquid-technologies.com/Tutorials/XmlSchemas/XsdTutorial_03.aspx
Alternative Strategies?
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> From: ml@batmat.net
> Date: Tue, 9 Apr 2013 10:58:00 +0200
> Subject: Re: Handle XSDs with Maven and Nexus?
> To: users@maven.apache.org
>
> FWIW, I also think this is a typical use case for maven remote resources
> plugin.
> I've used it in the past to store and version our checkstyle, pmd, and so
> config files, and it has been working fine for years.
>
> Cheers
>
>
> 2013/4/9 Thomas Sundberg <ts...@kth.se>
>
> > Hi!
> >
> > Thanks for all suggestions. I will contemplate this and see what we
> > come up with.
> >
> > Cheers
> > Thomas
> >
> >
> > On 8 April 2013 16:31, Wayne Fay <wa...@gmail.com> wrote:
> > >> How would you publish a XSD for a project and make it available for
> > >> other Maven builds?
> > >
> > > I expect that MRRP would be a part of the solution:
> > > http://maven.apache.org/plugins/maven-remote-resources-plugin/
> > >
> > > Wayne
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> >
> >
> >
> > --
> > Thomas Sundberg
> > M. Sc. in Computer Science
> >
> > Mobile: +46 70 767 33 15
> > Blog: http://thomassundberg.wordpress.com/
> > Twitter: @thomassundberg
> >
> > Better software through faster feedback
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> > --
> > Baptiste <Batmat> MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor ! nbsp;! <us...@maven.apache.org>
> >
Re: Handle XSDs with Maven and Nexus?
Posted by Baptiste MATHUS <ml...@batmat.net>.
FWIW, I also think this is a typical use case for maven remote resources
plugin.
I've used it in the past to store and version our checkstyle, pmd, and so
config files, and it has been working fine for years.
Cheers
2013/4/9 Thomas Sundberg <ts...@kth.se>
> Hi!
>
> Thanks for all suggestions. I will contemplate this and see what we
> come up with.
>
> Cheers
> Thomas
>
>
> On 8 April 2013 16:31, Wayne Fay <wa...@gmail.com> wrote:
> >> How would you publish a XSD for a project and make it available for
> >> other Maven builds?
> >
> > I expect that MRRP would be a part of the solution:
> > http://maven.apache.org/plugins/maven-remote-resources-plugin/
> >
> > Wayne
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
>
> --
> Thomas Sundberg
> M. Sc. in Computer Science
>
> Mobile: +46 70 767 33 15
> Blog: http://thomassundberg.wordpress.com/
> Twitter: @thomassundberg
>
> Better software through faster feedback
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! <us...@maven.apache.org>
>
Re: Handle XSDs with Maven and Nexus?
Posted by Thomas Sundberg <ts...@kth.se>.
Hi!
Thanks for all suggestions. I will contemplate this and see what we
come up with.
Cheers
Thomas
On 8 April 2013 16:31, Wayne Fay <wa...@gmail.com> wrote:
>> How would you publish a XSD for a project and make it available for
>> other Maven builds?
>
> I expect that MRRP would be a part of the solution:
> http://maven.apache.org/plugins/maven-remote-resources-plugin/
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://thomassundberg.wordpress.com/
Twitter: @thomassundberg
Better software through faster feedback
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Handle XSDs with Maven and Nexus?
Posted by Wayne Fay <wa...@gmail.com>.
> How would you publish a XSD for a project and make it available for
> other Maven builds?
I expect that MRRP would be a part of the solution:
http://maven.apache.org/plugins/maven-remote-resources-plugin/
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org