[
http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91763
]
Christophe Lallement edited comment on NMAVEN-19 at 5/2/07 9:14 AM:
--------------------------------------------------------------------
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
=> if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
was:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
* if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
> Dependency resolution and Maven integration (site, deploy)
> ----------------------------------------------------------
>
> Key: NMAVEN-19
> URL: http://jira.codehaus.org/browse/NMAVEN-19
> Project: NMaven
> Issue Type: Wish
> Reporter: Alexandre Garcia
> Attachments: components.patch
>
>
> First of all Shane, we really appreciate your effort.
> We tried to complement your packaging lifecycles in order to test site and
> deploy
> The Maven plugins site and deploy use the standard Maven artefact layout:
> ArtefactId-Version.dll
> We were able to use mvn site after renaming accordingly installed artefacts
> in the local repo ($reports is not expanded though).
> We rebuilt NMaven after altering
> NMaven\plugins\maven-compile-plugin\src\main\resources\META-INF\plexus\components.xml
> to include the deploy phase in the packaging lifecycles.
> The deploy phase is successful but is once again maven style.
> Unfortunately, the deployed artefacts cannot be downloaded because NMaven
> dependency resolution doesnot include the version suffix and hence doesnot
> find the artefact on the remote repo.
> More generally, i wish NMaven could adopt default Maven style artefact layout
> or a mixed mode for GAC dependencies.
> We attach the modified components.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
