Okay, I have updated the proposal with more info concerning the issues with .NET support. Currently, NMaven handles its own resolver and installation based on information from its net-dependencies.xml file. This is internal to NMaven as you suggest it should be for any plugin. The problem comes up because third-party developers are not able to reuse these internal resolver/installer implementations. Of course, I can come up with a solution that satisfies this reuse that is specific to NMaven; but I think that a general solution outside of the .NET context would be useful for other language support. This may require extension of the pom (as the installation information has to come from somewhere). One possible solution would be to add a requirement-installation tag as part of a general artifact requirements section (related to the expanding classifier support proposal) of the pom.
More details are in the proposal. Regards, Shane On 8/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > On 12 Aug 07, at 12:25 AM 12 Aug 07, Shane Isbell wrote: > > > I just submitted a new proposal here: > > > > http://docs.codehaus.org/display/MAVENUSER/Extending+Pom+to+Include > > +Artifact+Installation+Instructions > > > > You may want to explain some of your .net specifics as with C++ we > operate decently with what he have by creating plugins. John's C > toolchain for building C and producing RPMs works fine, and so does > Mark's NAR plugin. Both are extensions to Maven for native code and > both are not perfect but work well. In short I don't think that the > POM should describe this, but reference the toolchain that supports a > particular langauge. Just happens by default for Maven it is the Java > lifecycle. > > I think if you expand the .net requirements we can ask Mark and John > to expand on what they did so we get something that meshes up. > Dealing with multiple languages is important. John and Kenney have > also done work to insert custom components, like resolvers, into the > mix. For example the RPM resolver we use in the c toolchain. I call > it a toolchain for lack of a better word as this might not mesh up > with what Milos is proposing but the knowledge should be in the > toolchain for dealing with a specific language or environment. I > don't think you want to end up describing this in the POM as then you > end up having to share this information via inheritance or a profile > when really for .net you always want to use a particular set of > tools, rules, default operations or what have you. > > > Thanks, > > Shane > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
