maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: Handle XSDs with Maven and Nexus?
Date Mon, 08 Apr 2013 09:18:46 GMT
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 <tsu@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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message