On Fri, Dec 9, 2011 at 6:12 PM, Stephen Connolly
wrote:
> My point is that if returning classes is correct for a "jar" with no
> classifier, then the correct thing to do for a "test-jar" is return
> test-classes
Right. I didn't break that code which was already there.
>
> On 9 December 2011 22:2
To further clarify, the correct thing to do for a "test-jar" when
there is no test-jar, is to fall back to test-classes
On 9 December 2011 23:12, Stephen Connolly
wrote:
> My point is that if returning classes is correct for a "jar" with no
> classifier, then the correct thing to do for a "test-j
My point is that if returning classes is correct for a "jar" with no
classifier, then the correct thing to do for a "test-jar" is return
test-classes
On 9 December 2011 22:29, Benson Margulies wrote:
> On Fri, Dec 9, 2011 at 2:22 PM, Stephen Connolly
> wrote:
>> it is left as an exercise to the
I'm working on it. Next time i'll run them locally before I commit.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
On the substance of the original problem:
user runs 'mvn site:site'
site:site finds javadoc and checkstyle, trigger a forked lifecycle to
generate sources.
In this particular case, 'generate-sources' in module 'b' depends on
running out through 'process-classes' in module 'a'. b has a
compile-s
On Fri, Dec 9, 2011 at 5:27 PM, Olivier Lamy wrote:
> Did you try to use the ant bootstrap build ? (which will be faster IMHO )
No, I did not.
>
> 2011/12/9 Benson Margulies :
>> As for the format; I explained in the svn comment. I found it
>> convenient to be able to just run the newly-built pa
On Fri, Dec 9, 2011 at 2:22 PM, Stephen Connolly
wrote:
> it is left as an exercise to the reader to navigate the full fun of test
> jars (classifier test type jar or no classifier and type test-jar or some
> other wantonness (phone for once suggested suitable autocorrect fir
> randomness))
>
> so
Did you try to use the ant bootstrap build ? (which will be faster IMHO )
2011/12/9 Benson Margulies :
> As for the format; I explained in the svn comment. I found it
> convenient to be able to just run the newly-built package without
> unpacking it. If it really bugs anyone I can undo it.
>
> ---
As for the format; I explained in the svn comment. I found it
convenient to be able to just run the newly-built package without
unpacking it. If it really bugs anyone I can undo it.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.
Yes, I can. Can you tell me where some similar tests live?
On Fri, Dec 9, 2011 at 2:43 PM, Olivier Lamy wrote:
> Hello,
>
> 2011/12/9 :
>> Author: bimargulies
>> Date: Fri Dec 9 18:30:26 2011
>> New Revision: 1212564
>>
>> URL: http://svn.apache.org/viewvc?rev=1212564&view=rev
>> Log:
>> MNG-52
Hello,
2011/12/9 :
> Author: bimargulies
> Date: Fri Dec 9 18:30:26 2011
> New Revision: 1212564
>
> URL: http://svn.apache.org/viewvc?rev=1212564&view=rev
> Log:
> MNG-5214: Dependency resolution substitutes g:a:v:jar for
> j:a:v:something-else when something-else isn't in the reacto
>
> o Whe
it is left as an exercise to the reader to navigate the full fun of test
jars (classifier test type jar or no classifier and type test-jar or some
other wantonness (phone for once suggested suitable autocorrect fir
randomness))
source jars could also be resolved too... but i would suggest not.
-
On Fri, Dec 9, 2011 at 2:19 PM, Stephen Connolly
wrote:
> refinement: test-jar should resolve to test-classes as a fallback
It does. I didn't disturb that particular fallback. I can point you at
it if you like.
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, ran
refinement: test-jar should resolve to test-classes as a fallback
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 9 Dec 2011 18:30, wrote:
> Author: bimargulies
> Date: Fr
Ignore the below. I've found the spot in the reader that actually
forgets to check the classifier and the type.
On Fri, Dec 9, 2011 at 12:59 PM, Benson Margulies wrote:
> This makes keys that leave out type and classifier.
>
> And then things invalid matches happen in MNG-5214.
>
> The obvious fi
This makes keys that leave out type and classifier.
And then things invalid matches happen in MNG-5214.
The obvious fix is to use type and classifier, defaulting type to jar.
What will I break if I do that?
-
To unsubscribe, e-m
On 12/08/2011 06:34 AM, Benson Margulies wrote:
In the test case, there's a maven plugin which declares various maven
2 components as provided dependencies, notably the
DefaultArtifactResolver. So, my IDE keeps trying (I think) to show me
the source to the 2.2.1 version even though, since I'm run
Olivier,
You're pointing at the original problem: that process-classses doesn't
get included in the forked lifecycle.
I'm trying to start with the second problem: that the resolver gives a
bogus answer.
--benson
On Thu, Dec 8, 2011 at 11:05 AM, Olivier Lamy wrote:
> 2011/12/8 Benson Margulies
Brett,
What are you debugging in these days?
On Thu, Dec 8, 2011 at 12:31 PM, Brett Porter wrote:
> Are you running Maven from the IDE, or using the "mvnDebug" remote debugging?
>
> If you have the Maven projects open, and then attach to a Maven process built
> from those sources, you should
I have no problem with just putting process-classes on the command
line, now that I'm awake.
On Thu, Dec 8, 2011 at 7:34 PM, Martin Gainty wrote:
>
> Benson-
>
> if process-classes is missing how about placing 'process-classes' in a
> customised lifecycle
> src/main/resources/META-INF/plexus/com
20 matches
Mail list logo
