Technical Decisions Regarding NMaven?

[Shane Isbell <sh...@gmail.com>]

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

Re: Technical Decisions Regarding NMaven?

[Shane Isbell <sh...@gmail.com>]

Thanks Evan. So let's go ahead and start removing options 1 and 2. I've
opened a branch SI_MAVEN_INTEGRATION which will largely be used to start
hacking out the unneeded code and functionality.

We will need to rebuild the plugins without the use of the
NetExecutableFactory and most of the stuff that uses VendorInfo won't be
needed. A good place to start is to rebuild the compile plugin. We need to
support c# and vb, dump the ruby and compact profile for now. Most of the
compile functionality is in the DefaultCompiler class. This initial
effort deals in decoupling the plugins from the components, copying and
pasting whatever functionality we need. The more we can isolate into the
plugins, the easier integration with Maven will be.

I'd also like to use dotnet:library, dotnet:exe and so on for the types.
This way we could actually have two different compiler, testing, etc plugins
without conflicting.

Shane

On Nov 12, 2007 5:19 PM, Evan Worley <ev...@gmail.com> wrote:

> Nice analysis Shane,
>
> I have a few small comments.
>
> 1) I think including versions in fine, and for those that are using
> NMaven in a dual java/.net environment, we are used to versions in
> libraries, so this actually adds consistency.
>
> 2) I can't speak for everyone, but we are definitely targeting one
> environment, so we don't mind a little extra configuration.
>
> 3) I see this as a nice feature, it also allows us to resolve things
> like the NUnit runner, config, etc.  I don't see much difference
> between deploying and resolving a dll vs deploying and resolving an
> exe, it's just a different packaging in the same platform.  Unless I
> am missing something, I would vote to keep this feature.  Now if all
> the required executables are to be deployed as an "Nmaven install",
> then I might not see a need to keep this feature around.  Then we
> would not need to resolve Nunit, ResX, etc.
>
> -Evan
>
> On Nov 12, 2007 1:15 PM, Shane Isbell <sh...@gmail.com> 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
> >
>

Re: Technical Decisions Regarding NMaven?

[Evan Worley <ev...@gmail.com>]

Nice analysis Shane,

I have a few small comments.

1) I think including versions in fine, and for those that are using
NMaven in a dual java/.net environment, we are used to versions in
libraries, so this actually adds consistency.

2) I can't speak for everyone, but we are definitely targeting one
environment, so we don't mind a little extra configuration.

3) I see this as a nice feature, it also allows us to resolve things
like the NUnit runner, config, etc.  I don't see much difference
between deploying and resolving a dll vs deploying and resolving an
exe, it's just a different packaging in the same platform.  Unless I
am missing something, I would vote to keep this feature.  Now if all
the required executables are to be deployed as an "Nmaven install",
then I might not see a need to keep this feature around.  Then we
would not need to resolve Nunit, ResX, etc.

-Evan

On Nov 12, 2007 1:15 PM, Shane Isbell <sh...@gmail.com> 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
>

Re: Technical Decisions Regarding NMaven?

[dfabulich <da...@fabulich.com>]

Jason van Zyl-2 wrote:
> 
> 
>>  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.
> 
> 

Er, they only work in C on Linux/Unix.  In C/Windows DLLs link by name, and
without symlink support, you've got the same problem over again.

I spell out my argument in excruciating detail in the doc below, but IMO the
rule should be that if the artifact specifies a <finalName>, we should use
that finalName everywhere, including in the default repository layout.  That
will require a change to the way snapshots are story in the default layout,
where currently we put a bunch of snapshots all in one directory.  But we
should stop doing that anyway!

http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement+Documents

-Dan
-- 
View this message in context: http://www.nabble.com/Technical-Decisions-Regarding-NMaven--tf4793894.html#a13941130
Sent from the nmaven-dev mailing list archive at Nabble.com.

Re: Technical Decisions Regarding NMaven?

[Shane Isbell <sh...@gmail.com>]

Hi Dan,

Right now we are taking a fresh look at NMaven to get it integrated with
Maven; so provided that it works, there is nothing holding back using such a
change from the NMaven side (can't speak about the implications to the Maven
core and associated plugins). Anybody have any ideas on how this finalName
change would affect the various Maven plugins? The standard maven plugins
breaking has always been the biggest headache when dealing with this version
issue, which is also one of the reasons for the separate repo with a
repository format converter.

Shane

On Nov 25, 2007 3:16 PM, dfabulich <da...@fabulich.com> wrote:

>
>
>
> Shane Isbell wrote:
> >
> > I think the idea of having a separate repository per language/platform
> is
> > a good one.
>
> I'm mildly opposed to this, because this is not a language specific
> problem.
> A small change to the default repository layout would fix this problem for
> everyone: just use the <finalName> in the repository layout.  IMO this is
> the "right answer" for all languages, and should be the future of Maven.
>
> I wound up taking about a year long hiatus from Maven development, but if
> I
> get the thumbs-up, I'd happily code up the changes to the DRL in Maven
> trunk
> right now.  The change is small, but it's to something important, so it
> requires lots of consensus.
>
> -Dan
> --
> View this message in context:
> http://www.nabble.com/Technical-Decisions-Regarding-NMaven--tf4793894.html#a13941288
>  Sent from the nmaven-dev mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>

Re: Technical Decisions Regarding NMaven?

[Dan Fabulich <da...@fabulich.com>]

Jason van Zyl wrote:

>Dan Fabulich wrote:
>> A small change to the default repository layout would fix this problem for
>> everyone: just use the <finalName> in the repository layout.  IMO this is
>> the "right answer" for all languages, and should be the future of Maven.
>> 
>
> My opinion hasn't change and I definitely believe that is not the right 
> answer.

My point is argued in, ah, quite a bit of detail in my write-up.  The gist 
of the argument was simply that when <finalName> is set, you need that to 
be the name of your file.

http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement+Documents

I don't recall the gist of your objection.  I think an essential part of 
your objection was that Windows sucks, a point about which I agree.  ;-) I 
hope you don't think that Windows isn't very important, just because it 
sucks.  Windows is very important, because it is so ubiquitous.  (Helping 
users of Windows is important BECAUSE Windows sucks.)

Could you rehearse again your reasoning here, or perhaps in some wiki 
article so we don't have to bring it up again? ;-)

As I see it, the Pros/Cons of my proposal are:

Pro 1: If you declared a <finalName>, the artifact will have that name, 
which is what you said you needed.
Con 1: If people declare <finalName>, the artifact won't contain a version 
number, which is bad even if they say they need it.
Con 2: Changing the DefaultRepositoryLayout will require changing tools in 
the world code in the world, and that's worse than the benefit.
Pro 2: The benefit is smooth integration of Windows libraries into the 
Maven repository.  This benefit is very important, even though Windows 
sucks, because Windows is unfortunately ubiquitous.

-Dan

Re: Technical Decisions Regarding NMaven?

[Jason van Zyl <ja...@maven.org>]

On Nov 25, 2007, at 3:16 PM, dfabulich <da...@fabulich.com> wrote:

>
>
>
> Shane Isbell wrote:
>>
>> I think the idea of having a separate repository per language/ 
>> platform is
>> a good one.
>
> I'm mildly opposed to this, because this is not a language specific  
> problem.
> A small change to the default repository layout would fix this  
> problem for
> everyone: just use the <finalName> in the repository layout.  IMO  
> this is
> the "right answer" for all languages, and should be the future of  
> Maven.
>

My opinion hasn't change and I definitely believe that is not the  
right answer.

> I wound up taking about a year long hiatus from Maven development,  
> but if I
> get the thumbs-up, I'd happily code up the changes to the DRL in  
> Maven trunk
> right now.  The change is small, but it's to something important, so  
> it
> requires lots of consensus.

I was -1 a year ago and you still haven't convinced me otherwise.
>
> -Dan
> -- 
> View this message in context: http://www.nabble.com/Technical-Decisions-Regarding-NMaven--tf4793894.html#a13941288
> Sent from the nmaven-dev mailing list archive at Nabble.com.
>

Re: Technical Decisions Regarding NMaven?

[dfabulich <da...@fabulich.com>]

Shane Isbell wrote:
> 
> I think the idea of having a separate repository per language/platform is
> a good one.

I'm mildly opposed to this, because this is not a language specific problem. 
A small change to the default repository layout would fix this problem for
everyone: just use the <finalName> in the repository layout.  IMO this is
the "right answer" for all languages, and should be the future of Maven.  

I wound up taking about a year long hiatus from Maven development, but if I
get the thumbs-up, I'd happily code up the changes to the DRL in Maven trunk
right now.  The change is small, but it's to something important, so it
requires lots of consensus.

-Dan
-- 
View this message in context: http://www.nabble.com/Technical-Decisions-Regarding-NMaven--tf4793894.html#a13941288
Sent from the nmaven-dev mailing list archive at Nabble.com.

Re: Technical Decisions Regarding NMaven?

[Shane Isbell <sh...@gmail.com>]

Right. The resolver works fine and the repository layout is easy enough to
change so no changes needed there. I think the idea of having a separate
repository per language/platform is a good one. One reason having a separate
repo is beneficial is that you can run a format converter that copies
artifacts from the language/platform specific repo (say .NET) to the
standard local repository. In that way, most of the standard plugins built
for Java will still work. At least in .NET's case, a simple pom for
meta-data will also suffice in the separate repo.

For .NET, we also need an execution area (pab) for executing of assemblies.

I am wondering whether it would be a good idea to have event notification
within Maven that would notify listeners when an artifact is resolved. In
this way, app developers could easily deploy a resolved artifact to the GAC,
to a different repo or to an artifact execution area with little development
effort? This would make syncing everything easy.

Shane
On Nov 15, 2007 2:28 AM, Jason van Zyl <ja...@maven.org> wrote:

>
> 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: jcarpenter621@yahoo.com
> >
> > 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, <ca...@aol.com> 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 <jc...@yahoo.com>
> >>> To: nmaven-dev@incubator.apache.org
> >>> 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
> ----------------------------------------------------------
>
>
>
>

Re: Technical Decisions Regarding NMaven?

[Jason van Zyl <ja...@maven.org>]

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: jcarpenter621@yahoo.com
>
> 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, <ca...@aol.com> 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 <jc...@yahoo.com>
>>> To: nmaven-dev@incubator.apache.org
>>> 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
----------------------------------------------------------

Re: Technical Decisions Regarding NMaven?

[James Carpenter <jc...@yahoo.com>]

I think it is fair to argue that the current maven requirement to  
have versions in the repository artifact filenames 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.

I would therefore recommend the DefaultArtifactResolver within maven  
simply be enhanced to make versions in the artifact names optional.   
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: jcarpenter621@yahoo.com

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, <ca...@aol.com> 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 <jc...@yahoo.com>
>> To: nmaven-dev@incubator.apache.org
>> 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
>>

Re: Technical Decisions Regarding NMaven?

[Jason van Zyl <ja...@maven.org>]

On 14 Nov 07, at 6:00 PM 14 Nov 07, 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.
>

Is no version in the artifacts the only way .NET functions well?

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

What metadata do you need to store? More then simple properties?

> Shane
>
> On Nov 14, 2007 2:32 PM, <ca...@aol.com> 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 <jc...@yahoo.com>
>> To: nmaven-dev@incubator.apache.org
>> 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
----------------------------------------------------------

Re: Technical Decisions Regarding NMaven?

[Shane Isbell <sh...@gmail.com>]

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, <ca...@aol.com> 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 <jc...@yahoo.com>
> To: nmaven-dev@incubator.apache.org
> 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
>

Re: Technical Decisions Regarding NMaven?

[ca...@aol.com]

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 <jc...@yahoo.com>
To: nmaven-dev@incubator.apache.org
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

Re: Technical Decisions Regarding NMaven?

[James Carpenter <jc...@yahoo.com>]

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