multi-module build from parent with sources dependencies fails

[GoogleCodeExporter]

Is this Maven 1 or Maven 2?
Maven 2

What steps will reproduce the problem?
1. have multi-module project
2. don't have <build> section with resources directed to /src/main/java and
/src/main/resources
3. instead have dependencies with sources classifier
4. build project from parent

What is the expected output? What do you see instead?
I expect client, rpc and server parts will compile successfully. Instead of
that I see that client is not able because of missing sources.

What version of the product are you using? On what operating system?
using trunk version (currently 22) on either windows or linux

Please provide any additional information below.
While investigating the problem I found that when building classpath there
is dependency for currently active projects (built by multi-module build)
but its sources and resources are not included on the classpath. When
building client only everything is fine because all dependencies are available.

Solution is on the way, need only some further testing...

Original issue reported on code.google.com by eldz...@gmail.com on 10 Sep 2008 at 11:21

[GoogleCodeExporter]

I modified classpath building process including active projects sources and
resources. See attached patch.

Original comment by eldz...@gmail.com on 11 Sep 2008 at 8:43

Attachments:

• maven-googlewebtoolkit2-plugin.activeProjectClassPath.rev771.patch

[GoogleCodeExporter]

Thanks.  I will check this out and then get it committed ASAP - will be in next 
build. 

Original comment by charlie....@gmail.com on 11 Sep 2008 at 11:10

• Changed state: Accepted

[GoogleCodeExporter]

I looked at this patch this weekend and did not have time enough to clean it up 
to a
level that I felt was good enough to commit.  

First there are several unused variables and methods in the patch, those are 
easy to
remove those.  Second, the TEST stuff should have the same look up references 
type
handling, but the method that adds resources and such doesn't deal with test 
yet,
just compile.  Third, I personally do not condone passing in class members as
parameters to methods (return something from the method, and use that). 

Don't get me wrong, none of these are show stoppers, and this is a very valuable
patch, I just haven't yet had time to update it and commit it. 

Original comment by charlie....@gmail.com on 14 Sep 2008 at 6:21

[GoogleCodeExporter]

Well this was patch for the purpose I immediately saw and forgot to test 
stuff.. but
shouldn't be a problem to do it also for that. I will create patch against 
latest trunk. 

If you mean addSourcesAndResources method then there it is for me neccessary 
because
it is modifying existing set. I think creating a new set, filling it and then 
copying
back is not optimal. But I have no objections against modification, feel free to
modify it or give me instructions how to bend it suite the needs of the project.

Original comment by eldz...@gmail.com on 17 Sep 2008 at 2:11

[GoogleCodeExporter]

Again, don't get me wrong, this is a *very* helpful and welcome patch.  I just
couldn't slam it in in a few minutes of time I had to look at it the other day. 

The addSourcesAndResources thing is fine as it is, we don't have particular 
standards
here - I was just saying that is normally something I avoid (I am one of those 
final
parameter nazis ;)).  

If you have an updated patch I will look at that, or, when I get a chance I will
spend some more time with this one and get it tweaked to support the test 
stuff. 

Original comment by charlie....@gmail.com on 17 Sep 2008 at 2:45

[GoogleCodeExporter]

Well I reviewed the patch, cleaned it up, it is against current trunk (rev. 
885).
Also it applies for test scope. Some unnecessary methods were also removed. 

Maybe it would be good in the future to make from BuildClasspath not a class 
with
bunch of static methods but a class which will hold a state (like Set<File> 
items)
and will be instantiated. It would be more sufficient for other "classpath 
issues"
like 148 and 149 - you don't have to pass too much parameters across methods 
and can
use real "object power" :).

Original comment by eldz...@gmail.com on 3 Oct 2008 at 11:08

Attachments:

• maven-googlewebtoolkit2-plugin.issue147.rev885.patch

[GoogleCodeExporter]

Applied to trunk. 

Original comment by charlie....@gmail.com on 5 Nov 2008 at 9:05

• Changed state: Fixed