> Yes.
>
>> If this was configurable and you could assigned a user library defined
>> by me, that would be ideal.
>
> Well...kinda, but the problem with user libraries is that they are workspace
dependendent and not
> easily sharable.
Hmmm, I'm not sure I agree here. User libraries are, at least in my
case, based on absolute libraries.
Yes, so they are definitly not sharable.
OK, they're stored in the workspace
but you they're not based on workspace data but absolute paths. You can
export/import them easily. That's precisely what I did to move from a
Eclipse workspace to a JBDS workspace.
absolute paths is not what I call sharable between team members. of course it is possible
to "share"
it on the same machine
/max
>> Now, if you're able to export a runtime, which will
indirectly export
>> the user library I linked to it, then you have user libraries and
>> runtimes exported into a single file. Saving quite a few clicks when
>> moving from workspace to another.
>
> well we could save a set of libraries together with the runtime, that optionally
> could point to user libraries.
>
>> Out of runtime, you can create many servers, so if when you exported
>> runtimes, you exported any servers for it, triple bonus.
>
> servers are machine specific (e.g. paths to server), but yes this could be done more
generically.
>
>> Bottom line, the feature I propose is:
>> Exporting/Importing runtimes that indirectly e/i associated user
>> libraries (if this feature was approved) and associated servers.
>
> I actually think the servers today are saveable in the workspace.
>
> Rob, isn't that possible today in some sense?
What do you mean exactly? If you wanna rebuild your workspace, you need
to enter the runtimes and servers again, or can you copy them somehow
from the old workspace? Is that what you're trying to say?
>
> -max