Hi, Given a JBDS workspace, can Runtime/Servers be imported/exported in case you need to rebuild your workspace? Cheers,

> Let's say you have a runtime called "jboss-4.2". By default, such > runtime has a classpath associated which includes all jars in that runtime. 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.

> 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?

-max

>> 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

>> 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

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

(QFT) quoted for truth > Use the same workspace should work ;) > > /max >

No that is not a way. Unfortunately, webtools links the launch configuration with a specific server, and it does so by server *id*, NOT name. This causes breakages because even if you create a new server there is practically zero chance it has the same id as the launch configuration you're importing.

I'm thinking of making an import action from launch configuration files, but from what I've been able to tell so far it'd require much more than just the launch configuration and I'm not even entirely sure it's possible. I'll look into it. I might need to make an export and import in order to do both. - RS Max Rydahl Andersen wrote: > what about the option of storing the launch config in a seperate project ? is that not also a doable way ? > > We actually shuold get these things into the userdocs for the AS doc - hint hint. > > /max > > >> (QFT) quoted for truth >> >>> Use the same workspace should work ;) >>> >>> /max >>> >>> >> > > > >

I've yet to figure that out ;) I'll have to ask Tim. Max Rydahl Andersen wrote: > So what is the purpose of being able to save the launch config outside > of the workspace metadata? > -max > > >> I'm thinking of making an import action from launch configuration files, >> but from what I've been able to tell so far it'd require much more than >> just the launch configuration and I'm not even entirely sure it's possible. >> >> I'll look into it. I might need to make an export and import in order >> to do both. >> >> - RS >> >> Max Rydahl Andersen wrote: >> >>> what about the option of storing the launch config in a seperate project ? is that not also a doable way ? >>> >>> We actually shuold get these things into the userdocs for the AS doc - hint hint. >>> >>> /max >>> >>> >>> >>>> (QFT) quoted for truth >>>> >>>> >>>>> Use the same workspace should work ;) >>>>> >>>>> /max >>>>> >>>>> >>>>> >>> >>> >>> >> > > > >