Hi Costin, Is it possible to get access to your modified branch of the build? would make it easier to find and test possible solutions, instead of trying to suggest things based on a couple of poms.
I usually end up exploding wrapped libraries under target/classes as it makes Eclipse happy - that's why I don't see this problem. -- Cheers, Stuart On 08/05/07, Costin Leau <[EMAIL PROTECTED]> wrote:
Alin Dreghiciu wrote: > A solution will be indeed to separate the build of spring-modules, > including > required libraries from building of the rest. As with spring 2.1 anyway the > artifacts will be osgi bundles anyway. Until they will, we have to deal with this. > > P.S. if you are doing this refactoring isn't now also the moment to get rid > of some of the required libraries build and use those from felix commons? If I find time, I'll see if I can remove some of the libraries. > > Alin > > On 5/8/07, Costin Leau <[EMAIL PROTECTED]> wrote: >> >> ... >> Since maven for some reason, uses <module>/target/classes instead of the >> published jar and target/classes is empty, I really can't see any nice >> alternative here. > > > I caould not find a clear reference about but I'm suspecting that this is > done as you are not always installing the builded artifacts into the > repository hence if the resolution would be based on the repository > artifacts you would not be able to compile. > E.g. mvn clean package that is supposed to just generate the artifacts and > not install them into the local repo. (strange is that this will fail on > building spring osgi with a artifacts resolution on the spring-core that is > quite strange in my view) > > Am I the only one with this problem? > > > I just google for some moments and I saw some references but nothing > relevant. > -- Costin
