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 15:48:24 GMT
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"]}</Automat
> 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


Mime
View raw message