Re: [platform-dev] Localization bundles
Hi, FYI: I asked the community whether translations are needed on twitter. The results(90 votes) are the following: Q. Do you need translations? A1. Yes (Whole IDE) 41% A2. Yes (Only platform) 10% A3. No 49% https://twitter.com/junichi_11/status/1109250341634084864 So it seems that the community prefers translations for the whole IDE. Thanks, Junichi On Tue, Mar 19, 2019 at 9:59 PM Boris Heithecker wrote: > > I'd like to see the l10n files from the donation in the new repo for a > first thing to be done. Next thing could be rewriting the scripts, but it > depends on how the the bundles are going to be used. > I need them for a platform application which now still runs on 8.2 but > should be ported to 10 or 11 in the near future. So I'd like to either have > a script to integrate a specific locale into an existing target platform, > or have the specific binaries ready for use. > But that's for a platform application, which uses only a small part for the > whole IDE. > I don't know if anybody wants, or needs, multilingual IDE. That would be > one question to discuss. The point ise not only how to distribute. Another > point is the completeness of the bundles. As far as I know, in the early > days there were 3 officially supported languages (Brazilian Portuguese, > Japanese, Russian, and Simplified Chinese) and more community contributed > bundles. The latter are less complete, but I'm not sure. Distributing > multilingual binaries of the IDE means keeping the translations up to date > and that's a lot of never ending work for lots of native speakers. > Boris > > Am Mo., 18. März 2019 um 05:43 Uhr schrieb Jaroslav Tulach < > jaroslav.tul...@gmail.com>: > > > Hello Boris, > > thanks for tackling this issue. > > > > Dne sobota 16. března 2019 15:18:20 CET, Boris Heithecker napsal(a): > > > Hi all, > > > I'm preparing a pull request now for the localisation bundles from the > > 3rd > > > donation. I've made only slight changes to build.xml found in the folder. > > > A once-existing build target for the multilingual edition has obviously > > > been discarded as long ago as in NetBeans 7.2, > > > > The L10N stuff would certainly need more love. It was an afterthought, > > mostly > > ignored (not needed) by developers of NetBeans. As such the scripts could > > get > > out of sync. For example the NetBeans 10 restructured its sources to per > > cluster layout - that may also influence the L10N stuff a lot and nobody > > (certainly not me) was thinking of the impact on L10N bits. > > > > > but there are work-arounds > > > to create a localised IDE, or localise a platform app. It mostly > > involves > > > manually copying and zipping, so it's simple. > > > > The goal should be to press F11 (type ant build) somewhere and have the > > changed JAR copied to the appropriate place. So, subsequent "ant tryme" > > uses > > the changes. > > > > > Everything else is critical > > > because it means interfering with the existing build tasks of the whole > > > platform. > > > > > > If desired, I'm ready write a short instruction on how the localisation > > > bundles can be used with the current sources. > > > > PR is #1 thing. Instructions #2. Then the discussion can start. > > > > From what I hear it seems we want to merge the L10N files into the main > > repository. Where? l10n subfolder? > > > > How do we want to build the localized bits? How do we want to distribute > > them? > > All the translations will be included in the source release. Should they > > all > > be included in the binary release? Should they be only available as NBMs, > > so > > users can download just L10N for their locale? > > > > Good luck getting Apache NetBeans L10Ned! > > -jt > > > > > > > > > > > > Boris > > > > > > > > > Am Fr., 15. März 2019 um 11:59 Uhr schrieb Joerg Michelberger < > > > > > > j.michelber...@gmail.com>: > > > > Hi Boris, > > > > > > > > great to hear something about the localization stuff. > > > > > > > > For license changes there is a NB plugin > > > > http://plugins.netbeans.org/plugin/17960/license-changer > > > > > > > > I also have the need for at least german localization for my NB app > > and i > > > > can also test the bundles. > > > > > > > > Cheers > > > > Joerg > > > > > > > > Am Fr., 15. März 2019 um 11:37 Uhr schrieb Geertjan Wielenga > > > > > > > > : > > > > > Excellent work. Best is to fork this and provide a PR with the > > bundles > > > > > > > > and > > > > > > > > > other changes: > > > > > > > > > > https://github.com/apache/incubator-netbeans > > > > > > > > > > License header changes could be done after that (or before, your > > call) > > > > > > > > with > > > > > > > > > this: > > > > > > > > > > > > https://github.com/apache/incubator-netbeans-tools/tree/master/convert > > > > > > > > > > Gj > > > > > > > > > > On Fri, Mar 15, 2019 at 11:15 AM Boris Heithecker < > > > > > boris.heithec...@gmx.net> > > > > > > > > > > wrote: > > > > > > I was able to start a localized (german) version of NetBeans 10 >
Re: [VOTE] Release Apache Netbeans 11.0 (incubating) [vote candidate 4]
+1 (binding) I checked signature and sha512 files, LICENSE, NOTICE and DISCLAIMER files, of both source and binary release artifacts, as well as the output from the rat check. I only noticed one minor, not blocking, issue: the Copyright year in the NOTICE files should be updated to include 2019. Great work everyone, really! With all the additional enterprise modules, which AFAICT are properly covered on license and notice requirements, this is another huge step forward, bravo! Regards, Ate On 21/03/2019 08.41, Laszlo Kishalmi wrote: Dear all, This is our 4th voting candidate for the 11.0 release of Apache NetBeans. This time everything went through my smoke tests, so let's vote on it. Apache NetBeans 11.0 (incubating) constitutes all clusters in the Apache NetBeans Git repo, which together provide the NetBeans Platform (i.e., the underlying application framework), as well as all the modules that provide the Java SE, Java EE, PHP, JavaScript and Groovy features of Apache NetBeans. In short, Apache NetBeans 11.0 (incubating) is a full IDE for Java SE, Java EE, PHP and JavaScript development with some Groovy language support. Build artifacts available here: https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/ Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and NOTICE files, as well as a README file with build instructions, which are the same as these: https://github.com/apache/incubator-netbeans/blob/release110/README.md We are voting on: https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/incubating-netbeans-11.0-vc4-source.zip SHA512: e1ffe7873142bf6718f4365480501bec81126dc8e90884ea74f0cbc5d86a034ae3182515c4b78ccb250786bf84774d600f0b9451a6c518f773ca611cf82e4197 ./incubating-netbeans-11.0-vc4-source.zip KEYS file: https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS Apache NetBeans Git Repo tag: 11.0-vc4 : https://github.com/apache/incubator-netbeans/tree/11.0-vc4 Note: NetBeans license violation checks are managed via the rat-exclusions.txt file: https://github.com/apache/incubator-netbeans/blob/release110/nbbuild/rat-exclusions.txt Rat report shows no unknown licenses, except for license files: https://builds.apache.org/job/incubator-netbeans-release/404/artifact/rat-release-temp/nbbuild/build/rat-report.txt Included as a convenience binary, not relevant for the voting purposes (unzip it, run it and you'll see Apache NetBeans): https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/incubating-netbeans-11.0-vc4-bin.zip SHA512: 9d7fbe5c6bcf781fc1d3f8e2aee62db0435dd716c60dc73ef900ee2817473cc5b0a8e12c1453b7e57aedcece70cff778673a8cf563c1fa4eea816d9636955d4b ./incubating-netbeans-11.0-vc4-bin.zip Release specific wiki page: https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+11.0 How (and what) to try out the release: 1. Download the artifact to be voted on and unzip it. 2. Check that the artifact does not contain any jar files, save the: platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/empty.jar and enterprise/glassfish.common/test/unit/data/nottaDir-4_1_2.jar and enterprise/glassfish.common/test/unit/data/subdir/nottaDir-5.0.jar which are only jars by their name 3. Verify the cryptographic signatures, the NOTICE and LICENSE file 4. Build it using the README provided by the artifact. 5. Look in nbbuild/netbeans for the NetBeans installation created by the build process. This vote is going to be open at least 72 hours, vote with +1, 0, and -1 as usual. This vote round would determine if we carry on this release to the next IPMC vote . Binding votes are going to be carried over. Thank you for the hard work! Laszlo Kishalmi Volunteer Release Manager of Apache NetBeans 11.0 - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [MENTORS] Apache NetBeans maven artifacts groupId and process
Hi Mark,
Thanks a ton for the detailed reply, which makes a lot of sense to me.
Given that, I see no strong argument or reason to further hold up the
(re)quest to keep using org.netbeans for Maven GroupId.
Assuming of course all the technical and administrative hurdles with
Nexus and Sonatype can and will be dealt with appropriately.
So +1 on this from me.
A few comments and remarks inline below.
On 25/03/2019 19.36, Mark Struberg wrote:
Uff, quite a few questions. And really good ones! I try to play devils
advocate.
1) If the ASF owns the NetBeans mark and the netbeans.org domain it doesn't
make any legal difference if we call the groupId org.apache.netbeans or just
org.netbeans. Or even foo.netbeans.
2.) The referenced page with the artifact publishing guide lists it as SHOULD
and not as MUST.
Right, I should have noticed that.
3.) While org.apache.* is definitely preferred nowadays there are plenty ASF
projects which use a different groupId for historical reasons. Please check out
https://repository.apache.org/#view-repositories;releases~browsestorage
I wouldn't say 'plenty ASF projects'.
I just checked it out and besides freemarker and only a few recent
commons "maintenance" releases, all other releases not under the
org.apache groupId are at least from 2 or several more years ago.
In contrast to the like 100+ ASF projects which now are released under
the org.apache groupId, including many/most new commons releases.
So, while it may be OK and desired for NetBeans to keep using the
org.netbeans GroupId, IMO it is and remains 'uncommon' :-)
4.) The Branding is imo rarely related to the Maven groupId. The groupId is for
technicials to have a technical reference coordinate. The Branding is done on
the user facing level.
Sure, that makes sense to me as well.
However this isn't really made clear or explicit, at least not to my
understanding.
That said: I assume this 'problem' doesn't come up so often in practice
that it needed explicit attention in the policy.
5.)
But given the ongoing discussions with respect to externally hosted> 'binary'
releases (like on dockerhub) and especially how these should be
controlled and marked (branded) by the ASFNobody should be allowed to push
anything to any package name the ASF controls. This is simply something we have
to make clear with Sonatype, dockerhub and our infra. Sonatype eg has some
pretty strict control in place to forbid 'injection' of artifacts into foreign
groupIds.
6.) NetBeans is not only just an IDE but really a much bigger ecosystem!If we
change the groupId - or even worse the package names - then we break all the
projects depending on NetBeans for their own stuff. Be it plugins which
probably won't compile with new NB versions anymore. Or be it Editor projects
based on the NetBeans core.
NetBeans is actually not just an IDE and an ecosystem but also a modular
environment. A little bit like OSGi, but much more straight. There are many
dynamic processes involved which are based on names and reflection. Honestly I
do not really see a benefit in moving to org.apache.* for the groupId or
package names. Of course it would be more sane NOW, but it would most probably
be really disruptive for the whole surrounding projects building on top of
NetBeans core technologies.
Does this make sense?
Yes.
As you said, *if* doing a groupId change, NOW would be the more sane
time to do so.
And when not done now or soonish, more likely it won't be done at all,
ever.
Ultimately that is a decision for the (P)PMC and community to make, as
long as it is allowed and aligned with the ASF rules and policy.
Regards, Ate
LieGrue,strub
On Monday, 25 March 2019, 15:09:09 CET, Ate Douma wrote:
On 25/03/2019 12.59, Mark Struberg wrote:
We did have this discussion over a year ago with Greg Stein.
Back then the blocker was indeed the missing trademarks for 'NetBeans'.
With this resolved there is no legal problem anymore afaict.
Yes, the ASF by default prefers to use the org.apache.* groupIds. Mostly
because there is no exceptional management necessary in our Nexus
staging setup. But we have quite a few projects using other package
names. E.g. commons still publishes maintenance versions for commons-*
as groupId.
+1 for the Infra ticket as it might be some manual work for them to
allow NB to use org.netbeans.* as groupId. Please make sure to mention
that we need this package name for backward compatibility reasons.
I'm not sure about trademarks@a.o involvement. What do trademarks have
to do with our package name? It's _not_ about the domain, it's about
technical coordinates. Since we (ASF) now own the trademark on
'NetBeans' there is not much to clarify with them imo. It's really more
an infra thingy as this doesn't nicely fit into our
org.apache.${project} schema which is a proven path for them.
Hi Mark,
You may be completely right about this. The uncertainty I have (or had)
was not related to trademarks but the *b
Re: [DISCUSSION] Apache NetBeans 11.1 Development
On Mon, 25 Mar 2019, 17:50 Matthias Bläsing, wrote: > whether we release 4 times from master or 2 times IMHO does not matter > much. What I tryed to say was: > > - release what is in master a point X > - in the release branch only do minimal bugfixing > Yes, this is exactly what was originally discussed in the initial thread on time-based releases that we seem to have lost. Two other things worth discussion IMO - in the original thread I think it was Jan suggested having merge windows, and only merging things outside of that that are bug fixes intended for the next release - keep cherry picking minimal. - in line with that, maybe the release branch could happen later in the process? Or at least kept in sync with master for longer? > I don't see capacity to develop 11.1 and 12 in parallel. > If we have any need for a 11.1 at all, surely bug fixes only off the release branch would be better? Best wishes, Neil >
Re: [VOTE] Release Apache Netbeans 11.0 (incubating) [vote candidate 4]
Vote: +1 Source: - checked signature - verified sha512 - compared with the referenced git tag, differences are in unreleased modules/expected - build runs cleanly and results in a runnable IDE Binary - checked signature - verified sha512 Thank you Matthias Am Donnerstag, den 21.03.2019, 00:41 -0700 schrieb Laszlo Kishalmi: > Dear all, > > This is our 4th voting candidate for the 11.0 release of Apache > NetBeans. This time everything went through my smoke tests, so let's > vote on it. > > Apache NetBeans 11.0 (incubating) constitutes all clusters in the > Apache NetBeans Git repo, which together provide the NetBeans > Platform (i.e., the underlying application framework), as well as all > the modules that provide the Java SE, Java EE, PHP, JavaScript and > Groovy features of Apache NetBeans. > > In short, Apache NetBeans 11.0 (incubating) is a full IDE for Java > SE, Java EE, PHP and JavaScript development with some Groovy language > support. > > Build artifacts available here: > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/ > > Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and > NOTICE files, as well as a README file with build instructions, which > are the same as these: > > https://github.com/apache/incubator-netbeans/blob/release110/README.md > > We are voting on: > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/incubating-netbeans-11.0-vc4-source.zip > > SHA512: > e1ffe7873142bf6718f4365480501bec81126dc8e90884ea74f0cbc5d86a034ae3182 > 515c4b78ccb250786bf84774d600f0b9451a6c518f773ca611cf82e4197 ./incuba > ting-netbeans-11.0-vc4-source.zip > > KEYS file: > > https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS > > Apache NetBeans Git Repo tag: 11.0-vc4 : > https://github.com/apache/incubator-netbeans/tree/11.0-vc4 > > Note: NetBeans license violation checks are managed via the rat- > exclusions.txt file: > > https://github.com/apache/incubator-netbeans/blob/release110/nbbuild/rat-exclusions.txt > > Rat report shows no unknown licenses, except for license files: > > https://builds.apache.org/job/incubator-netbeans-release/404/artifact/rat-release-temp/nbbuild/build/rat-report.txt > > Included as a convenience binary, not relevant for the voting > purposes (unzip it, run it and you'll see Apache NetBeans): > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/incubating-netbeans-11.0-vc4-bin.zip > > SHA512: > 9d7fbe5c6bcf781fc1d3f8e2aee62db0435dd716c60dc73ef900ee2817473cc5b0a8e > 12c1453b7e57aedcece70cff778673a8cf563c1fa4eea816d9636955d4b ./incuba > ting-netbeans-11.0-vc4-bin.zip > > Release specific wiki page: > > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+11.0 > > How (and what) to try out the release: > > 1. Download the artifact to be voted on and unzip it. > 2. Check that the artifact does not contain any jar files, > save the: > platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdat > e/data/empty.jar and > enterprise/glassfish.common/test/unit/data/nottaDir-4_1_2.jar and > enterprise/glassfish.common/test/unit/data/subdir/nottaDir-5.0.jar > which are only jars by their name > 3. Verify the cryptographic signatures, the NOTICE and LICENSE file > 4. Build it using the README provided by the artifact. > 5. Look in nbbuild/netbeans for the NetBeans installation created by > the build process. > > > This vote is going to be open at least 72 hours, vote with +1, 0, and > -1 as usual. This vote round would determine if we carry on this > release to the next IPMC vote . Binding votes are going to be carried > over. > > Thank you for the hard work! > > Laszlo Kishalmi > Volunteer Release Manager of Apache NetBeans 11.0 > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [MENTORS] Apache NetBeans maven artifacts groupId and process
Uff, quite a few questions. And really good ones! I try to play devils
advocate.
1) If the ASF owns the NetBeans mark and the netbeans.org domain it doesn't
make any legal difference if we call the groupId org.apache.netbeans or just
org.netbeans. Or even foo.netbeans.
2.) The referenced page with the artifact publishing guide lists it as SHOULD
and not as MUST.
3.) While org.apache.* is definitely preferred nowadays there are plenty ASF
projects which use a different groupId for historical reasons. Please check out
https://repository.apache.org/#view-repositories;releases~browsestorage
4.) The Branding is imo rarely related to the Maven groupId. The groupId is for
technicials to have a technical reference coordinate. The Branding is done on
the user facing level.
5.)
> But given the ongoing discussions with respect to externally hosted> 'binary'
> releases (like on dockerhub) and especially how these should be
> controlled and marked (branded) by the ASFNobody should be allowed to push
> anything to any package name the ASF controls. This is simply something we
> have to make clear with Sonatype, dockerhub and our infra. Sonatype eg has
> some pretty strict control in place to forbid 'injection' of artifacts into
> foreign groupIds.
6.) NetBeans is not only just an IDE but really a much bigger ecosystem!If we
change the groupId - or even worse the package names - then we break all the
projects depending on NetBeans for their own stuff. Be it plugins which
probably won't compile with new NB versions anymore. Or be it Editor projects
based on the NetBeans core.
NetBeans is actually not just an IDE and an ecosystem but also a modular
environment. A little bit like OSGi, but much more straight. There are many
dynamic processes involved which are based on names and reflection. Honestly I
do not really see a benefit in moving to org.apache.* for the groupId or
package names. Of course it would be more sane NOW, but it would most probably
be really disruptive for the whole surrounding projects building on top of
NetBeans core technologies.
Does this make sense?
LieGrue,strub
On Monday, 25 March 2019, 15:09:09 CET, Ate Douma wrote:
On 25/03/2019 12.59, Mark Struberg wrote:
> We did have this discussion over a year ago with Greg Stein.
>
> Back then the blocker was indeed the missing trademarks for 'NetBeans'.
> With this resolved there is no legal problem anymore afaict.
>
> Yes, the ASF by default prefers to use the org.apache.* groupIds. Mostly
> because there is no exceptional management necessary in our Nexus
> staging setup. But we have quite a few projects using other package
> names. E.g. commons still publishes maintenance versions for commons-*
> as groupId.
>
> +1 for the Infra ticket as it might be some manual work for them to
> allow NB to use org.netbeans.* as groupId. Please make sure to mention
> that we need this package name for backward compatibility reasons.
>
>
> I'm not sure about trademarks@a.o involvement. What do trademarks have
> to do with our package name? It's _not_ about the domain, it's about
> technical coordinates. Since we (ASF) now own the trademark on
> 'NetBeans' there is not much to clarify with them imo. It's really more
> an infra thingy as this doesn't nicely fit into our
> org.apache.${project} schema which is a proven path for them.
Hi Mark,
You may be completely right about this. The uncertainty I have (or had)
was not related to trademarks but the *branding*, which happens to be
handled by the same committee.
I cannot find any public policy document at the ASF clarifying the
desire or possibly requirement how a Maven GroupId may or should be
used from branding POV.
The only practical documentation available with respect to Maven
artifacts is [1] and that assumes and requires using org.apache.
as prefix for the GroupId:
"Maven Group Ids: a list of the groupIds for this project. They should
all be subgroups of org.apache"
All this may indeed only be a technical hurdle, agreed.
But given the ongoing discussions with respect to externally hosted
'binary' releases (like on dockerhub) and especially how these should be
controlled and marked (branded) by the ASF, it seemed advisable to me
to check with the Branding (aka Trademarks) Committee what the rules and
policy requirements are, if any, with respect to Maven GroupId.
Regards,
Ate
[1] http://www.apache.org/dev/publishing-maven-artifacts
>
> LieGrue,
> strub
>
>
> Am 25.03.19 um 09:26 schrieb Bertrand Delacretaz:
>> Hi,
>>
>> On Mon, Mar 25, 2019 at 8:48 AM Ate Douma wrote:
>>> ...Unless one of the other mentors has a different view or is aware
>>> of more
>>> explicit guidelines in this, I suggest raising these questions at
>>> tradema...@apache.org instead
>> +1 and I suggest backing that discussion with a
>> https://issues.apache.org/jira/browse/NETBEANS ticket so as to
>> document what'sm being done and the conclusions.
>>
>> -Bertrand
>>
Let's clean up branches of incubator-netbeans-website repo
Hi, There are a lot of branches have been already merged in the repo[1]. However, I'm not sure whether I can delete them. So, could you please confirm your branches here[2], then delete unnecessary branches? [1] https://github.com/apache/incubator-netbeans-website/branches/all [2] https://github.com/apache/incubator-netbeans-website/branches/yours Thanks, Junichi - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSSION] Apache NetBeans 11.1 Development
No, definitely not in parallel. They’d be sequential. Gj On Mon, 25 Mar 2019 at 18:50, Matthias Bläsing wrote: > Hi, > > Am Montag, den 25.03.2019, 18:23 +0100 schrieb Geertjan Wielenga: > > I have been thinking differently about this ‘capacity’ item. In summary, > I > > think it will be easier to release 4 times per year than 2 times per > year, > > precisely because of the capacity item. Dealing with smaller incremental > > fixed date releases will I believe simplify rather than complexify > things. > > Neil C Smith did a good job of helping me see this perspective at Fosdem > > recently and I hope I summarized him correctly but this is how I have > come > > to see it. > > whether we release 4 times from master or 2 times IMHO does not matter > much. What I tryed to say was: > > - release what is in master a point X > - in the release branch only do minimal bugfixing > > I don't see capacity to develop 11.1 and 12 in parallel. > > Greetings > > Matthias > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: [DISCUSSION] Apache NetBeans 11.1 Development
Hi, Am Montag, den 25.03.2019, 18:23 +0100 schrieb Geertjan Wielenga: > I have been thinking differently about this ‘capacity’ item. In summary, I > think it will be easier to release 4 times per year than 2 times per year, > precisely because of the capacity item. Dealing with smaller incremental > fixed date releases will I believe simplify rather than complexify things. > Neil C Smith did a good job of helping me see this perspective at Fosdem > recently and I hope I summarized him correctly but this is how I have come > to see it. whether we release 4 times from master or 2 times IMHO does not matter much. What I tryed to say was: - release what is in master a point X - in the release branch only do minimal bugfixing I don't see capacity to develop 11.1 and 12 in parallel. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSSION] Apache NetBeans 11.1 Development
I have been thinking differently about this ‘capacity’ item. In summary, I think it will be easier to release 4 times per year than 2 times per year, precisely because of the capacity item. Dealing with smaller incremental fixed date releases will I believe simplify rather than complexify things. Neil C Smith did a good job of helping me see this perspective at Fosdem recently and I hope I summarized him correctly but this is how I have come to see it. Gj On Mon, 25 Mar 2019 at 18:08, Matthias Bläsing wrote: > Hi Laszlo, > > Am Sonntag, den 24.03.2019, 14:29 -0700 schrieb Laszlo Kishalmi: > > > > While we are doing the voting round, I think we need to think about > > NetBeans 11.1. > > > > Are we planning continue do cherry-picking into the release branch for > > 11.1 or do something more sophisticated? I mean 11.1 would be only some > > patch release or bringing some new things as well, like I'm planning to > > donate my Gradle support for Java EE projects. > > > > So any idea? > > my understanding was, that in 6 months (or whatever amount), we will > release netbeans 12 with whatever was integrated into master. I think > Gradle support for Java EE would fill that bill perfectly. > > Do we really have the capacity to release 12 and 11.1? I don't think > so. > > Greetings > > Matthias > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: [DISCUSSION] Apache NetBeans 11.1 Development
Hi Laszlo, Am Sonntag, den 24.03.2019, 14:29 -0700 schrieb Laszlo Kishalmi: > > While we are doing the voting round, I think we need to think about > NetBeans 11.1. > > Are we planning continue do cherry-picking into the release branch for > 11.1 or do something more sophisticated? I mean 11.1 would be only some > patch release or bringing some new things as well, like I'm planning to > donate my Gradle support for Java EE projects. > > So any idea? my understanding was, that in 6 months (or whatever amount), we will release netbeans 12 with whatever was integrated into master. I think Gradle support for Java EE would fill that bill perfectly. Do we really have the capacity to release 12 and 11.1? I don't think so. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Building and understanding Netbeans
Thanks! I had a little hope that the Readme is outdated ... :) Christoph Am 25.03.2019 um 15:12 schrieb Geertjan Wielenga: Here is the README which tells you JDK 8 is needed to build NetBeans: https://github.com/apache/incubator-netbeans Gj On Mon, Mar 25, 2019 at 2:47 PM Christoph Theis wrote: I could build Netbeans 11 vc4 within Netbeans successfully but I have some questions: Which JDK is required for the build? My first try, though some time ago, was from command line with JDK 11 and it failed. Now, building with Netbeans, I used a fairly recent JDK 8 but I couldn't change the JDK version in the nbbuild project. JDK 8 is nearing its en-of-lines so I wanted to check if it is still required or if a recent JDK can be used. Netbeans 10 didn't work with JavaHL from a recent subversion version but that fact was hidden in the log files. I wanted to have a look at the sources but I couldn't find the place for it. Is there a documentation of "what is where in the sources" to help beginners? Similar, in an HTML project, Netbeans complains about css syntax which looked perfectly OK to me. The css file came from the bootstrap project so I guess it should really be OK. I liked to have a look at the parser but I couldn't find the HTML5 plugin sources. Where can I find the sources of plugins which are already adapted for Apache Netbeans? Best regards Christoph - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [MENTORS] Apache NetBeans maven artifacts groupId and process
On 25/03/2019 12.59, Mark Struberg wrote:
We did have this discussion over a year ago with Greg Stein.
Back then the blocker was indeed the missing trademarks for 'NetBeans'.
With this resolved there is no legal problem anymore afaict.
Yes, the ASF by default prefers to use the org.apache.* groupIds. Mostly
because there is no exceptional management necessary in our Nexus
staging setup. But we have quite a few projects using other package
names. E.g. commons still publishes maintenance versions for commons-*
as groupId.
+1 for the Infra ticket as it might be some manual work for them to
allow NB to use org.netbeans.* as groupId. Please make sure to mention
that we need this package name for backward compatibility reasons.
I'm not sure about trademarks@a.o involvement. What do trademarks have
to do with our package name? It's _not_ about the domain, it's about
technical coordinates. Since we (ASF) now own the trademark on
'NetBeans' there is not much to clarify with them imo. It's really more
an infra thingy as this doesn't nicely fit into our
org.apache.${project} schema which is a proven path for them.
Hi Mark,
You may be completely right about this. The uncertainty I have (or had)
was not related to trademarks but the *branding*, which happens to be
handled by the same committee.
I cannot find any public policy document at the ASF clarifying the
desire or possibly requirement how a Maven GroupId may or should be
used from branding POV.
The only practical documentation available with respect to Maven
artifacts is [1] and that assumes and requires using org.apache.
as prefix for the GroupId:
"Maven Group Ids: a list of the groupIds for this project. They should
all be subgroups of org.apache"
All this may indeed only be a technical hurdle, agreed.
But given the ongoing discussions with respect to externally hosted
'binary' releases (like on dockerhub) and especially how these should be
controlled and marked (branded) by the ASF, it seemed advisable to me
to check with the Branding (aka Trademarks) Committee what the rules and
policy requirements are, if any, with respect to Maven GroupId.
Regards,
Ate
[1] http://www.apache.org/dev/publishing-maven-artifacts
LieGrue,
strub
Am 25.03.19 um 09:26 schrieb Bertrand Delacretaz:
Hi,
On Mon, Mar 25, 2019 at 8:48 AM Ate Douma wrote:
...Unless one of the other mentors has a different view or is aware
of more
explicit guidelines in this, I suggest raising these questions at
tradema...@apache.org instead
+1 and I suggest backing that discussion with a
https://issues.apache.org/jira/browse/NETBEANS ticket so as to
document what'sm being done and the conclusions.
-Bertrand
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Building and understanding Netbeans
Here is the README which tells you JDK 8 is needed to build NetBeans: https://github.com/apache/incubator-netbeans Gj On Mon, Mar 25, 2019 at 2:47 PM Christoph Theis wrote: > I could build Netbeans 11 vc4 within Netbeans successfully but I have > some questions: > > Which JDK is required for the build? My first try, though some time ago, > was from command line with JDK 11 and it failed. Now, building with > Netbeans, I used a fairly recent JDK 8 but I couldn't change the JDK > version in the nbbuild project. JDK 8 is nearing its en-of-lines so I > wanted to check if it is still required or if a recent JDK can be used. > > Netbeans 10 didn't work with JavaHL from a recent subversion version but > that fact was hidden in the log files. I wanted to have a look at the > sources but I couldn't find the place for it. Is there a documentation > of "what is where in the sources" to help beginners? > > Similar, in an HTML project, Netbeans complains about css syntax which > looked perfectly OK to me. The css file came from the bootstrap project > so I guess it should really be OK. I liked to have a look at the parser > but I couldn't find the HTML5 plugin sources. Where can I find the > sources of plugins which are already adapted for Apache Netbeans? > > > Best regards > > Christoph > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Building and understanding Netbeans
I could build Netbeans 11 vc4 within Netbeans successfully but I have some questions: Which JDK is required for the build? My first try, though some time ago, was from command line with JDK 11 and it failed. Now, building with Netbeans, I used a fairly recent JDK 8 but I couldn't change the JDK version in the nbbuild project. JDK 8 is nearing its en-of-lines so I wanted to check if it is still required or if a recent JDK can be used. Netbeans 10 didn't work with JavaHL from a recent subversion version but that fact was hidden in the log files. I wanted to have a look at the sources but I couldn't find the place for it. Is there a documentation of "what is where in the sources" to help beginners? Similar, in an HTML project, Netbeans complains about css syntax which looked perfectly OK to me. The css file came from the bootstrap project so I guess it should really be OK. I liked to have a look at the parser but I couldn't find the HTML5 plugin sources. Where can I find the sources of plugins which are already adapted for Apache Netbeans? Best regards Christoph - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: [MENTORS] Apache NetBeans maven artifacts groupId and process
Hi,
I think the ticket is already done here
https://issues.apache.org/jira/browse/INFRA-17127
Staging is possible on org.netbeans. for the maven artefacts for the IDE.
Newly created artefacts will go to their org.apache.netbeans
Like netbeans-parent, and the incoming utilities that are code donation from
codehaus we do a few month ago.
Regards
Eric
-Message d'origine-
De : Mark Struberg
Envoyé : lundi 25 mars 2019 13:00
À : dev@netbeans.incubator.apache.org
Objet : Re: [MENTORS] Apache NetBeans maven artifacts groupId and process
We did have this discussion over a year ago with Greg Stein.
Back then the blocker was indeed the missing trademarks for 'NetBeans'.
With this resolved there is no legal problem anymore afaict.
Yes, the ASF by default prefers to use the org.apache.* groupIds. Mostly
because there is no exceptional management necessary in our Nexus staging
setup. But we have quite a few projects using other package names. E.g. commons
still publishes maintenance versions for commons-* as groupId.
+1 for the Infra ticket as it might be some manual work for them to
allow NB to use org.netbeans.* as groupId. Please make sure to mention that we
need this package name for backward compatibility reasons.
I'm not sure about trademarks@a.o involvement. What do trademarks have
to do with our package name? It's _not_ about the domain, it's about
technical coordinates. Since we (ASF) now own the trademark on
'NetBeans' there is not much to clarify with them imo. It's really more
an infra thingy as this doesn't nicely fit into our
org.apache.${project} schema which is a proven path for them.
LieGrue,
strub
Am 25.03.19 um 09:26 schrieb Bertrand Delacretaz:
> Hi,
>
> On Mon, Mar 25, 2019 at 8:48 AM Ate Douma wrote:
>> ...Unless one of the other mentors has a different view or is aware of more
>> explicit guidelines in this, I suggest raising these questions at
>> tradema...@apache.org instead
> +1 and I suggest backing that discussion with a
> https://issues.apache.org/jira/browse/NETBEANS ticket so as to
> document what'sm being done and the conclusions.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [MENTORS] Apache NetBeans maven artifacts groupId and process
We did have this discussion over a year ago with Greg Stein.
Back then the blocker was indeed the missing trademarks for 'NetBeans'.
With this resolved there is no legal problem anymore afaict.
Yes, the ASF by default prefers to use the org.apache.* groupIds. Mostly
because there is no exceptional management necessary in our Nexus
staging setup. But we have quite a few projects using other package
names. E.g. commons still publishes maintenance versions for commons-*
as groupId.
+1 for the Infra ticket as it might be some manual work for them to
allow NB to use org.netbeans.* as groupId. Please make sure to mention
that we need this package name for backward compatibility reasons.
I'm not sure about trademarks@a.o involvement. What do trademarks have
to do with our package name? It's _not_ about the domain, it's about
technical coordinates. Since we (ASF) now own the trademark on
'NetBeans' there is not much to clarify with them imo. It's really more
an infra thingy as this doesn't nicely fit into our
org.apache.${project} schema which is a proven path for them.
LieGrue,
strub
Am 25.03.19 um 09:26 schrieb Bertrand Delacretaz:
Hi,
On Mon, Mar 25, 2019 at 8:48 AM Ate Douma wrote:
...Unless one of the other mentors has a different view or is aware of more
explicit guidelines in this, I suggest raising these questions at
tradema...@apache.org instead
+1 and I suggest backing that discussion with a
https://issues.apache.org/jira/browse/NETBEANS ticket so as to
document what'sm being done and the conclusions.
-Bertrand
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release Apache Netbeans 11.0 (incubating) [vote candidate 4]
+1 Le dim. 24 mars 2019 à 22:14, djamel torche a écrit : > +1 > > On Sun, 24 Mar 2019 at 15:46, Markus Kilås > wrote: > > > On 3/21/19 8:41 AM, Laszlo Kishalmi wrote: > > > We are voting on: > > > > > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-11.0-vc4/incubating-netbeans-11.0-vc4-source.zip > > > > > > > > > SHA512: > > > > > > e1ffe7873142bf6718f4365480501bec81126dc8e90884ea74f0cbc5d86a034ae3182515c4b78ccb250786bf84774d600f0b9451a6c518f773ca611cf82e4197 > > > ./incubating-netbeans-11.0-vc4-source.zip > > > > > > KEYS file: > > > > > > https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS > > > > +1 (non-binding) > > > > * Compared SHA-512 sum from e-mail with source ZIP > > * Verified PGP signature > > * Checked for other JAR files > > * Checked NOTICE, LICENSE and DEPENDENCIES files > > * Building with Apache Ant packaged with Fedora does not work but that > > is a known issue: https://issues.apache.org/jira/browse/NETBEANS-239 > > * Built full cluster with Fedora 28, Apache Ant 1.10.5 (from > > https://ant.apache.org), OpenJDK 1.8.0_201 (15 minutes) > > * Running with OpenJDK 11.0.2 > > > > Suggestion: Please use HTTPS links for the dependencies, licensees etc > > in DEPENDENCIES etc. > > > > Suggestion: It would be nice if the ZIP file had a top level folder and > > preferably with the version also so that it can be directly unzipped > > alongside other NetBeans versions and without risk of mixing its > > files/folders with any other files in the same folder. > > > > Best Regards, > > Markus Kilås > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > >
Re: [MENTORS] Apache NetBeans maven artifacts groupId and process
Hi, On Mon, Mar 25, 2019 at 8:48 AM Ate Douma wrote: > ...Unless one of the other mentors has a different view or is aware of more > explicit guidelines in this, I suggest raising these questions at > tradema...@apache.org instead +1 and I suggest backing that discussion with a https://issues.apache.org/jira/browse/NETBEANS ticket so as to document what'sm being done and the conclusions. -Bertrand - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [MENTORS] Apache NetBeans maven artifacts groupId and process
On 25/03/2019 05.55, Jaroslav Tulach wrote: Thanks Ate. It is great to hear that using org.netbeans.* groupId is legally OK and that it is not against any Apache policy. I didn't draw that conclusion, please don't make it sound as if I did... Instead, I wrote this: Legally, I think it should be fine, because netbeans.org has been transferred to the ASF. But it might still not be desired or allowed from ASF (branding) Policy POV. So again, I advise to explicitly ask this to be answered and agreed upon first by the Apache Trademark (and Branding) Committee. [APIs are like stars](http://wiki.apidesign.org/wiki/Star) - they are with us "forever" (or at least until their users/observers are alive). It is the goal of the maintainers to make sure the APIs evolve well. Code changes driven by marketing/branding purposes are the most harmful and useless changes to any API. Nobody wants to repeat the com.sun.swing -> javax.swing rename disaster. To be clear: we're discussing Maven coordinates here, not Java packages! Java package naming is a different topic and *may* not need to follow the rules or policy, transitionally. For example it might be feasible to provide and use org.apache. prefixed Maven coordinates which artifacts provide org.netbeans Java packaged classes. Or maybe even *also* provide org.netbeans. prefixed Maven coordinated artifacts as transitional solution for existing Maven users. But again, please ask at tradema...@apache.org, I'm not enough of an expert in this matter. It is important, especially right now, to make the migration of NetBeans Platform 8.2 to Apache NetBeans Platform as smooth as possible. We don't want people to ask questions like: "Should I upgrade or should I rather stay with pre-Apache version?" Keeping the artifact co-ordinates is essential part of making the migration of Maven based projects on top of NetBeans Platform "no brainer". Many Apache projects are [kept in historical co-ordinates]( https://repository.apache.org/content/groups/public/) - freemarker, log4j, etc. I you actually check the above you'll notice these projects *did* move and migrate to using the org.apache. prefix for their GroupId. What you're pointing at are indeed *historical* (old) artifacts. There may even be a necessary incidental maintenance/security release in one of the old / outdated coordinates, but for *new* releases these, and AFAIK every other ASF project with Maven artifacts, nowadays uses the org.apache. prefix. It is not fair to not allow NetBeans to do the same. Especially when backward compatibility has always been a major focus of everything we did in the NetBeans Platform. Dear mentors, please guide me on my quest to keep the Maven co-ordinates unchanged. Thanks you. Unless one of the other mentors has a different view or is aware of more explicit guidelines in this, I suggest raising these questions at tradema...@apache.org instead. Jaroslav Tulach NetBeans Founder NetBeans Platform Architect po 25. 3. 2019 v 0:57 odesílatel Ate Douma napsal: On 19/03/2019 18.34, Eric Barboni wrote: Hi, Prior to any process for voting/releasing the Apache Netbeans maven artefacts would be sure on one point. We may use groupId org.apache.netbeans or org.netbeans as we have the grant to do so. It would be easier and more backward compatible to use org.netbeans as groupId for Apache NetBeans artefacts. Can we use that groupId forever even if we became a TLP. Or was it only for transitioning purpose. I think you must ask this on tradema...@apache.org. The Apache Branding Policy says [1] that podlings may request to keep non apache domain names (e.g. netbeans.org) for *limited uses* once the podling graduates to TLP. That primarily concerns website and domain usages, but the Policy isn't really clear/explicit in how far the "limited uses" is, or may be extended to 'forever' usage when such a domain has been transferred to the ASF. My gut feeling is: only in exceptional cases, as explained at [1] for openoffice.org and groovy-lang.org. In how far this extends (or not) to the usage of non apache Maven GroupId, temporarily or 'forever', is really not addressed nor answered there, nor anywhere else I searched for it. Legally, I think it should be fine, because netbeans.org has been transferred to the ASF. But it might still not be desired or allowed from ASF (branding) Policy POV. So again, I advise to explicitly ask this to be answered and agreed upon first by the Apache Trademark (and Branding) Committee. Possibly other mentors may have more experience/knowledge in this area how other podlings dealt with this, and can chime in as well? Note: I understand the wish to retain the usage of org.netbeans as Maven GroupId for backwards compatibility. But even if this will be allowed, is it really needed to stick to using it 'forever'? If not yet now, IMO it is advisable to at least discuss and plan to migrate and transition to using org.apache.netbean
