maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: POM interoperability
Date Mon, 01 Nov 2010 22:59:25 GMT
I think we need to get use to the idea of deploying a different POM
(as XML) from the POM that is used to build.

Here are some use-cases I can see:

1. Corporate project which deploys an artifact to a public repo.  Some
of the info (e.g. SCM details, developers, build, distMgmt, etc) is,
due to corporate policies / sensible reasons, information that should
not be deployed publically.

  e.g. I may not want people contacting me directly just because I
worked for XYZ corp on that foobar-impl project

  e.g. May not want to publish how the artifact is built for external persons.

2. Shading

3. Backwards compat.

4. Properties behaving badly

-Stephen

On 1 November 2010 22:37, Jason van Zyl <jason@maven.org> wrote:
> I am working on a release of Polyglot Maven and the only tangible thing stopping me is
having a plan for POM interoperability between:
>
> 1) Different representations of the model for the same version of the model. This is
what I'd like for the first version of Polyglot Maven where I just want to translate the version
4.0.0 model between different representations.
>
> 2) Different versions of the model. This is something we will need for Maven 3.1.
>
> In talking with Benjamin and Brian for 1) I think it would be easiest to deploy both
versions of the model. The complete model in the native dialect like Clojure, and the complete
XML translation. Deploying both would be useful because in the case of Clojure they are trying
to come up with a common model, like the POM, for Clojure-based build tools. So if someone
built and deployed with Polyglot Maven using the Clojure dialect then they want people not
using Polyglot Maven i.e. a native Clojure tool to read the Clojure. This assumes our models
are compatible but we'll have to work that out. We need to start somewhere so I don't think
abbreviating any of the information is good for a first pass. Leave it all there for now and
we'll figure out if a build-only representation of the model will suffice for sending to the
repository.
>
> For 2) Benjamin's recommendation was to transform elements in the newer model back to
the 4.0.0 model. I'm not sure how long this will be possible but if we live with our baggage
and say we'll only add elements to the model I think this will be a lot easier. Having to
track removals across versions of the model will be a pain in the ass. We translate back for
as long as we can and when we can't do that anymore maybe we do a build-only transformation.
>
> I'd like to field other thoughts before I write something up. I'm going to do all this
work in Polyglot Maven because I'm sure I'm going to break things but the folks I'm working
with will tolerate this for a while. I'm chatting with folks in the Clojure community on a
Lein-like markup, Dhanji (a  Googler working on Guice and Sitebricks) who is working on a
format called Atom, and Kristian (fellow who makes all the Ruby/Maven tooling) who is working
on a Ruby DSL. If things break here for a while it's not the end of the world and is a good
testing ground.
>
> At any rate if anyone has ideas or documents I'll integrate it into the proposal I'm
writing. I'm moving pretty fast and I plan to release a version of the Maven Shell next week,
and then a couple weeks later a version with Polyglot capabilities. So if you have thoughts
I'd appreciate them sooner rather then later.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Selfish deeds are the shortest path to self destruction.
>
>  -- The Seven Samuari, Akira Kurosawa
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message