Re: Contrib repo & Community Plugin Repo

[Jesse Glick]

Resurrecting this thread, since Tim Boudreau recently Mavenized the
contrib repo:

https://github.com/timboudreau/netbeans-contrib

The Mavenization is certainly welcome (to me at least!) but someone
needs to officially decide what to *do* with all that stuff. Probably
all the live modules or logical module groups (those active on the
Plugin Portal) should each get their own GH repo somewhere—does not
make sense to shove them all into one repo. And then how do bits get
distributed to users? I am not sure what happened to deadlock and its
CI job for contrib modules. Plugin Portal still seems to be alive but
what is its future? Of

http://plugins.netbeans.org/my-plugins

there are a number of plugins I would like to keep running and
available; some were already being maintained on GitHub, but some
(notably quickfilechooser) were not.

-
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: The IDE for DevOps was: IntelliJ IDEA vs Netbeans

[Jesse Glick]

On Mon, Apr 23, 2018 at 2:14 AM, Jaroslav Tulach
 wrote:
> there should be no Maven index processing on the
> client (by default). There should be a webservice the IDE would query
> instead.

This just begs the question of which web service that would be. If you
only use Maven Central, fine, but if you are using custom or even
private/firewalled repositories, this will not fly.

Not to say that the current Nexus index system is ideal—in fact Nexus
3 seems to have dropped this feature, at least so far, so you have to
stay on Nexus 2. (Or, ironically, Artifactory.)

*Probably* the current indexer functionality could be replaced by REST
calls to your artifact manager. But there is no standard API for that,
as far as I know, so there would need to be separately maintained
Nexus and Artifactory modules.

One relatively easy target for optimization, however: stop relying on
the indexer to service queries about available versions of a given
artifact (i.e., find GAVs when GA is known). That is a common
operation: for example, completion on `` in a POM, or the
hint about an old ``. This can be done quite simply and
portably by downloading `maven-metadata.xml` from the repository. In
fact Maven itself downloads this automatically at various times, and
caches it in the local repository; and the accuracy of even the cached
version is generally better than that of a Nexus index: Maven
refreshes the cache once per day or when passed `-U` or when running
`mvn install`.

-
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: Current Status & Proposed Plan for Apache NetBeans

[Jesse Glick]

On Wed, Nov 1, 2017 at 7:52 AM, Jan Lahoda  wrote:
> There was a significant time between the snapshot for the donation was made
> and the donation actually happened. That's unfortunate, but I don't think
> anybody here could do anything about that (Geertjan tried, AFAIK).

To be clear, I have no problem with that decision. I am just
suggesting that it be clearly communicated somewhere prominent.

https://github.com/apache/incubator-netbeans/blob/master/README.md

for example could note the last-synchronized Mercurial revision and
explain the potential implications for contributors. (At least until
automated synchronization is up and running, or the relevant portions
of the Mercurial repository are officially closed.)

Re: Support for (Java) Pattern Matching

[Jesse Glick]

On Wed, Nov 1, 2017 at 2:31 AM, Jan Lahoda  wrote:
> when one opens a pull request against
> apache/(incubating-)netbeans, then I think the code can be considered to be
> submitted to ASF (per iCLA).

IANAL but that sounds right.

> for a long-running branch in a
> personal repository, if the author of the branch cannot send the pull
> request to merge it for whatever reason

I recommend just filing a PR the moment you start the branch and have
some initial commits. It can be marked as a work in progress / not for
immediate merge / etc. with various labels. (It is possible to create
PR search permalinks on GitHub which filter by label.) If your
experiment never comes to anything, close the PR if you like. You can
always reopen it and pick up where you left off, with review comments
and everything intact.

(Normally when merging a PR I would delete the corresponding fork
branch, both on GitHub and in my local clone, to tidy up; but if you
are closing a PR you expect to maybe resume work on later, you can
just leave the branch in the remote. You could probably even recreate
the branch based on the last commit hash visible in the PR, though I
cannot recall ever trying that.)

On this topic: the Eclipse foundation apparently has some tool they
run automatically on PRs which verifies that all commits have been
signed and that the signature matches someone with a CLA on file. This
shows up as a GitHub status check, so you can see right in the PR
whether the contribution is coming from someone who has done the right
paperwork. If as a new contributor you forget about this, there will
be a red X until you file a CLA, fix your Git settings, and amend your
commit to include a signature.

> how about releases from the branches. It may be desirable to do a
> "preview" "release" for the branch (e.g. "pattern" preview; although I'd
> prefer if we handled Java language features in the master, but even if we
> succeed in that, it will take a long time to achieve). I don't think we can
> release from a personal github.

Certainly you would not want to cut official releases from a fork
branch. If this is an official preview of some kind—like a beta
release?—then there should I suppose be some origin branch for that
purpose. You can still use PRs to propose specific additions to that
branch; you just set the target branch accordingly when filing the PR.

It really depends on what your policy for distributing experimental
changes is. As you say, using feature flags or hidden settings to
enable unstable code in normal releases is the simplest approach for
infrastructure, but might not be practical until the code has been
refactored enough to allow this kind of behavior to be switched
dynamically. So if you are publishing, essentially, forks of official
modules, you are going to run into tricky questions anyway. What
version number could you pick which is newer than the official
ancestor merge base, but will be older than the official release
version when the feature is stabilized, and incomparable to unrelated
feature forks? Etc.

Re: Support for (Java) Pattern Matching

[Jesse Glick]

FWIW I have been working exclusively in GitHub for years now, and my
advice is to have every change be a PR coming from a repository fork.
Once you are accustomed to this workflow, it is not onerous, and
provides a natural place to track discussion of changes and
relationships to other changes. It also ensures that repositories of
record are not polluted with dozens of long-obsolete branches; there
are only PRs, which are either open or merged or closed without merge,
and a handful of origin branches reflecting official release lines.
Committers are just people trusted to push the Merge button.

(My project also generally demands that a PR not be merged until there
has been at least one code review from another committer; and an
automated build of that PR has passed all tests, so that the target
branch is always “clean”.)

On Fri, Oct 20, 2017 at 4:50 PM, Jan Lahoda  wrote:
> if multiple people (can)
> contribute to a branch and the branch has a fair chance to end up in the
> mainline, it is IMO easier to keep it in an ASF repo, than on GitHub.

Even for this case I do not recommend using “origin PRs”. If you are
proposing a change, create a topic branch in your fork and file the
PR. If someone else has minor comments or suggestions, they can review
and you can decide how to process their feedback. If they have
significant changes to propose which are too complex to comfortably
describe verbally, they can simply create a child branch and file a PR
_against your PR_. If you agree with what they propose—perhaps after
some discussion and refinement—you just merge the sub-PR, and their
changes are incorporated. But the author of the PR remains of control.
When someone else can push directly to the branch of your PR, they may
well be “putting words in your mouth”.

Once you start to use GitHub the way it is designed, your development
style changes, and for the better.

Re: Current Status & Proposed Plan for Apache NetBeans

[Jesse Glick]

So, at this point, what is the repository of record for ongoing
development of that subset of NetBeans included in the initial
contribution? I mean real functional changes, not licensing or build
stuff.

Maybe I am missing some very obvious FAQ (and I surely missed prior
discussions), but I looked in

http://netbeans.apache.org/
https://cwiki.apache.org/confluence/display/NETBEANS/NetBeans+Transition+Process
https://cwiki.apache.org/confluence/display/NETBEANS/How+to+Participate

and none appear to say definitively.

I ask because there appear to be at least some divergent changes. For example,

https://github.com/apache/incubator-netbeans/commits/master/jshell.support/src/org/netbeans/modules/jshell/support/ShellSession.java

does not include

http://hg.netbeans.org/main-silver/rev/fcaaa60addf7

There seem to be bigger differences, too; for example
`org.openide.windows.ModeSelector` dates back to May in Mercurial, yet
seems to be absent from Git. If you simply check Tools » Plugins »
Updates on a fresh build you see that there are a bunch of updates
coming from the original UC servers; and these of course only show
changes which happened to involve bumping some
`OpenIDE-Module-Specification-Version`.

So is the code drop based on some very old snapshot? This is not
encouraging to developers who want to make sure changes they spend
time working on are sent to the “right” fork. If some divergence is
indeed deliberate, this ought to be called out somewhere prominent.

Re: Download binaries from Maven

[Jesse Glick]

You could try using Git LFS. That would be the most direct equivalent to
the existing system, which I cooked up IIRC before Mercurial had an
official largefiles extension. Using a Maven repository would make sense if
the build itself is being switched to some modern build tool, but that is a
far larger project.

On Dec 7, 2016 20:28, "Niclas Hedhman"  wrote:

> Maven repository normally contains hashes for each file. They are intended
> for download integrity check, but you could also keep the hash in your
> distro. Additionally, many projects uploads detached PGP signatures of each
> file, for you to truly verify its origin if you so desire.
>
> Example; http://repo1.maven.org/maven2/org/qi4j/core/org.qi4j.core.
> api/2.1/
>
> Cheers
> Niclas
>
> On Thu, Dec 8, 2016 at 2:13 AM, Emilian Bold  wrote:
>
> > The previous system was a bit more solid if only because you also saved
> the
> > hash in the dependency. So after download you could do an automated
> > integrity check.
> >
> > The Maven groupId:artifactId:version does not guarantee you have the same
> > file. Perhaps groupId:artifactId:version:hash should be used instead?
> >
> > Also, is there some (automatic) check during this transition that
> verifies
> > the binary JAR from http://hg.netbeans.org/binaries and the replacing
> one
> > from the Maven repository are actually identical?
> >
> > > the NetBeans build currently downloads bits from its own proprietary
> > binary repository.
> >
> > I wouldn't call this "proprietary". It's basically a lib/ folder stored
> an
> > a public HTTP server. Perhaps 'non-standard' would be the right word but
> > it's a very simple, open and functional system.
> >
> >
> >
> > --emi
> >
> > On Wed, Dec 7, 2016 at 6:13 PM, Jaroslav Tulach <
> > jaroslav.tul...@oracle.com>
> > wrote:
> >
> > > Hi.
> > > As we previously discussed, the NetBeans build currently downloads bits
> > > from
> > > its own proprietary binary repository. I assume it would be better to
> > > download
> > > them directly from Maven (Central) repository. I am willing to
> implement
> > > such
> > > system. I've created issue
> > >
> > > https://netbeans.org/bugzilla/show_bug.cgi?id=269264
> > >
> > > to track progress of my work. Feel free to share comments and
> > observations.
> > >
> > > -jt
> > >
> > >
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>