Most of my classpath stuff for wtp projects relates to the runtime's
name. I did this because if I depended on the runtime id, which is a
cryptic character string related to a timestamp, the runtimes would not
be replicatable in a new environment.
By keying off names, the user is free to create a new runtime of the
same name as the one in the old workspace and the classpath containers
should all still work.
- RS
Max Rydahl Andersen wrote:
Use the same workspace should work ;)
/max
> True but look at it this way. I have been using JBDS for a couple of
> weeks and I have 10 runtime/servers there. I'm gonna be switching to CR1
> next week and how do I bring the runtime/servers with me to CR1? Do I
> have to create them from scratch again? If so, it's a royal pain in the...
>
> Max Rydahl Andersen wrote:
>
>>>> 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
>>>>
>>
>>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev