Cargo

Generic solution for handling packaging-type conversion for Deployable

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 1.0.2
  • Fix Version/s: 1.5.0
  • Component/s: Maven2
  • Labels:
    None
  • Environment:
    n/a
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

The current solution that handles ejb, über war, and jboss types, is hard-coded. A better solution would be a generic way of handling project packaging <-> artifact type.

In Maven, type, packaging and extension are often the same but not always. Type
sources actually means classifier sources and extension jar for
example. Packaging maven-plugin actually means extension jar.

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. CARGO-710 The CARGO maven2 plugin's project type check creates a warning for JBoss' special types

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Anders Hammar added a comment -

One comment about why this is important. In Maven, the data in the pom is metadata. So, creating a custom packaging is good. So, someone having a special case of a war (for example), could create a custom packing for that. With the current solution in Cargo, that person would run into trouble when he/she wants to use Cargo, which is not good.

Show
Anders Hammar added a comment - One comment about why this is important. In Maven, the data in the pom is metadata. So, creating a custom packaging is good. So, someone having a special case of a war (for example), could create a custom packing for that. With the current solution in Cargo, that person would run into trouble when he/she wants to use Cargo, which is not good.
Hide
Permalink
Savas Ali Tokmen added a comment -

Anders, do you have any complexity and/or time estimation for this?

Show
Savas Ali Tokmen added a comment - Anders, do you have any complexity and/or time estimation for this?
Hide
Permalink
Savas Ali Tokmen added a comment -

BTW, I would like to say that I would love this issue to be resolved. For example, on Java EE servers that support OSGi bundles (JOnAS, GlassFish), we need to deploy our bundles as "jar" to CARGO. That's annoying.

Show
Savas Ali Tokmen added a comment - BTW, I would like to say that I would love this issue to be resolved. For example, on Java EE servers that support OSGi bundles (JOnAS, GlassFish), we need to deploy our bundles as "jar" to CARGO. That's annoying.
Hide
Permalink
Anders Hammar added a comment -

I have no estimate for this. I don't even know if it's possible or not, really.

Show
Anders Hammar added a comment - I have no estimate for this. I don't even know if it's possible or not, really.
Hide
Permalink
Tuomas Kiviaho added a comment -

I think this is at least partially solved by https://jira.codehaus.org/browse/CARGO-1097 if I understood the problem correctly. I am not sure if isTypeCompatible and computeExtension are event needed. There might be some tweaks around 'file' type that would break if I had removed the fallback procedure.

Show
Tuomas Kiviaho added a comment - I think this is at least partially solved by https://jira.codehaus.org/browse/CARGO-1097 if I understood the problem correctly. I am not sure if isTypeCompatible and computeExtension are event needed. There might be some tweaks around 'file' type that would break if I had removed the fallback procedure.
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Tuomas

Patch propositions are welcome

Cheers

Show
Savas Ali Tokmen added a comment - Hi Tuomas Patch propositions are welcome Cheers

People

  • Assignee:
    Unassigned
    Reporter:
    Anders Hammar
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: