Ah, I see, you are right. For most artifacts, a more complex filename is used,
like “net.java.html.boot”. xhr4j and ko4j being the exceptions. Should we use
the maven coordinates (groupId.artifactId) for these as Automatic-Module-Name
attribute in their manifest files?
Dave
> Op 9 november 201
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
Now, it is not my itch. I don't use the artifacts as dependency in my
applications yet. It may be or become other peoples pain, now or on the future.
Nevertheless, I will try to make a pull request, however, the next couple of
days I have very limited time. I will try to do it over the next coup
Hi Dave,
This is your itch, feel free to scratch it, i.e., pull request. :-)
Gj
On Thu, 9 Nov 2017 at 09:30, Dave Schoorl wrote:
> This is the link to the presentation of Robert Scholte at Devoxx (half
> hour): https://www.youtube.com/watch?v=tHTmFlVAyAc
>
> >
> > Op 9 november 2017 om 9:0
This is the link to the presentation of Robert Scholte at Devoxx (half hour):
https://www.youtube.com/watch?v=tHTmFlVAyAc
>
> Op 9 november 2017 om 9:00 schreef Dave Schoorl :
>
> That is correct. But please note, that a module name must be unique on
> the module path. In order to prev
All HTML/Java modules are OSGi bundles. The automatic module name shall be
the same as Bundle-SymbolicName, I assume. The manifest entry is defined
here:
https://github.com/apache/incubator-netbeans-html4j/blob/master/pom.xml#L329
Feel free to create the PR.
I wanted to prepare 1.5.1 release relat
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,
@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
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
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 :
> Should
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 :
OK, the bits are now in
https://dist.apache.org/repos/dist/releas
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
On Mon, Nov 6, 2017 at 4:54 PM, Jaroslav Tulach
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 proce
If you want mentors to respond, best to put [mentors] tag at the start of
the subject line, so they can quickly see their insights are needed.
Gj
On Mon, Nov 6, 2017 at 4:54 PM, Jaroslav Tulach
wrote:
> I see. I started to think about moving the bits to proper place on the
> lasts weekend, but
I see. I started to think about moving the bits to proper place on the
lasts weekend, but then I realized that the release is so bad, that we need
release 1.5.1 anyway. Thus I stopped trying.
All bugs reported against 1.5 version have been fixed. It is possible to
release 1.5.1 now. Does it still
Jaroslav,
Don't forget that an ASF release isn't official until it's been placed in
/dist/release. In your case, it goes into /dist/release/incubator/netbeans.
John
On Mon, Oct 23, 2017 at 4:29 AM Jaroslav Tulach
wrote:
> The vote started four days ago, so it is time to announce the result:
>
The vote started four days ago, so it is time to announce the result:
Approved.
Bertrand Delacretaz: +1
John D. Ament: Here's my +1 to release.
Mark Struberg: +1 IPMC binding ...
Ate Douma: +1 (binding)
No vote against, four binding approvals, plus one extra:
Wade Chandler: +1
Thanks for making
17 matches
Mail list logo
