maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Heinz Marbaise <khmarba...@gmx.de>
Subject Re: Idea RFI: Artifact-based repositories
Date Sat, 21 Mar 2015 13:37:11 GMT
Hi,

On 3/21/15 2:14 PM, Arcadiy Ivanov wrote:
> So Maven pom is set in stone and no changes can be introduced to it?

For Model version 4.0.0 at which is Maven at the moment i don't see a 
chance for such things...

But there is no thing which prevents us from changing for Maven Model 
5.0.0 (Maven 4.X)...

> I'm writing this specifically to guage the community interest before
> starting the work. I.e. my intention is to have a general consensus that
> 1) it's a good thing to add 2) it's the right way to go about it.


>
> Generally speaking, adding optional tags does not break forward
> functionality, i.e. it's relatively safe.

It breaks cause the tags are not optional....

I have simply added a repository like you suggested to an existing pom 
which results in the following:

[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project  (/sapm/pom.xml) has 1 error
[ERROR]     Non-parseable POM /sapm/pom.xml: Unrecognised tag: 'groupId' 
(position: START_TAG seen ...</layout>\n            <groupId>... 
@131:22)  @ line 131, column 22 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the 
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, 
please read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] 
http://cwiki.apache.org/confluence/display/MAVEN/ModelParseException

>
> What would be the fundamental reason for never ever ever considering any
> additions to the POM ever again?

The problem is compatibility and the toolchain which already exist and 
would break...

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?

>
> 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 <arcadiy@gmail.com>
>> 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 <arcadiy@gmail.com>
>>>> 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
>>>>> arcadiy@gmail.com | @arcivanov | https://ivanov.biz
>>>>> https://github.com/arcivanov
>>>>>
>>>>>
>>>>>
>>> --
>>> Arcadiy Ivanov
>>> arcadiy@gmail.com | @arcivanov | https://ivanov.biz
>>> https://github.com/arcivanov
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>

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


Mime
View raw message