As I said, the JAR-Names are sensible and will lead to a proper unique
automatic module name which is unique on module path, e.g. “net.java.html.boot”
. Still I think it’s good to add the manifest entry, as it indicates we care
about modules.
I would oppose to using org.apache.netbeans.html yet. The module name should be
the same as OSGi Bundle-SymbolicName and maven coordinates
(groupId.artifactId). Otherwise it would be confusing. If we decide to change
this then all of them should change.
--Toni
Am 09.11.17, 09:00 schrieb "Dave Schoorl" <dscho...@bkwi.nl>:
That is correct. But please note, that a module name must be unique on the
module path. In order to prevent name collisions, you should provide a propper
name, probably containing a reverse DNS name like in packages. And if it is
something in maven central, I believe there are more restrictions, E.g.
regarding the groupId. I saw a presentation of Robert Scholte (maven committer)
at Devoxx yesterday explaining this stuff.
To keep your module name unique, I propose to start it of with
org.apache.netbeans.html, like org.apache.netbeans.html.xhr4j. Or are there
other suggestions?
I will try to make a pull request this weekend at the latest.
Kind regards,
Dave
> Op 9 november 2017 om 7:53 schreef Anton Epple <toni.ep...@eppleton.de>:
>
>
> @Geertjan: All JARs are treated as automatic modules in Java 9,
regardless of this entry in manifest. Only difference of manifest entry is
that you can provide a proper name others can rely on.
>
> In absence of the manifest entry, the JPMS derives an automatic module
name from the name of the jar stripping version numbers. Since the jar names
are sensible in case of HTML-Java APIs (reverse domain), the module name will
probably be correct. The automatic module name we put in manifest will make no
difference as it’s the same string as the automatically derived one.
>
> That said, since all that is needed is to put a key in manifest, we
should do that. This way it’s guaranteed to work, and we don’t need to test if
automatic name is really correct :-).
>
> --Toni
>
>
>
> Am 09.11.17, 06:41 schrieb "Geertjan Wielenga"
<geertjan.wiele...@googlemail.com>:
>
> But Dave's idea of including Automatic-Module-Name would make
HTML/Java API
> an automatic JDK 9 module (
> http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html).
>
> Maybe a cool idea, what would the problem be, and maybe Dave should
provide
> a pull request for this?
>
> Gj
>
> On Thu, Nov 9, 2017 at 6:39 AM, Jaroslav Tulach
<jaroslav.tul...@gmail.com>
> wrote:
>
> > Hello Dave,
> > I know little about desirable changes to target JDK9. However if
you want
> > to start development that would bring HTML/Java API closer to JDK9,
you are
> > more than welcomed. Of course, that would be for some future
release, not
> > 1.5.x.
> > -jt
> >
> >
> > 2017-11-09 0:52 GMT+01:00 Dave Schoorl <dscho...@bkwi.nl>:
> >
> > > Should we not add Automatic-Module-Name attribute to the jar's
manifests,
> > > now that Java9 is out? Especially since these files end up in
public
> > maven
> > > repo.
> > >
> > > Kind regards,
> > >
> > > Dave
> > >
> > >
> > > Op 8 november 2017 om 20:40 schreef Jaroslav Tulach <
> > > jaroslav.tul...@gmail.com>:
> > >
> > > OK, the bits are now in
> > > https://dist.apache.org/repos/dist/release/incubator/
> > > netbeans/incubating-netbeans-html4j/
> > > directory since revision 23014.
> > >
> > > Since revision 23015 the files are removed from the
> > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/
> > > directory.
> > >
> > > The release 1.5 is out! Time to prepare 1.5.1...
> > > -jt
> > >
> > > 2017-11-07 17:20 GMT+01:00 Bertrand Delacretaz
<bdelacre...@apache.org>:
> > >
> > > On Mon, Nov 6, 2017 at 4:54 PM, Jaroslav Tulach
> > >
> > > <jaroslav.tul...@gmail.com> wrote:
> > >
> > > ...Does it still make sense to do official release of
> > > version 1.5 or can we skip that?...
> > >
> > > IIUC the only thing left is to move that release under
> > > /dist/release/incubator/netbeans - I think you should do it to
> > > demonstrate the complete process.
> > >
> > > If you don't expect people to use that release it's fine to avoid
> > > "advertising" it.
> > >
> > > -Bertrand
> > >
> >
>
>
>
