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

This is a really interesting idea. I'd like to see a JIRA on it but with a low priority since it's not at all on my roadmap now. But it's something I'd like to investigate "Later". Thanks for the idea, Galder. 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 >

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 >

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

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