Am 2017-05-28 um 09:43 schrieb Hervé BOUTEMY:
are there seconders for
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
(aka "option 2")?
I'd completely leave it off to 1.x until the expect group with Mark
Reinhold has agreed on the disputed points.
I don't see a reason to put any effort into a system which is still in
constant flux.
Le samedi 27 mai 2017, 19:05:27 CEST Hervé BOUTEMY a écrit :
good links
yes, with this in mind, "api" is required for artifactId but should not be
added to module name: good catch, and good experience to share because that
was not so obvious
Regards,
Hervé
Le samedi 27 mai 2017, 18:43:22 CEST Robert Scholte a écrit :
There's no experience with this yet.
Stephen Colebourne has written to related blogs: module naming[1] and
modules are not artifacts[2]
which might suggest that "api" should not be added.
I do understand the addition of "api". And to make it worse, this is
probably the most important artifact needing a module name. In most cases
developers will only need this one: frameworks will handle the
implementation part. :)
Robert
[1] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
[2]
http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html
On Sat, 27 May 2017 17:48:24 +0200, Hervé BOUTEMY <herve.bout...@free.fr>
wrote:
second option committed in another branch:
option 1:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
option 2:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/17f804d7
The only part that I'm not sure in option 2 is
org.apache.maven.resolver.api >
org.apache.maven.resolver: is it better to be explicit on the api or
implicit?
Regards,
Hervé
Le samedi 27 mai 2017 17:37:03 CEST, vous avez écrit :
I think I would change the following 2:
org.apache.maven.resolver.connector_basic >
org.apache.maven.resolver.connector.basic (in line with transport)
org.apache.maven.resolver.test_util >
org.apache.maven.resolver.testutil
it's a matter of taste: the underscores look kind of weird, but that's
probably caused because we've never used them as package names.
And wondering if "api" should be changed, since this is the
access-module
and we don't use api in our packages:
org.apache.maven.resolver.api > org.apache.maven.resolver
Using a property makes it easier to configure the maven-jar-plugin, but
it
also makes these constants turn into variables, i.e. you could set them
via system properties or cmdline args.
If only we supported something like
<Automatic-Module-Name>${project.properties["AutomaticModuleName"]}</Au
to
mat ic-Module-Name>
for the rest it's looking good.
thanks
Robert
On Sat, 27 May 2017 17:20:15 +0200, Hervé BOUTEMY
<herve.bout...@free.fr>
wrote:
please review and second if you think it's ok:
http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/d1724eb7
Regards,
Hervé
Le samedi 27 mai 2017, 13:24:47 CEST Hervé BOUTEMY a écrit :
he he, Java 9 is really coming, with associated real world
questions.
Maven Artifact Resolver is one of rare Maven components that has a
chance to
become a collection Java 9 modules, since it was written quite
recently
and
is pure new code as a result of Maven 3 refactoring, then does not
have
shared package names issues we have with Maven core itself.
And since it is expected to be a lib for easy embedding of artifact
resolution, making it a collection of Java 9 modules would be not
only a
great opportunity to test Java 9 modules, but it could be useful for
people
using it.
Then I'm highly in favor of trying.
Adding Automatic-Module-Name to the MANIFEST.MF looks feasible right
now,
without waiting much: I'm pretty sure module names will be obvious,
and
much
better if we define them instead of waiting for automatic names.
Let's
start! MRESOLVER-26 created [1]
Then there is the question of making real modules: is it feasible
right
now?
Or would we need a delay to tweak the module descriptors? And that
would
mean that we need Java 9 to build, even if the generated bytecode
remains
Java 7 compatible, isn't it? Is Maven tooling ready to it?
MRESOLVER-27 created to track the issue [2], but I'm not sure this
is
the
right time to do this job, but for the next release after this 1.1.0
Regards,
Hervé
[1] https://issues.apache.org/jira/browse/MRESOLVER-26
[2] https://issues.apache.org/jira/browse/MRESOLVER-27
Le samedi 27 mai 2017, 11:58:43 CEST Robert Scholte a écrit :
Hi,
I've got a question from Remi Forax if we could add Java9 module
descriptors to this project.
This will be one of the first which can provide such descriptors
since it
has no required dependencies other then its own and its package
structure
seems valid with the new Java9 rules.
We haven't discussed this in general yet, but we have several
projects
which are at the bottom of the dependency tree which should
provide
either
a module name or module descriptor when possible.
Do we want to help the community by having already several
libraries
with
a module descriptor?
Or we could add a Automatic-Module-Name to the MANIFEST.MF, so
others
can
refer to it by its official module name and we can add the
descriptor
once
Java9 has officially been released. (pro: doesn't require Java 9
:
:) )
:
Or do nothing yet...
thanks,
Robert
On Sat, 27 May 2017 11:42:32 +0200, Hervé BOUTEMY
<herve.bout...@free.fr>
wrote:
Hi,
No objection from me, thanks for keeping the ball rolling.
I tried to improve documentation by adding some useful links to
other
related
components [1]: I think the current state is better and ok for a
release.
One key question now is about Aether wiki content [2]: should we
copy
it? In a
wiki or in components sources?
I suppose wiki source format is supported by Doxia, then it
could be
imported
quite easily in sources.
And of course, there is the final question: should we do it
before
the
release?
Regards,
Hervé
[1] http://maven.apache.org/resolver-archives/resolver-LATEST/
[2] http://wiki.eclipse.org/Aether
Le vendredi 26 mai 2017, 16:18:02 CEST Michael Osipov a écrit :
Hi folks,
is there anything holding us back from MRESOLVER 1.1.0?
I'd like to start the release by the end of the week and have
it
integrated into Maven 3.5.1.
Any objections?
Michael
--------------------------------------------------------------------
-
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
