Hi,
>> The problem is compatibility and the toolchain which already exist and
would break..
It is absolutely true that if this feature is introduced Maven less than
version X will not accept the POM.
The Maven version is not related to this, cause its based on the POM
modellVersion....which is at the moment at 4.0.0 and this is the factor
which will limit this. All Maven verisons which will read modellVersion
4.0.0 will work..(maven 2.2.1, 3.0.5, 3.1.1, 3.2.5, 3.3.1 etc.
(theoretical Maven 2.0.X will work also)
There have been longer discussions on the dev list about exactly this
subject...
If we would change Maven 4.X to use a different POM (modellVersion) but
you need to distribute a POM which is modellVersion 4.0.0 conform to be
consumed by other Maven versions as well...otherwise you will force
everyone to upgrade by changing a switch which will not work.
It takes a really long time to get people to upgrade new
versions...currently people are working with Maven 2.2.1 etc. (I know
they should think hard about it)...
> But Maven ver X+ will still accept
both URL-based and Artifact-based repositories. Hence the forward
compatibility, not backwards.
See above. The POM is the factor NOT the Maven version itself...
Furthermore if you change the pom modell this will result in artifacts
within repositories (like Maven Central) which can't be used by other
versions which will not work...
> Maven already has prerequisites
prerequisites defines the build time requirement for a particular
project and has nothing to do with run time...and consuming the pom file....
>> .
>>
>> See here: Many ideas already exist...
>>
>>
http://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
>>
>>
>> In particular the part: "Issues to be reviewed for 4.x"...
>>
>> You could make a entry with your suggestins etc. and maybe a proof of
>> concept implementation?
> That's great! Thanks a lot, I'll do that.
>
>>
>>>
>>> On 2015-03-21 04:11, Jeff MAURY wrote:
>>>> then your stuff will not be Maven compatible. You will face non
>>>> adoption
>>>> from the community
>>>>
>>>> Jeff
>>>>
>>>> On Sat, Mar 21, 2015 at 9:01 AM, Arcadiy Ivanov <[email protected]>
>>>> wrote:
>>>>
>>>>> Presumably, by editing maven-model/src/main/mdo/maven.mdo ? :)
>>>>>
>>>>>
>>>>> On 2015-03-21 03:31, Jeff MAURY wrote:
>>>>>
>>>>>> how will you extend the repository element in maven ?
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>> On Fri, Mar 20, 2015 at 11:52 PM, Arcadiy Ivanov <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>> Hi folks,
>>>>>>> I'd like to feel your temperature wrt the following improvement I
>>>>>>> would
>>>>>>> like to make to Maven before I start working on it.
>>>>>>>
>>>>>>> *== Artifact-based Reposi**tories* ==
>>>>>>>
>>>>>>> In Tycho we have these constructs:
>>>>>>>
>>>>>>>
https://wiki.eclipse.org/Tycho/Reference_Card#Repository_providing_the_
>>>>>>>
>>>>>>>
>>>>>>> context_of_the_build
>>>>>>>
>>>>>>> <repository>
>>>>>>> <id>eclipse-indigo</id>
>>>>>>> <layout>p2</layout>
>>>>>>> <url>http://download.eclipse.org/releases/indigo</url>
>>>>>>> </repository>
>>>>>>>
>>>>>>> P2 repositories can be encapsulated in an archive. An archive,
>>>>>>> naturally,
>>>>>>> can be available as an artifact in some repo somewhere (including
>>>>>>> the
>>>>>>> local
>>>>>>> one).
>>>>>>>
>>>>>>>
>>>>>>> What would you think about adding something like:
>>>>>>>
>>>>>>>
>>>>>>> <repository>
>>>>>>> <id>eclipse-indigo</id>
>>>>>>> <layout>p2</layout>
>>>>>>> <groupId>foo</artifactId>
>>>>>>> <artifactId>bar</artifactId>
>>>>>>> <version>1.2.3-SNAPSHOT</version>
>>>>>>> <type>tgz</type>
>>>>>>> <required>true</required>
>>>>>>> </repository>
>>>>>>>
>>>>>>>
>>>>>>> The broad strokes are as follows:
>>>>>>>
>>>>>>> * Repo artifact becomes a dependency of an artifact being built
>>>>>>> on the
>>>>>>> same terms as its parent would be, i.e. if you can't find
>>>>>>> parent you
>>>>>>> can't build same with repo artifact (by default)
>>>>>>> * If repo <required> (or <optional> to reverse the semantics) is
>>>>>>> false
>>>>>>> (true), failure to resolve the repository does not lead to a
>>>>>>> critical failure and reactor proceeeds as if the repository
>>>>>>> declaration did not occur.
>>>>>>> * Repo artifact is attempted to be resolved using all of the
>>>>>>> repositories inherited from parents, ad infinitum, or in the
>>>>>>> repository declarations prior to the one being considered.
>>>>>>> Artifact
>>>>>>> is, otherwise, resolved by standard means.
>>>>>>>
>>>>>>> Let me know what you think,
>>>>>>>
>>>>>>> --
>>>>>>> Arcadiy Ivanov
>>>>>>> [email protected] | @arcivanov | https://ivanov.biz
>>>>>>> https://github.com/arcivanov
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Arcadiy Ivanov
>>>>> [email protected] | @arcivanov | https://ivanov.biz
>>>>> https://github.com/arcivanov
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
