You are viewing a plain text version of this content. The canonical link for it is here.
Posted to nmaven-dev@incubator.apache.org by Brett Porter <br...@apache.org> on 2007/06/22 03:07:58 UTC
Re: svn commit: r549393 - /incubator/nmaven/branches/SI_GAC/
In addition to, or instead of?
Sounds like a contradiction with Maven philosophy of being able to
use different versions for different applications (IIUC, the GAC
doesn't permit duplicates of an artifact with different versions).
- Brett
On 21/06/2007, at 3:55 PM, sisbell@apache.org wrote:
> Author: sisbell
> Date: Wed Jun 20 22:55:03 2007
> New Revision: 549393
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=549393
> Log:
> Copy of trunk. Branch deals with experimental work with using the
> GAC instead of the maven repo for storing artifacts.
>
> Added:
> incubator/nmaven/branches/SI_GAC/
> - copied from r549392, incubator/nmaven/trunk/
Re: svn commit: r549393 - /incubator/nmaven/branches/SI_GAC/
Posted by Shane Isbell <sh...@gmail.com>.
Since this is already under discussion, let me outline some of the things I
am already seeing with the GAC prototype. First, I don't think that we
should install everything into the GAC. There are legitimate reasons for
wanting (private) application bases where you can swap out assemblies with
different versions. This also means that the performance of the install
phase will be better (a simple copy is much faster than a gacutil install)
and that we can reduce the pollution of the GAC with assemblies that are not
meant to be shared (one of the issues that Brett raised). Second, I think
that we should create a separate space for handling of these private
application bases; currently, this is handled within the repository itself.
This gets messy to maintain. Third, I think that we should bring the
repository structure of that NMaven uses in-line with the one for that the
GAC uses.
This would lead to something that looks like this (locally), where uac
denotes User Assembly Cache, pab denotes Private Application Base and
gac_msil is the process architecture.
|--.m2
| `--repository
| `--uac
| `--gac_msil
| `--NMaven.Model.Pom
| `--0.14.0.0__NMaven.Model
| `--NMaven.Model.Pom.dll
| `--NMaven.Model.Pom.pom
| `--NMaven.Executable
| `--0.14.0.0__NMaven.Executables
| `--NMaven.Executable.exe
| `--NMaven.Executable.pom
| `--pab
| `--NMaven.Executable
| `--0.14.0.0__NMaven.Executables
| `--NMaven.Executable.exe
| `--NMaven.Model.Pom.dll
If the NMaven.Model.Pom artifact is installed into the GAC, it would look
like:
| `--assembly
| `--gac_msil
| `--NMaven.Model.Pom
| `--0.14.0.0__4b435f4d76e2f0e6
| `--NMaven.Model.Pom.dll
| `--NMaven.Model.Pom.pom
and the private application base would change to
| `--pab
| `--NMaven.Executable
| `--0.14.0.0__NMaven.Executables
| `--NMaven.Executable.exe
Currently, the repository, uac and pab are all one concept. By breaking them
apart, it will clean up the code and make the system more modular (and
easier to maintain). Bringing the local Maven repository structure for .NET
artifacts in line with the GAC, also has some additional advantages. First,
we can think about and treat .NET artifacts in a similar way, regardless of
whether they are in a global or user scope. Second, we can quickly delineate
the implicit assumptions that plugins, Maven core and NMaven make regarding
the repository structure from the explicit ones defined through the use of
the Maven core API. For example, under the current version of NMaven, I
plugin a new repository layout, which makes certain things work, but then
I may also add in the same artifact using the default layout to make other
things work, which are not as easily addressable through the API. By using a
completely different format, I don't have the option of being lazy. This
will help push more changes back into Maven core (and plugins). Then I know
the Maven API will hold up. Thoughts?
Shane
On 6/22/07, Evan Worley <ev...@gmail.com> wrote:
>
> Shane,
>
> At the very least there will be great learning that will come out of this
> experimentation.
>
> From below it seems that the biggest issue is that when NMaven is building
> an artifact, it copies the dependencies into a directory (e.g.
> test-assemblies) with the built assembly. These dependencies might
> include
> two of the same artifacts, with differing versions. These artifacts will
> collide since .net standards don't allow for version numbers in the
> assembly
> name. Do we know if any of the assembly version standards are going to
> change in .net 3.0?go
>
> Just my thoughts,
> Evan
>
> On 6/22/07, Shane Isbell <sh...@gmail.com> wrote:
> >
> > I should probably outline my line of reasoning for this branch since
> Brett
> > (and others) have expressed concern. If we look at the structure of the
> > maven repo, we have .m2/repository/groupId/artifactId/version structure.
> > The
> > GAC's structure is
> > process_architecture/artifactId/version_culture_publickey. The process
> > architecture would typically be handled by a maven classifier. Replacing
> > the
> > equivalent GAC values into a maven repo structure would yield:
> > publickey/arifactId/version/culture_process_architecture. So we have a
> > rough
> > equivalence here. If we are only concerned with compiling assemblies (no
> > third-party downloaded executables, no unit tests) then using the GAC
> buys
> > us exactly nothing. For the runtime, it is very different.
> >
> > Currently, NMaven places all of the dependent assemblies of an
> executable
> > assembly into the executable assembly's repo location (the following
> line
> > of
> > reasoning also applies for running NUnit tests). This has a few
> > implications: First, we need to manage these copies, which can get out
> of
> > date. For example, say I have assembly B dependent on assembly A. Now
> say,
> > I
> > have executable C dependent on assembly B. When I compile executable
> > C, NMaven copies over A and B, provided they are newer than the local
> > ones.
> > Now if I recompile A, C does not know about it. Any application using C
> > will
> > also be using an out-of-date A. Of course, just replacing A, without
> > recompiling C could be just as dangerous; but this is still a runtime
> > issue
> > that people need to consider. The second issue is that the current
> > implementation doesn't have an application base structure for the
> > executable
> > to be able to handle running two versions of the same assembly name.
> Say,
> > one part of my application needs MyAssembly.dll version 2.0 from apache.
> > Now
> > say that I am dependent on SF.dll, which is dependent on
> > MyAssembly.dllversion
> > 2.0 from sourceforge. The current NMaven implementation wouldn't know
> how
> > to
> > handle this loading.
> >
> > So if we look at the purpose of the repository as 1) providing
> > compile-time
> > artifacts; and 2) executing programs by using the artifact directory as
> an
> > application base, then we have a lot more work in deciding the runtime
> > structure. There may be grounds to say that (2) should not be a
> > consideration, but it's a constraint that I am operating under. I also
> > maintain that the repository structure should not be considered a public
> > schema, it's really an implementation detail. From a technical
> standpoint,
> > I
> > think it makes a lot of sense to explore direct use of the GAC as one
> > possible solution; I do not know whether it will pan out, so I am not
> > going
> > to advocate this approach without some viable prototypes.
> >
> > The more fundamental issue in my mind is the potential bifurcation of
> > Maven
> > and NMaven code since so much revolves around repo structure and its
> > implict
> > assumptions. Maven core seems about 80% there in terms of having a
> > configurable API (the plugins being around 1%, although I still looking
> > for
> > it). I must lay out some of my feelings on this (and believe me the
> > frustration definately does color the technical merits of what I am
> about
> > to
> > say)
> > 1) The (failed) remote resolving of snapshot has been a pain. Up until
> > that
> > point, I felt that NMaven was stable, but this was the tipping point
> where
> > I
> > realized that copying and renaming of files just did not work. A simple
> > concept destabilized the entire system.
> > 2) I am concerned with the use of the artifact resolver (one of the most
> > beneficial parts of the Maven API). NMaven has a lot of code wrapped
> > around
> > this API. Any changes from maven 2.1 onward can impact a large part of
> the
> > NMaven code base, as NMaven does a lot of massaging of resolved results
> > and
> > dependencies. Since I am tied into the maven 2.1's MavenEmbedder (for
> the
> > IDE part), I don't have a stable option to sit things out while the dust
> > clears; and I have enough moving parts not to want to hit another (very
> > architecturally significant) moving target in the form of the resolver.
> > Since I am a downstream consumer of Maven - and have customer
> deliverables
> > -
> > my gut instinct is to put up a high context boundary on this one and not
> > tie
> > myself down any further.
> > 3) Even though the core is configurable, Maven plugins don't work with
> > NMaven. The most recent example was the maven-assembly-plugin: it did
> not
> > recognize any of my custom artifact types (library, exe, winexe, etc)
> even
> > though they were configured. This left me scrambling on a delivery,
> trying
> > to build my own (buggy) assembly plugin at the last minute. At this
> point,
> > I
> > am left questioning how much does stuffing everything into the default
> > repo
> > format buy me.
> >
> > Naturally, I want to find the simplest way forward.
> >
> > Shane
> >
> >
> > On 6/21/07, Brett Porter <brett@apache.org > wrote:
> > >
> > > I admit to limited practical understanding of this, but it raises a
> > > couple of other concerns (if they are applicable):
> > >
> > > - won't this require system admin privileges?
> > > - isn't it possible some people won't want their gac touched?
> > > - can this impact other applications on the system?
> > >
> > > Cheers,
> > > Brett
> > >
> > > On 22/06/2007, at 2:10 PM, Shane Isbell wrote:
> > >
> > > > Currently, we have dual support for both GAC and maven repo
> > > > installation.
> > > > This is to experiment with just using the GAC. There are some
> > > > potential
> > > > benefits, including: 1) not needing to copy dependent assemblies
> into
> > > > executable addin and netplugin directories (within the repo); 2)
> > > > not needing
> > > > to copy dependent assemblies into the target directory for unit
> > > > testing; 3)
> > > > simpilfication and readability of code. The current way (1) is
> > > > handled does
> > > > not allow the application to use two different versions of the same
> > > > assembly
> > > > during execution. This may be required for assemblies with strong
> > > > names.
> > > >
> > > > Shane
> > > >
> > > > On 6/21/07, Evan Worley < evanworley@gmail.com> wrote:
> > > >>
> > > >> Brett,
> > > >>
> > > >> I believe the GAC does allow multiple versions of the same
> artifact,
> > > >> http://en.wikipedia.org/wiki/Global_Assembly_Cache#Side-by-
> > > >> side_versioning
> > > >>
> > > >> -Evan
> > > >>
> > > >> On 6/21/07, Brett Porter < brett@apache.org> wrote:
> > > >> >
> > > >> > In addition to, or instead of?
> > > >> >
> > > >> > Sounds like a contradiction with Maven philosophy of being able
> to
> > > >> > use different versions for different applications (IIUC, the GAC
> > > >> > doesn't permit duplicates of an artifact with different
> versions).
> > > >> >
> > > >> > - Brett
> > > >> >
> > > >> > On 21/06/2007, at 3:55 PM, sisbell@apache.org wrote:
> > > >> >
> > > >> > > Author: sisbell
> > > >> > > Date: Wed Jun 20 22:55:03 2007
> > > >> > > New Revision: 549393
> > > >> > >
> > > >> > > URL: http://svn.apache.org/viewvc?view=rev&rev=549393
> > > >> > > Log:
> > > >> > > Copy of trunk. Branch deals with experimental work with using
> the
> > > >> > > GAC instead of the maven repo for storing artifacts.
> > > >> > >
> > > >> > > Added:
> > > >> > > incubator/nmaven/branches/SI_GAC/
> > > >> > > - copied from r549392, incubator/nmaven/trunk/
> > > >> >
> > > >>
> > >
> >
>
Re: svn commit: r549393 - /incubator/nmaven/branches/SI_GAC/
Posted by Evan Worley <ev...@gmail.com>.
Shane,
At the very least there will be great learning that will come out of this
experimentation.
From below it seems that the biggest issue is that when NMaven is building
an artifact, it copies the dependencies into a directory (e.g.
test-assemblies) with the built assembly. These dependencies might include
two of the same artifacts, with differing versions. These artifacts will
collide since .net standards don't allow for version numbers in the assembly
name. Do we know if any of the assembly version standards are going to
change in .net 3.0?go
Just my thoughts,
Evan
On 6/22/07, Shane Isbell <sh...@gmail.com> wrote:
>
> I should probably outline my line of reasoning for this branch since Brett
> (and others) have expressed concern. If we look at the structure of the
> maven repo, we have .m2/repository/groupId/artifactId/version structure.
> The
> GAC's structure is
> process_architecture/artifactId/version_culture_publickey. The process
> architecture would typically be handled by a maven classifier. Replacing
> the
> equivalent GAC values into a maven repo structure would yield:
> publickey/arifactId/version/culture_process_architecture. So we have a
> rough
> equivalence here. If we are only concerned with compiling assemblies (no
> third-party downloaded executables, no unit tests) then using the GAC buys
> us exactly nothing. For the runtime, it is very different.
>
> Currently, NMaven places all of the dependent assemblies of an executable
> assembly into the executable assembly's repo location (the following line
> of
> reasoning also applies for running NUnit tests). This has a few
> implications: First, we need to manage these copies, which can get out of
> date. For example, say I have assembly B dependent on assembly A. Now say,
> I
> have executable C dependent on assembly B. When I compile executable
> C, NMaven copies over A and B, provided they are newer than the local
> ones.
> Now if I recompile A, C does not know about it. Any application using C
> will
> also be using an out-of-date A. Of course, just replacing A, without
> recompiling C could be just as dangerous; but this is still a runtime
> issue
> that people need to consider. The second issue is that the current
> implementation doesn't have an application base structure for the
> executable
> to be able to handle running two versions of the same assembly name. Say,
> one part of my application needs MyAssembly.dll version 2.0 from apache.
> Now
> say that I am dependent on SF.dll, which is dependent on
> MyAssembly.dllversion
> 2.0 from sourceforge. The current NMaven implementation wouldn't know how
> to
> handle this loading.
>
> So if we look at the purpose of the repository as 1) providing
> compile-time
> artifacts; and 2) executing programs by using the artifact directory as an
> application base, then we have a lot more work in deciding the runtime
> structure. There may be grounds to say that (2) should not be a
> consideration, but it's a constraint that I am operating under. I also
> maintain that the repository structure should not be considered a public
> schema, it's really an implementation detail. From a technical standpoint,
> I
> think it makes a lot of sense to explore direct use of the GAC as one
> possible solution; I do not know whether it will pan out, so I am not
> going
> to advocate this approach without some viable prototypes.
>
> The more fundamental issue in my mind is the potential bifurcation of
> Maven
> and NMaven code since so much revolves around repo structure and its
> implict
> assumptions. Maven core seems about 80% there in terms of having a
> configurable API (the plugins being around 1%, although I still looking
> for
> it). I must lay out some of my feelings on this (and believe me the
> frustration definately does color the technical merits of what I am about
> to
> say)
> 1) The (failed) remote resolving of snapshot has been a pain. Up until
> that
> point, I felt that NMaven was stable, but this was the tipping point where
> I
> realized that copying and renaming of files just did not work. A simple
> concept destabilized the entire system.
> 2) I am concerned with the use of the artifact resolver (one of the most
> beneficial parts of the Maven API). NMaven has a lot of code wrapped
> around
> this API. Any changes from maven 2.1 onward can impact a large part of the
> NMaven code base, as NMaven does a lot of massaging of resolved results
> and
> dependencies. Since I am tied into the maven 2.1's MavenEmbedder (for the
> IDE part), I don't have a stable option to sit things out while the dust
> clears; and I have enough moving parts not to want to hit another (very
> architecturally significant) moving target in the form of the resolver.
> Since I am a downstream consumer of Maven - and have customer deliverables
> -
> my gut instinct is to put up a high context boundary on this one and not
> tie
> myself down any further.
> 3) Even though the core is configurable, Maven plugins don't work with
> NMaven. The most recent example was the maven-assembly-plugin: it did not
> recognize any of my custom artifact types (library, exe, winexe, etc) even
> though they were configured. This left me scrambling on a delivery, trying
> to build my own (buggy) assembly plugin at the last minute. At this point,
> I
> am left questioning how much does stuffing everything into the default
> repo
> format buy me.
>
> Naturally, I want to find the simplest way forward.
>
> Shane
>
>
> On 6/21/07, Brett Porter <br...@apache.org> wrote:
> >
> > I admit to limited practical understanding of this, but it raises a
> > couple of other concerns (if they are applicable):
> >
> > - won't this require system admin privileges?
> > - isn't it possible some people won't want their gac touched?
> > - can this impact other applications on the system?
> >
> > Cheers,
> > Brett
> >
> > On 22/06/2007, at 2:10 PM, Shane Isbell wrote:
> >
> > > Currently, we have dual support for both GAC and maven repo
> > > installation.
> > > This is to experiment with just using the GAC. There are some
> > > potential
> > > benefits, including: 1) not needing to copy dependent assemblies into
> > > executable addin and netplugin directories (within the repo); 2)
> > > not needing
> > > to copy dependent assemblies into the target directory for unit
> > > testing; 3)
> > > simpilfication and readability of code. The current way (1) is
> > > handled does
> > > not allow the application to use two different versions of the same
> > > assembly
> > > during execution. This may be required for assemblies with strong
> > > names.
> > >
> > > Shane
> > >
> > > On 6/21/07, Evan Worley <ev...@gmail.com> wrote:
> > >>
> > >> Brett,
> > >>
> > >> I believe the GAC does allow multiple versions of the same artifact,
> > >> http://en.wikipedia.org/wiki/Global_Assembly_Cache#Side-by-
> > >> side_versioning
> > >>
> > >> -Evan
> > >>
> > >> On 6/21/07, Brett Porter < brett@apache.org> wrote:
> > >> >
> > >> > In addition to, or instead of?
> > >> >
> > >> > Sounds like a contradiction with Maven philosophy of being able to
> > >> > use different versions for different applications (IIUC, the GAC
> > >> > doesn't permit duplicates of an artifact with different versions).
> > >> >
> > >> > - Brett
> > >> >
> > >> > On 21/06/2007, at 3:55 PM, sisbell@apache.org wrote:
> > >> >
> > >> > > Author: sisbell
> > >> > > Date: Wed Jun 20 22:55:03 2007
> > >> > > New Revision: 549393
> > >> > >
> > >> > > URL: http://svn.apache.org/viewvc?view=rev&rev=549393
> > >> > > Log:
> > >> > > Copy of trunk. Branch deals with experimental work with using the
> > >> > > GAC instead of the maven repo for storing artifacts.
> > >> > >
> > >> > > Added:
> > >> > > incubator/nmaven/branches/SI_GAC/
> > >> > > - copied from r549392, incubator/nmaven/trunk/
> > >> >
> > >>
> >
>
Re: svn commit: r549393 - /incubator/nmaven/branches/SI_GAC/
Posted by Shane Isbell <sh...@gmail.com>.
I should probably outline my line of reasoning for this branch since Brett
(and others) have expressed concern. If we look at the structure of the
maven repo, we have .m2/repository/groupId/artifactId/version structure. The
GAC's structure is
process_architecture/artifactId/version_culture_publickey. The process
architecture would typically be handled by a maven classifier. Replacing the
equivalent GAC values into a maven repo structure would yield:
publickey/arifactId/version/culture_process_architecture. So we have a rough
equivalence here. If we are only concerned with compiling assemblies (no
third-party downloaded executables, no unit tests) then using the GAC buys
us exactly nothing. For the runtime, it is very different.
Currently, NMaven places all of the dependent assemblies of an executable
assembly into the executable assembly's repo location (the following line of
reasoning also applies for running NUnit tests). This has a few
implications: First, we need to manage these copies, which can get out of
date. For example, say I have assembly B dependent on assembly A. Now say, I
have executable C dependent on assembly B. When I compile executable
C, NMaven copies over A and B, provided they are newer than the local ones.
Now if I recompile A, C does not know about it. Any application using C will
also be using an out-of-date A. Of course, just replacing A, without
recompiling C could be just as dangerous; but this is still a runtime issue
that people need to consider. The second issue is that the current
implementation doesn't have an application base structure for the executable
to be able to handle running two versions of the same assembly name. Say,
one part of my application needs MyAssembly.dll version 2.0 from apache. Now
say that I am dependent on SF.dll, which is dependent on MyAssembly.dllversion
2.0 from sourceforge. The current NMaven implementation wouldn't know how to
handle this loading.
So if we look at the purpose of the repository as 1) providing compile-time
artifacts; and 2) executing programs by using the artifact directory as an
application base, then we have a lot more work in deciding the runtime
structure. There may be grounds to say that (2) should not be a
consideration, but it's a constraint that I am operating under. I also
maintain that the repository structure should not be considered a public
schema, it's really an implementation detail. From a technical standpoint, I
think it makes a lot of sense to explore direct use of the GAC as one
possible solution; I do not know whether it will pan out, so I am not going
to advocate this approach without some viable prototypes.
The more fundamental issue in my mind is the potential bifurcation of Maven
and NMaven code since so much revolves around repo structure and its implict
assumptions. Maven core seems about 80% there in terms of having a
configurable API (the plugins being around 1%, although I still looking for
it). I must lay out some of my feelings on this (and believe me the
frustration definately does color the technical merits of what I am about to
say)
1) The (failed) remote resolving of snapshot has been a pain. Up until that
point, I felt that NMaven was stable, but this was the tipping point where I
realized that copying and renaming of files just did not work. A simple
concept destabilized the entire system.
2) I am concerned with the use of the artifact resolver (one of the most
beneficial parts of the Maven API). NMaven has a lot of code wrapped around
this API. Any changes from maven 2.1 onward can impact a large part of the
NMaven code base, as NMaven does a lot of massaging of resolved results and
dependencies. Since I am tied into the maven 2.1's MavenEmbedder (for the
IDE part), I don't have a stable option to sit things out while the dust
clears; and I have enough moving parts not to want to hit another (very
architecturally significant) moving target in the form of the resolver.
Since I am a downstream consumer of Maven - and have customer deliverables -
my gut instinct is to put up a high context boundary on this one and not tie
myself down any further.
3) Even though the core is configurable, Maven plugins don't work with
NMaven. The most recent example was the maven-assembly-plugin: it did not
recognize any of my custom artifact types (library, exe, winexe, etc) even
though they were configured. This left me scrambling on a delivery, trying
to build my own (buggy) assembly plugin at the last minute. At this point, I
am left questioning how much does stuffing everything into the default repo
format buy me.
Naturally, I want to find the simplest way forward.
Shane
On 6/21/07, Brett Porter <br...@apache.org> wrote:
>
> I admit to limited practical understanding of this, but it raises a
> couple of other concerns (if they are applicable):
>
> - won't this require system admin privileges?
> - isn't it possible some people won't want their gac touched?
> - can this impact other applications on the system?
>
> Cheers,
> Brett
>
> On 22/06/2007, at 2:10 PM, Shane Isbell wrote:
>
> > Currently, we have dual support for both GAC and maven repo
> > installation.
> > This is to experiment with just using the GAC. There are some
> > potential
> > benefits, including: 1) not needing to copy dependent assemblies into
> > executable addin and netplugin directories (within the repo); 2)
> > not needing
> > to copy dependent assemblies into the target directory for unit
> > testing; 3)
> > simpilfication and readability of code. The current way (1) is
> > handled does
> > not allow the application to use two different versions of the same
> > assembly
> > during execution. This may be required for assemblies with strong
> > names.
> >
> > Shane
> >
> > On 6/21/07, Evan Worley <ev...@gmail.com> wrote:
> >>
> >> Brett,
> >>
> >> I believe the GAC does allow multiple versions of the same artifact,
> >> http://en.wikipedia.org/wiki/Global_Assembly_Cache#Side-by-
> >> side_versioning
> >>
> >> -Evan
> >>
> >> On 6/21/07, Brett Porter < brett@apache.org> wrote:
> >> >
> >> > In addition to, or instead of?
> >> >
> >> > Sounds like a contradiction with Maven philosophy of being able to
> >> > use different versions for different applications (IIUC, the GAC
> >> > doesn't permit duplicates of an artifact with different versions).
> >> >
> >> > - Brett
> >> >
> >> > On 21/06/2007, at 3:55 PM, sisbell@apache.org wrote:
> >> >
> >> > > Author: sisbell
> >> > > Date: Wed Jun 20 22:55:03 2007
> >> > > New Revision: 549393
> >> > >
> >> > > URL: http://svn.apache.org/viewvc?view=rev&rev=549393
> >> > > Log:
> >> > > Copy of trunk. Branch deals with experimental work with using the
> >> > > GAC instead of the maven repo for storing artifacts.
> >> > >
> >> > > Added:
> >> > > incubator/nmaven/branches/SI_GAC/
> >> > > - copied from r549392, incubator/nmaven/trunk/
> >> >
> >>
>
Re: svn commit: r549393 - /incubator/nmaven/branches/SI_GAC/
Posted by Brett Porter <br...@apache.org>.
I admit to limited practical understanding of this, but it raises a
couple of other concerns (if they are applicable):
- won't this require system admin privileges?
- isn't it possible some people won't want their gac touched?
- can this impact other applications on the system?
Cheers,
Brett
On 22/06/2007, at 2:10 PM, Shane Isbell wrote:
> Currently, we have dual support for both GAC and maven repo
> installation.
> This is to experiment with just using the GAC. There are some
> potential
> benefits, including: 1) not needing to copy dependent assemblies into
> executable addin and netplugin directories (within the repo); 2)
> not needing
> to copy dependent assemblies into the target directory for unit
> testing; 3)
> simpilfication and readability of code. The current way (1) is
> handled does
> not allow the application to use two different versions of the same
> assembly
> during execution. This may be required for assemblies with strong
> names.
>
> Shane
>
> On 6/21/07, Evan Worley <ev...@gmail.com> wrote:
>>
>> Brett,
>>
>> I believe the GAC does allow multiple versions of the same artifact,
>> http://en.wikipedia.org/wiki/Global_Assembly_Cache#Side-by-
>> side_versioning
>>
>> -Evan
>>
>> On 6/21/07, Brett Porter <br...@apache.org> wrote:
>> >
>> > In addition to, or instead of?
>> >
>> > Sounds like a contradiction with Maven philosophy of being able to
>> > use different versions for different applications (IIUC, the GAC
>> > doesn't permit duplicates of an artifact with different versions).
>> >
>> > - Brett
>> >
>> > On 21/06/2007, at 3:55 PM, sisbell@apache.org wrote:
>> >
>> > > Author: sisbell
>> > > Date: Wed Jun 20 22:55:03 2007
>> > > New Revision: 549393
>> > >
>> > > URL: http://svn.apache.org/viewvc?view=rev&rev=549393
>> > > Log:
>> > > Copy of trunk. Branch deals with experimental work with using the
>> > > GAC instead of the maven repo for storing artifacts.
>> > >
>> > > Added:
>> > > incubator/nmaven/branches/SI_GAC/
>> > > - copied from r549392, incubator/nmaven/trunk/
>> >
>>
Re: svn commit: r549393 - /incubator/nmaven/branches/SI_GAC/
Posted by Shane Isbell <sh...@gmail.com>.
Currently, we have dual support for both GAC and maven repo installation.
This is to experiment with just using the GAC. There are some potential
benefits, including: 1) not needing to copy dependent assemblies into
executable addin and netplugin directories (within the repo); 2) not needing
to copy dependent assemblies into the target directory for unit testing; 3)
simpilfication and readability of code. The current way (1) is handled does
not allow the application to use two different versions of the same assembly
during execution. This may be required for assemblies with strong names.
Shane
On 6/21/07, Evan Worley <ev...@gmail.com> wrote:
>
> Brett,
>
> I believe the GAC does allow multiple versions of the same artifact,
> http://en.wikipedia.org/wiki/Global_Assembly_Cache#Side-by-side_versioning
>
> -Evan
>
> On 6/21/07, Brett Porter <br...@apache.org> wrote:
> >
> > In addition to, or instead of?
> >
> > Sounds like a contradiction with Maven philosophy of being able to
> > use different versions for different applications (IIUC, the GAC
> > doesn't permit duplicates of an artifact with different versions).
> >
> > - Brett
> >
> > On 21/06/2007, at 3:55 PM, sisbell@apache.org wrote:
> >
> > > Author: sisbell
> > > Date: Wed Jun 20 22:55:03 2007
> > > New Revision: 549393
> > >
> > > URL: http://svn.apache.org/viewvc?view=rev&rev=549393
> > > Log:
> > > Copy of trunk. Branch deals with experimental work with using the
> > > GAC instead of the maven repo for storing artifacts.
> > >
> > > Added:
> > > incubator/nmaven/branches/SI_GAC/
> > > - copied from r549392, incubator/nmaven/trunk/
> >
>
Re: svn commit: r549393 - /incubator/nmaven/branches/SI_GAC/
Posted by Evan Worley <ev...@gmail.com>.
Brett,
I believe the GAC does allow multiple versions of the same artifact,
http://en.wikipedia.org/wiki/Global_Assembly_Cache#Side-by-side_versioning
-Evan
On 6/21/07, Brett Porter <br...@apache.org> wrote:
>
> In addition to, or instead of?
>
> Sounds like a contradiction with Maven philosophy of being able to
> use different versions for different applications (IIUC, the GAC
> doesn't permit duplicates of an artifact with different versions).
>
> - Brett
>
> On 21/06/2007, at 3:55 PM, sisbell@apache.org wrote:
>
> > Author: sisbell
> > Date: Wed Jun 20 22:55:03 2007
> > New Revision: 549393
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=549393
> > Log:
> > Copy of trunk. Branch deals with experimental work with using the
> > GAC instead of the maven repo for storing artifacts.
> >
> > Added:
> > incubator/nmaven/branches/SI_GAC/
> > - copied from r549392, incubator/nmaven/trunk/
>