ACCUMULO-4121 - netbeans

[mjwall]

Added typical files for a maven project to all .gitignores

Also excluded those files in the rat plugin section of the pom.xml files. Not
excluded by default, see
http://creadur.apache.org/rat/apache-rat-plugin/check-mojo.html#useDefaultExcludes

[madrob]

This change set is inconsistent on terminating files with a newline or not.

[mjwall]

@madrob you are correct. I see https://github.com/apache/accumulo/blob/master/contrib/Eclipse-Accumulo-Codestyle.xml#L205, but running mvn with -Pautoformat doesn't add the newlines. Neither did the EclipseFormatter plugin for Netbeans.

I can add them manually, but is there a better way?

[madrob]

http://unix.stackexchange.com/a/31955 looks helpful? Idk, manually might be fine since there's only a handful of files, but using sed might be more fun.

[mjwall]

@madrob, thanks for sed. My question was more along the lines of "Why didn't the Eclipse-Accumulo-Codestyle.xml fix this?" Maybe it doesn't format .gitignore files?

I'll fix this manually.

[joshelser]

My question was more along the lines of "Why didn't the Eclipse-Accumulo-Codestyle.xml fix this?" Maybe it doesn't format .gitignore files?

Not sure, myself. Also not a big deal to me FWIW.

[joshelser]

QQ about the xml files: are these created by netbeans when you import the project?

[mjwall]

It is possible to run a maven project without generating any of these files. But say I want to run Netbeans with Java 8 and compile the project with Java 7, then a nb-configuration.xml is created. That file is use for other configs too. If I want to run a custom task, like mvn clean test -Psunny, a nbactions.xml file is created. The nbproject directory is created for any non maven projects. I don't actually have any nbproject but a user could create one for say some of the native code or some of the python code in the test module.

I have been unable to get Netbeans to not require these files under each sub module.

[joshelser]

Ok, the spirit of my question was just "netbeans is creating these itself", but thanks for the explanation!

[joshelser]

👍 by me. Will merge later today/this weekend unless someone beats me to it.

[mjwall]

Cool, thanks @joshelser. Looks like it doesn't merge cleanly with 1.7 and master. Should I do separate pull requests?

[joshelser]

Looks like it doesn't merge cleanly with 1.7 and master. Should I do separate pull requests?

Nah, don't worry about it. I can just do the merge locally. Your changes aren't difficult to reason about :). I'll ping you if I need help.

[ctubbsii]

Looking at the changes, I'm reminded why we didn't do this before: a lot of maven plugins assume that generated files will not appear in a place other than target, or if they do, they will appear as dotfiles.

Netbeans has the unfortunate behavior of using configuration files plopped right in the middle of the source tree, which are not dotfiles. This can cause some very unexpected and undesirable behavior in some plugins, especially packaging/assembly plugins, which might create "dirty" artifacts containing these configuration files.

They might also not get properly ignored by a wide variety of plugins. I say this not to object, but only to document that we need to pay attention to these files, if they make it into the source tree, and we need to be extra careful to check that they do not exist in any of our released artifacts. (which is an easy enough check to do).

It would be nice if Netbeans allowed putting these files outside the source tree, or if it wrote them as dotfiles. Perhaps that's an option? If not, I'd encourage Netbeans developers to poke upstream about doing that in the future.

[joshelser]

especially packaging/assembly plugins, which might create "dirty" artifacts containing these configuration files

Yeah, I thought about that. I figured it was limited to release managers (so only a few people would have to worry about it), so it was OK.