subcomp->project

As designed.

OK, I change it to enhancement and elaborate a bit.

One of the many advantages with libraries is that a version controlled
project definition can specify that certain libraries are needed but
the exact physical location of the jars can differ between developers.
The team can probably agree on the library names but often not on
where they are located on disk. This and all pure convenience reasons
for libraries are I believe equaly valid for freeform projects as for
any other project type.

One problem with the current classpath definition is that you don't
have access to it in your build script. You have to make sure that the
two are synchronized. It would probably not be very difficult to
ensure that a property file is updated (much like what j2seproject
does) before the script is run that contains the complete classpath.
If libraries could be used this technique would be even more useful,
since the sourcepath could then also be made available to the script,
esp useful for the nbjpdastart task.

A good example of why we should be able to do this is in the form for
the freeform web project. Netbeans comes with the all the needed
libraries, but because we cant add the actual Library that NB uses, we
need to hunt down each of the needed j2ee jars that we need
(servlet-api.jar, etc..) and add them AND we loose javadoc support.

By simply adding a library it takes care of these problems and others
as Gunnar has pointed out.

so its gets a +1 in my book 

Wrong component, probably no one saw this issue after it was reopened...

You can already add the same JAR as you use in the lib mgr to
project.xml's classpath and you will get sources/Javadoc. (See issue
#47498 for more.)

If you really wanted to, you could also load
${netbeans.user}/build.properties to share classpath definitions with
the IDE's lib mgr, though generally I don't recommend this - better to
keep your libs under version control in a shared location. See also
issue #44035.

Re. synching the build script w/ project.xml, which as far as I can
tell is the only other thing mentioned here: see instead issue #46485.

I must disagree here. The arguments I stated in my 2004-08-05 commment
still stand IMO. Libraries often reference several jars and in several
freeform project I want to be able to say that I use e g "Sun App
Server Client" instead of specifying all six or seven jars. Also, I
may keep these files in a different place than other team members but
since we can agree on the library name we could use the same project.xml.

Forgot to reopen

As I said, you can already do this, if you load
${netbeans.user}/build.properties into your project.xml and your build
script (if you wish to use the IDE's library manager GUI) or any other
properties file (if you do not). Issue #47498 already proposes some
kind of library management GUI that would make sense in the context of
freeform projects, which in many cases would not want to depend on the
current library manager's build.properties. Please use #47498 for this
issue.

*** This issue has been marked as a duplicate of 47498 ***

This is originally a NetCAT enhancement.

verified/closed

In the 8.1 beta I opened a seam project as a netbeans free form project and can add sources jar but nor libraries jar.
I'd like something like an space in the project properties window that allow us to select projects and library jars.
Then when running ant task configured as run the libraries & the dist folder of projects can be addeded temporarily to class path. When the stop button is hit, then reset classpath to the original config.

Not having the ability to add an external .jar to a Java Free-Form Project means that contained code is always erroneous in the editor, and only compilable/runnable using Ant.