Various design related questions

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Various design related questions

James Carpenter-2
Its fantastic to finally see real movement in the maven csharp
suppport.  I have been using a tweaked in-house version of the maven
csharp plugins found in the maven SVN for 6months or so.  (See JIRA
issues submitted by nawkboy at: http://jira.codehaus.org/browse/MPA)  In
looking over the nmaven codebase a few questions came up.  As I have not
yet tried to actually use the nmaven plugins, there may still be a
slight misunderstanding of what is going on.

With great respect for the effort expended in developing the nmaven
support, the questions/issues are:

Design Questions:
1) Although there are several tagged versions of nmaven in SVN, the
"getting started" instructions have the typical user build the plugins
on their own desktop.  I would expect released versions to be deployed
to ibiblio (or another public mvn2 repo).  Using a released version of a
standard maven plugin requires nothing more than registering the plugin
within a pom.  Why should the nmaven plugins be any different?  
(Potential exception for the .NET framework.)

2) Why did you remove support for transitive dependencies?
The nmaven site docs imply that nmaven intentionally removes support for
transitive dependencies.  Transitive dependencies are one of the best
features of mvn2.  From code inspection it appears you have solved the
issues of version numbers as part of the dll names within the maven
repo.  (http://jira.codehaus.org/browse/MNG-2369,
http://jira.codehaus.org/browse/MNG-2527)  With this problem gone,
non-public assemblies (unsigned) should be quite compatible with
transitive dependencies.  When resolving public dependencies it would of
course be necessary to fail the build when inconsistent versions of the
same library are discovered.

3) Does the nmaven resource plugin provide the same level of filter
support available in the standard maven resource plugin?  If not are
there plans to refactor the standard resource plugin so as to push the
relevant code into reusable utility classes which the nmaven resource
plugin can then leverage?

4) I currently provide the build artifacts of my C# code (built using
the tweaked maven csharp plugins found in the maven SVN) to another  
team which is not using maven.  To do this I have configured the
assembly plugin to create a zip file containing my top level dll as well
as all of its dependencies (explicit and transitive) along with a
configuration file or two.  Will the assembly plugin still work with the
new nmaven plugins?  If not is there an alternative available?  If an
alternative is needed and not available, do you have any thoughts on how
to best attack this problem?

5) How are you handling satellite assemblies?  From maven's standpoint
I'm sure one could treat them as attached artifacts, but the relevant
plugins must obviously be smart enough to work with them.

Design Recommendations:
1) The java builds derive much of their implicit behavior from the
master parent pom burried in one of the maven jars.  In working with the
tweaked in-house versioned maven csharp plugins found in the maven SVN I
soon ended up building a com.mycompany.csharp:maven-csharp-parent:X.X.X
pom.  My versioned maven-csharp-parent pom could then be used by a
typical csharp build to easily get all the necessary plugins.  This has
been so useful, I think the nmaven project should provide the same sort
of master parent with any versioned release of the nmaven plugins
deployed to ibiblio (or alt.).

Usage Questions:
1) I have several custom plugins which leverage code generators to
produce C# code and/or resource files.  Is there anything special I need
to do to include generated source in a build artifact?  My plugins
producing C# currently just use the MavenProject to add the additional
source directory.  My plugins producing resources simply drop the output
into special directories within the target directory. (See
http://jira.codehaus.org/browse/MNG-2487 for details on how I currently
handle resources.)

2) Although I have become proficient at developing maven plugins, I
still don't have a great grasp of how artifact resolution is
coordinated.  The artifact resolver itself is conceptually quite
straightforward.  My problem is getting clarity on the interaction of
the artifact resolver, MavenProject (which knows the transitive
dependencies, etc.), and other core interactions which occur beneath a
typical maven plugin.  A few sequence diagrams which detailed a typical
build would be very helpful in this regard, as would a few paragraphs
providing an architectural overview of the topic.  I noticed the nmaven  
plugins/components provide a custom repository layout, but didn't really
understand it or how it would be used.  (I am painfully aware of the
requirement to enhance the repository layout to properly support .NET
artifacts, just not sure where all the proper hooks are.)  Can anyone
provide some clarity here?  (Say a wiki page?)

Thank you for your time and effort in reviewing and answering these
questions.

Sincerely,
James Carpenter
jcarpenter621 Remove Spaces yahoo.com
james.le.carpenter Remove Spaces jpmorgan.com

P.S.: I'm having trouble subscribing to the mailing list.  Please copy
me on replies, and/or try to fix the subscription problem.
I would like to subscribe using [hidden email] so that I
can easily filter and/or deal with spam issues that may arise.







Reply | Threaded
Open this post in threaded view
|

Re: Various design related questions

Shane Isbell
Comments inline.

On 1/4/07, James Carpenter <[hidden email]> wrote:

> Its fantastic to finally see real movement in the maven csharp
> suppport.  I have been using a tweaked in-house version of the maven
> csharp plugins found in the maven SVN for 6months or so.  (See JIRA
> issues submitted by nawkboy at: http://jira.codehaus.org/browse/MPA)  In
> looking over the nmaven codebase a few questions came up.  As I have not
> yet tried to actually use the nmaven plugins, there may still be a
> slight misunderstanding of what is going on.
>
> With great respect for the effort expended in developing the nmaven
> support, the questions/issues are:
>
> Design Questions:
> 1) Although there are several tagged versions of nmaven in SVN, the
> "getting started" instructions have the typical user build the plugins
> on their own desktop.  I would expect released versions to be deployed
> to ibiblio (or another public mvn2 repo).  Using a released version of a
> standard maven plugin requires nothing more than registering the plugin
> within a pom.  Why should the nmaven plugins be any different?
> (Potential exception for the .NET framework.)
>
Its not the intention for end developers to do the NMaven build.
Support on a public repo is the single biggest request that I get.
Brett how would we do that for incubator projects?

> 2) Why did you remove support for transitive dependencies?
> The nmaven site docs imply that nmaven intentionally removes support for
> transitive dependencies.  Transitive dependencies are one of the best
> features of mvn2.  From code inspection it appears you have solved the
> issues of version numbers as part of the dll names within the maven
> repo.  (http://jira.codehaus.org/browse/MNG-2369,
> http://jira.codehaus.org/browse/MNG-2527)  With this problem gone,
> non-public assemblies (unsigned) should be quite compatible with
> transitive dependencies.  When resolving public dependencies it would of
> course be necessary to fail the build when inconsistent versions of the
> same library are discovered.

NMaven does support transitive dependencies, with the exception of
satellite assemblies. The satellite assemblies are not transitive,
otherwise they would be linked into all assemblies within the
dependency chain.

> 3) Does the nmaven resource plugin provide the same level of filter
> support available in the standard maven resource plugin?  If not are
> there plans to refactor the standard resource plugin so as to push the
> relevant code into reusable utility classes which the nmaven resource
> plugin can then leverage?

This is supported. Referring you to the previous site at sourceforge
http://sourceforge.net/tracker/index.php?func=detail&aid=1589706&group_id=176362&atid=876936


> 4) I currently provide the build artifacts of my C# code (built using
> the tweaked maven csharp plugins found in the maven SVN) to another
> team which is not using maven.  To do this I have configured the
> assembly plugin to create a zip file containing my top level dll as well
> as all of its dependencies (explicit and transitive) along with a
> configuration file or two.  Will the assembly plugin still work with the
> new nmaven plugins?  If not is there an alternative available?  If an
> alternative is needed and not available, do you have any thoughts on how
> to best attack this problem?

You could specify the packaging as type "nar" (or net archive) within
the pom. This will pull in all of the assembly dependencies and place
it within ./target/<assembly-name>.nar. This is a zip a file. For an
example, see it0005 under the integration-tests.

> 5) How are you handling satellite assemblies?  From maven's standpoint
> I'm sure one could treat them as attached artifacts, but the relevant
> plugins must obviously be smart enough to work with them.

This is handled. Just specify the direct dependency within the pom and
it will link it at compile time. If NMaven sees a direct dependency of
type of "module" it will include it as a dependency, otherwise NMaven
just ignores it. See integration-test it0002 for an example.

> Design Recommendations:
> 1) The java builds derive much of their implicit behavior from the
> master parent pom burried in one of the maven jars.  In working with the
> tweaked in-house versioned maven csharp plugins found in the maven SVN I
> soon ended up building a com.mycompany.csharp:maven-csharp-parent:X.X.X
> pom.  My versioned maven-csharp-parent pom could then be used by a
> typical csharp build to easily get all the necessary plugins.  This has
> been so useful, I think the nmaven project should provide the same sort
> of master parent with any versioned release of the nmaven plugins
> deployed to ibiblio (or alt.).
>
> Usage Questions:
> 1) I have several custom plugins which leverage code generators to
> produce C# code and/or resource files.  Is there anything special I need
> to do to include generated source in a build artifact?  My plugins
> producing C# currently just use the MavenProject to add the additional
> source directory.  My plugins producing resources simply drop the output
> into special directories within the target directory. (See
> http://jira.codehaus.org/browse/MNG-2487 for details on how I currently
> handle resources.)

NMaven copies everything from the sourceDirectory to the
./target/build-sources directory. You just need to put your
autogenerated code the build-sources directory and NMaven will pick it
up and compile it.


> 2) Although I have become proficient at developing maven plugins, I
> still don't have a great grasp of how artifact resolution is
> coordinated.  The artifact resolver itself is conceptually quite
> straightforward.  My problem is getting clarity on the interaction of
> the artifact resolver, MavenProject (which knows the transitive
> dependencies, etc.), and other core interactions which occur beneath a
> typical maven plugin.  A few sequence diagrams which detailed a typical
> build would be very helpful in this regard, as would a few paragraphs
> providing an architectural overview of the topic.  I noticed the nmaven
> plugins/components provide a custom repository layout, but didn't really
> understand it or how it would be used.  (I am painfully aware of the
> requirement to enhance the repository layout to properly support .NET
> artifacts, just not sure where all the proper hooks are.)  Can anyone
> provide some clarity here?  (Say a wiki page?)

I'll work on this once the wiki is up. In the mean time, you will get
a good idea how resolving works by looking at
org.apache.maven.dotnet.artifact.impl.AssemblyResolverImpl. The
implementation instance of AssemblyResolver invokes
org.apache.maven.artifact.resolver.ArtifactResolver#resolveTransitively,
feeding in as a parameter an instance of the AssemblyRepositoryLayout.
The AssemblyRepositoryLayout just tells the standard Maven
ArtifactResolver not to use a version in the assembly name.

> Thank you for your time and effort in reviewing and answering these
> questions.
>
> Sincerely,
> James Carpenter
> jcarpenter621 Remove Spaces yahoo.com
> james.le.carpenter Remove Spaces jpmorgan.com
>
> P.S.: I'm having trouble subscribing to the mailing list.  Please copy
> me on replies, and/or try to fix the subscription problem.
> I would like to subscribe using [hidden email] so that I
> can easily filter and/or deal with spam issues that may arise.
>
>
>
>
>
>
>
>

Regards,
Shane
Reply | Threaded
Open this post in threaded view
|

Re: Various design related questions

James Carpenter-2
Shane Isbell wrote:
Additional code generation questions inline.

> Comments inline.
>
> On 1/4/07, James Carpenter <[hidden email]> wrote:
>> Its fantastic to finally see real movement in the maven csharp
>> suppport.  I have been using a tweaked in-house version of the maven
>> csharp plugins found in the maven SVN for 6months or so.  (See JIRA
>> issues submitted by nawkboy at: http://jira.codehaus.org/browse/MPA)  In
>> looking over the nmaven codebase a few questions came up.  As I have not
>> yet tried to actually use the nmaven plugins, there may still be a
>> slight misunderstanding of what is going on.
>>
>> With great respect for the effort expended in developing the nmaven
>> support, the questions/issues are:
>>
>> Design Questions:
>> 1) Although there are several tagged versions of nmaven in SVN, the
>> "getting started" instructions have the typical user build the plugins
>> on their own desktop.  I would expect released versions to be deployed
>> to ibiblio (or another public mvn2 repo).  Using a released version of a
>> standard maven plugin requires nothing more than registering the plugin
>> within a pom.  Why should the nmaven plugins be any different?
>> (Potential exception for the .NET framework.)
>>
> Its not the intention for end developers to do the NMaven build.
> Support on a public repo is the single biggest request that I get.
> Brett how would we do that for incubator projects?
>
>> 2) Why did you remove support for transitive dependencies?
>> The nmaven site docs imply that nmaven intentionally removes support for
>> transitive dependencies.  Transitive dependencies are one of the best
>> features of mvn2.  From code inspection it appears you have solved the
>> issues of version numbers as part of the dll names within the maven
>> repo.  (http://jira.codehaus.org/browse/MNG-2369,
>> http://jira.codehaus.org/browse/MNG-2527)  With this problem gone,
>> non-public assemblies (unsigned) should be quite compatible with
>> transitive dependencies.  When resolving public dependencies it would of
>> course be necessary to fail the build when inconsistent versions of the
>> same library are discovered.
>
> NMaven does support transitive dependencies, with the exception of
> satellite assemblies. The satellite assemblies are not transitive,
> otherwise they would be linked into all assemblies within the
> dependency chain.
>
>> 3) Does the nmaven resource plugin provide the same level of filter
>> support available in the standard maven resource plugin?  If not are
>> there plans to refactor the standard resource plugin so as to push the
>> relevant code into reusable utility classes which the nmaven resource
>> plugin can then leverage?
>
> This is supported. Referring you to the previous site at sourceforge
> http://sourceforge.net/tracker/index.php?func=detail&aid=1589706&group_id=176362&atid=876936 
>
>
>
>> 4) I currently provide the build artifacts of my C# code (built using
>> the tweaked maven csharp plugins found in the maven SVN) to another
>> team which is not using maven.  To do this I have configured the
>> assembly plugin to create a zip file containing my top level dll as well
>> as all of its dependencies (explicit and transitive) along with a
>> configuration file or two.  Will the assembly plugin still work with the
>> new nmaven plugins?  If not is there an alternative available?  If an
>> alternative is needed and not available, do you have any thoughts on how
>> to best attack this problem?
>
> You could specify the packaging as type "nar" (or net archive) within
> the pom. This will pull in all of the assembly dependencies and place
> it within ./target/<assembly-name>.nar. This is a zip a file. For an
> example, see it0005 under the integration-tests.
>
>> 5) How are you handling satellite assemblies?  From maven's standpoint
>> I'm sure one could treat them as attached artifacts, but the relevant
>> plugins must obviously be smart enough to work with them.
>
> This is handled. Just specify the direct dependency within the pom and
> it will link it at compile time. If NMaven sees a direct dependency of
> type of "module" it will include it as a dependency, otherwise NMaven
> just ignores it. See integration-test it0002 for an example.
>
>> Design Recommendations:
>> 1) The java builds derive much of their implicit behavior from the
>> master parent pom burried in one of the maven jars.  In working with the
>> tweaked in-house versioned maven csharp plugins found in the maven SVN I
>> soon ended up building a com.mycompany.csharp:maven-csharp-parent:X.X.X
>> pom.  My versioned maven-csharp-parent pom could then be used by a
>> typical csharp build to easily get all the necessary plugins.  This has
>> been so useful, I think the nmaven project should provide the same sort
>> of master parent with any versioned release of the nmaven plugins
>> deployed to ibiblio (or alt.).
>>
>> Usage Questions:
>> 1) I have several custom plugins which leverage code generators to
>> produce C# code and/or resource files.  Is there anything special I need
>> to do to include generated source in a build artifact?  My plugins
>> producing C# currently just use the MavenProject to add the additional
>> source directory.  My plugins producing resources simply drop the output
>> into special directories within the target directory. (See
>> http://jira.codehaus.org/browse/MNG-2487 for details on how I currently
>> handle resources.)
>
> NMaven copies everything from the sourceDirectory to the
> ./target/build-sources directory. You just need to put your
> autogenerated code the build-sources directory and NMaven will pick it
> up and compile it.
 >How about generated resources, where should they be placed? I need to
build a plugin which generates a set of multi-lingual .NET resources
from a Java resource bundle.

All of my code/resource generation so far is done as follows:
1) Create a C# module which produces an exe (type:exe as I recall).  The
arguments to the main method within the build artifact
(somecodegen-X.X.X.exe) provide the necessary context for the code
generator.  The code within the code generator has no knowledge of maven.
2) Create a Java based maven-plugin which does the following:
    a) Uses the artifact resolver to download somecodegen-X.X.X.exe into
a target subdirectory along with any dependencies.
    b) Uses the artifact resolver to download any input artifacts.  For
example in one case a plugin's usage identifies a library containing
interfaces with custom attributes the code generator will be looking
for.  The identified library is resolved and placed into a target
subdirectory.
    c) Uses the plexus command line util to execute
../target/myplugin/workdir/somecodegen-X.X.X.exe passing in any
necessary arguments.

As you can see any C# based code generator is accompanied by a custom
specialized Java based maven plugin.

Does NMaven incorporate/demonstrate a better approach for java/.NET
plugin integration?

>
>> 2) Although I have become proficient at developing maven plugins, I
>> still don't have a great grasp of how artifact resolution is
>> coordinated.  The artifact resolver itself is conceptually quite
>> straightforward.  My problem is getting clarity on the interaction of
>> the artifact resolver, MavenProject (which knows the transitive
>> dependencies, etc.), and other core interactions which occur beneath a
>> typical maven plugin.  A few sequence diagrams which detailed a typical
>> build would be very helpful in this regard, as would a few paragraphs
>> providing an architectural overview of the topic.  I noticed the nmaven
>> plugins/components provide a custom repository layout, but didn't really
>> understand it or how it would be used.  (I am painfully aware of the
>> requirement to enhance the repository layout to properly support .NET
>> artifacts, just not sure where all the proper hooks are.)  Can anyone
>> provide some clarity here?  (Say a wiki page?)
>
> I'll work on this once the wiki is up. In the mean time, you will get
> a good idea how resolving works by looking at
> org.apache.maven.dotnet.artifact.impl.AssemblyResolverImpl. The
> implementation instance of AssemblyResolver invokes
> org.apache.maven.artifact.resolver.ArtifactResolver#resolveTransitively,
> feeding in as a parameter an instance of the AssemblyRepositoryLayout.
> The AssemblyRepositoryLayout just tells the standard Maven
> ArtifactResolver not to use a version in the assembly name.
>
>> Thank you for your time and effort in reviewing and answering these
>> questions.
>>
>> Sincerely,
>> James Carpenter
>> jcarpenter621 Remove Spaces yahoo.com
>> james.le.carpenter Remove Spaces jpmorgan.com
>>
>> P.S.: I'm having trouble subscribing to the mailing list.  Please copy
>> me on replies, and/or try to fix the subscription problem.
>> I would like to subscribe using [hidden email] so that I
>> can easily filter and/or deal with spam issues that may arise.
>>
>>
>>
>>
>>
>>
>>
>>
>
> Regards,
> Shane
>

Reply | Threaded
Open this post in threaded view
|

Re: Various design related questions

Shane Isbell
Hi James,

As a plugin developer with NMaven, you would first create your .NET
project for your executable, say module N. You would then create your
maven plugin module, making sure to include within the pom the .NET
executable (module N) as a dependency. Let's call the plugin module
module P. Your parent pom, would then include modules N and P and
that's it. So in short, there a single "mvn install" command would
compile both .NET and Java. So this is definitely improved over the
way that you outlined where you have to build and deploy your .NET
artifacts without the assistance of a Maven .NET build system. NMaven
also allows you to deploy the entire build to third-parties without
going through some manual steps.

NMaven also handles resolving an application.exe.config associated
with the executable. You just need to include the config file within
the src/main/config directory. Maven will then generate a exe.config
dependency within the installed pom file so that this config is always
associated and resolved with the executable.  You can look at
nmaven-utility-resx to see an example.

As a side note, NMaven uses a bootstrap process that needs a special
net-dependencies.xml file because the .NET executable artifacts do not
exist. After the NMaven artifacts are generated, the Maven plugin
developer does not need to deal with the net-dependencies file but
rather directly uses the pom file for .NET dependencies.

Regards,
Shane

On 1/4/07, James Carpenter <[hidden email]> wrote:

> Shane Isbell wrote:
> Additional code generation questions inline.
> > Comments inline.
> >
> > On 1/4/07, James Carpenter <[hidden email]> wrote:
> >> Its fantastic to finally see real movement in the maven csharp
> >> suppport.  I have been using a tweaked in-house version of the maven
> >> csharp plugins found in the maven SVN for 6months or so.  (See JIRA
> >> issues submitted by nawkboy at: http://jira.codehaus.org/browse/MPA)  In
> >> looking over the nmaven codebase a few questions came up.  As I have not
> >> yet tried to actually use the nmaven plugins, there may still be a
> >> slight misunderstanding of what is going on.
> >>
> >> With great respect for the effort expended in developing the nmaven
> >> support, the questions/issues are:
> >>
> >> Design Questions:
> >> 1) Although there are several tagged versions of nmaven in SVN, the
> >> "getting started" instructions have the typical user build the plugins
> >> on their own desktop.  I would expect released versions to be deployed
> >> to ibiblio (or another public mvn2 repo).  Using a released version of a
> >> standard maven plugin requires nothing more than registering the plugin
> >> within a pom.  Why should the nmaven plugins be any different?
> >> (Potential exception for the .NET framework.)
> >>
> > Its not the intention for end developers to do the NMaven build.
> > Support on a public repo is the single biggest request that I get.
> > Brett how would we do that for incubator projects?
> >
> >> 2) Why did you remove support for transitive dependencies?
> >> The nmaven site docs imply that nmaven intentionally removes support for
> >> transitive dependencies.  Transitive dependencies are one of the best
> >> features of mvn2.  From code inspection it appears you have solved the
> >> issues of version numbers as part of the dll names within the maven
> >> repo.  (http://jira.codehaus.org/browse/MNG-2369,
> >> http://jira.codehaus.org/browse/MNG-2527)  With this problem gone,
> >> non-public assemblies (unsigned) should be quite compatible with
> >> transitive dependencies.  When resolving public dependencies it would of
> >> course be necessary to fail the build when inconsistent versions of the
> >> same library are discovered.
> >
> > NMaven does support transitive dependencies, with the exception of
> > satellite assemblies. The satellite assemblies are not transitive,
> > otherwise they would be linked into all assemblies within the
> > dependency chain.
> >
> >> 3) Does the nmaven resource plugin provide the same level of filter
> >> support available in the standard maven resource plugin?  If not are
> >> there plans to refactor the standard resource plugin so as to push the
> >> relevant code into reusable utility classes which the nmaven resource
> >> plugin can then leverage?
> >
> > This is supported. Referring you to the previous site at sourceforge
> > http://sourceforge.net/tracker/index.php?func=detail&aid=1589706&group_id=176362&atid=876936
> >
> >
> >
> >> 4) I currently provide the build artifacts of my C# code (built using
> >> the tweaked maven csharp plugins found in the maven SVN) to another
> >> team which is not using maven.  To do this I have configured the
> >> assembly plugin to create a zip file containing my top level dll as well
> >> as all of its dependencies (explicit and transitive) along with a
> >> configuration file or two.  Will the assembly plugin still work with the
> >> new nmaven plugins?  If not is there an alternative available?  If an
> >> alternative is needed and not available, do you have any thoughts on how
> >> to best attack this problem?
> >
> > You could specify the packaging as type "nar" (or net archive) within
> > the pom. This will pull in all of the assembly dependencies and place
> > it within ./target/<assembly-name>.nar. This is a zip a file. For an
> > example, see it0005 under the integration-tests.
> >
> >> 5) How are you handling satellite assemblies?  From maven's standpoint
> >> I'm sure one could treat them as attached artifacts, but the relevant
> >> plugins must obviously be smart enough to work with them.
> >
> > This is handled. Just specify the direct dependency within the pom and
> > it will link it at compile time. If NMaven sees a direct dependency of
> > type of "module" it will include it as a dependency, otherwise NMaven
> > just ignores it. See integration-test it0002 for an example.
> >
> >> Design Recommendations:
> >> 1) The java builds derive much of their implicit behavior from the
> >> master parent pom burried in one of the maven jars.  In working with the
> >> tweaked in-house versioned maven csharp plugins found in the maven SVN I
> >> soon ended up building a com.mycompany.csharp:maven-csharp-parent:X.X.X
> >> pom.  My versioned maven-csharp-parent pom could then be used by a
> >> typical csharp build to easily get all the necessary plugins.  This has
> >> been so useful, I think the nmaven project should provide the same sort
> >> of master parent with any versioned release of the nmaven plugins
> >> deployed to ibiblio (or alt.).
> >>
> >> Usage Questions:
> >> 1) I have several custom plugins which leverage code generators to
> >> produce C# code and/or resource files.  Is there anything special I need
> >> to do to include generated source in a build artifact?  My plugins
> >> producing C# currently just use the MavenProject to add the additional
> >> source directory.  My plugins producing resources simply drop the output
> >> into special directories within the target directory. (See
> >> http://jira.codehaus.org/browse/MNG-2487 for details on how I currently
> >> handle resources.)
> >
> > NMaven copies everything from the sourceDirectory to the
> > ./target/build-sources directory. You just need to put your
> > autogenerated code the build-sources directory and NMaven will pick it
> > up and compile it.
>  >How about generated resources, where should they be placed? I need to
> build a plugin which generates a set of multi-lingual .NET resources
> from a Java resource bundle.
>
> All of my code/resource generation so far is done as follows:
> 1) Create a C# module which produces an exe (type:exe as I recall).  The
> arguments to the main method within the build artifact
> (somecodegen-X.X.X.exe) provide the necessary context for the code
> generator.  The code within the code generator has no knowledge of maven.
> 2) Create a Java based maven-plugin which does the following:
>    a) Uses the artifact resolver to download somecodegen-X.X.X.exe into
> a target subdirectory along with any dependencies.
>    b) Uses the artifact resolver to download any input artifacts.  For
> example in one case a plugin's usage identifies a library containing
> interfaces with custom attributes the code generator will be looking
> for.  The identified library is resolved and placed into a target
> subdirectory.
>    c) Uses the plexus command line util to execute
> ../target/myplugin/workdir/somecodegen-X.X.X.exe passing in any
> necessary arguments.
>
> As you can see any C# based code generator is accompanied by a custom
> specialized Java based maven plugin.
>
> Does NMaven incorporate/demonstrate a better approach for java/.NET
> plugin integration?
> >
> >> 2) Although I have become proficient at developing maven plugins, I
> >> still don't have a great grasp of how artifact resolution is
> >> coordinated.  The artifact resolver itself is conceptually quite
> >> straightforward.  My problem is getting clarity on the interaction of
> >> the artifact resolver, MavenProject (which knows the transitive
> >> dependencies, etc.), and other core interactions which occur beneath a
> >> typical maven plugin.  A few sequence diagrams which detailed a typical
> >> build would be very helpful in this regard, as would a few paragraphs
> >> providing an architectural overview of the topic.  I noticed the nmaven
> >> plugins/components provide a custom repository layout, but didn't really
> >> understand it or how it would be used.  (I am painfully aware of the
> >> requirement to enhance the repository layout to properly support .NET
> >> artifacts, just not sure where all the proper hooks are.)  Can anyone
> >> provide some clarity here?  (Say a wiki page?)
> >
> > I'll work on this once the wiki is up. In the mean time, you will get
> > a good idea how resolving works by looking at
> > org.apache.maven.dotnet.artifact.impl.AssemblyResolverImpl. The
> > implementation instance of AssemblyResolver invokes
> > org.apache.maven.artifact.resolver.ArtifactResolver#resolveTransitively,
> > feeding in as a parameter an instance of the AssemblyRepositoryLayout.
> > The AssemblyRepositoryLayout just tells the standard Maven
> > ArtifactResolver not to use a version in the assembly name.
> >
> >> Thank you for your time and effort in reviewing and answering these
> >> questions.
> >>
> >> Sincerely,
> >> James Carpenter
> >> jcarpenter621 Remove Spaces yahoo.com
> >> james.le.carpenter Remove Spaces jpmorgan.com
> >>
> >> P.S.: I'm having trouble subscribing to the mailing list.  Please copy
> >> me on replies, and/or try to fix the subscription problem.
> >> I would like to subscribe using [hidden email] so that I
> >> can easily filter and/or deal with spam issues that may arise.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > Regards,
> > Shane
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Various design related questions

Shane Isbell
Hi James,

I just ran a quick test for the behavior outlined below and it failed:
I need to amend my previous e-mail. Since I removed the need for
version info (with the AssemblyRepositoryLayout), the behavior below
is no longer supported: the resolver defaults to Maven's which
requires the version in the artifact name.

Let me look into the best way of fixing this. In the mean time, you
can look in maven-core resources directory at the net-dependencies.xml
file. If you add your custom exe to this config file, NMaven will
resolve it for you and you won't need to include the version within
the artifact name.

Shane

On 1/4/07, Shane Isbell <[hidden email]> wrote:

> Hi James,
>
> As a plugin developer with NMaven, you would first create your .NET
> project for your executable, say module N. You would then create your
> maven plugin module, making sure to include within the pom the .NET
> executable (module N) as a dependency. Let's call the plugin module
> module P. Your parent pom, would then include modules N and P and
> that's it. So in short, there a single "mvn install" command would
> compile both .NET and Java. So this is definitely improved over the
> way that you outlined where you have to build and deploy your .NET
> artifacts without the assistance of a Maven .NET build system. NMaven
> also allows you to deploy the entire build to third-parties without
> going through some manual steps.
>
> NMaven also handles resolving an application.exe.config associated
> with the executable. You just need to include the config file within
> the src/main/config directory. Maven will then generate a exe.config
> dependency within the installed pom file so that this config is always
> associated and resolved with the executable.  You can look at
> nmaven-utility-resx to see an example.
>
> As a side note, NMaven uses a bootstrap process that needs a special
> net-dependencies.xml file because the .NET executable artifacts do not
> exist. After the NMaven artifacts are generated, the Maven plugin
> developer does not need to deal with the net-dependencies file but
> rather directly uses the pom file for .NET dependencies.
>
> Regards,
> Shane
>
> On 1/4/07, James Carpenter <[hidden email]> wrote:
> > Shane Isbell wrote:
> > Additional code generation questions inline.
> > > Comments inline.
> > >
> > > On 1/4/07, James Carpenter <[hidden email]> wrote:
> > >> Its fantastic to finally see real movement in the maven csharp
> > >> suppport.  I have been using a tweaked in-house version of the maven
> > >> csharp plugins found in the maven SVN for 6months or so.  (See JIRA
> > >> issues submitted by nawkboy at: http://jira.codehaus.org/browse/MPA)  In
> > >> looking over the nmaven codebase a few questions came up.  As I have not
> > >> yet tried to actually use the nmaven plugins, there may still be a
> > >> slight misunderstanding of what is going on.
> > >>
> > >> With great respect for the effort expended in developing the nmaven
> > >> support, the questions/issues are:
> > >>
> > >> Design Questions:
> > >> 1) Although there are several tagged versions of nmaven in SVN, the
> > >> "getting started" instructions have the typical user build the plugins
> > >> on their own desktop.  I would expect released versions to be deployed
> > >> to ibiblio (or another public mvn2 repo).  Using a released version of a
> > >> standard maven plugin requires nothing more than registering the plugin
> > >> within a pom.  Why should the nmaven plugins be any different?
> > >> (Potential exception for the .NET framework.)
> > >>
> > > Its not the intention for end developers to do the NMaven build.
> > > Support on a public repo is the single biggest request that I get.
> > > Brett how would we do that for incubator projects?
> > >
> > >> 2) Why did you remove support for transitive dependencies?
> > >> The nmaven site docs imply that nmaven intentionally removes support for
> > >> transitive dependencies.  Transitive dependencies are one of the best
> > >> features of mvn2.  From code inspection it appears you have solved the
> > >> issues of version numbers as part of the dll names within the maven
> > >> repo.  (http://jira.codehaus.org/browse/MNG-2369,
> > >> http://jira.codehaus.org/browse/MNG-2527)  With this problem gone,
> > >> non-public assemblies (unsigned) should be quite compatible with
> > >> transitive dependencies.  When resolving public dependencies it would of
> > >> course be necessary to fail the build when inconsistent versions of the
> > >> same library are discovered.
> > >
> > > NMaven does support transitive dependencies, with the exception of
> > > satellite assemblies. The satellite assemblies are not transitive,
> > > otherwise they would be linked into all assemblies within the
> > > dependency chain.
> > >
> > >> 3) Does the nmaven resource plugin provide the same level of filter
> > >> support available in the standard maven resource plugin?  If not are
> > >> there plans to refactor the standard resource plugin so as to push the
> > >> relevant code into reusable utility classes which the nmaven resource
> > >> plugin can then leverage?
> > >
> > > This is supported. Referring you to the previous site at sourceforge
> > > http://sourceforge.net/tracker/index.php?func=detail&aid=1589706&group_id=176362&atid=876936
> > >
> > >
> > >
> > >> 4) I currently provide the build artifacts of my C# code (built using
> > >> the tweaked maven csharp plugins found in the maven SVN) to another
> > >> team which is not using maven.  To do this I have configured the
> > >> assembly plugin to create a zip file containing my top level dll as well
> > >> as all of its dependencies (explicit and transitive) along with a
> > >> configuration file or two.  Will the assembly plugin still work with the
> > >> new nmaven plugins?  If not is there an alternative available?  If an
> > >> alternative is needed and not available, do you have any thoughts on how
> > >> to best attack this problem?
> > >
> > > You could specify the packaging as type "nar" (or net archive) within
> > > the pom. This will pull in all of the assembly dependencies and place
> > > it within ./target/<assembly-name>.nar. This is a zip a file. For an
> > > example, see it0005 under the integration-tests.
> > >
> > >> 5) How are you handling satellite assemblies?  From maven's standpoint
> > >> I'm sure one could treat them as attached artifacts, but the relevant
> > >> plugins must obviously be smart enough to work with them.
> > >
> > > This is handled. Just specify the direct dependency within the pom and
> > > it will link it at compile time. If NMaven sees a direct dependency of
> > > type of "module" it will include it as a dependency, otherwise NMaven
> > > just ignores it. See integration-test it0002 for an example.
> > >
> > >> Design Recommendations:
> > >> 1) The java builds derive much of their implicit behavior from the
> > >> master parent pom burried in one of the maven jars.  In working with the
> > >> tweaked in-house versioned maven csharp plugins found in the maven SVN I
> > >> soon ended up building a com.mycompany.csharp:maven-csharp-parent:X.X.X
> > >> pom.  My versioned maven-csharp-parent pom could then be used by a
> > >> typical csharp build to easily get all the necessary plugins.  This has
> > >> been so useful, I think the nmaven project should provide the same sort
> > >> of master parent with any versioned release of the nmaven plugins
> > >> deployed to ibiblio (or alt.).
> > >>
> > >> Usage Questions:
> > >> 1) I have several custom plugins which leverage code generators to
> > >> produce C# code and/or resource files.  Is there anything special I need
> > >> to do to include generated source in a build artifact?  My plugins
> > >> producing C# currently just use the MavenProject to add the additional
> > >> source directory.  My plugins producing resources simply drop the output
> > >> into special directories within the target directory. (See
> > >> http://jira.codehaus.org/browse/MNG-2487 for details on how I currently
> > >> handle resources.)
> > >
> > > NMaven copies everything from the sourceDirectory to the
> > > ./target/build-sources directory. You just need to put your
> > > autogenerated code the build-sources directory and NMaven will pick it
> > > up and compile it.
> >  >How about generated resources, where should they be placed? I need to
> > build a plugin which generates a set of multi-lingual .NET resources
> > from a Java resource bundle.
> >
> > All of my code/resource generation so far is done as follows:
> > 1) Create a C# module which produces an exe (type:exe as I recall).  The
> > arguments to the main method within the build artifact
> > (somecodegen-X.X.X.exe) provide the necessary context for the code
> > generator.  The code within the code generator has no knowledge of maven.
> > 2) Create a Java based maven-plugin which does the following:
> >    a) Uses the artifact resolver to download somecodegen-X.X.X.exe into
> > a target subdirectory along with any dependencies.
> >    b) Uses the artifact resolver to download any input artifacts.  For
> > example in one case a plugin's usage identifies a library containing
> > interfaces with custom attributes the code generator will be looking
> > for.  The identified library is resolved and placed into a target
> > subdirectory.
> >    c) Uses the plexus command line util to execute
> > ../target/myplugin/workdir/somecodegen-X.X.X.exe passing in any
> > necessary arguments.
> >
> > As you can see any C# based code generator is accompanied by a custom
> > specialized Java based maven plugin.
> >
> > Does NMaven incorporate/demonstrate a better approach for java/.NET
> > plugin integration?
> > >
> > >> 2) Although I have become proficient at developing maven plugins, I
> > >> still don't have a great grasp of how artifact resolution is
> > >> coordinated.  The artifact resolver itself is conceptually quite
> > >> straightforward.  My problem is getting clarity on the interaction of
> > >> the artifact resolver, MavenProject (which knows the transitive
> > >> dependencies, etc.), and other core interactions which occur beneath a
> > >> typical maven plugin.  A few sequence diagrams which detailed a typical
> > >> build would be very helpful in this regard, as would a few paragraphs
> > >> providing an architectural overview of the topic.  I noticed the nmaven
> > >> plugins/components provide a custom repository layout, but didn't really
> > >> understand it or how it would be used.  (I am painfully aware of the
> > >> requirement to enhance the repository layout to properly support .NET
> > >> artifacts, just not sure where all the proper hooks are.)  Can anyone
> > >> provide some clarity here?  (Say a wiki page?)
> > >
> > > I'll work on this once the wiki is up. In the mean time, you will get
> > > a good idea how resolving works by looking at
> > > org.apache.maven.dotnet.artifact.impl.AssemblyResolverImpl. The
> > > implementation instance of AssemblyResolver invokes
> > > org.apache.maven.artifact.resolver.ArtifactResolver#resolveTransitively,
> > > feeding in as a parameter an instance of the AssemblyRepositoryLayout.
> > > The AssemblyRepositoryLayout just tells the standard Maven
> > > ArtifactResolver not to use a version in the assembly name.
> > >
> > >> Thank you for your time and effort in reviewing and answering these
> > >> questions.
> > >>
> > >> Sincerely,
> > >> James Carpenter
> > >> jcarpenter621 Remove Spaces yahoo.com
> > >> james.le.carpenter Remove Spaces jpmorgan.com
> > >>
> > >> P.S.: I'm having trouble subscribing to the mailing list.  Please copy
> > >> me on replies, and/or try to fix the subscription problem.
> > >> I would like to subscribe using [hidden email] so that I
> > >> can easily filter and/or deal with spam issues that may arise.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > > Regards,
> > > Shane
> > >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Various design related questions

James Carpenter-2
 >Thanks for looking into this.

Shane Isbell wrote:

> Hi James,
>
> I just ran a quick test for the behavior outlined below and it failed:
> I need to amend my previous e-mail. Since I removed the need for
> version info (with the AssemblyRepositoryLayout), the behavior below
> is no longer supported: the resolver defaults to Maven's which
> requires the version in the artifact name.
>
> Let me look into the best way of fixing this. In the mean time, you
> can look in maven-core resources directory at the net-dependencies.xml
> file. If you add your custom exe to this config file, NMaven will
> resolve it for you and you won't need to include the version within
> the artifact name.
>
> Shane
>
> On 1/4/07, Shane Isbell <[hidden email]> wrote:
>> Hi James,
>>
>> As a plugin developer with NMaven, you would first create your .NET
>> project for your executable, say module N. You would then create your
>> maven plugin module, making sure to include within the pom the .NET
>> executable (module N) as a dependency. Let's call the plugin module
>> module P. Your parent pom, would then include modules N and P and
>> that's it. So in short, there a single "mvn install" command would
>> compile both .NET and Java. So this is definitely improved over the
>> way that you outlined where you have to build and deploy your .NET
>> artifacts without the assistance of a Maven .NET build system. NMaven
>> also allows you to deploy the entire build to third-parties without
>> going through some manual steps.
>>
>> NMaven also handles resolving an application.exe.config associated
>> with the executable. You just need to include the config file within
>> the src/main/config directory. Maven will then generate a exe.config
>> dependency within the installed pom file so that this config is always
>> associated and resolved with the executable.  You can look at
>> nmaven-utility-resx to see an example.
>>
>> As a side note, NMaven uses a bootstrap process that needs a special
>> net-dependencies.xml file because the .NET executable artifacts do not
>> exist. After the NMaven artifacts are generated, the Maven plugin
>> developer does not need to deal with the net-dependencies file but
>> rather directly uses the pom file for .NET dependencies.
>>
>> Regards,
>> Shane
>>
>> On 1/4/07, James Carpenter <[hidden email]> wrote:
>> > Shane Isbell wrote:
>> > Additional code generation questions inline.
>> > > Comments inline.
>> > >
>> > > On 1/4/07, James Carpenter <[hidden email]> wrote:
>> > >> Its fantastic to finally see real movement in the maven csharp
>> > >> suppport.  I have been using a tweaked in-house version of the
>> maven
>> > >> csharp plugins found in the maven SVN for 6months or so.  (See JIRA
>> > >> issues submitted by nawkboy at:
>> http://jira.codehaus.org/browse/MPA)  In
>> > >> looking over the nmaven codebase a few questions came up.  As I
>> have not
>> > >> yet tried to actually use the nmaven plugins, there may still be a
>> > >> slight misunderstanding of what is going on.
>> > >>
>> > >> With great respect for the effort expended in developing the nmaven
>> > >> support, the questions/issues are:
>> > >>
>> > >> Design Questions:
>> > >> 1) Although there are several tagged versions of nmaven in SVN, the
>> > >> "getting started" instructions have the typical user build the
>> plugins
>> > >> on their own desktop.  I would expect released versions to be
>> deployed
>> > >> to ibiblio (or another public mvn2 repo).  Using a released
>> version of a
>> > >> standard maven plugin requires nothing more than registering the
>> plugin
>> > >> within a pom.  Why should the nmaven plugins be any different?
>> > >> (Potential exception for the .NET framework.)
>> > >>
>> > > Its not the intention for end developers to do the NMaven build.
>> > > Support on a public repo is the single biggest request that I get.
>> > > Brett how would we do that for incubator projects?
>> > >
>> > >> 2) Why did you remove support for transitive dependencies?
>> > >> The nmaven site docs imply that nmaven intentionally removes
>> support for
>> > >> transitive dependencies.  Transitive dependencies are one of the
>> best
>> > >> features of mvn2.  From code inspection it appears you have
>> solved the
>> > >> issues of version numbers as part of the dll names within the maven
>> > >> repo.  (http://jira.codehaus.org/browse/MNG-2369,
>> > >> http://jira.codehaus.org/browse/MNG-2527)  With this problem gone,
>> > >> non-public assemblies (unsigned) should be quite compatible with
>> > >> transitive dependencies.  When resolving public dependencies it
>> would of
>> > >> course be necessary to fail the build when inconsistent versions
>> of the
>> > >> same library are discovered.
>> > >
>> > > NMaven does support transitive dependencies, with the exception of
>> > > satellite assemblies. The satellite assemblies are not transitive,
>> > > otherwise they would be linked into all assemblies within the
>> > > dependency chain.
>> > >
>> > >> 3) Does the nmaven resource plugin provide the same level of filter
>> > >> support available in the standard maven resource plugin?  If not
>> are
>> > >> there plans to refactor the standard resource plugin so as to
>> push the
>> > >> relevant code into reusable utility classes which the nmaven
>> resource
>> > >> plugin can then leverage?
>> > >
>> > > This is supported. Referring you to the previous site at sourceforge
>> > >
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1589706&group_id=176362&atid=876936 
>>
>> > >
>> > >
>> > >
>> > >> 4) I currently provide the build artifacts of my C# code (built
>> using
>> > >> the tweaked maven csharp plugins found in the maven SVN) to another
>> > >> team which is not using maven.  To do this I have configured the
>> > >> assembly plugin to create a zip file containing my top level dll
>> as well
>> > >> as all of its dependencies (explicit and transitive) along with a
>> > >> configuration file or two.  Will the assembly plugin still work
>> with the
>> > >> new nmaven plugins?  If not is there an alternative available?  
>> If an
>> > >> alternative is needed and not available, do you have any
>> thoughts on how
>> > >> to best attack this problem?
>> > >
>> > > You could specify the packaging as type "nar" (or net archive)
>> within
>> > > the pom. This will pull in all of the assembly dependencies and
>> place
>> > > it within ./target/<assembly-name>.nar. This is a zip a file. For an
>> > > example, see it0005 under the integration-tests.
>> > >
>> > >> 5) How are you handling satellite assemblies?  From maven's
>> standpoint
>> > >> I'm sure one could treat them as attached artifacts, but the
>> relevant
>> > >> plugins must obviously be smart enough to work with them.
>> > >
>> > > This is handled. Just specify the direct dependency within the
>> pom and
>> > > it will link it at compile time. If NMaven sees a direct
>> dependency of
>> > > type of "module" it will include it as a dependency, otherwise
>> NMaven
>> > > just ignores it. See integration-test it0002 for an example.
>> > >
>> > >> Design Recommendations:
>> > >> 1) The java builds derive much of their implicit behavior from the
>> > >> master parent pom burried in one of the maven jars.  In working
>> with the
>> > >> tweaked in-house versioned maven csharp plugins found in the
>> maven SVN I
>> > >> soon ended up building a
>> com.mycompany.csharp:maven-csharp-parent:X.X.X
>> > >> pom.  My versioned maven-csharp-parent pom could then be used by a
>> > >> typical csharp build to easily get all the necessary plugins.  
>> This has
>> > >> been so useful, I think the nmaven project should provide the
>> same sort
>> > >> of master parent with any versioned release of the nmaven plugins
>> > >> deployed to ibiblio (or alt.).
>> > >>
>> > >> Usage Questions:
>> > >> 1) I have several custom plugins which leverage code generators to
>> > >> produce C# code and/or resource files.  Is there anything
>> special I need
>> > >> to do to include generated source in a build artifact?  My plugins
>> > >> producing C# currently just use the MavenProject to add the
>> additional
>> > >> source directory.  My plugins producing resources simply drop
>> the output
>> > >> into special directories within the target directory. (See
>> > >> http://jira.codehaus.org/browse/MNG-2487 for details on how I
>> currently
>> > >> handle resources.)
>> > >
>> > > NMaven copies everything from the sourceDirectory to the
>> > > ./target/build-sources directory. You just need to put your
>> > > autogenerated code the build-sources directory and NMaven will
>> pick it
>> > > up and compile it.
>> >  >How about generated resources, where should they be placed? I
>> need to
>> > build a plugin which generates a set of multi-lingual .NET resources
>> > from a Java resource bundle.
>> >
>> > All of my code/resource generation so far is done as follows:
>> > 1) Create a C# module which produces an exe (type:exe as I
>> recall).  The
>> > arguments to the main method within the build artifact
>> > (somecodegen-X.X.X.exe) provide the necessary context for the code
>> > generator.  The code within the code generator has no knowledge of
>> maven.
>> > 2) Create a Java based maven-plugin which does the following:
>> >    a) Uses the artifact resolver to download somecodegen-X.X.X.exe
>> into
>> > a target subdirectory along with any dependencies.
>> >    b) Uses the artifact resolver to download any input artifacts.  For
>> > example in one case a plugin's usage identifies a library containing
>> > interfaces with custom attributes the code generator will be looking
>> > for.  The identified library is resolved and placed into a target
>> > subdirectory.
>> >    c) Uses the plexus command line util to execute
>> > ../target/myplugin/workdir/somecodegen-X.X.X.exe passing in any
>> > necessary arguments.
>> >
>> > As you can see any C# based code generator is accompanied by a custom
>> > specialized Java based maven plugin.
>> >
>> > Does NMaven incorporate/demonstrate a better approach for java/.NET
>> > plugin integration?
>> > >
>> > >> 2) Although I have become proficient at developing maven plugins, I
>> > >> still don't have a great grasp of how artifact resolution is
>> > >> coordinated.  The artifact resolver itself is conceptually quite
>> > >> straightforward.  My problem is getting clarity on the
>> interaction of
>> > >> the artifact resolver, MavenProject (which knows the transitive
>> > >> dependencies, etc.), and other core interactions which occur
>> beneath a
>> > >> typical maven plugin.  A few sequence diagrams which detailed a
>> typical
>> > >> build would be very helpful in this regard, as would a few
>> paragraphs
>> > >> providing an architectural overview of the topic.  I noticed the
>> nmaven
>> > >> plugins/components provide a custom repository layout, but
>> didn't really
>> > >> understand it or how it would be used.  (I am painfully aware of
>> the
>> > >> requirement to enhance the repository layout to properly support
>> .NET
>> > >> artifacts, just not sure where all the proper hooks are.)  Can
>> anyone
>> > >> provide some clarity here?  (Say a wiki page?)
>> > >
>> > > I'll work on this once the wiki is up. In the mean time, you will
>> get
>> > > a good idea how resolving works by looking at
>> > > org.apache.maven.dotnet.artifact.impl.AssemblyResolverImpl. The
>> > > implementation instance of AssemblyResolver invokes
>> > >
>> org.apache.maven.artifact.resolver.ArtifactResolver#resolveTransitively,
>> > > feeding in as a parameter an instance of the
>> AssemblyRepositoryLayout.
>> > > The AssemblyRepositoryLayout just tells the standard Maven
>> > > ArtifactResolver not to use a version in the assembly name.
>> > >
>> > >> Thank you for your time and effort in reviewing and answering these
>> > >> questions.
>> > >>
>> > >> Sincerely,
>> > >> James Carpenter
>> > >> jcarpenter621 Remove Spaces yahoo.com
>> > >> james.le.carpenter Remove Spaces jpmorgan.com
>> > >>
>> > >> P.S.: I'm having trouble subscribing to the mailing list.  
>> Please copy
>> > >> me on replies, and/or try to fix the subscription problem.
>> > >> I would like to subscribe using [hidden email] so
>> that I
>> > >> can easily filter and/or deal with spam issues that may arise.
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > > Regards,
>> > > Shane
>> > >
>> >
>> >
>>
>