Adding to path vs. linking from /bin

On linking

You generally do not link /usr/local/* with /bin, but this is more of a historical practice. In general, there are a few "technical" reason why you cannot do what you're suggesting.

Making links to executables in /bin can cause problems:

1. Probably the biggest caveat would be if you're system is having packages managed by some sort of package manager such as RPM, dpkg, APT, YUM, pacman, pkg_add, etc. In these cases, you'll generally want to let the package manager do its job and manage directories such as /sbin, /bin, /lib, and /usr. One exception would be /usr/local which is typically a safe place to do as you see fit on the box, without having to worry about a package manager interfering with your files.

2. Often times executables built for /usr/local will have this PATH hard-coded into their executables. There may also be configuration files that are included in /usr/local as part of the installation of these applications. So linking to just the executable could cause issues with these apps finding the .cfg files later one. Here's an example of such a case:

   $ strings /usr/local/bin/wit | grep '/usr/local'
   /usr/local/share/wit
   /usr/local/share/wit/
   

3. The same issue that applies to finding .cfg files can also occur with "helper" executables that the primary app needs to run. These too would also need to be linked into /usr/bin, knowing this might be problematic and only show up when you actually attempted to execute the linked app.

NOTE: in general it's best to avoid the temptation to link to one off apps in /usr/bin.

/etc/profile.d

Rather then have all the users provide this management, the admin could very easily add this to everyone's $PATH on the box by adding a corresponding file in the /etc/profile.d directory.

A file such as this, /etc/profile.d/maven.sh:

PATH=$PATH:/usr/local/maven/bin

You generally do this as an admin instead of polluting all the users' setups with this.

Using alternatives

Most distros now provide another tool called alternatives (Fedora/CentOS) or update-alternatives (Debian/Ubuntu) which you can also use to loop into the $PATH tools which might be outside the /bin. Using tools such as these is preferable since these are adhering more to what most admins would consider "standard practice" and so makes the systems easier to hand off from one admin to another.

This tool does a similar thing in making links in /bin; but it manages the creation and destruction of these links, so it's easier to understand a system's intended setup when done through a tool vs. done directly as you're suggesting.

Here I'm using that system to manage Oracle's Java on a box:

$ ls -l /etc/alternatives/ | grep " java"
lrwxrwxrwx. 1 root root 73 Feb  5 13:15 java -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java
lrwxrwxrwx. 1 root root 77 Feb  5 13:15 java.1.gz -> /usr/share/man/man1/java-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 70 Feb  5 13:19 javac -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javac
lrwxrwxrwx. 1 root root 78 Feb  5 13:19 javac.1.gz -> /usr/share/man/man1/javac-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 72 Feb  5 13:19 javadoc -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javadoc
lrwxrwxrwx. 1 root root 80 Feb  5 13:19 javadoc.1.gz -> /usr/share/man/man1/javadoc-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz

You can see the effects of this:

$ type java
java is /usr/bin/java

$ readlink -f /usr/bin/java
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java

My $0.02

Making links in /bin, though plausible, would likely be highly discouraged by most sysadmins:

1. Would be frowned upon because it's viewed as custom and can lead to confusion if another admin is required to pick up the box
2. Can lead to a system becoming broken at a future state as a result of this "fragile" customization.

Answering to the questions asked:

Is this correct?

No, it is a poor practice.

Are there some hidden side-effects to my suggestion?

Yes there are several side effects. Your suggestion might work or not depending on the application, and might regress or be broken in the long term.

There are sensible reasons not to create such a symbolic link:

• Administrators do not "own" /bin (see note 1) as this directory belongs to the operating system/distribution developers. On the other hand /usr/local is a traditional location for software built by the local administrator, /opt/<packagename> being one for unbundled software. If you create a file or a link in /bin, there is a risk for it to be overwritten by a package installation, in your case an hypothetical maven package provided by the OS, which might lead to a regression if the one built locally is created from newer source code that the OS version. For example, SVR4 pkgadd , debian dpkg, red-hat rpm and slackware tarballs will all blindingly overwrite your symbolic link.

• Some applications do look to the place where they are called to retrieve configuration files, plugins and similar resources. If you call the application by a symbolic link, its code might fail to follow it and then look for these resource files around /usr/bin where they are not.

• There might be other binaries in /usr/local/maven/bin and not adding this directory to your PATH will make them unavailable. Removed as you already take that into account with your command by linking all potential commands.

• The maven2 page tells to add this directory to your PATH (precisely: Add M2 environment variable to your path, e.g. export PATH=$M2:$PATH.) , by using a different approach, your are breaking that step so are going an unsupported way. Of course, if most users of a system are potential maven users, it would make more sense to set the PATH globally instead than on each and every .profile.

Note 1:

Slackware documentation:

   The /bin directory usually doesn't receive modification
   after installation. If it does, it's usually in the form
   of package upgrades that we provide.

Debian / Filesystem Hierarchy Standard

/bin/
   Essential command executable (binaries) for all users (e.g., cat, ls, cp) 
   (especially files required to boot or rescue the system)
...
/opt/
   Add-on application software packages 
   Pre-compiled, non ".deb" binary distribution (tar'ed..) goes here.
/opt/bin/
   Same as for top-level hierarchy

Solaris documentation:

/usr/bin
   Platform-dependent, user-invoked executables. These  are
   commands  users expect to be run as part of their normal
   $PATH. For executables that are different  on  a  64-bit
   system  than  on a 32-bit system, a wrapper that selects
   the  appropriate  executable   is   placed   here.   See
   isaexec(3C).  An approved installation location for bun-
   dled Solaris software. The analogous location for add-on
   system     software     or     for    applications    is
   /opt/packagename/bin.

Simple test showing Debian's dpkg doesn't preserve an existing link, even while the --force-overwrite option is not used:

# ls -l /usr/bin/banner
lrwxrwxrwx 1 root root 11 Feb 25 21:37 /usr/bin/banner -> /tmp/banner
# dpkg -i sysvbanner_1.0.15_amd64.deb 
Selecting previously unselected package sysvbanner.
(Reading database ... 236250 files and directories currently installed.)
Unpacking sysvbanner (from sysvbanner_1.0.15_amd64.deb) ...
Setting up sysvbanner (1.0.15) ...
Processing triggers for man-db ...
# ls -l /usr/bin/banner
-rwxr-xr-x 1 root root 11352 May  7  2009 /usr/bin/banner

If you want to symlink, it would be better to symlink to /usr/local/bin. On my server, I used to install local software into /opt/NAME and symlink the binaries to /usr/local/bin.