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 <and...@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.conno...@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 <t...@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-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>
