RE: Working parallel on different modules without building and pu blishing jar files

[SELG Alexander <al...@wave-solutions.com>]

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

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").

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 <al...@wave-solutions.com> 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
> >
> >

Re: Working parallel on different modules without building and pu blishing jar files

[Xavier Hanin <xa...@gmail.com>]

On 1/26/07, SELG Alexander <al...@wave-solutions.com> 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 <al...@wave-solutions.com> 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
> > >
> > >
>
>