[jbosstools-dev] Export/Import Runtime/Servers?

Rob Stryker rob.stryker at redhat.com
Tue Apr 29 16:55:48 EDT 2008


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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>   




More information about the jbosstools-dev mailing list