RE: Artifacts & Versioning Spec. Was: RFE for the war plugin

[Tim Reilly <ti...@consultant.com>]

Thanks for the concrete example (use-case). Now I understand better at least
as a list lurker.
I had originally thought you and Michal were debating which way `round to
get metadata to the web container, now I see.

So if me were you: I'd login to Jira:
  create an rfe request
  attach the patch(es* - w/ documentation as well)
  vote for the enhancement
  send the jira issue url to the list with some message like: "...here's the
link to the rfe. If you want the option to jar the classes in a war... vote
for this issue. I use this so that....logging [etc].."

Users could then "vote" for it...
committers can get a sense of who's looking for this feature.
IMO no feature is without some cost. The new property will likely need to be
documented if it's not already with your patch. Inevitably there will be
mailing list questions about it (hopefully you'd monitor to answer them.)
Any unforeseen issues or downstream affects have to be dealt with - code
maintenance.
Then in the bigger picture someone else will say why are there so many
properties all over,
why is maven hard to learn, why isn't there more documentation, why are
property names not consistent,
why does the war plugin generate more than one artifact.
Not lazy..intelligent.

-TR

> [Brill Pappin wrote:]
> Sent: Wednesday, June 30, 2004 10:45 AM
> Ok, let me explain this one more time.
> [...]
> An example of where I specifically use this information:
> I'm sure you've seen how you have have log4j output the file and line
> number of a log message. Now using the versioning API you can also
> output other information as well as the file and line number, such as
> what version it is, the module or company it came from... you can even
> tell things like what dependencies it has etc.


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

Re: Artifacts & Versioning Spec. Was: RFE for the war plugin

[Dion Gillard <di...@gmail.com>]

Tim, you forgot the updating of the plugin tests :-)

On Wed, 30 Jun 2004 18:48:46 -0400, Tim Reilly
<ti...@consultant.com> wrote:
> 
> Thanks for the concrete example (use-case). Now I understand better at least
> as a list lurker.
> I had originally thought you and Michal were debating which way `round to
> get metadata to the web container, now I see.
> 
> So if me were you: I'd login to Jira:
>   create an rfe request
>   attach the patch(es* - w/ documentation as well)
>   vote for the enhancement
>   send the jira issue url to the list with some message like: "...here's the
> link to the rfe. If you want the option to jar the classes in a war... vote
> for this issue. I use this so that....logging [etc].."
> 
> Users could then "vote" for it...
> committers can get a sense of who's looking for this feature.
> IMO no feature is without some cost. The new property will likely need to be
> documented if it's not already with your patch. Inevitably there will be
> mailing list questions about it (hopefully you'd monitor to answer them.)
> Any unforeseen issues or downstream affects have to be dealt with - code
> maintenance.
> Then in the bigger picture someone else will say why are there so many
> properties all over,
> why is maven hard to learn, why isn't there more documentation, why are
> property names not consistent,
> why does the war plugin generate more than one artifact.
> Not lazy..intelligent.
> 
> -TR
> 
> > [Brill Pappin wrote:]
> > Sent: Wednesday, June 30, 2004 10:45 AM
> > Ok, let me explain this one more time.
> > [...]
> 
> 
> > An example of where I specifically use this information:
> > I'm sure you've seen how you have have log4j output the file and line
> > number of a log message. Now using the versioning API you can also
> > output other information as well as the file and line number, such as
> > what version it is, the module or company it came from... you can even
> > tell things like what dependencies it has etc.
> 
> ---------------------------------------------------------------------
> 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