incubator-nmaven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Technical Decisions Regarding NMaven?
Date Thu, 15 Nov 2007 10:28:25 GMT

On 14 Nov 07, at 5:51 PM 14 Nov 07, James Carpenter wrote:

> I think it is fair to argue that the current maven requirement to  
> have versions in the repository artifact filenames is fundamentally  
> deficient.

I think it's the Window's linker that's fundamentally deficient no?.  
Any system that will not allow you to look at an artifact and tell  
exactly what is immediately is fundamentally deficient.

>  Just as .NET assemblies must maintain the same filename regardless  
> of version, there are bound to be other exotic artifacts which have  
> the same requirement.

Things work fine in Java, and fine in C.

> I would therefore recommend the DefaultArtifactResolver within maven  
> simply be enhanced to make versions in the artifact names optional.

It's controlled with a layout which has already been tried by Dan  
Fabulich. It's not a problem with the resolver, it's how it's laid out  
in the file system which is controlled by the ...  
ArtifactRepositoryLayout. Having both systems running at the same time  
would need a change, maybe a layout per language and we might even  
want per language local repositories. For the C stuff that's been done  
it used the standard layout. Maybe it's just local repository per  
layout used.

>  I expect the maven core maintainers would willingly conceed this  
> change as long as a good explanation is provided.  To make this  
> actually happen an NMaven developer should simply work out and  
> implement the actual changes within the maven source and submit a  
> patch with an explanation.  I have successfully contributed maven  
> patches in the past and find that any reasonable change is generally  
> accepted. (See for an  
> example.)
> Some mechanism to enforce the current conventions for java artifacts  
> should probably be put in place.  As appropriate the definition of a  
> type could include a filename pattern.  The default pattern being  
> the standard one which includes versions in the filename, with  
> the .NET artifact types explicitly specifying filename patterns  
> without versions.
> I would suggest that a given artifact type always follow a specific  
> filename pattern.  So java artifacts should always have version  
> numbers in their filenames, and .NET artifacts should never have  
> version numbers in their filenames.  In typical maven spirt,  
> convention should be favored over configuration.  The more flexible  
> the artifact repository structure becomes, the greater the  
> complexity and maintenance cost.
> Some additional discussion of this issue can be found on a JIRA  
> issue I created over a year ago, when still actively writing .NET  
> code built with maven.
> The JIRA proposes post-processing maven artifacts.  Although this  
> will work, I expect teaching the DefaultArtifactResolver to handle  
> alternative artifact filename patterns (as described above) is  
> likely a better choice.
> The implementation effort required to make these changes within the  
> DefaultArtifactResolver is probably at least a few days if not a  
> week or two.  As I don't have this time to spend myself, I'm just  
> acting as a really bad back seat driver.  As I have not actively  
> worked with nmaven as of late I expect I am restating the obvious at  
> times, or failing to account for certain functionality that is now  
> in place.  It is my hope, that by the time I next work with .NET all  
> of the nmaven goodness will be worked into standard maven and all  
> the little kinks worked out.  Its already far far better than what I  
> worked with a year and a half ago.
> Sincerely,
> James Carpenter
> email:
> On Nov 14, 2007, at 5:00 PM, Shane Isbell wrote:
>> Currently, NMaven supports not having versions in the file name,  
>> but the
>> implementation is creating a divergence from Maven. From the  
>> response here,
>> it does look as though we are going to need to continue supporting no
>> versions in the assembly file name. The issue now becomes how we do  
>> it in
>> such a way as to bring the implementation more in line with Maven.
>> If we do away with capabilities/requirements, we could do away with  
>> RDF, but
>> we are still left with a fairly big implementation divergence.  
>> Throwing out
>> some half-baked thoughts here: the copying of assembly files within  
>> the same
>> repo is a nightmare to deal with, so we would still need some uac  
>> concept
>> (or shadow repo) that also contains the poms and assemblies w/o  
>> versions in
>> file name.  If we require pom + additional meta data file, then  
>> this will
>> likely be more complicated to manage than RDF.
>> Shane
>> On Nov 14, 2007 2:32 PM, <> wrote:
>>> I agree with James - let's?put the?versioning in the directory  
>>> structure
>>> or a separate file - in the large corporate environment I work in,  
>>> we've got
>>> a lot of third-party proprietary binaries that will need to be  
>>> included in
>>> the repository, and recompiling is not feasible.
>>> -----Original Message-----
>>> From: James Carpenter <>
>>> To:
>>> Sent: Tue, 13 Nov 2007 4:33 pm
>>> Subject: Re: Technical Decisions Regarding NMaven?
>>> I'm not currently actively engaged in .NET development built via  
>>> maven,
>>> but I did use the early pre-nmaven plugins which used to be found  
>>> down in
>>> maven's SVN.?
>>> While working with those I was frequently tweaking the various  
>>> plugins to
>>> implement tactical fixes, recognizing a proper solution would  
>>> require the
>>> major architectural changes and momentum shown by nmaven. If you  
>>> look on the
>>> maven JIRA you will actually see a lot of old obsolete JIRAs I  
>>> posted
>>> against them.?
>>> ?
>>> While doing this work it became painfully obvious that .NET  
>>> artifacts
>>> should be stored in the maven repository without versions as part  
>>> of their
>>> names (or at least moved to their original filename once  
>>> downloaded by the
>>> resolver). The assembly dependencies listed in the meta-data files  
>>> within a
>>> strongly named (digitally signed) 3rd party .NET assembly must  
>>> have the same
>>> name they were built with. When placing strongly named 3rd party  
>>> dlls into
>>> my maven repo (such as Tibco), I don't get to monkey with the meta- 
>>> data
>>> within them as they are digitally signed. Furthermore I don't have  
>>> the
>>> source code with which to build my own. Even if I did have source,  
>>> its
>>> unreasonable to require me to recompile every 3rd party library I  
>>> want to
>>> use.?
>>> ?
>>> In short, please please don't do anything which mandates a name  
>>> change
>>> when placing an arbitrary 3rd party artifact into the repository.  
>>> If you
>>> have not already done so, I recommend you simply teach the  
>>> standard maven
>>> artifact resolver to be capable of using the repository directory  
>>> structure
>>> and pom contents alone to determine version information. If you  
>>> absolutely
>>> must, introduce an extra meta-data file (say version.xml) to sit  
>>> alongside
>>> the pom, but please don't impose mandatory inflexible naming  
>>> convention on
>>> the artifacts. (Java artifacts should continue to place the  
>>> version in the
>>> filename as its really nice to have when it doesn't cause  
>>> problems, but this
>>> should become optional.)?
>>> ?
>>> Please forgive me if what I am discussing is overly obvious.?
>>> ?
>>> On Nov 12, 2007, at 3:15 PM, Shane Isbell wrote:?
>>> ?
>>>> We do need to come to some technical decisions regarding the >  
>>>> direction
>>> of?
>>>> NMaven. I've taken a hard look at what are the most difficult  
>>>> parts > to
>>> bring?
>>>> in line with Maven core and hope to get some feedback and a >  
>>>> decision
>>> on how?
>>>> we want to approach it.?
>>>> ?
>>>> 1) Including the versions in the file name??
>>>> Pros: Simplifies the resolving and brings it in line with Maven.  
>>>> No >
>>> RDF, no?
>>>> uac directory.?
>>>> Cons: Forces assembly loading equivalent to strong naming. This >  
>>>> means
>>> that?
>>>> you need to recompile the whole assembly chain when making a  
>>>> change > in
>>> a?
>>>> dependency.?
>>>> ?
>>>> 2) Remove support for the nmaven-settings and requirement/ 
>>>> capability?
>>>> matching??
>>>> Pros: Faster start up time, due to no reading of settings file  
>>>> and >
>>> matching.?
>>>> Easier integration with Maven core.?
>>>> Cons: No longer can change the framework versions/vendors of  
>>>> builds >
>>> through?
>>>> an external settings file, but rather need to manually configure  
>>>> > the
>>> paths?
>>>> to framework versions and vendors. More manually coding required  
>>>> > when
>>> adding?
>>>> support for new framework versions.?
>>>> ?
>>>> The nmaven-settings is particularly good for testing applications >
>>> against?
>>>> multiple build environments and makes it much easier to add  
>>>> support >
>>> for new?
>>>> framework versions, but not so useful for environments that  
>>>> target > a
>>> single?
>>>> environment, which appears to be the general use case for NMaven.?
>>>> ?
>>>> 3) Continued support for downloading and running executables from  
>>>> the?
>>>> repository??
>>>> ?
>>>> These three decisions have to do with the reduction of >  
>>>> functionality
>>> to make?
>>>> integration with Maven core easier. In the first case (1), I'm  
>>>> all for?
>>>> including versions in the file-name as I now think that strong >  
>>>> naming
>>> should?
>>>> be required of all open-source projects, but I am not certain if  
>>>> > there
>>> are?
>>>> any individual cases (particularly on corporate projects) where >  
>>>> this
>>> may?
>>>> prove disadvantageous.?
>>>> ?
>>>> The second case (2) is a little trickier because we would lose  
>>>> some >
>>> cool?
>>>> functionality, but from my observations, most people are  
>>>> targeting one?
>>>> environment anyway, so they may not mind a little extra >  
>>>> configuration.
>>> My?
>>>> vision for the requirements/capabilities concept requires >  
>>>> eventually
>>> having?
>>>> requirement concepts within the pom.xml file. I moved toward the  
>>>> > RDF
>>> concept?
>>>> which solved this issue of needing to modify the pom but then I  
>>>> was?
>>>> confronted with all the repository work (Archiva, etc) that would  
>>>> > be
>>> needed?
>>>> to eventually support RDF, as well as the concerns with moving  
>>>> away >
>>> from the?
>>>> core Maven implementation. So if (1) goes away, (2) promises only  
>>>> > half
>>> a?
>>>> solution. In that case, we should consider deprecating it.?
>>>> ?
>>>> The third case (3) deals with being able to deploy an executable,  
>>>> > its
>>> conf?
>>>> file and dependencies into a repo and then be able to resolve and  
>>>> > run
>>> that?
>>>> exe during a build. In some ways, this is really there to allow >  
>>>> NMaven
>>> to?
>>>> run as a Maven plugin and have all the runners, loaders download?
>>>> automatically and be part of the life-cycle. I think eventually >
>>> everything?
>>>> will be deployed within Maven core (or through an MSI or other >
>>> installer),?
>>>> so there will not be a direct need from NMaven's perspective to >
>>> support?
>>>> this. However, others may find it useful. My preference would be  
>>>> to?
>>>> discontinue this unless someone finds this useful and intends to  
>>>> > use
>>> it.?
>>>> ?
>>>> Shane?
>>> ?
>>> ________________________________________________________________________
>>> Email and AIM finally together. You've gotta check out free AOL  
>>> Mail! -



Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com

View raw message