RE: Question about native library path
Maven has promise for being a worthwhile tool and we all share the expectation that it will get better. I get from this thread that Wayne is frustrated with the available resources to target more feature development. Dave appears to be equially frustrated. Perhaps the Maven team would consider adding a vote your feature with donation component to the site. That way companies and individuals may participate in a positive way toward Maven even though they may not be able to manage the time at the contributor level? Best Regards, Sean -Original Message- From: Dave Feltenberger [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 06, 2007 7:28 AM To: Maven Users List Subject: Re: Question about native library path The reason the *user's* list exists is to discuss using Maven, not to lecture people about adding features that may or may not exist. If a person wants to find out if features exist, or has a question about usage, they should not be lectured about adding the features themselves. A simple, "I don't think this feature exists" suffices. I am -- and I'm sure the vast majority of others are -- quite aware that this is an open source project and I can contribute, but during the normal course of a work day my employer pays me to make software for them, not drain resources to modify open source projects that are designed to support our infrastructure. When I ask questions on OS project lists, I try to contribute by answering a question or two that I'm able to answer, as adding features to the projects is simply not something I'm able to rationalize to my employers. On Nov 2, 2007 4:22 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > Any time, Dave! Some people simply need a little nudge in the right > direction. > > It seems like a lot of people on this list either don't realize or > forget that Maven is Open Source Software. You're a developer, right?? > If you want a feature and it isn't obviously available, go write some > code!! Maven plugins are (generally) trivial to modify or even create > from scratch to deal with a particular issue. > > The only way that Maven gets any better is by the contributions of > people (like yourself) -- some in the core dev team and others who are > simply motivated users who want to get their work done. > > In the (short) amount of time we've spent discussing this issue, you > could have already written and tested your addition to the Eclipse > plugin, and you'd be on dealing with the next issue in your project. > > > Wayne > > On 11/2/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote: > > Thank you for pointing out that if a feature doesn't exist I'm free > > to add the necessary features myself, Wayne. > > > > On Nov 2, 2007 2:16 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > > > Its possible this functionality is not currently available. Take a > > > look at the source code, add in your needed features, and > > > contribute it back for future inclusion in the next release of the > > > Eclipse plugin. > > > > > > Wayne > > > > > > > > > On 11/2/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote: > > > > All, > > > > > > > > Does anybody know if it's possible (and if so, how) to add the > > > > native library location to a classpath entry? Specifically the > > > > Eclipse .project classpath attribute > > > > "org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY". > > > > I'd like to have some dlls in my library path without having to > > > > add additional JVM arguments everytime I create a launcher (and > > > > without having to specify it JVM-wide or something). The > > > > closest thing I could find in the project documentation was > > > > "classpathContainers", but that's not exactly it. Here's an > > > > example of what I'd want the end result to be: > > > > > > > > > > > path="M2_REPO/org/ecliplse/swt/swt/3.323/swt.jar"> > > > > > > > > > > > name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" > > > > value="MySwtProject/target/swt-native-libs"/> > > > > > > > > > > > > > > > > And I can't figure out how to add the additional attributes > > > > without doing it manually in Eclipse everytime. > > > > > > > > Thanks. > > > > > > > > Dave > > > > > > > >
Re: Question about native library path
The reason the *user's* list exists is to discuss using Maven, not to lecture people about adding features that may or may not exist. If a person wants to find out if features exist, or has a question about usage, they should not be lectured about adding the features themselves. A simple, "I don't think this feature exists" suffices. I am -- and I'm sure the vast majority of others are -- quite aware that this is an open source project and I can contribute, but during the normal course of a work day my employer pays me to make software for them, not drain resources to modify open source projects that are designed to support our infrastructure. When I ask questions on OS project lists, I try to contribute by answering a question or two that I'm able to answer, as adding features to the projects is simply not something I'm able to rationalize to my employers. On Nov 2, 2007 4:22 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > Any time, Dave! Some people simply need a little nudge in the right direction. > > It seems like a lot of people on this list either don't realize or > forget that Maven is Open Source Software. You're a developer, right?? > If you want a feature and it isn't obviously available, go write some > code!! Maven plugins are (generally) trivial to modify or even create > from scratch to deal with a particular issue. > > The only way that Maven gets any better is by the contributions of > people (like yourself) -- some in the core dev team and others who are > simply motivated users who want to get their work done. > > In the (short) amount of time we've spent discussing this issue, you > could have already written and tested your addition to the Eclipse > plugin, and you'd be on dealing with the next issue in your project. > > > Wayne > > On 11/2/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote: > > Thank you for pointing out that if a feature doesn't exist I'm free to > > add the necessary features myself, Wayne. > > > > On Nov 2, 2007 2:16 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > > > Its possible this functionality is not currently available. Take a > > > look at the source code, add in your needed features, and contribute > > > it back for future inclusion in the next release of the Eclipse > > > plugin. > > > > > > Wayne > > > > > > > > > On 11/2/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote: > > > > All, > > > > > > > > Does anybody know if it's possible (and if so, how) to add the native > > > > library location to a classpath entry? Specifically the Eclipse > > > > .project classpath attribute > > > > "org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY". I'd > > > > like to have some dlls in my library path without having to add > > > > additional JVM arguments everytime I create a launcher (and without > > > > having to specify it JVM-wide or something). The closest thing I > > > > could find in the project documentation was "classpathContainers", but > > > > that's not exactly it. Here's an example of what I'd want the end > > > > result to be: > > > > > > > > > > > path="M2_REPO/org/ecliplse/swt/swt/3.323/swt.jar"> > > > > > > > > > > > name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" > > > > value="MySwtProject/target/swt-native-libs"/> > > > > > > > > > > > > > > > > And I can't figure out how to add the additional attributes without > > > > doing it manually in Eclipse everytime. > > > > > > > > Thanks. > > > > > > > > Dave > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about native library path
Any time, Dave! Some people simply need a little nudge in the right direction. It seems like a lot of people on this list either don't realize or forget that Maven is Open Source Software. You're a developer, right?? If you want a feature and it isn't obviously available, go write some code!! Maven plugins are (generally) trivial to modify or even create from scratch to deal with a particular issue. The only way that Maven gets any better is by the contributions of people (like yourself) -- some in the core dev team and others who are simply motivated users who want to get their work done. In the (short) amount of time we've spent discussing this issue, you could have already written and tested your addition to the Eclipse plugin, and you'd be on dealing with the next issue in your project. Wayne On 11/2/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote: > Thank you for pointing out that if a feature doesn't exist I'm free to > add the necessary features myself, Wayne. > > On Nov 2, 2007 2:16 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > > Its possible this functionality is not currently available. Take a > > look at the source code, add in your needed features, and contribute > > it back for future inclusion in the next release of the Eclipse > > plugin. > > > > Wayne > > > > > > On 11/2/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote: > > > All, > > > > > > Does anybody know if it's possible (and if so, how) to add the native > > > library location to a classpath entry? Specifically the Eclipse > > > .project classpath attribute > > > "org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY". I'd > > > like to have some dlls in my library path without having to add > > > additional JVM arguments everytime I create a launcher (and without > > > having to specify it JVM-wide or something). The closest thing I > > > could find in the project documentation was "classpathContainers", but > > > that's not exactly it. Here's an example of what I'd want the end > > > result to be: > > > > > > > > path="M2_REPO/org/ecliplse/swt/swt/3.323/swt.jar"> > > > > > > > > name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" > > > value="MySwtProject/target/swt-native-libs"/> > > > > > > > > > > > > And I can't figure out how to add the additional attributes without > > > doing it manually in Eclipse everytime. > > > > > > Thanks. > > > > > > Dave > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about native library path
Thank you for pointing out that if a feature doesn't exist I'm free to add the necessary features myself, Wayne. On Nov 2, 2007 2:16 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > Its possible this functionality is not currently available. Take a > look at the source code, add in your needed features, and contribute > it back for future inclusion in the next release of the Eclipse > plugin. > > Wayne > > > On 11/2/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote: > > All, > > > > Does anybody know if it's possible (and if so, how) to add the native > > library location to a classpath entry? Specifically the Eclipse > > .project classpath attribute > > "org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY". I'd > > like to have some dlls in my library path without having to add > > additional JVM arguments everytime I create a launcher (and without > > having to specify it JVM-wide or something). The closest thing I > > could find in the project documentation was "classpathContainers", but > > that's not exactly it. Here's an example of what I'd want the end > > result to be: > > > > > path="M2_REPO/org/ecliplse/swt/swt/3.323/swt.jar"> > > > > > name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" > > value="MySwtProject/target/swt-native-libs"/> > > > > > > > > And I can't figure out how to add the additional attributes without > > doing it manually in Eclipse everytime. > > > > Thanks. > > > > Dave > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about native library path
Its possible this functionality is not currently available. Take a look at the source code, add in your needed features, and contribute it back for future inclusion in the next release of the Eclipse plugin. Wayne On 11/2/07, Dave Feltenberger <[EMAIL PROTECTED]> wrote: > All, > > Does anybody know if it's possible (and if so, how) to add the native > library location to a classpath entry? Specifically the Eclipse > .project classpath attribute > "org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY". I'd > like to have some dlls in my library path without having to add > additional JVM arguments everytime I create a launcher (and without > having to specify it JVM-wide or something). The closest thing I > could find in the project documentation was "classpathContainers", but > that's not exactly it. Here's an example of what I'd want the end > result to be: > > path="M2_REPO/org/ecliplse/swt/swt/3.323/swt.jar"> > > name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" > value="MySwtProject/target/swt-native-libs"/> > > > > And I can't figure out how to add the additional attributes without > doing it manually in Eclipse everytime. > > Thanks. > > Dave > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
