The scope of the solution is starting to expand; so I want to hit it point-by-point from my perspective. First, I don't implement the ArtifactResolver interface. There are various reasons for this which I have blogged about and sent on the NMaven list. A much more detailed list of reasons is here: http://www.jroller.com/random7/entry/apache_nmaven_repository_structure_and
So the issue of the extensions and how to replace the resolver implementation are not relevant to my situation. I have a resolver and I am still left with the issue of needing meta-data to tell me the place(s) to install the artifacts. The toolchains tell me something about the capabilities of the environment - and what tools are needed to complete the build - but again it tells me nothing about where to install the artifacts. The packaging concept is an interesting idea and has relevance. I could package the dlls that I need (say inside a zip) with additional meta-data containing the instructions of the install; or I could place the an install.txt file as additional meta-data within the dll repository path; or I could let the developer define the net-dependencies.xml file within their jars and pick it up. The packaging concept is an interesting idea, as I was planning on just picking up the net-dependencies.xml file. The problem with these approaches, however, is we don't have a general way of solving the issue of resolving and installing non-java artifacts that are needed by the runtime Maven build environment. Everybody wanting to support a different language has no common Maven components to rely on and will just go off and do their own thing. >From my perspective, I am growing more conscious of the growing divide between Maven and NMaven and am trying to make sure that I do not duplicate something that already exists or vice versa. That is why I want to bring this proposal up for discussion. One of the key questions in this discussion is: do we need a common solution? If I am the only one encountering this problem, and there is no anticipation - from those doing C/C++ or other language support - of this problem occurring in their respective build environments, then everyone going there own way makes sense. I do not want to abstract a problem that does not exist in a general sense. Regards, Shane On 8/12/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote: > > > > Jason van Zyl wrote: > > > > On 12 Aug 07, at 8:15 PM 12 Aug 07, Shane Isbell wrote: > > > >> 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. > > > > There are two. The one in 2.0.x allows you to drop in a JAR that > > contains a replacement resolver which is used. John used this for the > > RPM resolver. In 2.1.x Kenney made this cleaner by allow the > > specification of extension. So I'm sure you could use the same > > mechanism. Kenney needs to write up exactly what he did and how it works > > (nudge, nudge, wink, wink). > > yeah it's currently only documented in the jira issue concerning this. > My work was for the $M2_HOME/extensions/ dir, which can contain > jars and META-INF/plexus/components.xml; these are added to the core > components, overriding them; so you can put drop-in replacements or > additions > there. > > The better way is to declare the <extensions> tag and add your artifact > there. > John is currently working on isolating it's usage on a per-project basis, > but currently > they are globally added - basically handled the same as the > $M2_HOME/extensions. > > >> This may require extension of the pom (as the installation > >> information has to come from somewhere). > > > > For 2.1.x it would be nice if we could extend a packaging to include any > > other components that may be required. So if you're packaging is "rpm" > > the required resolver is used. For a ruby gem, or shared library the > > same. There may be other components that are also required, but off the > > top of my head packaging could probably be the only key we need to pull > > in a required language tool chain. > > Indeed, the packaging (plugin) could provide for this. Although 'jar' > is just a zip; war, ejb etc. all use the same toolchain but different > packaging. > Only the lifecycle determines which toolchain is called, but there's > nothing > provided for artifact resolution. Perhaps adding some value to the > repository > tag could help - normally the local/remote m2 repo's with different > layouts, > but having an RPM repository with a specific handler could be useful too. > Wagon could deal with that, except that the repo layout is applied before > artifacts > are pushed/pulled from wagon. > > Just read the proposal. There is really no need for LD_LIBRARY_PATH with > JNI, > or even -Dlibrary.path or whatever, since you can load libraries from any > file. > OSGi does it - they package .dll/.so inside the bundle; they just have to > be extracted > and accessible to a file. I've successfully implemented something like > this; > classloaders have the findLibrary method which can do whatever they want > with a library > file and just return a String pointing to the library file. > > As for GAC/PAB, no idea what those are.. googling... your proposal turns > up.. ;) > Ok, I know what a GAC is now. It does seem, from the wikipedia page, that > it's not really necessary to have one; in fact, it's usually recommended > that > not everybody has write access to the GAC directory. Is it possible to > just use the artifact from the local repository directly? I guess not, but > if it is, the tools can handle it without changes to the POM. > > -- Kenney > > > > > Simple, and we already employ it and > > effectively the Java tool chain is pulled in by default. You probably > > want to sync up with John and Mark because they have been doing this > > very type of work for close to two years now. The .NET I imagine is not > > that different in sprit and the particular language toolchain would > > encapsulate any of the requirements. The only limitation might be that > > packaging right now assumes variants within the same language. That > > being our default of Java. > > > >> 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. > > > > If this is something that would be language specific, and we could tie > > to packaging (or something else) then a set of descriptors that map to > > that packaging could pull them in. I don't think you want to have to > > state that in every project that might want a different toolchain. With > > a simple key the toolchain should be pulled in using the default > > resolver to just get the tools and then the toolchain could bootstrap. > > > >> > >> More details are in the proposal. > >> > > > > Cool, thanks. > > > >> 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] > >>> > >>> > > > > 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] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
