On Tuesday, 26 November 2013, Robert Scholte wrote: > 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 > platforms? > > The platforms as described here look more like a new kind of profiles: > platform as activation.
Actually I see it as both. In the Java space, platforms are things like JVM version, app server, perhaps even layering in extensions in the lib/ext di In the native space platforms are Linux, osx, windows, .net, etc Each if these is potentially versioned. Each of these has the potential to provide specific dependencies that can be collapsed from the tree... And also the potential to require additional deps > 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? > > <platforms> > <platform gav="java:standard-edition:1.5"> > <classifier>jse15</classifier> > </platform> > <platform gav="java:standard-edition:1.6"> > <classifier>jse16</classifier> > </platform> > <platform gav="google:android:4.2"> > <classifier>android42</classifier> > </platform> > </platforms> > > not sure if gav is the correct way to identify the platform, though. > > Robert > > [1] https://jira.codehaus.org/browse/MDEPLOY-118 > > Op Mon, 25 Nov 2013 14:34:29 +0100 schreef Stephen Connolly < > [email protected]>: > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Sent from my phone
