POM additions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

POM additions

brettporter
Administrator
Hi,

I'd like to propose the following POM additions, rounding out what's
left from the M1 JIRA, for inclusion in both m1 and m2.

<defaultGoal> inside <build>. Not inherited. Specifies the goal to use
if none is specified.

<organizationUrl> in <developer/> alongside <organization>.
Also, <properties/> which allows arbitrary settings, like
<irc.username/>, <jabber.id/> etc. We can standardise some of these, but
I don't think they need to be part of the developer info.
Long term, we should separate the developer info out, so that only id
and per project roles are listed.

Thoughts?

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: POM additions

Felipe Leme
On Mon, 2005-05-16 at 20:17 +1000, Brett Porter wrote:

> <defaultGoal> inside <build>. Not inherited. Specifies the goal to use
> if none is specified.

Why not inherited?

-- Felipe



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: POM additions

Dan Tran
In M1, I heavily use default goal inheritant.This way I dont have to add an
extra maven.xml to all sub probject.

-D

On 5/16/05, Felipe Leme <[hidden email]> wrote:

> On Mon, 2005-05-16 at 20:17 +1000, Brett Porter wrote:
>
> > <defaultGoal> inside <build>. Not inherited. Specifies the goal to use
> > if none is specified.
>
> Why not inherited?
>
> -- Felipe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: POM additions

Jason van Zyl
In reply to this post by brettporter
On Mon, 2005-05-16 at 20:17 +1000, Brett Porter wrote:
> Hi,
>
> I'd like to propose the following POM additions, rounding out what's
> left from the M1 JIRA, for inclusion in both m1 and m2.
>
> <defaultGoal> inside <build>. Not inherited. Specifies the goal to use
> if none is specified.

The case where you don't want to inherit is where the goal of an
aggregation type parent has a particular goal which doesn't make sense
in the context of module but what about a policy of inheriting the
default goal if the packaging is the same? In plexus-components for
example a default goal of install I think would be appropriate. But a
good addition:

+1

> <organizationUrl> in <developer/> alongside <organization>.

+1

> Also, <properties/> which allows arbitrary settings, like
> <irc.username/>, <jabber.id/> etc. We can standardise some of these, but
> I don't think they need to be part of the developer info.

That could end up being a big jumble, would certainly be better to have
a database of developer info but I suppose there is no downside to
having a properties there other then varying usage all over the place.

> Long term, we should separate the developer info out, so that only id
> and per project roles are listed.
>
> Thoughts?
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
--
jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: POM additions

brettporter
Administrator
In reply to this post by Dan Tran
Can you explain your use case, and would adding the 1 - 3 lines in each
pom be prohibitive?

- Brett

dan tran wrote:

>In M1, I heavily use default goal inheritant.This way I dont have to add an
>extra maven.xml to all sub probject.
>
>-D
>
>On 5/16/05, Felipe Leme <[hidden email]> wrote:
>  
>
>>On Mon, 2005-05-16 at 20:17 +1000, Brett Porter wrote:
>>
>>    
>>
>>><defaultGoal> inside <build>. Not inherited. Specifies the goal to use
>>>if none is specified.
>>>      
>>>
>>Why not inherited?
>>
>>-- Felipe
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>>    
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: POM additions

Felipe Leme
In reply to this post by Dan Tran
Me too...

On Mon, 2005-05-16 at 09:15 -0700, dan tran wrote:
> In M1, I heavily use default goal inheritant.This way I dont have to add an
> extra maven.xml to all sub probject.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: POM additions

Felipe Leme-2
In reply to this post by brettporter
On Tue, 2005-05-17 at 07:19 +1000, Brett Porter wrote:
> Can you explain your use case, and would adding the 1 - 3 lines in each
> pom be prohibitive?

It would not be prohibitive, but imagine I have dozens of projects whose
default goal is the same (defined in a custom plugin, for instance). It
would require an extra work of 1-3 lines x dozens of projects. What if
the default goal changes? I would need to either change all these lines
or make the old default goal an alias to the new one (which is not
always possible).

-- Felipe

 


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]