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]
