Re: [classlib] clash in eclipse metadata
On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I have a problem with how we do eclipse meta-data in classlib, and I'm guessing there's some cool trick everyone else knows about. We have a user guide on development with eclipse in the website. [1] Is it helpful? Right now, tree has lots of mods to modules/*/.settings/* and modules/*/.classpath, resulting in pain and suffering when I try to do a commit that spans multiple modules. How are people solving this? I check out the whole trunk, configure "Target Platform", and import the interested module and support module into Eclipse. Meta data needn't to be modified in most cases. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_eclipse.html geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Andrew Zhang
Re: [classlib] clash in eclipse metadata
I think it would be nice if we had examples in bundle form of different usage models. We could drop those into SVN too,a nd people could just take them and overlay... geir Nathan Beyer wrote: Realistically, we could probably just eliminate all of the Eclipse IDE files, as they don't really work out of the box anyway, so I always end up tweaking them anyway or tweaking my setup. For those who do use Eclipse IDE, a simple script could be create to generate the appropriate artifacts or it can be done manually. Then we can just add these files to the ignore list. BTW - The way I use the Eclipse IDE is to setup a custom "Target Platform" (a set of folders that contains OSGi bundles/plugins) that points to the deploy folder build and the support JAR. This assumes you've run a full build or have a snapshot build. Then, in each project's .classpath, the "Required Plugins" container and the JUNIT variable are set. The "Required Plugins" just takes the current project's Import-Packages attribute from the manifest and looks at all of the plugins in the Target Platform and resolves the appropriate JARs, so the code can compile. The JUNIT variable is for resolving the JUnit classes, since this isn't explicitly in the OSGi bundles. -Nathan On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I have a problem with how we do eclipse meta-data in classlib, and I'm guessing there's some cool trick everyone else knows about. Right now, tree has lots of mods to modules/*/.settings/* and modules/*/.classpath, resulting in pain and suffering when I try to do a commit that spans multiple modules. How are people solving this? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] clash in eclipse metadata
Realistically, we could probably just eliminate all of the Eclipse IDE files, as they don't really work out of the box anyway, so I always end up tweaking them anyway or tweaking my setup. For those who do use Eclipse IDE, a simple script could be create to generate the appropriate artifacts or it can be done manually. Then we can just add these files to the ignore list. BTW - The way I use the Eclipse IDE is to setup a custom "Target Platform" (a set of folders that contains OSGi bundles/plugins) that points to the deploy folder build and the support JAR. This assumes you've run a full build or have a snapshot build. Then, in each project's .classpath, the "Required Plugins" container and the JUNIT variable are set. The "Required Plugins" just takes the current project's Import-Packages attribute from the manifest and looks at all of the plugins in the Target Platform and resolves the appropriate JARs, so the code can compile. The JUNIT variable is for resolving the JUnit classes, since this isn't explicitly in the OSGi bundles. -Nathan On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I have a problem with how we do eclipse meta-data in classlib, and I'm guessing there's some cool trick everyone else knows about. Right now, tree has lots of mods to modules/*/.settings/* and modules/*/.classpath, resulting in pain and suffering when I try to do a commit that spans multiple modules. How are people solving this? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] clash in eclipse metadata
I have a problem with how we do eclipse meta-data in classlib, and I'm guessing there's some cool trick everyone else knows about. Right now, tree has lots of mods to modules/*/.settings/* and modules/*/.classpath, resulting in pain and suffering when I try to do a commit that spans multiple modules. How are people solving this? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]