Cargo

Allow a container distribution to be installed from a Maven artifact definition

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 0.2-maven2
  • Fix Version/s: 1.1.0
  • Component/s: Maven2
  • Labels:
    None
  • Complexity:
    Intermediate
  • Tested on JDKs:
    1.5.0
  • Number of attachments :
    1

Description

Attaching a patch that allows you to:

  • put/find a server as an artifact in a maven repository
  • use this artifact as the source for an Installer

Use configuration like this where you would normally specify a ZipUrlInstaller (you'll need to install the jboss artifact locally)

    <artifactInstaller>
      <groupId>jboss</groupId>
      <artifactId>jboss</artifactId>
      <version>4.0.4.GA</version>
      <type>tar.gz</type>
    </artifactInstaller>

Issue Links

is related to

Improvement - An improvement or enhancement to an existing feature or task. CARGO-436 Download Progress for zipUrlInstaller

  • Trivial - Cosmetic problem like misspelt words or misaligned text.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
supercedes

New Feature - A new feature of the product, which has yet to be developed. CARGO-312 Create a Maven2Installer implementation of Installer

  • 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
Frank Morawietz added a comment -

Is there a chance for this to make it into the official distribution?

I would also very much like to have it.

Show
Frank Morawietz added a comment - Is there a chance for this to make it into the official distribution? I would also very much like to have it.
Hide
Permalink
Robert Herschke added a comment -

Please provide the patch to the official distribution!!! See CARGO-312 also!

Show
Robert Herschke added a comment - Please provide the patch to the official distribution!!! See CARGO-312 also!
Hide
Permalink
Matt Wringe added a comment -

The patch is now long outdated and doesn't apply cleanly. I would be happy to apply a clean patch with a test case attached.

Do any servers actually provide a zip of the server in the maven repo?

Show
Matt Wringe added a comment - The patch is now long outdated and doesn't apply cleanly. I would be happy to apply a clean patch with a test case attached. Do any servers actually provide a zip of the server in the maven repo?
Hide
Permalink
Robert Herschke added a comment -

Hi Matt,

the question is not, if there is an AS-Provider but how is the IT-Infrastructure organized in a company.

Most often Developers and IT-Services contend a huge fight about IT ressources and so on. The need about servers (esp. webservers) are heavilly discussed and it is hard to win IT Services around and to get another server.

So, most often (in case we do maven build) a company already intruduced a Maven Repository or a Maven Repository Proxy. It is very easy to use the maven repository also for distributing installation archives of an application server by simply mvn install:install-file the zip. On the other hand it is hard to get a new or an additional intranet-"web"-server to do the job: Host the AS-Installation Zip.

Next, it is more common, that the architects modify the installation zip's for the needs of the project and not distribute the original instalation zip. Think about Datasources and Realms aso.... Not all AS (and their corresponding cargo container plugin) are ready to accept the cargo.container.datasource or cargo.container.resource properties!

Well... short meaning: For me a clear vote to apply the (well, updated (if so)) patch!

Show
Robert Herschke added a comment - Hi Matt, the question is not, if there is an AS-Provider but how is the IT-Infrastructure organized in a company. Most often Developers and IT-Services contend a huge fight about IT ressources and so on. The need about servers (esp. webservers) are heavilly discussed and it is hard to win IT Services around and to get another server. So, most often (in case we do maven build) a company already intruduced a Maven Repository or a Maven Repository Proxy. It is very easy to use the maven repository also for distributing installation archives of an application server by simply mvn install:install-file the zip. On the other hand it is hard to get a new or an additional intranet-"web"-server to do the job: Host the AS-Installation Zip. Next, it is more common, that the architects modify the installation zip's for the needs of the project and not distribute the original instalation zip. Think about Datasources and Realms aso.... Not all AS (and their corresponding cargo container plugin) are ready to accept the cargo.container.datasource or cargo.container.resource properties! Well... short meaning: For me a clear vote to apply the (well, updated (if so)) patch!
Hide
Permalink
Savas Ali Tokmen added a comment -

It could be interesting to have this for CARGO 1.1.0

Show
Savas Ali Tokmen added a comment - It could be interesting to have this for CARGO 1.1.0
Hide
Permalink
Anders Hammar added a comment -

One important thing regarding build management is reproducibility. Artifacts in a Maven repo are supposed to be immutable and shouldn't be removed. This should be well known by now. However, resources on some web server are very often moved/changed/deleted without the person doing this understanding the impact. Using a Maven repo as a resource would then ensure that the build working today will work tomorrow (or in a month, a year, ...).

Show
Anders Hammar added a comment - One important thing regarding build management is reproducibility. Artifacts in a Maven repo are supposed to be immutable and shouldn't be removed. This should be well known by now. However, resources on some web server are very often moved/changed/deleted without the person doing this understanding the impact. Using a Maven repo as a resource would then ensure that the build working today will work tomorrow (or in a month, a year, ...).
Hide
Permalink
Savas Ali Tokmen added a comment -

Well, today you can write the download URL. But yes, many servers tend to delete old download files (whereas Maven tends to keep all these)

Show
Savas Ali Tokmen added a comment - Well, today you can write the download URL. But yes, many servers tend to delete old download files (whereas Maven tends to keep all these)
Hide
Permalink
Savas Ali Tokmen added a comment - - edited

New versions of most application servers have their distribution packages built by Maven2, hence distribute these as ZIP or TAR.GZ files on a Maven2 repository. The CARGO ZipUrlInstaller can be used to reuse the Maven2 dependency.

Updated documentation on: http://cargo.codehaus.org/Installer#Installer-installerwithmaven2dependencies

Show
Savas Ali Tokmen added a comment - - edited New versions of most application servers have their distribution packages built by Maven2, hence distribute these as ZIP or TAR.GZ files on a Maven2 repository. The CARGO ZipUrlInstaller can be used to reuse the Maven2 dependency. Updated documentation on: http://cargo.codehaus.org/Installer#Installer-installerwithmaven2dependencies
Hide
Permalink
Savas Ali Tokmen added a comment -

... any progress on this?

Show
Savas Ali Tokmen added a comment - ... any progress on this?
Hide
Permalink
Anders Hammar added a comment -

No, but it would be very nice to get it implemented. I'll try to find some time to look at this for 1.1.0.

Show
Anders Hammar added a comment - No, but it would be very nice to get it implemented. I'll try to find some time to look at this for 1.1.0.
Hide
Permalink
Savas Ali Tokmen added a comment -

OK, great, thank you

Show
Savas Ali Tokmen added a comment - OK, great, thank you
Hide
Permalink
Savas Ali Tokmen added a comment -

... any news?

Show
Savas Ali Tokmen added a comment - ... any news?
Hide
Permalink
Anders Hammar added a comment -

Not really. But I'm starting to think that we should postpone this to 1.2.0 for example. I don't seem to get enough spare time to get started with this.

Show
Anders Hammar added a comment - Not really. But I'm starting to think that we should postpone this to 1.2.0 for example. I don't seem to get enough spare time to get started with this.
Hide
Permalink
Savas Ali Tokmen added a comment -

If you want I can give a try this Friday (probably morning and/or early afternoon)

Show
Savas Ali Tokmen added a comment - If you want I can give a try this Friday (probably morning and/or early afternoon)
Hide
Permalink
Anders Hammar added a comment - - edited

Sure, be my guest.
One thing I can't really make up my mind about is the pom configuration. One way is as suggested in the description. But, possibly a (test scope) dependency should be declared to the artifact in the pom and then the artifact reference doesn't need the version specified. The latter is a more Maven correct way I think.

Show
Anders Hammar added a comment - - edited Sure, be my guest. One thing I can't really make up my mind about is the pom configuration. One way is as suggested in the description. But, possibly a (test scope) dependency should be declared to the artifact in the pom and then the artifact reference doesn't need the version specified. The latter is a more Maven correct way I think.
Hide
Permalink
Savas Ali Tokmen added a comment -

Committed revision 2873.

Moreover, updated http://cargo.codehaus.org/Maven2+Plugin+Reference+Guide and http://cargo.codehaus.org/Installer

Show
Savas Ali Tokmen added a comment - Committed revision 2873. Moreover, updated http://cargo.codehaus.org/Maven2+Plugin+Reference+Guide and http://cargo.codehaus.org/Installer
Hide
Permalink
Anders Hammar added a comment -

Cool. We should probably update archetypes and maven samples to use this instead of the zipUrlInstaller where applicable (jetty and what else?).

Show
Anders Hammar added a comment - Cool. We should probably update archetypes and maven samples to use this instead of the zipUrlInstaller where applicable (jetty and what else?).
Hide
Permalink
Savas Ali Tokmen added a comment -

Good remark!!

Committed revision 2875.

With this, the Jetty container is not embedded anymore but a standalone container, and I've switched from jetty6 to jetty7 -as only Jetty 7 publishes its artifacts as Maven2 dependency.

Moreover, JOnAS assembly is also downloaded from m2 central.

Other containers stay as they were:

  • Tomcat is actually built using ANT
  • JBoss and GlassFish don't deploy their artifacts on central (yet)
Show
Savas Ali Tokmen added a comment - Good remark!! Committed revision 2875. With this, the Jetty container is not embedded anymore but a standalone container, and I've switched from jetty6 to jetty7 -as only Jetty 7 publishes its artifacts as Maven2 dependency. Moreover, JOnAS assembly is also downloaded from m2 central. Other containers stay as they were: Tomcat is actually built using ANT JBoss and GlassFish don't deploy their artifacts on central (yet)
Hide
Permalink
Anders Hammar added a comment -

Possibly I didn't think this through. Should we really switch the embedded Jetty? Using the embedded container has advantages. Will we not run into those port issues now when for the tests of the archetypes that made us not include the other containers?

Maybe we should include one profile for embedded Jetty (default) and one for installed Jetty container, in the archetypes?

Show
Anders Hammar added a comment - Possibly I didn't think this through. Should we really switch the embedded Jetty? Using the embedded container has advantages. Will we not run into those port issues now when for the tests of the archetypes that made us not include the other containers? Maybe we should include one profile for embedded Jetty (default) and one for installed Jetty container, in the archetypes?
Hide
Permalink
Savas Ali Tokmen added a comment -

Embedded Jetty uses as many ports as the standalone Jetty; the reason why doing automated integration tests is easier with Jetty is because Jetty uses only one port (HTTP).

We could include one profile for embedded Jetty, indeed; thought I personally believe the embedded Jetty on Maven2 will only make sense once we implement CARGO-571 (Ability to specify embedded Jetty version when calling it from maven plugin). Right now, the version of embedded Jetty is "locked" by Cargo. What do you think?

Show
Savas Ali Tokmen added a comment - Embedded Jetty uses as many ports as the standalone Jetty; the reason why doing automated integration tests is easier with Jetty is because Jetty uses only one port (HTTP). We could include one profile for embedded Jetty, indeed; thought I personally believe the embedded Jetty on Maven2 will only make sense once we implement CARGO-571 (Ability to specify embedded Jetty version when calling it from maven plugin). Right now, the version of embedded Jetty is "locked" by Cargo. What do you think?
Hide
Permalink
Anders Hammar added a comment -

I kind of think that if you use Cargo with your "integration tests" in the same Maven project as your code, you're most likely doing that to perform unit testing in a integration test shape. Most likely because it's too difficult to mock external dependencies. In that case I'm thinking that the exact Jetty version shouldn't matter that much as you're not verifying the final runtime environment. Here you could use embedded Jetty (or any container for that matter).
However, when you do serious integration tests, IMHO, you have a separate Maven project for that. In this case you want to ensure that you're using the exact right environment that you are going to go live with and then the version of Jetty matters. But then you wouldn't want to use an embedded version of Jetty, but a standalone installation as that's what you will be using in production. And also you want to ensure the correct version.

Applying this on our archetypes would mean that we should do differently in the single-module archetype from what we do in the functional-tests-module archetype, which might be confusion? Or maybe not if that's how we anticipate people's use of Cargo?

Show
Anders Hammar added a comment - I kind of think that if you use Cargo with your "integration tests" in the same Maven project as your code, you're most likely doing that to perform unit testing in a integration test shape. Most likely because it's too difficult to mock external dependencies. In that case I'm thinking that the exact Jetty version shouldn't matter that much as you're not verifying the final runtime environment. Here you could use embedded Jetty (or any container for that matter). However, when you do serious integration tests, IMHO, you have a separate Maven project for that. In this case you want to ensure that you're using the exact right environment that you are going to go live with and then the version of Jetty matters. But then you wouldn't want to use an embedded version of Jetty, but a standalone installation as that's what you will be using in production. And also you want to ensure the correct version. Applying this on our archetypes would mean that we should do differently in the single-module archetype from what we do in the functional-tests-module archetype, which might be confusion? Or maybe not if that's how we anticipate people's use of Cargo?
Hide
Permalink
Savas Ali Tokmen added a comment -

Well, I don't agree with this approach: the only container that can be run in an embedded fashion is Jetty, and an embedded container's many parts are "polluted" by Maven's initialization (XML parser, various settings, ...).

Moreover, if you want to run tests on any complete container (JBoss, GlassFish, ...) or want to use, say, Xmx settings; you will need to use a standalone container.

But, we could add a "jetty-embedded" profile; for people who really want to use an embedded container. But, frankly speaking, I see no real-life use cases for the embedded container in Maven2. And, if we add it, we should add it in both archetypes.

Show
Savas Ali Tokmen added a comment - Well, I don't agree with this approach: the only container that can be run in an embedded fashion is Jetty, and an embedded container's many parts are "polluted" by Maven's initialization (XML parser, various settings, ...). Moreover, if you want to run tests on any complete container (JBoss, GlassFish, ...) or want to use, say, Xmx settings; you will need to use a standalone container. But, we could add a "jetty-embedded" profile; for people who really want to use an embedded container. But, frankly speaking, I see no real-life use cases for the embedded container in Maven2. And, if we add it, we should add it in both archetypes.
Hide
Permalink
Savas Ali Tokmen added a comment -

... any comments?

Show
Savas Ali Tokmen added a comment - ... any comments?
Hide
Permalink
Anders Hammar added a comment -

Well, I'm not sure I agree with you. It all boils down to how the embedding is done. In many cases embedding is better as it gives you full control, but for integration tests one could argue that you normally would like to use a standalone installation as you would in production.

Maybe we should leave it as it is now (just standalone profiles). The only thing that troubles me is that the archetypes then don't show how to use embedded container. But maybe you're right - there is no real use case for that (at least for the Maven plugin).

Show
Anders Hammar added a comment - Well, I'm not sure I agree with you. It all boils down to how the embedding is done. In many cases embedding is better as it gives you full control, but for integration tests one could argue that you normally would like to use a standalone installation as you would in production. Maybe we should leave it as it is now (just standalone profiles). The only thing that troubles me is that the archetypes then don't show how to use embedded container. But maybe you're right - there is no real use case for that (at least for the Maven plugin).
Hide
Permalink
Savas Ali Tokmen added a comment -

I agree, not showing an embedded container is not good. Moreover, CARGO 1.0.6 had this jetty6x embedded profile.

Committed revision 2878.

Show
Savas Ali Tokmen added a comment - I agree, not showing an embedded container is not good. Moreover, CARGO 1.0.6 had this jetty6x embedded profile. Committed revision 2878.

People

  • Assignee:
    Savas Ali Tokmen
    Reporter:
    Tom Huybrechts
Vote (3)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: