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).
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. 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]
