> this is just the location of the dependency in the Maven repository
>
> This is fine for external stuff, but when my stuff is
> internal, this
> destroys Eclipse's ability to refector, which is like, uhhh,
> the main
> advantage of using an IDE to begin with. ;-)
>
> you mean you don't want internal projects added using their location
> in the Maven repository? hmm - this is actually tricky because of the
> wacky PDE rules for locating dependencies in the target platform
Well, I can only assume that this is the cause. Eclipse will refactor
anything that is using the changed source, but from Eclipse's
perspective, it's using the classes from the maven repo, not the ones
that just changed, so it won't refactor.
> if we don't add the dependencies this way then Eclipse/PDE will not
> find bundle dependencies used for unit tests (because they aren't in
> the actual manifest, so aren't seen by PDE)
Normally I don't mind this. I rarely run tests directly in Eclipse
anyway.
Would it be possible to provide the option to use external bundles from
the maven repo (as is current -- can keep as the default) or to use
Eclipse projects?
> we could add project references - but then this could also get tricky
> depending on what set of projects you have loaded into Eclipse...
Don't think we need them. IIUC, if other projects are exporting the
packages, then PDE will pick up on this and all will be well.
Here is an example of a project's classpath file as generated by the
plugin:
<classpath>
<classpathentry kind="src" path="src/main/java"/>
<classpathentry excluding=".svn|**/.svn|**/.svn/*|**/*.java"
kind="src" path="src/main/resources"/>
<classpathentry kind="output" path="target/classes"/>
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.St
andardVMType/J2SE-1.5"/>
<classpathentry kind="var"
path="M2_REPO/javax/activation/activation/1.1/activation-1.1.jar"/>
... and lots of other such entries, including my internal projects ...
<classpathentry exported="true" kind="lib" path="target/pax-eclipse"/>
<classpathentry exported="true" kind="lib"
path="target/pax-eclipse/ops4j-base-0.4.0.jar"/>
</classpath>
And here is that same file again after invoking the PDE->Update
classpath:
<classpath>
<classpathentry kind="src" path="src/main/java"/>
<classpathentry excluding=".svn|**/.svn|**/.svn/*|**/*.java"
kind="src" path="src/main/resources"/>
<classpathentry exported="true" kind="lib"
path="target/pax-eclipse" sourcepath="target/pax-eclipse"/>
<classpathentry exported="true" kind="lib"
path="target/pax-eclipse/ops4j-base-0.4.0.jar"/>
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launc
her.StandardVMType/J2SE-1.5"/>
<classpathentry kind="con"
path="org.eclipse.pde.core.requiredPlugins"/>
<classpathentry kind="output" path="target/classes"/>
</classpath>
Now, I'm now really familiar with how all this stuff works, but in this
case I am pretty sure that my internal projects really are being
references properly, so again I am assuming that PDE is able to resolve
them.
(Don't know why the project still builds ok, though, when it seems like
external deps are missing... )
> this is not true - you can refactor as much as you like, just remember
> to regenerate the Eclipse project files from Maven. In fact you
> should
> probably be refactoring things like the artifact details in the
> pom.xml
> first rather than just in Eclipse - otherwise other developers won't
> get
> the changes (as typically generated eclipse files aren't committed)
Not sure what you mean.
Here is an example of what I'm talking about:
- Refactor package com.company.blahblah to
com.company.blabla
- Check dependend project that imports com.company.blahblah
- Note that it still references com.company.blahblah whereas
it should have been refactored to use
com.company.blabla
- Choose to either:
o complain on list ;-)
or
o spend countless hours refactoring stuff by hand
> Has anybody found a good way to deal with this?
>
> use IDEA ;)
Yeah, yeah... >:-(
Cheers,
Dave
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
