2008/5/9 David Leangen <[EMAIL PROTECTED]>: > > > 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. >
hmm, sounds like a bug in Eclipse - if you're changing a class and have other projects in your workspace that reference that class then why won't it refactor them? unless it's just going by the "requiredPlugins" dynamic container (PDE projects don't typically contain direct project references) > > 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. > but there are several other users of this plugin that do, and have raised issues explicitly requesting this feature (they're also Eclipse developers) > 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? > by "use Eclipse projects" do you mean add explicit project references, or just remove the external maven repo reference so it defaults to use the "requiredPlugins" dynamic classpath container? > 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. > so is it just a matter of moving the "requiredPlugins" entry above the rest of the classpath, so that PDE will use this first? - ie. perhaps the explicit entries are confusing the PDE resolver... > 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... ) > possibly because it's doing an incremental build - but you may run into other problems later on because of the missing entries. > 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 > or... raise a bug with Eclipse/PDE could you try using the original generated .classpath file, but move the "requiredPlugins" entry up so it's before the rest of the dependencies? then try refactoring - this might work because then PDE will check its dynamic container before the explicit maven references if this doesn't work then we could always add a switch (-DpdeSucks?) > 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 > -- Cheers, Stuart
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
