Ralph,
Ralph Goers wrote:
This whole thread makes my head hurt.
Frankly, and at the risk of being repetitious, I think all this work
into making this resolution based on versioning is pretty much a waste
of time. Now if your picture incorporated artifact metadata, such as
"provides" and "re
This whole thread makes my head hurt.
Frankly, and at the risk of being repetitious, I think all this work
into making this resolution based on versioning is pretty much a waste
of time. Now if your picture incorporated artifact metadata, such as
"provides" and "requires" attributes I'd si
I'm working on open-sourcing an annotation-based solution for
externalizing messages. I hope this is an opportunity to get some
quick feedback. Please let me know if I'm out-of-line.
Example Workflow:
Create an interface to hold messages. Annotate the methods with the
text of the default trans
Brian E. Fox wrote:
Let me respectfully disagree: I used to work for a company where I was
responsible for productivity of hundreds of developers. If I would've
introduced a change where they have to do 5 mouse clicks instead of 1 -
I would be out of job the next day.
Btw, eclipse has
On Thu, Dec 25, 2008 at 5:24 AM, Brian E. Fox wrote:
>
>>Can you name one single reason why moving this file away and creating 6
>>additional folders on the way that would not exist otherwise is
>>beneficial? Without using the argument "it's a convention"? :)
>
> Sure. What if you want to filter i
On Dec 24, 2008, at 10:58 AM, Brian E. Fox wrote:
Let me respectfully disagree: I used to work for a company where I
was
responsible for productivity of hundreds of developers. If I would've
introduced a change where they have to do 5 mouse clicks instead of
1 -
I would be out of job the n
On Dec 24, 2008, at 10:43 AM, Oleg Gusakov wrote:
Brian E. Fox wrote:
I also respect the conventions, but in this particular case the
convention became counter-productive: I externalized all the
messages into Messages.properties file per package and have to
modify this file all the time
>Let me respectfully disagree: I used to work for a company where I was
>responsible for productivity of hundreds of developers. If I would've
>introduced a change where they have to do 5 mouse clicks instead of 1 -
>I would be out of job the next day.
Btw, eclipse has tabs, last time I checked
>Can you name one single reason why moving this file away and creating 6
>additional folders on the way that would not exist otherwise is
>beneficial? Without using the argument "it's a convention"? :)
Sure. What if you want to filter it? This is trivial if you have it in
resources where it be
Brian E. Fox wrote:
I also respect the conventions, but in this particular case the
convention became counter-productive: I externalized all the messages
into Messages.properties file per package and have to modify this file
all the time.
If this file sits in the src/main/java/... p
>I also respect the conventions, but in this particular case the
>convention became counter-productive: I externalized all the messages
>into Messages.properties file per package and have to modify this file
>all the time.
>If this file sits in the src/main/java/... package - it's one mouse
>c
Vincent,
Vincent Siveton wrote:
Hi,
All Maven subprojects respect (AFAIK) the common directory structure
[1] of Maven. IMHO Maven sell speech is about convention, and Maven
should be the first place where it would be applied. There is nothing
about properties files in our convention [2], but I
Benjamin,
It slipped in - fixing. Yes - I remember MERCURY-58 :)
Thanks for catching,
Oleg
Benjamin Bentmann wrote:
Hi Oleg,
Author: ogusakov
Date: Tue Dec 23 19:55:25 2008
New Revision: 729211
URL: http://svn.apache.org/viewvc?rev=729211&view=rev
Log:
[MERCURY-65] adding mapped repo implem
Hi,
All Maven subprojects respect (AFAIK) the common directory structure
[1] of Maven. IMHO Maven sell speech is about convention, and Maven
should be the first place where it would be applied. There is nothing
about properties files in our convention [2], but I suggest to revert
these changes to
Hi,
2008/12/23, Brian E. Fox :
> Vincent, what's the snapshot needed for? R728944 is a change to maven 2.1's
> parent
It is the maven-stylus-skin snap, read the r728944 message:
http://svn.apache.org/viewvc?view=rev&revision=728944
no apparent reason this should affect the enforcer. Changin
Brian E. Fox wrote:
However I don't think it's completely useless
Sure, and I never meant to say that. I appreciate the grid as a great
step towards easier cross-platform testing/debugging.
because the testing and building once maven runs is the same.
As I tried to outline, this doesn't
Hi Oleg,
Author: ogusakov
Date: Tue Dec 23 19:55:25 2008
New Revision: 729211
URL: http://svn.apache.org/viewvc?rev=729211&view=rev
Log:
[MERCURY-65] adding mapped repo implementation
Added:
maven/mercury/trunk/mercury-repo/mercury-repo-map/src/main/java/org/apache/maven/mercury/repositor
17 matches
Mail list logo
