An alternate lifecycle

["Gorham-Engard, Frank" <Fr...@cable.comcast.com>]

I see several other people are also doing projects that are similar to some of mine.
- They need to pull artifacts from the Maven repositories. They are referred to as 'dependencies, although, there is nothing in the project that is actually dependent on the those artifacts (for compile, test, execution, etc.).
- The files of the artifacts must actually be acquired, not just referenced. This means the use of one or more plugins bound to an arbitrary phase that occurs in the needed sequence.
- files need to be 'post-processed' in some way. Some files need to be removed, moved, signed, repackaged, etc.
- there is no source code to be compiled or tested.
- No Maven install or deploy is performed.
- The results of the project are transferred to some distribution or production location. We used to call this deploying or installing.

It occurs to me that perhaps, rather than trying to kludge these projects onto the 'default' lifecycle, we should define an alternate lifecycle that better fits this kind of project.

In general, I would characterize these projects as getting files from Maven and sending them somewhere else, rather than producing files to be put into Maven repositories. We need one lifecycle to put thing into Maven and another to get them out.

Would anyone like to help define and implement such a product?
What would we call the lifecycle? How does the 'export' lifecycle sound.
What phases would it need to have?
Would any default bindings be appropriate?
Would we use words other than package, install, deploy to avoid confusion with the default lifecycle phases?

Frank_Gorham-Engard@cable.comcast.com
      Software Development Infrastructure Specialist
        Process, Configuration, Tools, Automation, Distribution, Development, Analysis, Design, Architecture
      Comcast CVS, Radnor, PA; (610)535-4431      →

Re: An alternate lifecycle

[Justin Edelson <ju...@gmail.com>]

Frank-
It sounds to me like you're describing a new packaging type, not
necessarily a new lifecycle. What do you see below that isn't mappable
to a phase in the default lifecycle.

Justin

On 8/20/10 4:17 PM, Gorham-Engard, Frank wrote:
> I see several other people are also doing projects that are similar to some of mine.
> - They need to pull artifacts from the Maven repositories. They are referred to as 'dependencies, although, there is nothing in the project that is actually dependent on the those artifacts (for compile, test, execution, etc.).
> - The files of the artifacts must actually be acquired, not just referenced. This means the use of one or more plugins bound to an arbitrary phase that occurs in the needed sequence.
> - files need to be 'post-processed' in some way. Some files need to be removed, moved, signed, repackaged, etc.
> - there is no source code to be compiled or tested.
> - No Maven install or deploy is performed.
> - The results of the project are transferred to some distribution or production location. We used to call this deploying or installing.
> 
> It occurs to me that perhaps, rather than trying to kludge these projects onto the 'default' lifecycle, we should define an alternate lifecycle that better fits this kind of project.
> 
> In general, I would characterize these projects as getting files from Maven and sending them somewhere else, rather than producing files to be put into Maven repositories. We need one lifecycle to put thing into Maven and another to get them out.
> 
> Would anyone like to help define and implement such a product?
> What would we call the lifecycle? How does the 'export' lifecycle sound.
> What phases would it need to have?
> Would any default bindings be appropriate?
> Would we use words other than package, install, deploy to avoid confusion with the default lifecycle phases?
> 
> Frank_Gorham-Engard@cable.comcast.com
>       Software Development Infrastructure Specialist
>         Process, Configuration, Tools, Automation, Distribution, Development, Analysis, Design, Architecture
>       Comcast CVS, Radnor, PA; (610)535-4431      →


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org