You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2013/11/25 14:34:29 UTC
More hard problems...
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
Re: More hard problems...
Posted by Stephen Connolly <st...@gmail.com>.
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 <
> stephen.alan.connolly@gmail.com>:
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
RE: More hard problems...
Posted by Martin Gainty <mg...@hotmail.com>.
> To: dev@maven.apache.org
> Subject: Re: More hard problems...
> Date: Tue, 26 Nov 2013 22:57:45 +0100
> From: ecki@zusammenkunft.net
>
> Am 26.11.2013, 22:02 Uhr, schrieb Robert Scholte <rf...@apache.org>:
> > 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?
>
> Related there is also the need for "features". Larger projects typically
> have a lot of optional dependencies but dont help to requesat a specific
> subset. For example a Scheduler like Quartz offers a core engine but also
MG>Here are the Quartz configuration properties i have
org.quartz.scheduler.instanceName = JBossQuartzScheduler
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 10
org.quartz.threadPool.threadPriority = 5
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true
MG>would you know of a plugin that will update my quartz.properties
MG>in org\jboss\resource\adapter\quartz\inflow
> EJB APIs or a Servlet manager implementation. In an ideal world the
> project would be split into multiple artifacts, but even then there can be
> a complexity explosion. Depending on the "core scheduler" feature of
> "quartz" would then skip all optional dependencies (like servlet and EJB
> API).
MG>How best to configure quartz core scheduler feature?
MG>What would this look like?
>
> (This is similiar to the testing scope, which could be implemented as a
> well known "feature"). And this also goes in line with
> platforms/implementations: the "jdk1.4" feature can depend on a
> concurrent-backport wherees the java7 does not.
>
> Gruss
> Bernd
MG>Beste Grüße
MG>Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: More hard problems...
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Am 26.11.2013, 22:02 Uhr, schrieb Robert Scholte <rf...@apache.org>:
> 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?
Related there is also the need for "features". Larger projects typically
have a lot of optional dependencies but dont help to requesat a specific
subset. For example a Scheduler like Quartz offers a core engine but also
EJB APIs or a Servlet manager implementation. In an ideal world the
project would be split into multiple artifacts, but even then there can be
a complexity explosion. Depending on the "core scheduler" feature of
"quartz" would then skip all optional dependencies (like servlet and EJB
API).
(This is similiar to the testing scope, which could be implemented as a
well known "feature"). And this also goes in line with
platforms/implementations: the "jdk1.4" feature can depend on a
concurrent-backport wherees the java7 does not.
Gruss
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: More hard problems...
Posted by Robert Scholte <rf...@apache.org>.
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.
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
<st...@gmail.com>:
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org