RE: inheriting from plugins
Please expound on what you mean by using libraries in a dependency fashion. I want to do this as well, and I'm not sure how. Do you mean I should create an instance of the other Mojo within my Mojo class? If so, how does it get configured properly? ..David.. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, November 27, 2005 10:46 AM To: Maven Users List Subject: Re: inheriting from plugins No, I mean using libraries in a dependency fashion, rather than inheritance. plexus-utils contains the DirectoryScanner class from Ant if you'd like a lighter dependency for that. Our priorities for documentation are: 1) pure user documentation on Maven feature usage 2) plugin developer documentation and related javadoc 3) maven developer internals documentation and related javadoc On 11/27/05, Anuerin Diaz [EMAIL PROTECTED] wrote: thanks brett. by composition you mean coding from scratch? currently i am doing that but i was hoping to re-use some of the code in the plugins. as it is i am going to use ant classes for directory scanning and processing because most of the classes used in the code do not have javadocs (and they seem to have low priority) to guide new users. that is one issue that i have beef with but we have other alternatives so we might as well leverage on that. - 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: inheriting from plugins
No, I mean using libraries in a dependency fashion, rather than inheritance. plexus-utils contains the DirectoryScanner class from Ant if you'd like a lighter dependency for that. Our priorities for documentation are: 1) pure user documentation on Maven feature usage 2) plugin developer documentation and related javadoc 3) maven developer internals documentation and related javadoc On 11/27/05, Anuerin Diaz [EMAIL PROTECTED] wrote: thanks brett. by composition you mean coding from scratch? currently i am doing that but i was hoping to re-use some of the code in the plugins. as it is i am going to use ant classes for directory scanning and processing because most of the classes used in the code do not have javadocs (and they seem to have low priority) to guide new users. that is one issue that i have beef with but we have other alternatives so we might as well leverage on that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inheriting from plugins
On 11/27/05, Brett Porter [EMAIL PROTECTED] wrote: No, I mean using libraries in a dependency fashion, rather than inheritance. sorry but im lost on how to implement this 'dependency fashion'. it might have just been terminologies or it can be a whole ballpark. :) basically my understanding of that is if i want to depend on a library then i should have a list of the API that i could use which is perfectly alright if i have those API handy. i am opting for inheritance since most of the code in the assembly plugin is reusable and i dont want to code them again in our plugin. thinking back this also might not be prudent since i am not sure how parent methods will perform with child variables. i guess i have to take a quick crash review on oop. plexus-utils contains the DirectoryScanner class from Ant if you'd like a lighter dependency for that. great. my beef is looking at the code of maven plugins (via the web frontend since i cant use svn at the office), most use classes from plexus utils. as a normal user, i would say that i can find more information on the plexus website at codehaus but then again i am facing the same blank wall when it comes to documentation availability. i can even find the correct site for plexus utils. i admit this is no longer a maven problem but since maven uses plexus intensively then logic dictates that some form of documentation is available to guide users in understanding how things work and what can be done to extend and add to the existing functionalities- Our priorities for documentation are: 1) pure user documentation on Maven feature usage 2) plugin developer documentation and related javadoc 3) maven developer internals documentation and related javadoc which is well and good. most of the javadoc problem is not even directly maven-related. one thing that i find interesting is that i am seeing a lot of maven-built maven-used utilities and the projects that publish javadocs are rare even if there is a maven plugin for it. i am amazed at the work being accomplished by the maven team (and other people using these libraries) because they either have the means to get all the source codes and generate the javadocs themselves, or else they are really gifted coders. the rest of us who do not fit in those categories are left twiddling our thumbs and scratcing our heads. sorry if my mail is sounding like a rant. i am a convert, but it gets pretty frustrating telling my superiors that most projects built by maven do not even publish maven-generated reports. my coding skills are only average but it does not inspire confidence when they see me scrambling to get documentation so i can finish my takss and all the while i am telling them that their migration to maven is a sound move. ciao! On 11/27/05, Anuerin Diaz [EMAIL PROTECTED] wrote: thanks brett. by composition you mean coding from scratch? currently i am doing that but i was hoping to re-use some of the code in the plugins. as it is i am going to use ant classes for directory scanning and processing because most of the classes used in the code do not have javadocs (and they seem to have low priority) to guide new users. that is one issue that i have beef with but we have other alternatives so we might as well leverage on that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Programming, an artform that fights back Anuerin G. Diaz Registered Linux User #246176 Friendly Linux Board @ http://mandrivausers.org/index.php http://capsule.ramfree17.org , when you absolutely have nothing else better to do - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inheriting from plugins
Anuerin Diaz wrote: On 11/27/05, Brett Porter [EMAIL PROTECTED] wrote: No, I mean using libraries in a dependency fashion, rather than inheritance. sorry but im lost on how to implement this 'dependency fashion'. it might have just been terminologies or it can be a whole ballpark. :) basically my understanding of that is if i want to depend on a library then i should have a list of the API that i could use which is perfectly alright if i have those API handy. i am opting for inheritance since most of the code in the assembly plugin is reusable and i dont want to code them again in our plugin. thinking back this also might not be prudent since i am not sure how parent methods will perform with child variables. i guess i have to take a quick crash review on oop. Perhaps they mean you can wrap the base class in your class and build on top of it? (I'm just guessing) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inheriting from plugins
On 11/28/05, Srepfler Srgjan [EMAIL PROTECTED] wrote: Anuerin Diaz wrote: On 11/27/05, Brett Porter [EMAIL PROTECTED] wrote: No, I mean using libraries in a dependency fashion, rather than inheritance. sorry but im lost on how to implement this 'dependency fashion'. it might have just been terminologies or it can be a whole ballpark. :) basically my understanding of that is if i want to depend on a library then i should have a list of the API that i could use which is perfectly alright if i have those API handy. i am opting for inheritance since most of the code in the assembly plugin is reusable and i dont want to code them again in our plugin. thinking back this also might not be prudent since i am not sure how parent methods will perform with child variables. i guess i have to take a quick crash review on oop. Perhaps they mean you can wrap the base class in your class and build on top of it? (I'm just guessing) wrapping by inheritance was my initial goal, so i can only override the methods that we need to. dependency building might be something like instantiating an object and using it but i am not sure if instantiating plugins will have them configured as described in the pom. ciao! -- Programming, an artform that fights back Anuerin G. Diaz Registered Linux User #246176 Friendly Linux Board @ http://mandrivausers.org/index.php http://capsule.ramfree17.org , when you absolutely have nothing else better to do - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inheriting from plugins
The field metadata when creating plugins is read from source files, so is not available when the original source is not. The metadata is available in the plugin in {{META-INF/maven/plugin.xml}}, but at this point there is no way to incorporate it when building a new plugin. We currently recommend building your plugins using composition instead of inheritence. Cheers, Brett On 11/25/05, Anuerin Diaz [EMAIL PROTECTED] wrote: hi, i am planning to develop a plugin similar to the assembly:directory goal so i am looking at extending the AbstractAssemblyMojo to re-use some of its properties and code. the configuration is similar to that of the assemblies but we would like to rewrite and add some more project features. my problem is that the properties in the parent class is not being initialized properly in our custom classes. as an example the descriptor variable is always set to null, but the configuration properties that we added are initialized properly. anybody have a clue what we missed? i am looking at the DirectoryMojo source code and it is implemented the same way. thanks. ciao! -- Programming, an artform that fights back Anuerin G. Diaz Registered Linux User #246176 Friendly Linux Board @ http://mandrivausers.org/index.php http://capsule.ramfree17.org , when you absolutely have nothing else better to do - 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: inheriting from plugins
Why archetypes is needed at all? What can I do with ones :-\ Creating an archetype is a pretty straight forward process. An archetype is a very simple plugin, that contains the project prototype you wish to create. An archetype is made up of:. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inheriting from plugins (Answer to archetype question)
Hi, Archetypes are templates for projects that are often used. Standard Maven 2 directory structure; common files and folders; and some resources will be created for you. An example is the maven-archetype-webapp which can be used to create a skeleton project for a web application. It will create your starting pom, the WEB-INF folder, a deployment descriptor and some sample JSPs which you could edit later. Here's a full description of archetypes for your reference: http://maven.apache.org/guides/introduction/introduction-to-archetypes.html By the way, it would be nice if you changed the subject of the email you replied to because your question was not related. :-) Hope this helps. Regards, John Oles wrote: Why archetypes is needed at all? What can I do with ones :-\ Creating an archetype is a pretty straight forward process. An archetype is a very simple plugin, that contains the project prototype you wish to create. An archetype is made up of:. - 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]