Fantastic !!! Works as expected.
Can I rely on that you will include this patch in your next release (maybe with a fix for re-resolving opened projects to automatically link them) ? Alex > -----Original Message----- > From: "Xavier Hanin" <[EMAIL PROTECTED]>@DSI > Sent: Montag, 29. Jänner 2007 15:18 > To: [email protected] > Subject: Re: Working parallel on different modules without > building and publishing jar files > > > On 1/26/07, SELG Alexander <[EMAIL PROTECTED]> wrote: > > I can't get the patch you provided to me, I just found a > URL=mailto - > > maybe a problem with my mail-client or our firewall ... > This is weird... > > > > So I played around with Ivy and tried to extend > IvyClasspathContainer > > for my needs. I thought it should be possible to substitute in the > > method updateClasspathEntries the LibraryEntries with > IProjectEntries > > for those IProjects found in the Workspace and marked as open > > (ResourcesPlugin.getWorkspace().getRoot().getProjects();). Than it > > would be possible to switch all projects found in the workspace to > > source mode if they are open and referenced by an ivy.xml > (may be with > > an additional switch for this behaviour). My problem was, that I > > wasn't able to get an ivy module name from the > classpathItems or from > > any other member of IvyClasspathContainer to compare it with the > > eclipse project name. > > > > So my questions are: > > - Is it ok to change the classpath in that method? > > - If no, where else should I to that? > > - Where do I get the ivy module name to compare it with the eclipse > > project name? > > - Should I write a Listener to register the module names? > > - Possibly your patch would do the same? - But I don't want > to switch > > to project dependencies for every depending project (if the modules > > "extension0" to "extension9" depend on module "core" I > don't want to > > say 10 times "core in source"). > I think the patch would really be a good starting point, > because it already works, the only problem is that it > requires a specific resolver. Since you didn't get the patch > with my last e-mail, and since IvyDE issues are still not > imported in Apache JIRA, what I suggest is that you get the > IvyDE JIRA export here: > http://www.jaya.free.fr/downloads/ivyde/ivyde-jira-export.zip > > Then you can check the issues in the xml (not > straightforward, but not too difficult), the issue is > IVYDE43. You will also see the patch in the attachments > directory of the zip. With that you should (I hope!) have a > better idea of how to tackle the problem. > > Xavier > > > > > Another important point is that I don't want to handle the > > dependencies with the .classpath (as suggested by Gilles with his > > ivymakeclipse) because then you always have to take care about the > > .classpath cvs handling (not to checkin the file (cvsignore) or > > overwrite it with the next synchronize, ...). > > > > > > I really would like to extend ivy with that feature but I'm > not sure > > if that's the right way. > > > > Alex > > > > > > > On 1/22/07, SELG Alexander <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > Hi, > > > > > > > > I'm trying to setup our projects with ivy 1.4.1 in eclipse 3.2 > > > > using the IvyDE 1.2 . I declared the module dependencies in the > > > > ivy.xmls and use our cvs-repository to retrieve the artifacts. > > > > So far so good. > > > > > > > > Say we have a module "core" and a module "extension" > which depends > > > > on "core" ("extension" -> "core"). > > > > I find a bug in a class of module "extension" and > during debugging I > > want > > > > to > > > > step into class C of the "core" module. I find a bug in > C and want > > > > to > > fix > > > > this bug and retest it, fix it again and retest it > again and so on > > > > ... > > > > > > > > I want to do this work in a very quick way (that means without > > > > building any > > > > libraries) because there are many "extension"-modules and many > > > > projects with projects-modules depending on the "core"- and > > > > "extension"-modules (about 30 > > > > modules of our own and about 60 thirdparty modules) - > and I have to do > > > > this > > > > very often. > > > > > > > > We have done this so far in eclipse by changing the "Java Build > > > > Path" in the properties of the eclipse "core"-module > (remove the > > > > core.jar in the Libraries-Tab and add the source folder of the > > > > "core" module in the > > > > Source-Tab) - quite simple and you have the source available in > > > > every module referencing classes of module "core". > > > > Pressing <F3> or stepping into a method of class C > opens C.java . > > > > > > > > Now I want to declare the dependencies between the modules with > > > > ivy and I'm searching for an easy way to switch to a > "source-mode" > > > > of the modules I depend on. > > > > > > > > I know it is possible to attach sources and it's even > possible to > > > > do > > this > > > > automatically with ivy. > > > > But I don't want to attach the sources of the module > "core" to the > > > > core.jar because > > > > - I would have to build the "core" library to see the > changes a made > > (too > > > > much time for turn around) > > > > - during debugging I would open a core/C.class file and > lose the > > > > Hot > > Code > > > > Replace feature of the eclipse debugger (not acceptable for our > > > > developers). > > > > > > > > I know it would be possible to remove the "extension" -> "core" > > dependency > > > in the ivy.xml and declare it again with eclipse (.classpath, > > > .project > > > > files) - a way for two modules but no way for 90 > modules. I want > > > > that there is one particular point for the developer to > say, this > > > > module now in source please. > > > > > > > > Are there any possibilities to accomplish this with ivy; or are > > > > there > > any > > > > other possibilities to handle this? > > > > > > > > > For the moment this is not possible, but there is a patch > > > contributed by a user which allows to automatically use project > > > dependencies instead of library dependency with some > settings. The > > > problem is that this is only a patch for the moment, and > since IvyDE > > > is still not migrated to ASF, IvyDE JIRA is currently not > > > accessible... So the only thing I can do for the moment is attach > > > the patch here with a small example of how it looks like > > if > > > you manage to get it working (not straightforward with > only a patch, > > sorry). > > > > > > Xavier > > > > > > Thanks, > > > > Alex > > > > > > > > > > > > >
