Yep. We can be opinionated, but we should allow others to follow their own
opinions (even if they are "wrong")... we just don't have to make it easy!
On Tue 21 Feb 2017 at 22:16, Hervé BOUTEMY wrote:
> Maven tool can't check everything against developper's will: we
Maven tool can't check everything against developper's will: we already have
bad reputation because we put contraints on the build.
We can't force people, we can't enforce rules.
We can define good conventions and ease their use.
Regards,
Hervé
Le mardi 21 février 2017, 03:41:12 CET
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
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
IMHO, this means that there is the vast majority of "normal" case
then there is life, where exceptionnally everything is mixed:
- publishing a temporary fork (for example to have some local patches)
- really forking or moving
then I'm not sure checking rules on what is inside an artifact while
Am 02/18/17 um 12:25 schrieb Robert Scholte:
> The idea from Hervé and Rémi is about having a publish rule in Central if
> you want to publish a modular jar there which will prevent module name
> collisions.
> Because the groupId is already owned by a specific organisation, you could
> use
yes, that's it
(eventually without even checking that rule automatically when publishing into
central: just making an explicit convention to avoid stupid choice of module
prefix that is different from groupId but another DNS entry one may own)
Regards,
Hervé
Le samedi 18 février 2017,
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 idea from Hervé and Rémi is about having a publish rule in Central if
you want to publish a modular jar there which will prevent module name
collisions.
Because the groupId is already owned by a specific organisation, you could
use them as well as "namespace"/prefix of the modular name
there is some level of misunderstanding
my proposal is not to force any default value: just check (for people
publishing to Central) that chosen value starts with groupId
then, in some Maven plugin, we can independently propose magic help to propose
auto-calculated default values to people
>
> The idea is to not default to group:artifact but to check if the artifact
> starts with a suffix of the group-ID and then skip this. So g=org.hibernate
> a=hibernate-core would become org.hibernate.core and not
> org.hibernate.hibernate.core. This is a neat trick I wished in the past in
> some
Thats how I understand it as well and I like it.
Brian Fox wrote on 2017-02-17 06:01:
> Hervé: I feel like I don't completely understand the proposal, but I feel
> like we can achieve your intent using the Module-Name simply by defaulting
> it to g:a and building up a good base of new stuff
Hervé: I feel like I don't completely understand the proposal, but I feel
like we can achieve your intent using the Module-Name simply by defaulting
it to g:a and building up a good base of new stuff going into Central such
that when people start using jigsaw, there is a good pattern in place and
tuesday, I was at a Jigsaw presentation from Remi Forax in France, where the
fact that nothing was taken into consideration looked something that was
happenning (and the recent publication shows that it has happened now)
Then Remi and I discussed and looked for ideas on what lighter proposal to
And it looks like they are saying .. just add the groupId (or similar
namespace) to the modulename. A bit like some artifact repeat the groupId in
the artifactId to be specific... seems like a wasted opportunity to define a
good usage pattern. The idea of actually supporting same module names
On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko wrote:
> Can't we just block auto-named modules from the build? We control
> dependencies and should be able to look inside and barf if we don't like
> anything, no?
>
Yes but this only applies to things that are modularized.
Can't we just block auto-named modules from the build? We control
dependencies and should be able to look inside and barf if we don't like
anything, no?
I realize this does not set good defaults for non-maven projects, so
there will be some friction there, but hopefully maven userbase is big
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.
The inclusion of the Module-Name metadata is frankly, more than I expected
we would get. I think
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,
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
20 matches
Mail list logo