You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Alexandre Garcia (JIRA)" <ji...@codehaus.org> on 2007/03/16 11:10:33 UTC
[jira] Created: (NMAVEN-19) Dependency resolution and Maven
integration (site, deploy)
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
[jira] Issue Comment Edited: (NMAVEN-19) Dependency resolution and
Maven integration (site, deploy)
Posted by "Christophe Lallement (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Issue Comment Edited: (NMAVEN-19) Dependency resolution and
Maven integration (site, deploy)
Posted by "Christophe Lallement (JIRA)" <ji...@codehaus.org>.
[ 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:15 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
[jira] Issue Comment Edited: (NMAVEN-19) Dependency resolution and
Maven integration (site, deploy)
Posted by "Christophe Lallement (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (NMAVEN-19) Dependency resolution and Maven
integration (site, deploy)
Posted by "Shane Isbell (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90268 ]
Shane Isbell commented on NMAVEN-19:
------------------------------------
Alexandre, just to clarify the request: do you just need the site and deploy functionality to work (say with the existing ArtifactId.dll format) or do you also need support for the ArtifactId-Version.dll convention itself?
> 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
[jira] Closed: (NMAVEN-19) Dependency resolution and Maven
integration (site, deploy)
Posted by "Shane Isbell (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shane Isbell closed NMAVEN-19.
------------------------------
Resolution: Fixed
> 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
[jira] Commented: (NMAVEN-19) Dependency resolution and Maven
integration (site, deploy)
Posted by "Shane Isbell (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95394 ]
Shane Isbell commented on NMAVEN-19:
------------------------------------
A resolution issue for this has become critical so expect a merge of the fix into the trunk sometime around May 21st. The way it will work is that that the remote repo will contain the version info within the artifact file name; but upon resolution, NMaven will remove the version and place it into the local repo.
> 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
[jira] Commented: (NMAVEN-19) Dependency resolution and Maven
integration (site, deploy)
Posted by "Alexandre Garcia (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90578 ]
Alexandre Garcia commented on NMAVEN-19:
----------------------------------------
Well, thinking about it, we prefer to keep consistent with the default .NET artefact convention you adopted (no version suffix).
It is the integration to standard Maven plugins that we lack: site, deploy, package.
As a workaround, we tried to apply a finalName to the build element without success.
> 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
[jira] Commented: (NMAVEN-19) Dependency resolution and Maven
integration (site, deploy)
Posted by "Shane Isbell (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95423 ]
Shane Isbell commented on NMAVEN-19:
------------------------------------
This issue is fixed in the SI_XPT branch.
> 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