On Fri, May 5, 2017 at 10:41 AM, wrote:
> I suspect what you really mean is "Never publish JARs that refer to
> automatic modules that do not have `Automatic-Module-Name` attributes".
> In general that's good advice.
>
+1 For me, the point of the attribute was to allow an intermediate step.
>
On Thu, May 4, 2017 at 1:39 PM, wrote:
> Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and
> Robert Scholte, for the extensive feedback.
>
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/
> 2017-May/000687.html
>
> TL;DR: Keep automatic mo
On Wed, Apr 26, 2017 at 12:27 PM, wrote:
> If one of those automatic modules is modularized later on, and given a
> different name, then how is having to fix that materially different from
> having to fix code that was using a package that's no longer exported?
> If anything it might actually be
Here's one I'm familiar with:
https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
At least within Maven, it's a known best practice to ensure you're not
dependent on transitives.
On Tue, Apr 25, 2017 at 11:44 AM, wrote:
> 2017/4/25 6:53:45 -0700, bri...@infinity.nu:
> > .
On Tue, Apr 25, 2017 at 9:10 AM, David M. Lloyd
wrote:
> I agree with everything except for this last point. I think that, given
> the amount of evangelism over the past 5 or so years, people will adopt
> JPMS whether or not it is a fit for their use case. Different shops will
> use different t
I completely agree with Stephen.
While it's technically true you can consider all the exports to be part of
the API, the reality is that most libraries aren't used that way. In fact,
there are commonly accepted tools to detect when you are depending on a
transitive dependency that isn't explicitly
On Mon, Apr 24, 2017 at 12:14 PM, wrote:
> The problem with any approach that allows you to give a stable name to
> what is otherwise an automatic module is that the API of that module is
> inherently unstable. If and when the module is completely modularized
> then its API will almost certainly
n something with a Module-Name, it becomes very easy and very quick for
the ecosystem to get to a sane building point for full modularization.
Without the Module-Name metadata or some equivalent, you are effectively
barring all the build systems from helping with the conversion to achieve
the very goal of this entire process.
--Brian Fox
e a smooth migration path between now and when
this hits critical mass. Now that it's out the window, we're right back
where we started from.
On Wed, Apr 5, 2017 at 1:17 AM, wrote:
> 2017/4/4 2:38:37 -0700, Brian Fox :
> > Mark I think some of the assertions on the prevalence o
Mark I think some of the assertions on the prevalence of the pom.properties
is wrong. We pulled our own top 20 list based on download popularity and
you can see it lines up well with your cited article:
count | group_name |artifact_name
-+
The standard within the scala ecosystem is to append the runtime version to
the artifactid, making every scala module out of compliance with the
proposal.
On Wed, Mar 15, 2017 at 4:00 PM, Robert Scholte
wrote:
> On Wed, 15 Mar 2017 11:13:25 +0100, Stephen Colebourne <
> scolebou...@joda.org> wro
This seems sensible and not unfamiliar with how import statements already
work in Java to determine the fqn to search for a given class.
On Fri, Feb 17, 2017 at 4:07 AM, Michael Rasmussen <
michael.rasmus...@zeroturnaround.com> wrote:
> On 17 February 2017 at 01:19, Stephen Colebourne
> wrote:
>
Thanks for the follow up Mark.
I obviously don't completely agree with all of the assumptions and that's
ok.
I do however applaud the inclusion of the Module-Name into the algorithm.
This gives enough of a hook that tools like Maven can hopefully send the
ecosystem down a smooth transition path,
On Fri, Feb 3, 2017 at 10:40 AM, Alan Bateman
wrote:
> As regards the example naming clash then these two projects might already
> get complaints over their poor choice of artifacts, esp. when artifacts for
> both projects are in same directory (say where someone distributes with all
> JAR files
In my mind, proposal 2 (eliminating automobiles) is infinitely preferable
to what we have today.
The one downside as compared to leveraging the existing coordinates
(proposal 1) is that it doesn't do anything to set a best practice in what
good names look like. If nothing else, the maven coordinat
15 matches
Mail list logo
