Re: Fwd: How to name modules, automatic and otherwise

[Christian Schulte]

Am 02/19/17 um 04:38 schrieb Hervé BOUTEMY:
> then I'm not sure checking rules on what is inside an artifact while 
> publishing in Central is the right thing to do: we don't do it currently 
> (checking that package names are consistent with groupId), then I feel we 
> should not do it either for module info

If we would have checked that, there would not be this "redundant class
files on class path coming from different coordinates" issue.

> 
> it's just a basic convention for normal cases, that will be applied more than 
> 90% of time: and there will be less than 10% of time where discrepency will 
> happen, due to some special cases in code life
> As usual

Issue with the module names is the same as with the package or
classnames. They can be deployed to different coordinates and then
produce conflicts later when consumed. If we can avoid this with module
names, we should.

Regards,
-- 
Christian


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

Re: I think we are ready for 3.5.0-alpha-1

[Stephen Connolly]

After some digging I think the fix for MNG-6078 is incorrect. I have taken
an initial stab at what I believe to be a more correct approach:
https://github.com/apache/maven/tree/mng-6078-take-2

If the integration tests pass:
https://builds.apache.org/job/maven-3.x-jenkinsfile/job/mng-6078-take-2/
then I believe that should solve the regressions in the surefire build
between Maven 3.3.9 and Maven 3.5.0-SNAPSHOT

While there are other issues with Surefire, at this point in time, from the
PoV of a core release, what we need is that the build behaves the same for
3.3.9 and 3.5.0-SNAPSHOT

Let's see what the build result is tomorrow!

On 18 February 2017 at 17:48, Christian Schulte  wrote:

> Am 02/18/17 um 11:41 schrieb Stephen Connolly:
> > We need help testing on Solaris 10/11 if anyone has access to such a
> system
>
> On a SPARC machine, if possible, please.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Fwd: How to name modules, automatic and otherwise

[Robert Scholte]

On Sat, 18 Feb 2017 12:46:32 +0100, Robert Scholte   
wrote:



On Thu, 16 Feb 2017 19:11:33 +0100, Brian Fox  wrote:


I generally agree the concerns were mostly ignored. Specifically the
dangers in not carefully approaching and setting best practices in the
names, thereby willfully ignoring what happened with NPM.



It doesn't take away the issue that you can still refer to automodules  
and that their name can/will change in the future.


I think we should introduce 2 new packaging types:
- modlib, which does not allow references to automodules
- modapp, which allows references to automodules, but will never be  
installed or deployed.




After some rethinking we can solve this all with the current jar packaging  
type. If module-info doesn't export any packages it is considered an  
application and we can allow automodules. If there are exports defined, it  
is considered a dependency meaning we cannot allow automodules, but only  
named modules.


Robert

In fact, modapp matches one of my ideas for POM5 where GA are not always  
required anymore, e.g. if they are not distributed as dependency.


The inclusion of the Module-Name metadata is frankly, more than I  
expected

we would get. I think this does give us something to work with, first by
making that defaulted by the Maven plugins and later by enforcing in the
repo as appropriate. Using this correctly could help solve some of my
initial concerns that we weren't appropriately leveraging the
default-effect.


Hmm, not sure about the default behavior. I think developers should  
choose their name with care, just as they should choose their groupId  
and artifactId with care.


The Module-Name will make it possible to prepare your project as modular  
jar. This also implies that in the module-info you must specify *every*  
requirement. If only one jar is not yet a named module (either by  
Module-Name or by module-info), you must omit the module-info.java;  
that's a choice, makes our lives a bit easier :)

Just have to be very clear about it towards the community.

Robert



PS: those of you who aren't sure what this was all about, see here:
http://www.sonatype.org/nexus/2017/01/23/advice-for-jigsaw-regarding-auto-modules/

On Thu, Feb 16, 2017 at 12:26 PM, Manfred Moser  


wrote:


I just read it all .. sigh. Looks like our concerns got ignored to me

Manfred

Robert Scholte wrote on 2017-02-16 09:23:

> FYI,
>
> Robert
>
> --- Forwarded message ---
> From: mark.reinh...@oracle.com
> To: jpms-spec-expe...@openjdk.java.net
> Cc:
> Subject: How to name modules, automatic and otherwise
> Date: Thu, 16 Feb 2017 17:48:27 +0100
>
> This note is in reply to the concerns about automatic modules raised  
by
> Robert Scholte and Brian Fox [1], and by Stephen Colebourne and  
others
> [2].  I've collected my conclusions here rather than in separate  
messages

> because there are several distinct yet intertwined issues.
>
> Summary:
>
>- Module names should not include Maven group identifiers, because
>  modules are more abstract than the artifacts that define them.
>
>- Module names should use the reverse-domain-name-prefix  
convention

>  or, preferably, the project-name-prefix convention.
>
>- We should not abandon automatic modules, since they are a key  
tool

>  for migration and adoption.
>
>- We can address the problems of automatic modules with two fairly
>  minor technical enhancements.
>
> If any of these points strikes you as controversial, please read on!
>
>* * *
>
> Module names should not include Maven group identifiers, as Robert
> Scholte and Brian Fox suggest [1], even for modules declared  
explicitly
> in `module-info.java` files.  Modules in JPMS are a construct of the  
Java
> programming language, implemented in both the compiler and the  
virtual

> machine.  As such, they are more abstract entities than the artifacts
> that define them.  This distinction is useful, both conceptually and
> practically, hence module names should remain more abstract.
>
> This distinction is useful conceptually because it makes it easier,  
as
> we read source code, to think clearly about the nature of a module.   
We
> can reason about a module's dependences, exports, services, and so  
forth
> without cluttering our minds with the details of group identifiers  
and

> version constraints.  Today, e.g., we can write, and read:
>
>  module foo.data {
>  exports com.bar.foo.data;
>  requires hibernate.core;
>  requires hibernate.jcache;
>  requires hibernate.validator;
>  }
>
> If we were to extend the syntax of module names to include group
> identifiers, and encourage people to use them, then we'd be faced  
with

> something much more verbose:
>
>  module com.bar:foo.data {
>  exports com.bar.foo.data;
>  requires org.hibernate:hibernate.core;
> 

Re: Build of maven-dependency-analyzer fails on Windows.

[Robert Scholte]

On Mon, 20 Feb 2017 02:17:12 +0100, Christian Schulte   
wrote:



Am 02/20/17 um 01:53 schrieb Christian Schulte:

Hi,

I cannot build 'maven-dependency-analyzer' trunk on Windows. Is there
some dependency I could upgrade to get this going? This is what I am
doing locally:

svn checkout /repos/asf/maven/shared/trunk/maven-dependency-analyzer
cd maven-dependency-analyzer
mvn verify -Papache-snapshots,run-its

Jenkins build job is here:



Regards,



Seems we cannot rename the mvn.bat file to mvn.cmd. Can someone clarify
this, please. Is it "just" our invoker relying on this?


Effective pom says maven-invoker-plugin-2.0.0 is used, which is aware of  
both mvn.bat and mvn.cmd


Robert



Regards,


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

[GitHub] maven-release pull request #13: MRELEASE-980 Allow commit comments to be con...

[jodastephen]

GitHub user jodastephen opened a pull request:

https://github.com/apache/maven-release/pull/13

MRELEASE-980 Allow commit comments to be controlled

Provide the ability to override commit comments from configuration.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jodastephen/maven-release comment-control

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-release/pull/13.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #13


commit 35b2a50900cfc8e8fca88a94e46985a09e538e86
Author: Stephen Colebourne 
Date:   2017-02-17T12:40:56Z

Allow commit comments to be controlled

Provide the ability to override commit comments from configuration




---
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

[GitHub] maven pull request #106: Fixing a typo in 'lifecycle'

[hmemcpy]

GitHub user hmemcpy opened a pull request:

https://github.com/apache/maven/pull/106

Fixing a typo in 'lifecycle'



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hmemcpy/maven patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven/pull/106.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #106


commit 054ca34aa16db9f564bfa15123f07bdadf165c03
Author: Igal Tabachnik 
Date:   2017-02-20T14:14:50Z

Fixing a typo in 'lifecycle'




---
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