maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <>
Subject Re: More hard problems...
Date Tue, 26 Nov 2013 21:02:36 GMT
In addition to this story: There's an open issue called MDEPLOY-118 which  
describes a related issue: how to release the same version for different  

The platforms as described here look more like a new kind of profiles:  
platform as activation.
In this case I'm not so sure if the platform-tags are really adding.

But should we be talking about the platform specific dependencies or the  
platform specific artifact?
How about redirecting to a classified artifact for every platform?

          <platform gav="java:standard-edition:1.5">
          <platform gav="java:standard-edition:1.6">
          <platform gav="google:android:4.2">

not sure if gav is the correct way to identify the platform, though.



Op Mon, 25 Nov 2013 14:34:29 +0100 schreef Stephen Connolly  

> In addition to the modelVersion evolution problem, there are some other
> issues that I think we need to address for Maven 4.0+
> * Platform specific builds
> * Architecture specific builds
> * Native build flavours (e.g. debug vs non-debug)
> You could see this as the "side-artifact" dilemma.
> Here are some issues as I see it.... in no specific order
> * You may have a Java artifact that works on Java 1.5+ and Android. How
> would you express that?
>   One idea I have had is to have a "platform" descriptor... this could  
> be a
> simple dependency type or it could be an explicit model object... there  
> are
> swings and roundabouts to both.
>     - A "platform" dependency type is perhaps even doable in Maven 2.x,
> 3.x... just needs somebody to do all the work for everyone... You would
> have e.g. java:standard-edition:1.4:platform,
> java:standard-edition:1.5:platform, java:standard-edition:1.6:platform,
> java:standard-edition:1.7:platform, etc... they could have dependencies  
> on
> the additional libraries and apis that those platforms provide... which
> would let you collapse the dependency tree somewhat... the question is  
> how
> do we express android into that set?
>     - A "platforms" element in the model would allow for a list of
> platforms against which the artifact is compatible... perhaps even  
> allowing
> for expressing different dependency lists on each platform (if we go the
> .dml route) so you might have
>       <platforms>
>         <platform gav="java:standard-edition:1.5+">
>           <dependencies>
>             <dependency gav="..."/>
>           </dependencies>
>         </platform>
>         <platform gav="java:standard-edition:1.6+">
>           <dependencies>
>             <dependency gav="..."/>
>           </dependencies>
>         </platform>
>         <platform gav="google:android:4.2+">
>           <dependencies>
>             <dependency gav="..."/>
>           </dependencies>
>         </platform>
>       </platforms>
>       In such a scheme, you'd pick the best match platform, so JavaSE 1.7
> would have a best match against the 1.6 platform dependency list... but
> from the platform descriptor you may already have resolved some of the
> required dependencies...
>     - Another approach is to list the platforms like scopes in
> dependencies...
>     - In any case, this would be a consumer side information store... the
> build side descriptor would be responsible for constructing the
> information... and I presume some sort of tooling could end up being
> required to validate artifacts against the platform(s) they target.
>     - Do not assume all target platforms are JVM based... we could have
> people with NodeJS as a target platform... or .Net or Ruby On Rails (if
> they don't like Gem... or perhaps we get this right and Gem adopts our
> repo's new .dml descriptor!... don't worry that will never happen)
>     - If we get this right there would be a multitude of platforms...  
> e.g.
> Tomcat 7 could be seen as a valid platform for running on... similarly
> TomEE and Jetty. Each of these provide additional classes on the
> classpath... some classes are container specific and some not... plus
> people can run with different JVMs... could get messy real fast... [that
> may be a legitimate excuse as to why we have not tackled this problem  
> until
> now... does not make a valid excuse for continuing to dodge it though]
> * You may not be able to build all flavours of an artifact on the same
> machine at the same time. Need to support differential publishing.
>     - Publish the OS-X built artifact day 1
>     - Publish the x86 linux artifact day 2
>     - Publish the Windows artifact day 3
>     - Publish the debug ARM linux artifact that has additional runtime
> dependencies day 4
>     - This is calling out for tweaks in the repository format... we  
> cannot
> leverage classifiers for this without risk of some sort of hell...  
> perhaps
> we add platform/arch/build-type as a path layer in the repo... risks
> alienating existing clients... but as existing clients cannot handle this
> currently... so what... and as long as we let them construct a GAVCT that
> can retrieve the specific artifact they want... do we care?
>     - So G:A:V:P can be mapped to G.A:V:P or to put it a different way,
> legacy clients could access the osx-x86_64-debug build of
> org.manchu:foobar:1.0:dylib as  
> org.manchu.foobar:1.0:osx-x86_64-debug:dylib
> the downside with that mapping is -SNAPSHOT symantics are lost, e.g.
> org.manchu.foobar:1.0-SNAPSHOT:osx-x86_64-debug:dylib would not be
> considered a -SNAPSHOT version
>     - An alternative is to append P to A... letting us keep the G and V,  
> so
> we'd have org.manchu:foobar-osx-x86_64-debug:1.0:dylib and
> org.manchu:foobar-osx-x86_64-debug:1.0-SNAPSHOT:dylib
>       This one actually doesn't feel too bad... ok, so people may have  
> fun
> excluding transitive dependencies on other P's... but then again you may
> want to bundle the different native binaries in the same jar file, so  
> this
> affords the option and retains a lot of the feel you'd expect... but is
> this just a hack?
> What do people think on this set of hard problems?
> -Stephen

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message