On 26 April 2017 at 19:35, Alan Bateman wrote:
> On 26/04/2017 18:35, Stephen Colebourne wrote:
>
>> :
>> - an incomplete module defines as many dependencies as it can
>> - an incomplete module also depends on the classpath
>> - the current automatic module concept ceases to exist
>> (an incomplet
On 26/04/2017 18:35, Stephen Colebourne wrote:
:
- an incomplete module defines as many dependencies as it can
- an incomplete module also depends on the classpath
- the current automatic module concept ceases to exist
(an incomplete module is not an automatic module, as it doesn't get to
read a
On 26 April 2017 at 17:27, wrote:
> 2017/4/25 5:08:21 -0700, Stephen Colebourne :
>> As discussed before, removing automatic modules and allowing modules
>> to have partially specified dependencies [1] 1b allows projects to
>> migrate to modules immediately. This would be a huge win. Any project
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
On 04/26/2017 11:27 AM, mark.reinh...@oracle.com wrote:
2017/4/25 5:08:21 -0700, Stephen Colebourne :
On 24 April 2017 at 19:54, wrote:
An explicit module that depends upon one or more modules that are
automatic today is, itself, no more stable than those automatic modules.
It could be broken
2017/4/25 5:08:21 -0700, Stephen Colebourne :
> On 24 April 2017 at 19:54, wrote:
>> An explicit module that depends upon one or more modules that are
>> automatic today is, itself, no more stable than those automatic modules.
>> It could be broken when those automatic modules are modularized
>>
Just to add a note that came up in a twitter conversation.
Modules are not artifacts. [1]
ergo, module names are usually not artifact names
yet, automatic module names are derived from artifact names
Its no wonder that I have seen lots of confusion between modules and
artifacts, Jigsaw itself is
On 26/04/2017 12:55, Juergen Hoeller wrote:
:
You're saying that such transitive resolution of automatic modules
happens implicitly now, i.e. "requires spring.context" implicitly
makes spring.core visible to the application module when both
spring.context and spring.core are automatic module
Alan,
In my last round of testing, application modules had to declare not only
"requires spring.context" but also "requires spring.core", since
spring.context - as an automatic module - couldn't bring in spring.core
transitively. Explicitly adding those through --add-modules is a way out
that I'm
On 25/04/2017 09:48, Juergen Hoeller wrote:
:
For the time being, we'll have to keep focusing on the use of our framework
jars as automatic modules... which works fine for us so far. Even if the
lack of transitive dependencies is a bit of a nuisance, there is enough
value for somebody choosing
- Mail original -
> De: "mark reinhold"
> À: "Brian Fox"
> Cc: jigsaw-dev@openjdk.java.net
> Envoyé: Lundi 24 Avril 2017 20:54:18
> Objet: Re: Alternatives for naming automatic modules, and a proposal
> (#AutomaticModuleNames)
> 2017/4/24 10:3
On 25.04.2017 16:38, David M. Lloyd wrote:
[...]
I think that Maven- and Gradle-based tooling will appear to fill this
need. The only correct solution (automatic modules or not) to
modularizing arbitrary groups of artifacts will likely involve a
separate assembly step which will inevitably inclu
Maven Enforcer Plugin
http://maven.apache.org/enforcer/enforcer-rules/banTransitiveDependencies.html
Checks for lots of different things, including transitive deps.
Stephen
On 25 April 2017 at 17:00, Brian Fox wrote:
> Here's one I'm familiar with:
> https://maven.apache.org/plugins/maven-depend
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:
> > .
2017/4/25 6:53:45 -0700, bri...@infinity.nu:
> ...
>
> 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 depe
- Mail original -
> De: "David M. Lloyd"
> À: "Brian Fox"
> Cc: "jigsaw-dev"
> Envoyé: Mardi 25 Avril 2017 16:38:54
> Objet: Re: Alternatives for naming automatic modules, and a proposal
> (#AutomaticModuleNames)
[...]
>
>
On 04/25/2017 09:15 AM, Brian Fox wrote:
On Tue, Apr 25, 2017 at 9:10 AM, David M. Lloyd mailto:david.ll...@redhat.com>> 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 wheth
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
On 25/04/2017 14:51, Stephen Colebourne wrote:
:
Has this been documented anywhere? Because all modules in one
classloader seems like entirely the wrong default and I don't
understand the trade off. Clashes on concealed packages will not be
popular.
Changing visibility would be a huge change, es
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
About multiple versions or true hiding of non exported packages, I do not
believe that someone is against those features.
But they both requires to change the VM in an extensive way and to my knowledge
nobody has ever done a prototype of those features.
The good news is that both these features
On 25 April 2017 at 14:31, Alan Bateman wrote:
> Someday then we might get to the point where modules on the application
> module path could be assigned to different class loaders but it has huge
> implications and would take an entire release to shake out issues.
Has this been documented anywher
On 25/04/2017 14:16, Michael Nascimento wrote:
:
and also the fact
packages must be defined by a single module even if they are not exported,
because it was considered nearly impossible to track in real world
scenarios.
Keep in mind that this is not a module system limitation, instead it is
ju
On Tue, Apr 25, 2017 at 10:10 AM, David M. Lloyd
wrote:
> Just the fact that there is the *very idea* of a "fit"/"non-fit" for JPMS
> is sad though. It should have been the ubiquitous thing that everyone was
> expecting. But denying multiple versions? Blowing up on run time cycles?
> Reneging
On 04/25/2017 07:08 AM, Stephen Colebourne wrote:
On 24 April 2017 at 19:54, wrote:
An explicit module that depends upon one or more modules that are
automatic today is, itself, no more stable than those automatic modules.
It could be broken when those automatic modules are modularized
explici
On 24 April 2017 at 19:54, wrote:
> An explicit module that depends upon one or more modules that are
> automatic today is, itself, no more stable than those automatic modules.
> It could be broken when those automatic modules are modularized
> explicitly, and if it `requires transitive` an autom
A related note from a Spring perspective:
If automatic module names for third-party dependencies are not to be baked
into higher-level module descriptors, we'll have to wait for all of our
(optional) dependencies to ship module descriptors first, which
single-handedly moves our target date to 2019
2017/4/24 10:39:25 -0700, Brian Fox :
> On Mon, Apr 24, 2017 at 12:14 PM, mark.reinh...@oracle.com 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 mod
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
2017/4/3 10:34:14 -0700, Stephen Colebourne :
> On [1] the conclusion given the premise is not unreasonable. The file
> name can be easily changed by a developer or build tool to match the
> expected module name. However, it is the premise I strongly object to:
>
> "The fundamental problem here is
What I meant to saw but didn't clearly articulate is that I found it
unlikely that half of the most popular stuff was somehow in that 6%. I
pulled the top 200 based on consumption and 136 had easily verifiable
pom.properties.
I don't think the facts really matter though,. I don't understand the
mo
2017/4/4 2:38:37 -0700, Brian Fox :
> 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 |artifa
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
-+
On [1] the conclusion given the premise is not unreasonable. The file
name can be easily changed by a developer or build tool to match the
expected module name. However, it is the premise I strongly object to:
"The fundamental problem here is that we're trying to infer a .. name..."
Inferring a n
Thanks for the continued feedback on this difficult issue.
FYI:
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000666.html
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000667.html
- Mark
35 matches
Mail list logo
