jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2.x WAR Plugin
  • MWAR-256

it's not possible to create classes attachment without classifier

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.1.1
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

I would like to package classes in my war-packaged project into a jar, but I don't want to use default 'classes' classifier assigned by the plugin. The generated artifacts have distinct packaging types, so there is no conflict and the classifier provides no useful additional information. Using the following configuration:

<configuration>
<classesClassifier/>
</configuration>

Results in "classes" classifier being used anyway. If I understand the behavior correctly Plexus assigns the variable it's default value, when presented an empty input. I don't think this can be fixed in way that is both clean and backward compatible. Either the default value will change, which would break existing builds that don't specify plugin version explicitly, or some clunky additional parameter like <useClassesClassifier>false</useClassesClassifier>, or magic value like <classesClassifier>NONE</classesClassifier> need to be introduced.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Liya Katz added a comment - 30/Oct/11 1:29 PM

It's quite odd that the jar inside the war does not have any classifier, but if the same jar is chosen to be attached as an artifact to the project, it has to have a classifier. There must be some disabling option for this annoying "feature".

Show
Liya Katz added a comment - 30/Oct/11 1:29 PM It's quite odd that the jar inside the war does not have any classifier, but if the same jar is chosen to be attached as an artifact to the project, it has to have a classifier. There must be some disabling option for this annoying "feature".
Hide
Permalink
Dmitry Goldenberg added a comment - 06/Feb/12 9:21 AM

Totally agreed. Am dealing with this issue now and not sure how to work around it.

Show
Dmitry Goldenberg added a comment - 06/Feb/12 9:21 AM Totally agreed. Am dealing with this issue now and not sure how to work around it.
Hide
Permalink
Stéphane Nicoll added a comment - 07/Feb/12 2:04 AM

well the idea is that this jar is meant to be deployed. you must have a classifer and if you don't like the default one, just change it.

Or what bothers you is the fact that the jar in WEB-INF/lib is named something-classes.jar ?

Show
Stéphane Nicoll added a comment - 07/Feb/12 2:04 AM well the idea is that this jar is meant to be deployed. you must have a classifer and if you don't like the default one, just change it. Or what bothers you is the fact that the jar in WEB-INF/lib is named something-classes.jar ?
Hide
Permalink
Rafal Krzewski added a comment - 07/Feb/12 2:44 AM

It wouldn't bother me if the jar was only in WEB-INF/lib. In this case I wouldn't bother packaging it into a jar at all - WEB-INF/classes are also fine. It bothers me because it's all over my other module's dependencies.

In my particular case I have a module that provides some java classes and some web resources (Velocity templates, js, css). The web resources need to be merged into the application WAR, and I'm using overlays for this. Hence WAR packaging on the project. The classes need to be packaged in the application WEB-INF/lib but are also needed to compile other modules' java sources - say, my module provides some base classes that are extended elsewhere.

I could split the module into a jar and war parts, but the classes and web resources are tightly coupled it would be rather artificial. It would also add quite a few new modules to my project layout. Getting rid of a classifier in dependency spec in a dozen places does not warrant that. But I still would be able to change the classier - to be nothing

Show
Rafal Krzewski added a comment - 07/Feb/12 2:44 AM It wouldn't bother me if the jar was only in WEB-INF/lib. In this case I wouldn't bother packaging it into a jar at all - WEB-INF/classes are also fine. It bothers me because it's all over my other module's dependencies. In my particular case I have a module that provides some java classes and some web resources (Velocity templates, js, css). The web resources need to be merged into the application WAR, and I'm using overlays for this. Hence WAR packaging on the project. The classes need to be packaged in the application WEB-INF/lib but are also needed to compile other modules' java sources - say, my module provides some base classes that are extended elsewhere. I could split the module into a jar and war parts, but the classes and web resources are tightly coupled it would be rather artificial. It would also add quite a few new modules to my project layout. Getting rid of a classifier in dependency spec in a dozen places does not warrant that. But I still would be able to change the classier - to be nothing

People

  • Assignee:
    Unassigned
    Reporter:
    Rafal Krzewski
Vote (2)
Watch (3)

Dates

  • Created:
    05/Jul/11 9:22 AM
    Updated:
    07/Feb/12 2:44 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.