Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

But reactor dependencies make perfect sense in m2e! Also, keep in mind that 
we are talking about new maven concept, it does not currently exist and 
can't be supported by m2e, netbeans or any other existing tool.


--
Regards,
Igor



On December 12, 2016 4:38:30 PM Christian Schulte  wrote:


Am 12/13/16 um 01:33 schrieb Igor Fedorenko:

This suggests inefficiency in existing implementation. We use this model
internally with some custom optimizations for a very large codebase.


Maybe. Netbeans is using the Maven API for all of this. It's like
building the full reactor on the command line with downloading source
jars and javadoc jars. That other IDE does not handle the artifacts as
artifacts but more or less views all of those artifacts as directories
in a common workspace and internally builds it's own classpaths and so
on. That's why the reactor coordinates do not seem to make any sense there.

Regards,
--
Christian


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





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

Re: Parent Version maybe not needed in child POM

[Tibor Digana]

>>Something like an J2EE
>>You can take a long walk
>>until it finishes downloading sources, javadoc, dependencies
>>I really only open the module(s) I need
This is not Maven problem then.
You architect must give you a freedom to move some modules apart and keep
some in it which makes the multi-module project as small as possible.
It must be really something wrong with your architect because you are
deploying SNAPSHOT versions to Nexus.
We only use multi-module project if and only if all projects have
compilation dependencies AND common database model.
There are always things which can be split to another trunk, for instance
Audit module or GenericDao, generic JSF components, Crypto utilities. There
was something wrong with our architect because he wanted to have a shared
business:jar and therefore we decided to combine multiple trunks to one
trunk and multi-module project and split the business part and minimize
coupling between WAR files and avoid cohesion in business:jar. It will be
still multi-module project but smaller because we will push some code apart
in another trunk but keep all WAR files in it because they have common
database model. In our case Microservices do not make sense because the web
UI requires using complex SQL JOINs and combining all Microservices in one
Elastic database brings us to one database again. One way or another I want
to combine all 12 war files only to 3 War files because it makes sense
which will make the big project smaller again and again. (admin:war,
customer:war, schedulers:war)

So I only wanted to say that multi-module project can be made small if
people have freedom to make it and then it is worth for them to still build
it from the root and test few applications together. Minimizing the
coupling and reorganizing cohesion is the way to reach the goal to have
multiple trunks (deploy release versions) having small multi-module project
(no snapshot deployment) in each trunk.



On Tue, Dec 13, 2016 at 12:25 AM, Christian Schulte  wrote:

> Am 12/12/16 um 23:23 schrieb Igor Fedorenko:
> > Disagree. I think in most if not all cases we build entire project, not
> > just random part of a project.
>
> Try opening a big multi-module project in Netbeans, for example.
> Something like an J2EE application server. You can take a long walk
> until it finishes downloading sources, javadoc, dependencies and the
> background scanning task before you can change a single line of code.
> Working on projects like that, I really only open the module(s) I need
> to work on, build them in isolation and copy resuling jar files around -
> during development.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

Jenkins: Modules changed, recalculating dependency graph

[Christian Schulte]

Would it be possible to assign me role in Jenkins allowing me to fix
things myself? I renamed 'maven-aether-provider' to
'maven-resolver-provider' and all hell breaks loose on Jenkins. I have a
strong need on a reliable CI system :-). I'd like to stop this one from
failing, for example, but cannot do anything about it.



If I ever meet Mr. Jenkins in person, he'll wish he never would have met
me for the rest of his live 8-) .

Regards,
-- 
Christian

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

2nd question regarding repository overriding.

[Christian Schulte]

Am 12/13/16 um 02:32 schrieb Christian Schulte:
> Consider these projects:
> 
> P1 declares a repository with id 'central' and a dependency on D1
> available in that repository.
> 
> D1 declares a repository with id 'central' with a different URL and has
> a dependency management import declaration on D2.
> 
> When importing D2 into the effective model of D1, which repository
> should be used? Does the 'central' repository definition in D1 override
> the 'central' repository definition in P1? How would you expect Maven to
> behave?
> 
> Regards,
> 

What repository to use if there is an active profile in the settings
also declaring a 'central' repository? That's the IT currently failing.
The resolver does not know about those profiles. Maybe that's the real
issue to fix. So - when there is an active profile in the settings
declaring a 'central' repository does that profile need to get injected
everywhere (also when building effective models of dependencies) or does
that profile only need to get injected into the initial effective model
and then can get ignored when building dependencies?




The fix to MNG-5639 introduced the issue uncovered now.

Regards,
-- 
Christian


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

Question regarding repository overriding.

[Christian Schulte]

Consider these projects:

P1 declares a repository with id 'central' and a dependency on D1
available in that repository.

D1 declares a repository with id 'central' with a different URL and has
a dependency management import declaration on D2.

When importing D2 into the effective model of D1, which repository
should be used? Does the 'central' repository definition in D1 override
the 'central' repository definition in P1? How would you expect Maven to
behave?

Regards,
-- 
Christian

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

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12/13/16 um 01:33 schrieb Igor Fedorenko:
> This suggests inefficiency in existing implementation. We use this model 
> internally with some custom optimizations for a very large codebase.

Maybe. Netbeans is using the Maven API for all of this. It's like
building the full reactor on the command line with downloading source
jars and javadoc jars. That other IDE does not handle the artifacts as
artifacts but more or less views all of those artifacts as directories
in a common workspace and internally builds it's own classpaths and so
on. That's why the reactor coordinates do not seem to make any sense there.

Regards,
-- 
Christian


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

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

This suggests inefficiency in existing implementation. We use this model 
internally with some custom optimizations for a very large codebase.


--
Regards,
Igor



On December 12, 2016 3:25:35 PM Christian Schulte  wrote:


Am 12/12/16 um 23:23 schrieb Igor Fedorenko:

Disagree. I think in most if not all cases we build entire project, not
just random part of a project.


Try opening a big multi-module project in Netbeans, for example.
Something like an J2EE application server. You can take a long walk
until it finishes downloading sources, javadoc, dependencies and the
background scanning task before you can change a single line of code.
Working on projects like that, I really only open the module(s) I need
to work on, build them in isolation and copy resuling jar files around -
during development.





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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/12/16 um 22:55 schrieb Michael Osipov:
> Am 2016-12-12 um 02:48 schrieb Christian Schulte:
>> Am 12/11/16 um 22:56 schrieb Michael Osipov:
>>> I just ran ITs with current master, only one IT fails:
>>
>> Should be fixed now.
> 
> Are you certain about this? I cannot confirm. 
> 723b942ad10ab471dfbc5d81ed1071891573dc01 fixes MNG-5227 IT but the IT 
> failing ist for MNG-4347.
> 

It's a bug in the core introduced a few releases ago and uncovered now
due to the changes to the import scope. Not sure the 'ModelResolver'
really should replace 'externalRepositories'. Will take some time
solving that. At least I know what's causing this.


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

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12/13/16 um 01:07 schrieb Manfred Moser:
> All of these task should only happen when you open a new project. Otherwise 
> all of it should be cached in the local repo.
> 
> When all of it is local it should NOT take so long. At least it doesnt in 
> M2e. If you resort to a hack like opening only part of the reactor you should 
> not be surprised if working on it is only semi-optimal.
> 

It's the opposite here. Opening a few modules takes a few seconds.
Opening a larger reactor takes ages. It needs to build tons of effective
models (processing imports etc.) vs. it needs to build just a few
effective models. I know nothing about m2e, so cannot comment on that. A
quick look tells me it's about an IDE refusing to give up on concepts
from the middleages (workspaces, projects) when all others have adopted
artifact based concepts for more than a decade.


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

Re: Parent Version maybe not needed in child POM

[Manfred Moser]

All of these task should only happen when you open a new project. Otherwise all 
of it should be cached in the local repo.

When all of it is local it should NOT take so long. At least it doesnt in M2e. 
If you resort to a hack like opening only part of the reactor you should not be 
surprised if working on it is only semi-optimal.

Manfred

Christian Schulte wrote on 2016-12-12 15:25:

> Am 12/12/16 um 23:23 schrieb Igor Fedorenko:
>> Disagree. I think in most if not all cases we build entire project, not 
>> just random part of a project.
> 
> Try opening a big multi-module project in Netbeans, for example.
> Something like an J2EE application server. You can take a long walk
> until it finishes downloading sources, javadoc, dependencies and the
> background scanning task before you can change a single line of code.
> Working on projects like that, I really only open the module(s) I need
> to work on, build them in isolation and copy resuling jar files around -
> during development.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12/12/16 um 23:23 schrieb Igor Fedorenko:
> Disagree. I think in most if not all cases we build entire project, not 
> just random part of a project.

Try opening a big multi-module project in Netbeans, for example.
Something like an J2EE application server. You can take a long walk
until it finishes downloading sources, javadoc, dependencies and the
background scanning task before you can change a single line of code.
Working on projects like that, I really only open the module(s) I need
to work on, build them in isolation and copy resuling jar files around -
during development.


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

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

-am should be aware of entire multimodule project and resolve in reactor 
dependencies accordingly.


--
Regards,
Igor



On December 12, 2016 2:36:08 PM "Robert Scholte"  wrote:


Absolutely agreeing with Igor. And if you want to be able to build a
single module of a multimodule without -am it is *your* responsibility to
add the versions to those dependencies, so these are pulled from a
repository.
That will still work, but will remove the safety belt (jigsaw(tm)?)

Robert

On Mon, 12 Dec 2016 23:23:51 +0100, Igor Fedorenko 
wrote:


Disagree. I think in most if not all cases we build entire project, not
just random part of a project.


Regards,
Igor



On December 12, 2016 11:22:50 AM Christian Schulte  wrote:


Am 12/12/16 um 10:16 schrieb Tibor Digana:

Is it really necessary to specify version of parent artifact in
?


It must be possible to checkout a single module and build that in
isolation. A parent without a version cannot be resolved from a
repository. Supporting that means you need to checkout the whole project
(can be very huge) just to be able to find the parent on disk.
Installing/deploying an artifact without version is impossible -
incomplete coordinates. So there needs to be a version as soon as an
artifact is to be installed or deployed.

Regards,
--
Christian


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





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


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





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

Re: Parent Version maybe not needed in child POM

[Robert Scholte]

Absolutely agreeing with Igor. And if you want to be able to build a  
single module of a multimodule without -am it is *your* responsibility to  
add the versions to those dependencies, so these are pulled from a  
repository.

That will still work, but will remove the safety belt (jigsaw(tm)?)

Robert

On Mon, 12 Dec 2016 23:23:51 +0100, Igor Fedorenko   
wrote:


Disagree. I think in most if not all cases we build entire project, not  
just random part of a project.



Regards,
Igor



On December 12, 2016 11:22:50 AM Christian Schulte  wrote:


Am 12/12/16 um 10:16 schrieb Tibor Digana:
Is it really necessary to specify version of parent artifact in  
?


It must be possible to checkout a single module and build that in
isolation. A parent without a version cannot be resolved from a
repository. Supporting that means you need to checkout the whole project
(can be very huge) just to be able to find the parent on disk.
Installing/deploying an artifact without version is impossible -
incomplete coordinates. So there needs to be a version as soon as an
artifact is to be installed or deployed.

Regards,
--
Christian


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





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


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

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

Disagree. I think in most if not all cases we build entire project, not 
just random part of a project.



Regards,
Igor



On December 12, 2016 11:22:50 AM Christian Schulte  wrote:


Am 12/12/16 um 10:16 schrieb Tibor Digana:

Is it really necessary to specify version of parent artifact in ?


It must be possible to checkout a single module and build that in
isolation. A parent without a version cannot be resolved from a
repository. Supporting that means you need to checkout the whole project
(can be very huge) just to be able to find the parent on disk.
Installing/deploying an artifact without version is impossible -
incomplete coordinates. So there needs to be a version as soon as an
artifact is to be installed or deployed.

Regards,
--
Christian


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





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

Re: future of aether

[Igor Fedorenko]

https://projects.eclipse.org/projects/technology.aether/reviews/termination-review

--
Regards,
Igor



On December 12, 2016 11:13:28 AM "Manfred Moser"  
wrote:


There should be some eclipse notes about the move of the project to the 
attic and the migration. But I dont know where they would be. Once the 
migration is done the Eclipse site should probably be updated or use a 
redirector..


Manfred

domi wrote on 2016-12-12 01:44:


Hi,

is there any official statement about the future of Aether published somewhere?
I just noticed that Spring plans to use it in one of there upcoming releases:
https://github.com/spring-projects/spring-boot/commit/1cd781b2426f1b63b80d990e19d7d7c6a6fd735a


/Domi



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





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

[VOTE] Release Apache Maven Dependency Plugin version 3.0.0

[Robert Scholte]

Hi,

We solved 25 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12330458=Text

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317227%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1312
https://repository.apache.org/content/repositories/maven-1312/org/apache/maven/plugins/maven-dependency-plugin/3.0.0/maven-dependency-plugin-3.0.0-source-release.zip

Source release checksum(s):
maven-dependency-plugin-3.0.0-source-release.zip sha1:  
094af75c62c7d36fc7de5dcac5d4589312495362


Staging site:
https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/

Notes:
- from now on this plugin will require Maven3 to run
- When running the list-goal with Java9 a new feature is exposed: the  
artifact coordinate is extended with the module name, marked with (auto)  
if it is an automatic module.


Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1

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

Re: Maven 3.4.0 Release

[Christian Schulte]

Am 12/12/16 um 22:55 schrieb Michael Osipov:
> Am 2016-12-12 um 02:48 schrieb Christian Schulte:
>> Am 12/11/16 um 22:56 schrieb Michael Osipov:
>>> I just ran ITs with current master, only one IT fails:
>>
>> Should be fixed now.
> 
> Are you certain about this? I cannot confirm. 
> 723b942ad10ab471dfbc5d81ed1071891573dc01 fixes MNG-5227 IT but the IT 
> failing ist for MNG-4347.
> 

Still looking into it. Does not seem to be an issue with maven core but
the resolver. Currently reviewing all commits since


Regards,
-- 
Christian


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

Re: Maven 3.4.0 Release

[Michael Osipov]

Am 2016-12-12 um 02:48 schrieb Christian Schulte:

Am 12/11/16 um 22:56 schrieb Michael Osipov:

I just ran ITs with current master, only one IT fails:


Should be fixed now.


Are you certain about this? I cannot confirm. 
723b942ad10ab471dfbc5d81ed1071891573dc01 fixes MNG-5227 IT but the IT 
failing ist for MNG-4347.


Michael


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

Re: [HEADS UP] Releasing maven-wagon-2.11

[Dan Tran]

Sure

-Dan

On Mon, Dec 12, 2016 at 1:06 PM, Michael Osipov  wrote:

> Am 2016-12-11 um 19:59 schrieb Dan Tran:
>
>> Hi
>>
>> I am planning to stage maven-wagon-2.11  tomorrow night US Pacific time.
>> Let me know if you need me to wait
>>
>
> Can you hold it for a week? I am currently investigating an issue with
> duplicate dependencies for the HTTP provider. At the end, several artifacts
> land in {maven.home}/lib twice.
>
> This is worth fixing in 2.11 for Maven 3.4.
>
> Thanks,
>
> Michael
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [HEADS UP] Releasing maven-wagon-2.11

[Michael Osipov]

Am 2016-12-11 um 19:59 schrieb Dan Tran:

Hi

I am planning to stage maven-wagon-2.11  tomorrow night US Pacific time.
Let me know if you need me to wait


Can you hold it for a week? I am currently investigating an issue with 
duplicate dependencies for the HTTP provider. At the end, several 
artifacts land in {maven.home}/lib twice.


This is worth fixing in 2.11 for Maven 3.4.

Thanks,

Michael


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

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12.12.2016 um 21:32 schrieb Tibor Digana:
> The IDEs like Eclipse, IDEA etc must adapt to versionless parent.
> 
> @Christian
> Execution of large projects and parent version depends on development team.
> Nowadays they are going to be Microservices very small and isolated in
> build time and runtime as well.
> It really depends on the needs. For instance nowadays I can non-recursively
> -N release a parent and a specific child -pl can be released separately and
> release plugin will ask me what is the release version of parent.
> 
> If Maven had continuous build based on SCM information, I would not care if
> I run the build from the root even if I want to build only changed child
> somewhere deeply in the tree.
> Actually this is the feature I am missing in Maven and installing Jenkins
> for that, no developer would do.
> 
> But logically if such large structure will always be built from root
> because of such coupling and because of all WAR file always will be
> deployed to JBoss together at the same time because they have common
> database model, then it makes perfect sense not to have intermediate Parent
> sections because this is one big consistent structure and always will be.

You wouldn't need an artifact based build system for this. One big 'src'
folder and one big 'classes' folder and packages build based on
directory/package names. You'll loose all kind of scoping that way, of
course. You are never deploying artifacts to a repository? So you only
deploy the final WAR files and that's it?

> And again if a developer wants to build a part of that then still can do
> that in the same manner but continuous Maven core should ask SCM for
> changes after last build time and build always only changed modules which
> would be perfect, would not it be?

Job of the CI system, IMHO. It's a matter of how you use to work. I am
used to only checkout what I need to work on and rely on Maven to
download the missing pieces from repositories for me. Makes a lot of
sense. If this will no longer be possible, I simply would not know how
to open such a project in my IDE of choice. Before Maven, there was no
way to just open a project in the IDE. You always needed to setup some
kind of project for each and every bit. Maven has made life so much
easier. I haven't had to manually setup a project in the IDE since
years. This is a must have for me. I am not objecting your use case. I
just would not want an artifact based build system to go the "monolithic
project structure" way.

Regards,
-- 
Christian



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

Re: maven-aether-provider renamed to maven-resolver-provider.

[Michael Osipov]

Am 2016-12-11 um 23:43 schrieb Christian Schulte:

Do we want to deploy a 'maven-aether-provider' relocating to
'maven-resolver-provider'?


Since we change the groupId already, why not?

Michael


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

Re: Parent Version maybe not needed in child POM

[Tibor Digana]

The IDEs like Eclipse, IDEA etc must adapt to versionless parent.

@Christian
Execution of large projects and parent version depends on development team.
Nowadays they are going to be Microservices very small and isolated in
build time and runtime as well.
It really depends on the needs. For instance nowadays I can non-recursively
-N release a parent and a specific child -pl can be released separately and
release plugin will ask me what is the release version of parent.

If Maven had continuous build based on SCM information, I would not care if
I run the build from the root even if I want to build only changed child
somewhere deeply in the tree.
Actually this is the feature I am missing in Maven and installing Jenkins
for that, no developer would do.

But logically if such large structure will always be built from root
because of such coupling and because of all WAR file always will be
deployed to JBoss together at the same time because they have common
database model, then it makes perfect sense not to have intermediate Parent
sections because this is one big consistent structure and always will be.
And again if a developer wants to build a part of that then still can do
that in the same manner but continuous Maven core should ask SCM for
changes after last build time and build always only changed modules which
would be perfect, would not it be?





On Mon, Dec 12, 2016 at 8:22 PM, Christian Schulte  wrote:

> Am 12/12/16 um 10:16 schrieb Tibor Digana:
> > Is it really necessary to specify version of parent artifact in
> ?
>
> It must be possible to checkout a single module and build that in
> isolation. A parent without a version cannot be resolved from a
> repository. Supporting that means you need to checkout the whole project
> (can be very huge) just to be able to find the parent on disk.
> Installing/deploying an artifact without version is impossible -
> incomplete coordinates. So there needs to be a version as soon as an
> artifact is to be installed or deployed.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

Re: Parent Version maybe not needed in child POM

[Martijn Dashorst]

On Mon, Dec 12, 2016 at 8:22 PM, Christian Schulte  wrote:
> Am 12/12/16 um 10:16 schrieb Tibor Digana:
>> Is it really necessary to specify version of parent artifact in ?
>
> It must be possible to checkout a single module and build that in
> isolation. A parent without a version cannot be resolved from a
> repository. Supporting that means you need to checkout the whole project
> (can be very huge) just to be able to find the parent on disk.
> Installing/deploying an artifact without version is impossible -
> incomplete coordinates. So there needs to be a version as soon as an
> artifact is to be installed or deployed.

But is it really a requirement that the version MUST be there always?
I never encountered your specific requirement, but I can imagine it be
necessary some times. But I can give you enough examples where your
requirement isn't necessary and the version can be omitted.

So, if you need need to checkout a submodule stand alone, then one
should include the version, but if that is not a use case, one can
omit the version and instead rely on the parent's module's version.

Martijn

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

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12/12/16 um 10:16 schrieb Tibor Digana:
> Is it really necessary to specify version of parent artifact in ?

It must be possible to checkout a single module and build that in
isolation. A parent without a version cannot be resolved from a
repository. Supporting that means you need to checkout the whole project
(can be very huge) just to be able to find the parent on disk.
Installing/deploying an artifact without version is impossible -
incomplete coordinates. So there needs to be a version as soon as an
artifact is to be installed or deployed.

Regards,
-- 
Christian


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

Re: future of aether

[Manfred Moser]

There should be some eclipse notes about the move of the project to the attic 
and the migration. But I dont know where they would be. Once the migration is 
done the Eclipse site should probably be updated or use a redirector.. 

Manfred

domi wrote on 2016-12-12 01:44:

> Hi,
> 
> is there any official statement about the future of Aether published 
> somewhere?
> I just noticed that Spring plans to use it in one of there upcoming releases:
> https://github.com/spring-projects/spring-boot/commit/1cd781b2426f1b63b80d990e19d7d7c6a6fd735a
> 
> 
> /Domi


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

Re: Parent Version maybe not needed in child POM

[Robert Scholte]

I forgot to mention that this must work for SNAPSHOTs as well, which  
confirms this is not something which needs to be resolved with the  
maven-release-plugin, but in Maven Core.


Robert

On Mon, 12 Dec 2016 10:16:46 +0100, Tibor Digana   
wrote:


Is it really necessary to specify version of parent artifact in  
?


Suppose we have multimodule reactor project and maven-release-plugin  
would

inline the version in the  section and remove it again in new
development iteration. The plugin fails then if the parent version is not
determined.

WDYT?

If I specify {project.version} in child POM dependencies I do it for the
reason to not to know anything about inconsistent versions. The parent
section with specific version breaks this idea because the parent runs
child and thus child should know the caller.
Maybe groupId+artifactId+relativePath in parent would be enough in such
project.

Cheers
Tibor


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

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

I think this is a good idea. And I'd go one step further and use 
"versionless"  to represent in-reactor version.


--
Regards,
Igor



On December 12, 2016 1:16:49 AM Tibor Digana  wrote:


Is it really necessary to specify version of parent artifact in ?

Suppose we have multimodule reactor project and maven-release-plugin would
inline the version in the  section and remove it again in new
development iteration. The plugin fails then if the parent version is not
determined.

WDYT?

If I specify {project.version} in child POM dependencies I do it for the
reason to not to know anything about inconsistent versions. The parent
section with specific version breaks this idea because the parent runs
child and thus child should know the caller.
Maybe groupId+artifactId+relativePath in parent would be enough in such
project.

Cheers
Tibor




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

[GitHub] maven-surefire issue #114: Parallel runner should not drop away runners that...

[Fuud]

Github user Fuud commented on the issue:

https://github.com/apache/maven-surefire/pull/114
  
"Master Origin" integration tests suite does not pass on my Windows box.
 
```
Results :

Failed tests:   
properNewlinesAndEncodingWithDifferentEncoding(org.apache.maven.surefire.its.ConsoleOutputIT):
 Did not find expected message in log
  
properNewlinesAndEncodingWithDefaultEncodings(org.apache.maven.surefire.its.ConsoleOutputIT):
 Did not find expected message in log
  
properNewlinesAndEncodingWithoutFork(org.apache.maven.surefire.its.ConsoleOutputIT):
 Did not find expected message in log

Tests in error:
  testUmlautIsolatedClassLoader(org.apache.maven.surefire.its.UmlautDirIT): 
Exit code was non-zero: 1; command line and log = (..)
  testUmlaut(org.apache.maven.surefire.its.UmlautDirIT): Exit code was 
non-zero: 1; command line and log = (..)
```

But this PR does nothing with encodings, I think we can ignore this errors 
now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

future of aether

[domi]

Hi,

is there any official statement about the future of Aether published somewhere?
I just noticed that Spring plans to use it in one of there upcoming releases: 
https://github.com/spring-projects/spring-boot/commit/1cd781b2426f1b63b80d990e19d7d7c6a6fd735a
 


/Domi

Re: Parent Version maybe not needed in child POM

[Robert Scholte]

Exactly! That's why we are thinking about a build pom and a distribution pom, 
which are now always the same file. By splitting it, it will be possible to 
replace the relativePath with the actual version. 
To be clear, developers will only have a build pom, the distribution pom will 
be generated based on the build pom, probably during the package phase 

Robert


Verzonden vanaf Samsung Mobile.

 Oorspronkelijk bericht Van: Jörg Schaible 
 Datum:12-12-2016  10:27  
(GMT+01:00) Aan: dev@maven.apache.org Onderwerp: Re: 
Parent Version maybe not needed in child POM 
Tibor Digana wrote:

> Is it really necessary to specify version of parent artifact in ?
> 
> Suppose we have multimodule reactor project and maven-release-plugin would
> inline the version in the  section and remove it again in new
> development iteration. The plugin fails then if the parent version is not
> determined.
> 
> WDYT?
> 
> If I specify {project.version} in child POM dependencies I do it for the
> reason to not to know anything about inconsistent versions. The parent
> section with specific version breaks this idea because the parent runs
> child and thus child should know the caller.
> Maybe groupId+artifactId+relativePath in parent would be enough in such
> project.

The problem starts when you get the child POM from a repository. And *a* 
repository might already be the local one. I.e. your suggestion with the 
automated manipluation must happen already at installation/deployment time.

Cheers,
Jörg


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

Re: Parent Version maybe not needed in child POM

[Jörg Schaible]

Tibor Digana wrote:

> Is it really necessary to specify version of parent artifact in ?
> 
> Suppose we have multimodule reactor project and maven-release-plugin would
> inline the version in the  section and remove it again in new
> development iteration. The plugin fails then if the parent version is not
> determined.
> 
> WDYT?
> 
> If I specify {project.version} in child POM dependencies I do it for the
> reason to not to know anything about inconsistent versions. The parent
> section with specific version breaks this idea because the parent runs
> child and thus child should know the caller.
> Maybe groupId+artifactId+relativePath in parent would be enough in such
> project.

The problem starts when you get the child POM from a repository. And *a* 
repository might already be the local one. I.e. your suggestion with the 
automated manipluation must happen already at installation/deployment time.

Cheers,
Jörg


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

Parent Version maybe not needed in child POM

[Tibor Digana]

Is it really necessary to specify version of parent artifact in ?

Suppose we have multimodule reactor project and maven-release-plugin would
inline the version in the  section and remove it again in new
development iteration. The plugin fails then if the parent version is not
determined.

WDYT?

If I specify {project.version} in child POM dependencies I do it for the
reason to not to know anything about inconsistent versions. The parent
section with specific version breaks this idea because the parent runs
child and thus child should know the caller.
Maybe groupId+artifactId+relativePath in parent would be enough in such
project.

Cheers
Tibor