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 http://jira.codehaus.org/browse/MSANDBOX-23 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.
http://jira.codehaus.org/browse/MSANDBOX-26
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: [EMAIL PROTECTED]
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, <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
To: [email protected]
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! -
http://mail.aol.com
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
