maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: Releasing Maven Resolver 1.1.0
Date Sat, 27 May 2017 17:05:27 GMT
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.boutemy@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"]}</Auto
> >> 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.boutemy@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.boutemy@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-unsubscribe@maven.apache.org
> >> >> > >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> 
> >> >> ---------------------------------------------------------------------
> >> >> 
> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> 
> >> ---------------------------------------------------------------------
> >> 
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> 
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> > 
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message