You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Phil Housley <un...@gmail.com> on 2010/03/11 17:49:16 UTC
Custom multi module packaging/removing default lifecycle plugins
Hi,
I am (yet again) trying to subvert Maven with a custom plugin and
finding that the special cases in the core are causing problems. What
I'm aiming for is the ability to have a project which combines a
couple of modules as a single "release", and then deploys their
artifacts together, along with some metafiles. The modules also have
custom packaging types, and the deployment means a custom process over
some webservices.
The issue is that only pom package projects are allowed to have
modules, and the pom lifecycle includes the standard install and
deploy plugin, which will fail as there is no distributionManagement
section. Is it possible to either completely inhibit the plugins in
the pom lifecycle, or to create another packaging type which allows
multi-module?
Any thoughts much appreciated.
Thanks,
--
Phil Housley
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Custom multi module packaging/removing default lifecycle plugins
Posted by Wayne Fay <wa...@gmail.com>.
> Sounds like you need a custom archetype.
Sounds like a custom lifecycle might be in order:
http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-custom-lifecycle.html
http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Custom multi module packaging/removing default lifecycle plugins
Posted by Maven User <ma...@gmail.com>.
Sounds like you need a custom archetype.
It's worth the investment.
On Mar 15, 2010, at 8:38 AM, Phil Housley <un...@gmail.com>
wrote:
> On 15 March 2010 12:05, Ron Wheeler <rw...@artifact-software.com>
> wrote:
>> Phil Housley wrote:
>>>
>>> On 15 March 2010 06:46, Jörg Schaible <jo...@gmx.de> wr
>>> ote:
>>>
>>>>
>>>> Phil Housley wrote at Sonntag, 14. März 2010 22:41:
>>>>
>>>>
>>>>>
>>>>> On 11 March 2010 16:49, Phil Housley <un...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am (yet again) trying to subvert Maven with a custom plugin and
>>>>>> finding that the special cases in the core are causing
>>>>>> problems. What
>>>>>> I'm aiming for is the ability to have a project which combines a
>>>>>> couple of modules as a single "release", and then deploys their
>>>>>> artifacts together, along with some metafiles. The modules
>>>>>> also have
>>>>>> custom packaging types, and the deployment means a custom
>>>>>> process over
>>>>>> some webservices.
>>>>>>
>>>>>> The issue is that only pom package projects are allowed to have
>>>>>> modules, and the pom lifecycle includes the standard install and
>>>>>> deploy plugin, which will fail as there is no
>>>>>> distributionManagement
>>>>>> section. Is it possible to either completely inhibit the
>>>>>> plugins in
>>>>>> the pom lifecycle, or to create another packaging type which
>>>>>> allows
>>>>>> multi-module?
>>>>>>
>>>>>
>>>>> To partly answer my own question, it seems that the checks for
>>>>> multi
>>>>> module and parent allowed are coded as simply if
>>>>> ("pom".equals(project.getPackaging()), so it doesn't look like I
>>>>> can
>>>>> use another packaging type there. I'm still looking into a way
>>>>> to get
>>>>> the install and deploy plugins out of the pom lifecycle, but
>>>>> without
>>>>> too much hope. I guess I will have to resort to specifying a
>>>>> specific
>>>>> goal and ignoring the lifecycle altogether...
>>>>>
>>>>
>>>> Why do you want this deployment happening at the parent? Just
>>>> create
>>>> another
>>>> modules with your custom packaging and declare all the other
>>>> modules as
>>>> dependencies.
>>>>
>>>
>>> It's for convenience of the users mostly. Hopefully people will be
>>> able to create these projects from an archetype, and then run deploy
>>> from the root to push several modules together as a release.
>>> Using a
>>> separate meta module is extra work for the users, but is the plan
>>> I'm
>>> currently working at.
>>>
>>
>> It is still not clear as to how your situation is so radically
>> different
>> from any other team of developers.
>> What are you building that is so different from a normal application?
>
> Sorry, I really don't seem to be doing a great job of explaining
> things.
>
> The situation is that we have some custom packaging types, call them
> bundles, which we generate using Maven and a custom plugin/packaging
> type, and are basically tarballs with some special files, plus some
> attached artifacts, made in the normal way.
> Several of these bundles, plus some common meta files (release notes,
> etc) make up a release of a project, which should be deployed at once.
> Because each bundle individually isn't complete by itself, there is no
> particular sense in which it can be deployed, other than just pushing
> it into a Maven repo as a temporary holding place.
>
> The ideal situation would be to have all bundle projects inside
> another project, giving roughly
> /project/
> pom.xml (with custom <packaging>, and <modules>)
> bundle-1/
> /pom.xml (with bundle-x packaging)
> bundle-2/
> /pom.xml (with bundle-y packaging)
> src/releaseinfo/...
>
> Then "mvn deploy" at the root would do the packaging, merge any common
> stuff, and push the whole lot together to the release location.
>
> Unfortunately, only pom packaged projects can have modules, and
> running deploy on a pom project will always invoke the
> maven-deploy-plugin, which is not appropriate here.
>
> My next plan was to add a "meta" module, which would depend on the
> bundles in the reactor. On running "mvn custom-plugin:deploy"
> directly from the command line, the bundles would be packaged, and the
> meta project would be detected as meaning the deployment should be
> done using meta-data contained within it.
>
> That plan is awkward, as you can't run "maven deploy," but works -
> excepting some issues, mainly that you can't access the bundle
> artifacts unless you run "install" on them, which renames the files.
>
>>> The main problem is that if the modules are not in the reactor when
>>> "deploy" is run, I have to add an install phase to be able to pick
>>> them up (which doesn't make much sense for the custom packaging I'm
>>> using); while to get them into reactor, I would need to run "mvn
>>> deploy" from the root, which would invoke the standard deploy plugin
>>> on the root pom.
>>>
>>
>> In the higher level projects, you just need to declare your
>> dependencies and
>> maven will make sure that the right stuff is included automatically.
>> It is not clear what you are trying to include that is so odd that
>> the
>> standard Maven lifecycle will not assemble properly.
>> Maven out-of-the-box supports multiple developers building a multi-
>> module
>> application with all the essential housekeeping.
>
> An alternative to my above plan is to skip the project aggregation
> entirely, build and install the bundles separately, and then use a
> similar meta project with a real "deploy" phase, which is neater in
> some ways, but means you can't do a one step release. Now that I've
> found you have to run the install phase even in the same reactor, this
> is looking like less of a disadvantage, as some of the overhead would
> be required anyway.
>
>>> I'm thinking currently of a goal "custom-stuff:deploy" which can be
>>> invoked on the root, will force a "package" phase in each module,
>>> and
>>> then when invoked (automatically) on each module will ignore all
>>> those
>>> without some special packaging type. This adds a requirement for a
>>> new meta project with dependencies on the others, but that isn't too
>>> much overhead to my mind - will have to see how it goes down with
>>> others.
>>>
>>
>> Unless you have a really odd setup, you should be able to greatly
>> simplify
>> life for everyone without having to resort to odd-ball procedures.
>> Each library module gets built and deployed into your artifact
>> repository
>> (really need one if you are multiple developers) as SNAPSHOTS or
>> releases
>> and when you build an executable
>> its dependencies are picked up automatically and incorporated into
>> the build
>> of the executable.
>> This is the normal Maven way - nothing special needed.
>
> I appreciate that, but the "deploy" phase on the bundles shouldn't
> really be the standard push to maven repo, it should be a custom
> thing, and only done in the context of deploying several modules
> together as a project release. If there is no way to do this, I will
> drop the plan and do it a more conventional way, if one that maps that
> much more awkwardly to the specific situation. But maybe that can't
> be helped.
>
> Thanks for your time.
>
>> Ron
>>
>>> Thanks for your input.
>>>
>>>
>>>>
>>>> - Jörg
>>>>
>
>
> --
> Phil Housley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Custom multi module packaging/removing default lifecycle plugins
Posted by Phil Housley <un...@gmail.com>.
On 15 March 2010 12:05, Ron Wheeler <rw...@artifact-software.com> wrote:
> Phil Housley wrote:
>>
>> On 15 March 2010 06:46, Jörg Schaible <jo...@gmx.de> wrote:
>>
>>>
>>> Phil Housley wrote at Sonntag, 14. März 2010 22:41:
>>>
>>>
>>>>
>>>> On 11 March 2010 16:49, Phil Housley <un...@gmail.com> wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am (yet again) trying to subvert Maven with a custom plugin and
>>>>> finding that the special cases in the core are causing problems. What
>>>>> I'm aiming for is the ability to have a project which combines a
>>>>> couple of modules as a single "release", and then deploys their
>>>>> artifacts together, along with some metafiles. The modules also have
>>>>> custom packaging types, and the deployment means a custom process over
>>>>> some webservices.
>>>>>
>>>>> The issue is that only pom package projects are allowed to have
>>>>> modules, and the pom lifecycle includes the standard install and
>>>>> deploy plugin, which will fail as there is no distributionManagement
>>>>> section. Is it possible to either completely inhibit the plugins in
>>>>> the pom lifecycle, or to create another packaging type which allows
>>>>> multi-module?
>>>>>
>>>>
>>>> To partly answer my own question, it seems that the checks for multi
>>>> module and parent allowed are coded as simply if
>>>> ("pom".equals(project.getPackaging()), so it doesn't look like I can
>>>> use another packaging type there. I'm still looking into a way to get
>>>> the install and deploy plugins out of the pom lifecycle, but without
>>>> too much hope. I guess I will have to resort to specifying a specific
>>>> goal and ignoring the lifecycle altogether...
>>>>
>>>
>>> Why do you want this deployment happening at the parent? Just create
>>> another
>>> modules with your custom packaging and declare all the other modules as
>>> dependencies.
>>>
>>
>> It's for convenience of the users mostly. Hopefully people will be
>> able to create these projects from an archetype, and then run deploy
>> from the root to push several modules together as a release. Using a
>> separate meta module is extra work for the users, but is the plan I'm
>> currently working at.
>>
>
> It is still not clear as to how your situation is so radically different
> from any other team of developers.
> What are you building that is so different from a normal application?
Sorry, I really don't seem to be doing a great job of explaining things.
The situation is that we have some custom packaging types, call them
bundles, which we generate using Maven and a custom plugin/packaging
type, and are basically tarballs with some special files, plus some
attached artifacts, made in the normal way.
Several of these bundles, plus some common meta files (release notes,
etc) make up a release of a project, which should be deployed at once.
Because each bundle individually isn't complete by itself, there is no
particular sense in which it can be deployed, other than just pushing
it into a Maven repo as a temporary holding place.
The ideal situation would be to have all bundle projects inside
another project, giving roughly
/project/
pom.xml (with custom <packaging>, and <modules>)
bundle-1/
/pom.xml (with bundle-x packaging)
bundle-2/
/pom.xml (with bundle-y packaging)
src/releaseinfo/...
Then "mvn deploy" at the root would do the packaging, merge any common
stuff, and push the whole lot together to the release location.
Unfortunately, only pom packaged projects can have modules, and
running deploy on a pom project will always invoke the
maven-deploy-plugin, which is not appropriate here.
My next plan was to add a "meta" module, which would depend on the
bundles in the reactor. On running "mvn custom-plugin:deploy"
directly from the command line, the bundles would be packaged, and the
meta project would be detected as meaning the deployment should be
done using meta-data contained within it.
That plan is awkward, as you can't run "maven deploy," but works -
excepting some issues, mainly that you can't access the bundle
artifacts unless you run "install" on them, which renames the files.
>> The main problem is that if the modules are not in the reactor when
>> "deploy" is run, I have to add an install phase to be able to pick
>> them up (which doesn't make much sense for the custom packaging I'm
>> using); while to get them into reactor, I would need to run "mvn
>> deploy" from the root, which would invoke the standard deploy plugin
>> on the root pom.
>>
>
> In the higher level projects, you just need to declare your dependencies and
> maven will make sure that the right stuff is included automatically.
> It is not clear what you are trying to include that is so odd that the
> standard Maven lifecycle will not assemble properly.
> Maven out-of-the-box supports multiple developers building a multi-module
> application with all the essential housekeeping.
An alternative to my above plan is to skip the project aggregation
entirely, build and install the bundles separately, and then use a
similar meta project with a real "deploy" phase, which is neater in
some ways, but means you can't do a one step release. Now that I've
found you have to run the install phase even in the same reactor, this
is looking like less of a disadvantage, as some of the overhead would
be required anyway.
>> I'm thinking currently of a goal "custom-stuff:deploy" which can be
>> invoked on the root, will force a "package" phase in each module, and
>> then when invoked (automatically) on each module will ignore all those
>> without some special packaging type. This adds a requirement for a
>> new meta project with dependencies on the others, but that isn't too
>> much overhead to my mind - will have to see how it goes down with
>> others.
>>
>
> Unless you have a really odd setup, you should be able to greatly simplify
> life for everyone without having to resort to odd-ball procedures.
> Each library module gets built and deployed into your artifact repository
> (really need one if you are multiple developers) as SNAPSHOTS or releases
> and when you build an executable
> its dependencies are picked up automatically and incorporated into the build
> of the executable.
> This is the normal Maven way - nothing special needed.
I appreciate that, but the "deploy" phase on the bundles shouldn't
really be the standard push to maven repo, it should be a custom
thing, and only done in the context of deploying several modules
together as a project release. If there is no way to do this, I will
drop the plan and do it a more conventional way, if one that maps that
much more awkwardly to the specific situation. But maybe that can't
be helped.
Thanks for your time.
> Ron
>
>> Thanks for your input.
>>
>>
>>>
>>> - Jörg
>>>
--
Phil Housley
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Custom multi module packaging/removing default lifecycle plugins
Posted by Ron Wheeler <rw...@artifact-software.com>.
Phil Housley wrote:
> On 15 March 2010 06:46, Jörg Schaible <jo...@gmx.de> wrote:
>
>> Phil Housley wrote at Sonntag, 14. März 2010 22:41:
>>
>>
>>> On 11 March 2010 16:49, Phil Housley <un...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am (yet again) trying to subvert Maven with a custom plugin and
>>>> finding that the special cases in the core are causing problems. What
>>>> I'm aiming for is the ability to have a project which combines a
>>>> couple of modules as a single "release", and then deploys their
>>>> artifacts together, along with some metafiles. The modules also have
>>>> custom packaging types, and the deployment means a custom process over
>>>> some webservices.
>>>>
>>>> The issue is that only pom package projects are allowed to have
>>>> modules, and the pom lifecycle includes the standard install and
>>>> deploy plugin, which will fail as there is no distributionManagement
>>>> section. Is it possible to either completely inhibit the plugins in
>>>> the pom lifecycle, or to create another packaging type which allows
>>>> multi-module?
>>>>
>>> To partly answer my own question, it seems that the checks for multi
>>> module and parent allowed are coded as simply if
>>> ("pom".equals(project.getPackaging()), so it doesn't look like I can
>>> use another packaging type there. I'm still looking into a way to get
>>> the install and deploy plugins out of the pom lifecycle, but without
>>> too much hope. I guess I will have to resort to specifying a specific
>>> goal and ignoring the lifecycle altogether...
>>>
>> Why do you want this deployment happening at the parent? Just create another
>> modules with your custom packaging and declare all the other modules as
>> dependencies.
>>
>
> It's for convenience of the users mostly. Hopefully people will be
> able to create these projects from an archetype, and then run deploy
> from the root to push several modules together as a release. Using a
> separate meta module is extra work for the users, but is the plan I'm
> currently working at.
>
It is still not clear as to how your situation is so radically different
from any other team of developers.
What are you building that is so different from a normal application?
> The main problem is that if the modules are not in the reactor when
> "deploy" is run, I have to add an install phase to be able to pick
> them up (which doesn't make much sense for the custom packaging I'm
> using); while to get them into reactor, I would need to run "mvn
> deploy" from the root, which would invoke the standard deploy plugin
> on the root pom.
>
In the higher level projects, you just need to declare your dependencies
and maven will make sure that the right stuff is included automatically.
It is not clear what you are trying to include that is so odd that the
standard Maven lifecycle will not assemble properly.
Maven out-of-the-box supports multiple developers building a
multi-module application with all the essential housekeeping.
> I'm thinking currently of a goal "custom-stuff:deploy" which can be
> invoked on the root, will force a "package" phase in each module, and
> then when invoked (automatically) on each module will ignore all those
> without some special packaging type. This adds a requirement for a
> new meta project with dependencies on the others, but that isn't too
> much overhead to my mind - will have to see how it goes down with
> others.
>
>
Unless you have a really odd setup, you should be able to greatly
simplify life for everyone without having to resort to odd-ball procedures.
Each library module gets built and deployed into your artifact
repository (really need one if you are multiple developers) as SNAPSHOTS
or releases and when you build an executable
its dependencies are picked up automatically and incorporated into the
build of the executable.
This is the normal Maven way - nothing special needed.
Ron
> Thanks for your input.
>
>
>> - Jörg
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Custom multi module packaging/removing default lifecycle plugins
Posted by Phil Housley <un...@gmail.com>.
On 15 March 2010 06:46, Jörg Schaible <jo...@gmx.de> wrote:
> Phil Housley wrote at Sonntag, 14. März 2010 22:41:
>
>> On 11 March 2010 16:49, Phil Housley <un...@gmail.com> wrote:
>>> Hi,
>>>
>>> I am (yet again) trying to subvert Maven with a custom plugin and
>>> finding that the special cases in the core are causing problems. What
>>> I'm aiming for is the ability to have a project which combines a
>>> couple of modules as a single "release", and then deploys their
>>> artifacts together, along with some metafiles. The modules also have
>>> custom packaging types, and the deployment means a custom process over
>>> some webservices.
>>>
>>> The issue is that only pom package projects are allowed to have
>>> modules, and the pom lifecycle includes the standard install and
>>> deploy plugin, which will fail as there is no distributionManagement
>>> section. Is it possible to either completely inhibit the plugins in
>>> the pom lifecycle, or to create another packaging type which allows
>>> multi-module?
>>
>> To partly answer my own question, it seems that the checks for multi
>> module and parent allowed are coded as simply if
>> ("pom".equals(project.getPackaging()), so it doesn't look like I can
>> use another packaging type there. I'm still looking into a way to get
>> the install and deploy plugins out of the pom lifecycle, but without
>> too much hope. I guess I will have to resort to specifying a specific
>> goal and ignoring the lifecycle altogether...
>
> Why do you want this deployment happening at the parent? Just create another
> modules with your custom packaging and declare all the other modules as
> dependencies.
It's for convenience of the users mostly. Hopefully people will be
able to create these projects from an archetype, and then run deploy
from the root to push several modules together as a release. Using a
separate meta module is extra work for the users, but is the plan I'm
currently working at.
The main problem is that if the modules are not in the reactor when
"deploy" is run, I have to add an install phase to be able to pick
them up (which doesn't make much sense for the custom packaging I'm
using); while to get them into reactor, I would need to run "mvn
deploy" from the root, which would invoke the standard deploy plugin
on the root pom.
I'm thinking currently of a goal "custom-stuff:deploy" which can be
invoked on the root, will force a "package" phase in each module, and
then when invoked (automatically) on each module will ignore all those
without some special packaging type. This adds a requirement for a
new meta project with dependencies on the others, but that isn't too
much overhead to my mind - will have to see how it goes down with
others.
Thanks for your input.
> - Jörg
>
--
Phil Housley
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Custom multi module packaging/removing default lifecycle plugins
Posted by Jörg Schaible <jo...@gmx.de>.
Phil Housley wrote at Sonntag, 14. März 2010 22:41:
> On 11 March 2010 16:49, Phil Housley <un...@gmail.com> wrote:
>> Hi,
>>
>> I am (yet again) trying to subvert Maven with a custom plugin and
>> finding that the special cases in the core are causing problems. What
>> I'm aiming for is the ability to have a project which combines a
>> couple of modules as a single "release", and then deploys their
>> artifacts together, along with some metafiles. The modules also have
>> custom packaging types, and the deployment means a custom process over
>> some webservices.
>>
>> The issue is that only pom package projects are allowed to have
>> modules, and the pom lifecycle includes the standard install and
>> deploy plugin, which will fail as there is no distributionManagement
>> section. Is it possible to either completely inhibit the plugins in
>> the pom lifecycle, or to create another packaging type which allows
>> multi-module?
>
> To partly answer my own question, it seems that the checks for multi
> module and parent allowed are coded as simply if
> ("pom".equals(project.getPackaging()), so it doesn't look like I can
> use another packaging type there. I'm still looking into a way to get
> the install and deploy plugins out of the pom lifecycle, but without
> too much hope. I guess I will have to resort to specifying a specific
> goal and ignoring the lifecycle altogether...
Why do you want this deployment happening at the parent? Just create another
modules with your custom packaging and declare all the other modules as
dependencies.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Custom multi module packaging/removing default lifecycle plugins
Posted by Jason van Zyl <ja...@sonatype.com>.
What are you trying to do?
Just run the build up to the verify phase if you don't want to install or deploy --> mvn verify which will run all the lifecycle phases up to and including verify. Stops there and no install or deploy.
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
On Mar 14, 2010, at 5:41 PM, Phil Housley wrote:
> On 11 March 2010 16:49, Phil Housley <un...@gmail.com> wrote:
>> Hi,
>>
>> I am (yet again) trying to subvert Maven with a custom plugin and
>> finding that the special cases in the core are causing problems. What
>> I'm aiming for is the ability to have a project which combines a
>> couple of modules as a single "release", and then deploys their
>> artifacts together, along with some metafiles. The modules also have
>> custom packaging types, and the deployment means a custom process over
>> some webservices.
>>
>> The issue is that only pom package projects are allowed to have
>> modules, and the pom lifecycle includes the standard install and
>> deploy plugin, which will fail as there is no distributionManagement
>> section. Is it possible to either completely inhibit the plugins in
>> the pom lifecycle, or to create another packaging type which allows
>> multi-module?
>
> To partly answer my own question, it seems that the checks for multi
> module and parent allowed are coded as simply if
> ("pom".equals(project.getPackaging()), so it doesn't look like I can
> use another packaging type there. I'm still looking into a way to get
> the install and deploy plugins out of the pom lifecycle, but without
> too much hope. I guess I will have to resort to specifying a specific
> goal and ignoring the lifecycle altogether...
>
>> Any thoughts much appreciated.
>>
>> Thanks,
>>
>> --
>> Phil Housley
>>
>
> --
> Phil Housley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: Custom multi module packaging/removing default lifecycle plugins
Posted by Phil Housley <un...@gmail.com>.
On 11 March 2010 16:49, Phil Housley <un...@gmail.com> wrote:
> Hi,
>
> I am (yet again) trying to subvert Maven with a custom plugin and
> finding that the special cases in the core are causing problems. What
> I'm aiming for is the ability to have a project which combines a
> couple of modules as a single "release", and then deploys their
> artifacts together, along with some metafiles. The modules also have
> custom packaging types, and the deployment means a custom process over
> some webservices.
>
> The issue is that only pom package projects are allowed to have
> modules, and the pom lifecycle includes the standard install and
> deploy plugin, which will fail as there is no distributionManagement
> section. Is it possible to either completely inhibit the plugins in
> the pom lifecycle, or to create another packaging type which allows
> multi-module?
To partly answer my own question, it seems that the checks for multi
module and parent allowed are coded as simply if
("pom".equals(project.getPackaging()), so it doesn't look like I can
use another packaging type there. I'm still looking into a way to get
the install and deploy plugins out of the pom lifecycle, but without
too much hope. I guess I will have to resort to specifying a specific
goal and ignoring the lifecycle altogether...
> Any thoughts much appreciated.
>
> Thanks,
>
> --
> Phil Housley
>
--
Phil Housley
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org