On Dec 25, 2008, at 7:02 PM, Jason van Zyl wrote:
On 25-Dec-08, at 4:27 PM, Ralph Goers wrote:
Jason,
I'm surprised you don't remember this discussion since we've had it
so many times.
The only thing I wanted to make sure you weren't doing was passing
on requirements as provisions t
I use hierarchical mode in Eclipse and it's a blast. I sympathize
towards anyone who feels conventions may slow them down, but Java
Resources shouldn't go into src/main/java because of a tooling
deficiency.
-
To unsubscribe, e-mai
Issue Subscription
Filter: Design & Best Practices (28 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
On 25-Dec-08, at 4:27 PM, Ralph Goers wrote:
Jason,
I'm surprised you don't remember this discussion since we've had it
so many times.
The only thing I wanted to make sure you weren't doing was passing on
requirements as provisions transitively. If you know RPMs then we're
on the sam
Ralph,
If we start walking this road - let's generalize starting from existing
model, so that it could still be a subset of the the solution.
So what we have now:
* each artifact "supplies"/"provides"/"has" a set of attributes: groupId
(G), artifactId (A), version (V), classifier (C), type (
Jason,
I'm surprised you don't remember this discussion since we've had it so
many times.
My opinion is that versions are just one piece of metadata, and a not
very important one at that since they are almost completely arbitrary.
When I speak of provides and requires I am referring to ex
Vincent Siveton wrote:
Hi,
2008/12/24, Oleg Gusakov :
[SNIP]
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"? :)
As said, that is truly
Benjamin,
Benjamin Bentmann wrote:
Oleg Gusakov wrote:
If this file sits in the src/main/java/... package - it's one mouse
click in Eclipse to open it. If I move it to src/main/resources/.. -
it becomes a multi-click - one has to click as many times as there
are members in the package name,
On 25-Dec-08, at 2:02 AM, 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.
I don't think anyone is OSGi land would agree with you.
2008/12/25, Benjamin Bentmann :
> Hm, using either the hierarchical mode in combination with the "Fold empty
> packages" preference or the flat mode in the package explorer works for me
> with Eclipse 3.4.1.
>
> From my experience for flattening to work properly, Eclipse needs to ignore
> the ".s
Hi,
2008/12/24, Oleg Gusakov :
[SNIP]
> 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"? :)
As said, that is truly what we (Maven and devs) are
Hi Oleg,
2008/12/24, Oleg Gusakov :
[SNIP]
> 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.
Since we are a community
Oleg Gusakov wrote:
If this file sits in the src/main/java/... package - it's one mouse
click in Eclipse to open it. If I move it to src/main/resources/.. - it
becomes a multi-click - one has to click as many times as there are
members in the package name, because Eclipse does not respect "fla
13 matches
Mail list logo
