[
http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215058#action_215058
]
Ondrej Zizka edited comment on MNG-4599 at 3/23/10 7:31 PM:
------------------------------------------------------------
*Paul*, the problem is that I don't want to do it at all, because it's
pointless and the ONLY REASON to do it is just to make Maven happy. These
artifact would never be used again. See above.
*Brett*,
I am 100 % sure that it would be misused. But is that a reason not to give the
users possibility? I can think of countless Maven features which can be
"misused" - e.g.
* using various archiving plugin to actually build WAR/EAR/...,
* using the Ant Plugin to do everything, setting test and source path to the
same directory to get the classes of the test to the result (another Maven flaw
complicating usage of JSFUnit),
* completely re-mapping the build phases to accomodate all steps that the
build process needs,
etc etc., I could continue but that's not what this issue is about.
My collegue already wrote a plugin which puts the .jar's on the classpath, but
it's a ad-hoc solution and does not work e.g. with WAR overlays.
Brett, Jason, before I move this discussion to the mailing list,
* could you please point me where should I look to add this feature?
* Is it possible to write it as a plugin, or does it need some changes Maven
core?
* Would it be similar to the jarPath (should I look at it first)?
Thanks.
was (Author: pekarna):
*Paul*, the problem is that I need to do it at all, because it's pointless
and the ONLY REASON to do it is just to make Maven happy. These artifact would
never be used again. See above.
*Brett*,
I am 100 % sure that it would be misused. But is that a reason not to give the
users possibility? I can think of countless Maven features which can be
"misused" - e.g.
* using various archiving plugin to actually build WAR/EAR/...,
* using the Ant Plugin to do everything, setting test and source path to the
same directory to get the classes of the test to the result (another Maven flaw
complicating usage of JSFUnit),
* completely re-mapping the build phases to accomodate all steps that the
build process needs,
etc etc., I could continue but that's not what this issue is about.
My collegue already wrote a plugin which puts the .jar's on the classpath, but
it's a ad-hoc solution and does not work e.g. with WAR overlays.
Brett, Jason, before I move this discussion to the mailing list,
* could you please point me where should I look to add this feature?
* Is it possible to write it as a plugin, or does it need some changes Maven
core?
* Would it be similar to the jarPath (should I look at it first)?
Thanks.
> Provide a way to create "virtual artifacts" out of plain .jar file.
> -------------------------------------------------------------------
>
> Key: MNG-4599
> URL: http://jira.codehaus.org/browse/MNG-4599
> Project: Maven 2 & 3
> Issue Type: Improvement
> Reporter: Ondrej Zizka
> Assignee: Brett Porter
>
> During the time I have been using Maven, I have come across numerous cases
> when I desperately needed to turn a simple .jar file into a dependency.
> Currently, this involves installing it properly to the repository first, and
> only then it can be used.
> I suggest to introduce some construct which would take a list of .jar files
> and turn them into dependencies in the sense they would be added to the
> classpaths, could be used for WAR overlays, etc. Of course, they would not
> have any transitional dependencies.
> <dependencyManagement>
> <jarPaths>
> <jarPath>../../releases/50GAAS/jboss-as/common/lib</jarPath>
> </jarPaths>
> ...
> </dependencyManagement>
> This would greately improve Maven's openness to non-mavenized world, and
> usability in cases when you really get a plain .jar/.war/.ear/... before
> every build cycle.
--
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
