You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Shane Isbell <sh...@gmail.com> on 2007/08/12 00:25:42 UTC
Extending Pom to Include Artifact Installation Instructions
I just submitted a new proposal here:
http://docs.codehaus.org/display/MAVENUSER/Extending+Pom+to+Include+Artifact+Installation+Instructions
Thanks,
Shane
Re: Extending Pom to Include Artifact Installation Instructions
Posted by Shane Isbell <sh...@gmail.com>.
On 8/12/07, Jason van Zyl <ja...@maven.org> wrote:
>
> On 13 Aug 07, at 12:13 AM 13 Aug 07, Shane Isbell wrote:
>
> >
> >
> > 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.
> >
>
> I don't believe for a second that we can't come up with a super to
> deal with grabbing and laying down some files somewhere which is
> basically what this all amounts to. If we're not using the same
Exactly! It's not a lot more complicated that. We just need to know:
1) where do I install/copy the artifact? 2) which class knows how to
install it? and maybe 3) where do I get that class?
> mechanisms i.e. you're using a different resolver, not using POMs
> locally and doing whatever else differently then it's not really
> Maven. I don't think it's going to be that hard to make something
> that works for Java, C/++, and .net.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending Pom to Include Artifact Installation Instructions
Posted by Jason van Zyl <ja...@maven.org>.
On 13 Aug 07, at 12:13 AM 13 Aug 07, Shane Isbell wrote:
>
>
> 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.
>
I don't believe for a second that we can't come up with a super to
deal with grabbing and laying down some files somewhere which is
basically what this all amounts to. If we're not using the same
mechanisms i.e. you're using a different resolver, not using POMs
locally and doing whatever else differently then it's not really
Maven. I don't think it's going to be that hard to make something
that works for Java, C/++, and .net.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending Pom to Include Artifact Installation Instructions
Posted by Shane Isbell <sh...@gmail.com>.
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 <ke...@apache.org> 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 <ja...@maven.org> 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: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder and PMC Chair, Apache Maven
> > jason at sonatype dot com
> > ----------------------------------------------------------
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Extending Pom to Include Artifact Installation Instructions
Posted by Kenney Westerhof <ke...@apache.org>.
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 <ja...@maven.org> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending Pom to Include Artifact Installation Instructions
Posted by Jason van Zyl <ja...@maven.org>.
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 <ja...@maven.org> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending Pom to Include Artifact Installation Instructions
Posted by Shane Isbell <sh...@gmail.com>.
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 <ja...@maven.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Extending Pom to Include Artifact Installation Instructions
Posted by Jason van Zyl <ja...@maven.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org