Re: Fwd: How to name modules, automatic and otherwise
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 do for the namespace concern when sharing modules publicly And I proposed a simplified idea that looked promising when we challenged it: for modules that are to be shared on Maven Central, handwritten full module name should *start with groupId* applied to the example for Hibernate, this would just say: Hibernate project owns "org.hibernate" module namespace on [Maven] Central since they own org.hibernate groupId Notice: automodules won't give same module names. Automodules are just transient automagic values for temporary local work, not for public shared work Notice 2: whatever does not go to [Maven] Central has just other conventions. Knowing the impact of existing [Maven] Central content, people doing their local convention will probably "naturally" think at: - immediate compatibility, to be able to consume public artifacts - future compatibility, to be able to later publish a private artifact that may be later shared as public artifact I started to share this idea (which is not far from initial proposal: just not about automodule names and not using artifactId) yesterday with Robert: the discussion just started, nobody had time yet to write the proposal down and share it with a wider audience WDYT? Regards, Hervé Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit : > 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 for different forks or the same thing is touted as an advantage. > Anybody that ever had to debug something like this will know its not an > advantage at all .. just simply path to troubleshooting nightmares. > > I expected as much but I am still disappointed and see lots of trouble with > this in the future. Maybe it would be good if all Apache project and others > that are going to publish modules start with using the full namespace in > the module name. Problem is of course that the examples I saw so far all do > NOT do that so we will end up with a mess anyway.. > > Manfred > > Brian Fox wrote on 2017-02-16 10:42: > > 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. The bigger issue > > is all the existing stuff that would be used as automodules...first they > > are already out there and second, there's nothing to see and block. > > > >> 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 > >> enough to create sufficient pressure for non-maven projects to provide > >> explicit module names. > > > > That's exactly my point in originally suggesting to leverage the g:a by > > default, but we can do exactly the same thing by injecting the Module-Name > > asap to build up the right practices before jigsaw takes off. > > > >> -- > >> Regards, > >> Igor > >> > >> On Thu, Feb 16, 2017, at 01:11 PM, 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. > >> > > >> > 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. > >> > > >> > 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 > >> > > >
[GitHub] maven-plugins pull request #103: Fix link to assembly-component.html
GitHub user arend-von-reinersdorff opened a pull request: https://github.com/apache/maven-plugins/pull/103 Fix link to assembly-component.html You can merge this pull request into a Git repository by running: $ git pull https://github.com/arend-von-reinersdorff/maven-plugins trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-plugins/pull/103.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 #103 commit cbddd67b73084c3b3208a2536c5dfcd0f1a471d0 Author: Arend.von.Reinersdorff Date: 2017-02-16T21:24:26Z Fix link to assembly-component.html --- 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
Re: Running a plugin integration test from an IDE?
On 2017-02-16T18:32:10 +0100 "Robert Scholte" wrote: > If you have a project under maven-assembly-plugin/src/it/projects/bugs and > want to debug it, try: > > mvn verify -Prun-its -Dinvoker.mavenExecutable=mvnDebug > -Dinvoker.test=projects/bugs (point to test-directory) > > You'll see that Maven will hang during the invoker, at which time you have > to hook your IDE to it. > Ah, interesting. That should do it. Thanks! M pgpZuCcS0ACDm.pgp Description: OpenPGP digital signature
Re: Fwd: How to name modules, automatic and otherwise
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 for different forks or the same thing is touted as an advantage. Anybody that ever had to debug something like this will know its not an advantage at all .. just simply path to troubleshooting nightmares. I expected as much but I am still disappointed and see lots of trouble with this in the future. Maybe it would be good if all Apache project and others that are going to publish modules start with using the full namespace in the module name. Problem is of course that the examples I saw so far all do NOT do that so we will end up with a mess anyway.. Manfred Brian Fox wrote on 2017-02-16 10:42: > 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. The bigger issue > is all the existing stuff that would be used as automodules...first they > are already out there and second, there's nothing to see and block. > > >> >> 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 >> enough to create sufficient pressure for non-maven projects to provide >> explicit module names. >> > > That's exactly my point in originally suggesting to leverage the g:a by > default, but we can do exactly the same thing by injecting the Module-Name > asap to build up the right practices before jigsaw takes off. > > > >> >> -- >> Regards, >> Igor >> >> On Thu, Feb 16, 2017, at 01:11 PM, 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. >> > >> > 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. >> > >> > 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 ma
Re: Fwd: How to name modules, automatic and otherwise
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. The bigger issue
is all the existing stuff that would be used as automodules...first they
are already out there and second, there's nothing to see and block.
>
> 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
> enough to create sufficient pressure for non-maven projects to provide
> explicit module names.
>
That's exactly my point in originally suggesting to leverage the g:a by
default, but we can do exactly the same thing by injecting the Module-Name
asap to build up the right practices before jigsaw takes off.
>
> --
> Regards,
> Igor
>
> On Thu, Feb 16, 2017, at 01:11 PM, 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.
> >
> > 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.
> >
> > 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;
> > > > requires org.hibernate:hibernate.jcache;
> > > > requires org.hibernate:hibernate.validator;
> > > >
Re: Fwd: How to name modules, automatic and otherwise
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
enough to create sufficient pressure for non-maven projects to provide
explicit module names.
--
Regards,
Igor
On Thu, Feb 16, 2017, at 01:11 PM, 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.
>
> 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.
>
> 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;
> > > requires org.hibernate:hibernate.jcache;
> > > requires org.hibernate:hibernate.validator;
> > > }
> > >
> > > Group identifiers make perfect sense in the context of a build system
> > > such as Maven, where they bring necessary structure to the names of the
> > > millions of artifacts available across different repositories. Such
> > > structure is superfluous and distracting in the context of a module
> > > system, where the number of relevant modules in any particular situation
> > > is more likely to be in the tens, or hundreds, or (rarely) thousands.
> > > All else being equal, simpler names are better.
> > >
> > > At a practical level, the distinction between modules and artifacts is
> > > useful because it leaves the entire problem of artifact selection to the
> > > build system. This allows
Re: Fwd: How to name modules, automatic and otherwise
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 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.
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;
> > requires org.hibernate:hibernate.jcache;
> > requires org.hibernate:hibernate.validator;
> > }
> >
> > Group identifiers make perfect sense in the context of a build system
> > such as Maven, where they bring necessary structure to the names of the
> > millions of artifacts available across different repositories. Such
> > structure is superfluous and distracting in the context of a module
> > system, where the number of relevant modules in any particular situation
> > is more likely to be in the tens, or hundreds, or (rarely) thousands.
> > All else being equal, simpler names are better.
> >
> > At a practical level, the distinction between modules and artifacts is
> > useful because it leaves the entire problem of artifact selection to the
> > build system. This allows us to switch from one artifact to another
> > simply by editing a `pom.xml` file to adjust a version constraint or a
> > group identifier; if module names included group identifiers then we'd
> > also have to edit the `module-info.java` file. This flexibility can be
> > helpful if, e.g., a project is forked and a new module with the same name
> > and artifact identifier is published under a different group identifier.
> > We long ago decided not to do version selection in the module system,
> > which surprised some people but has worked out fairly well. We should
> > treat group selection in the same manner.
> >
> > Another practical benefit of the modul
Re: Running a plugin integration test from an IDE?
If you have a project under maven-assembly-plugin/src/it/projects/bugs and want to debug it, try: mvn verify -Prun-its -Dinvoker.mavenExecutable=mvnDebug -Dinvoker.test=projects/bugs (point to test-directory) You'll see that Maven will hang during the invoker, at which time you have to hook your IDE to it. Robert http://maven.apache.org/plugins/maven-invoker-plugin/ https://dzone.com/articles/debugging-maven-build-mvndebug On Thu, 16 Feb 2017 15:08:33 +0100, wrote: Hello! I think I may have explained myself poorly. I'm not really looking for a general way to take a project and make it debuggable. I'm looking for a concrete way to work on a bug in the Assembly plugin. On 2017-02-16T13:39:33 + John Patrick wrote: this might work and is what I get into the company/project root pom so all developers can use the approach... On 2017-02-16T06:52:03 -0500 Igor Fedorenko wrote: I don't use intellij, but if you are willing to try eclipse/m2e then there are at least two viable ways to implement "debuggable" integration tests... I have a project that triggers the bug in the Assembly plugin, so I assumed that the most logical way to approach this would be to add the project as an integration test in here: https://github.com/apache/maven-plugins/tree/trunk/maven-assembly-plugin/src/it/projects/bugs ... and then run the test from an IDE and step through in a debugger to identify the problem. I perhaps erroneously assumed that a mature project like this would have a simple way to run a specific test directly from an IDE! Is there perhaps some other way to do this that all of the current developers know but that isn't written down anywhere? I don't care how it happens, I just want to get this bug fixed. M - 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
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;
> requires org.hibernate:hibernate.jcache;
> requires org.hibernate:hibernate.validator;
> }
>
> Group identifiers make perfect sense in the context of a build system
> such as Maven, where they bring necessary structure to the names of the
> millions of artifacts available across different repositories. Such
> structure is superfluous and distracting in the context of a module
> system, where the number of relevant modules in any particular situation
> is more likely to be in the tens, or hundreds, or (rarely) thousands.
> All else being equal, simpler names are better.
>
> At a practical level, the distinction between modules and artifacts is
> useful because it leaves the entire problem of artifact selection to the
> build system. This allows us to switch from one artifact to another
> simply by editing a `pom.xml` file to adjust a version constraint or a
> group identifier; if module names included group identifiers then we'd
> also have to edit the `module-info.java` file. This flexibility can be
> helpful if, e.g., a project is forked and a new module with the same name
> and artifact identifier is published under a different group identifier.
> We long ago decided not to do version selection in the module system,
> which surprised some people but has worked out fairly well. We should
> treat group selection in the same manner.
>
> Another practical benefit of the module/artifact distinction is that it
> keeps the module system independent of any particular build system, so
> that build systems can continue to improve and evolve independently over
> time. Maven-style coordinates are the most popular way to name artifacts
> in repositories today, but that might not be true ten years from now. It
> would be unwise to adopt Maven's naming convention for module names just
> because it's popular now, and doubly so to bake Maven's group-identifier
> concept into the Java programming language.
>
>* * *
>
> If module names don't include group identifiers, then how should modules
> be named? What advice should we give to someone who's creating a new
> module from scratch, or modularizing an existing component by writing a
> `module-info.java` file for it? (Continue to set aside, for the moment,
> the problems of automatic modules.)
>
> In structuring any partic
Fwd: How to name modules, automatic and otherwise
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;
requires org.hibernate:hibernate.jcache;
requires org.hibernate:hibernate.validator;
}
Group identifiers make perfect sense in the context of a build system
such as Maven, where they bring necessary structure to the names of the
millions of artifacts available across different repositories. Such
structure is superfluous and distracting in the context of a module
system, where the number of relevant modules in any particular situation
is more likely to be in the tens, or hundreds, or (rarely) thousands.
All else being equal, simpler names are better.
At a practical level, the distinction between modules and artifacts is
useful because it leaves the entire problem of artifact selection to the
build system. This allows us to switch from one artifact to another
simply by editing a `pom.xml` file to adjust a version constraint or a
group identifier; if module names included group identifiers then we'd
also have to edit the `module-info.java` file. This flexibility can be
helpful if, e.g., a project is forked and a new module with the same name
and artifact identifier is published under a different group identifier.
We long ago decided not to do version selection in the module system,
which surprised some people but has worked out fairly well. We should
treat group selection in the same manner.
Another practical benefit of the module/artifact distinction is that it
keeps the module system independent of any particular build system, so
that build systems can continue to improve and evolve independently over
time. Maven-style coordinates are the most popular way to name artifacts
in repositories today, but that might not be true ten years from now. It
would be unwise to adopt Maven's naming convention for module names just
because it's popular now, and doubly so to bake Maven's group-identifier
concept into the Java programming language.
* * *
If module names don't include group identifiers, then how should modules
be named? What advice should we give to someone who's creating a new
module from scratch, or modularizing an existing component by writing a
`module-info.java` file for it? (Continue to set aside, for the moment,
the problems of automatic modules.)
In structuring any particular space of names we must balance (at least)
three fundamental tensions: We want names that are long enough to be
descriptive, short enough to be memorable, and unique enough to avoid
needless conflicts.
If you control all of the modules upon which your module depends, and
all of the modules that depend upon it, then you can
Re: Running a plugin integration test from an IDE?
I use the takari testing with the Android Maven Plugin all the time and it works great for me. Manfred PS: also associated with Takari efforts.. Igor Fedorenko wrote on 2017-02-16 03:52: > I don't use intellij, but if you are willing to try eclipse/m2e then > there are at least two viable ways to implement "debuggable" integration > tests. Personally I prefer takari plugin testing harness [1] > (disclosure: I wrote the thing, so I am definitely biased). > Alternatively, you can also use Maven Verifier [2] (this is what Maven > core uses). Both ways to run integration tests are supported by my > "Maven Development Tools" set of m2e extensions [3]. > > [1] https://github.com/takari/takari-plugin-testing-project > [2] http://maven.apache.org/shared/maven-verifier/ > [3] https://github.com/ifedorenko/com.ifedorenko.m2e.mavendev > > -- > Regards, > Igor > > On Thu, Feb 16, 2017, at 04:03 AM, org.apache.maven.u...@io7m.com wrote: >> On 2017-02-14T15:13:46 + >> org.apache.maven.u...@io7m.com wrote: >> > >> > I can't work out how to run this integration >> > test from an IDE (Intellij IDEA, in this case) so that I can try to >> > step through the execution with a debugger and see what's going on. >> >> So nobody knows how to run an integration test from an IDE? How does >> anyone debug problems via tests? >> >> M >> Email had 1 attachment: >> + Attachment2 >> 1k (application/pgp-signature) > > - > 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: Running a plugin integration test from an IDE?
Hello! I think I may have explained myself poorly. I'm not really looking for a general way to take a project and make it debuggable. I'm looking for a concrete way to work on a bug in the Assembly plugin. On 2017-02-16T13:39:33 + John Patrick wrote: > this might work and is what I get into the company/project root pom so > all developers can use the approach... On 2017-02-16T06:52:03 -0500 Igor Fedorenko wrote: > I don't use intellij, but if you are willing to try eclipse/m2e then > there are at least two viable ways to implement "debuggable" integration > tests... I have a project that triggers the bug in the Assembly plugin, so I assumed that the most logical way to approach this would be to add the project as an integration test in here: https://github.com/apache/maven-plugins/tree/trunk/maven-assembly-plugin/src/it/projects/bugs ... and then run the test from an IDE and step through in a debugger to identify the problem. I perhaps erroneously assumed that a mature project like this would have a simple way to run a specific test directly from an IDE! Is there perhaps some other way to do this that all of the current developers know but that isn't written down anywhere? I don't care how it happens, I just want to get this bug fixed. M pgp9TtgjioU_j.pgp Description: OpenPGP digital signature
Re: Running a plugin integration test from an IDE?
this might work and is what I get into the company/project root pom so
all developers can use the approach. create a debug profile and get
the tests to use is so you can debug in your preferred IDE. it doesn't
give you the nice red/green process bars and fancy output but it might
help you debug the running issue.
not tried it with the maven tests but i've used it for surefire and
failsafe before, so something like this might work for you.
1) create debug profile which is simply, and make it suspend yes so it
pauses till you connect your debugger otherwise you might miss the 1st
few tests executing
debug
-Xdebug
-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y
2) setup a default version of the properties
3) change the maven-surefire-plugin and maven-failsafe-plugin to use
testing.args.debug
org.apache.maven.plugins
maven-surefire-plugin
...
... ${testing.args.debug}
...
..
John
On 16 February 2017 at 11:52, Igor Fedorenko wrote:
> I don't use intellij, but if you are willing to try eclipse/m2e then
> there are at least two viable ways to implement "debuggable" integration
> tests. Personally I prefer takari plugin testing harness [1]
> (disclosure: I wrote the thing, so I am definitely biased).
> Alternatively, you can also use Maven Verifier [2] (this is what Maven
> core uses). Both ways to run integration tests are supported by my
> "Maven Development Tools" set of m2e extensions [3].
>
> [1] https://github.com/takari/takari-plugin-testing-project
> [2] http://maven.apache.org/shared/maven-verifier/
> [3] https://github.com/ifedorenko/com.ifedorenko.m2e.mavendev
>
> --
> Regards,
> Igor
>
> On Thu, Feb 16, 2017, at 04:03 AM, org.apache.maven.u...@io7m.com wrote:
>> On 2017-02-14T15:13:46 +
>> org.apache.maven.u...@io7m.com wrote:
>> >
>> > I can't work out how to run this integration
>> > test from an IDE (Intellij IDEA, in this case) so that I can try to
>> > step through the execution with a debugger and see what's going on.
>>
>> So nobody knows how to run an integration test from an IDE? How does
>> anyone debug problems via tests?
>>
>> M
>> Email had 1 attachment:
>> + Attachment2
>> 1k (application/pgp-signature)
>
> -
> 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: Running a plugin integration test from an IDE?
I don't use intellij, but if you are willing to try eclipse/m2e then there are at least two viable ways to implement "debuggable" integration tests. Personally I prefer takari plugin testing harness [1] (disclosure: I wrote the thing, so I am definitely biased). Alternatively, you can also use Maven Verifier [2] (this is what Maven core uses). Both ways to run integration tests are supported by my "Maven Development Tools" set of m2e extensions [3]. [1] https://github.com/takari/takari-plugin-testing-project [2] http://maven.apache.org/shared/maven-verifier/ [3] https://github.com/ifedorenko/com.ifedorenko.m2e.mavendev -- Regards, Igor On Thu, Feb 16, 2017, at 04:03 AM, org.apache.maven.u...@io7m.com wrote: > On 2017-02-14T15:13:46 + > org.apache.maven.u...@io7m.com wrote: > > > > I can't work out how to run this integration > > test from an IDE (Intellij IDEA, in this case) so that I can try to > > step through the execution with a debugger and see what's going on. > > So nobody knows how to run an integration test from an IDE? How does > anyone debug problems via tests? > > M > Email had 1 attachment: > + Attachment2 > 1k (application/pgp-signature) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Running a plugin integration test from an IDE?
On 2017-02-14T15:13:46 + org.apache.maven.u...@io7m.com wrote: > > I can't work out how to run this integration > test from an IDE (Intellij IDEA, in this case) so that I can try to > step through the execution with a debugger and see what's going on. So nobody knows how to run an integration test from an IDE? How does anyone debug problems via tests? M pgpfbWjF3DFVS.pgp Description: OpenPGP digital signature
