You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@adobe.com> on 2011/03/02 18:29:56 UTC
Full Build Issue with Launchpad Content
Hi all,
When doing a full build like this:
* Remove all Sling SNAPSHOT from your local maven repo
* mvn -o clean install
The Launchpad Builder will fail, because the Launchpad Content will only
be built after the builder ...
It looks like the launchpad plugin properly fails builds for missing
artifacts but it does not properly support build order for multimodule
builds.
This happens for me with Maven 3.0.2.
Can we do something about this ?
Regards
Felix
Re: Full Build Issue with Launchpad Content
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 04.03.11 14:43, schrieb Justin Edelson:
>
> It depends :) the dependency plugin can operate on project dependencies (the copy-dependencies goal) or on dependencies declared working the plugin's configuration (the copy goal). If you used the latter, you could run into this same issue.
>
> This is certainly a regression in the sense that before maven-launchpad-plugin was introduced the launchpad bundles were dependencies of launchpad.builder and we used copy-dependencies. Apologies for not having spotted this possibility at the time.
>
No worries :)
However, we should find a solution to this problem - in one way or the
other. As soon as you are referencing snapshots this might be a problem
though the chance is very low if you put the builder at the bottom of
the module list in the reactor.
The more I think about it, the more I think it would be nice to define
the list of modules in a separate project which is then just referenced
by the builder. Or the builder could references more than one of these.
This would allow to define kind of "feature" poms which then are
included in the final launchpad.
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Full Build Issue with Launchpad Content
Posted by Justin Edelson <ju...@justinedelson.com>.
On Mar 4, 2011, at 2:17 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Justin Edelson wrote
>
>>>
>> Not as far as I know. By the time the plugin executes, the project
>> model (including the dependency graph) has already been generated.
>>
> Hmm, ok, so this would mean when e.g. using the maven dependency plugin,
> the same problem arises.
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
It depends :) the dependency plugin can operate on project dependencies (the copy-dependencies goal) or on dependencies declared working the plugin's configuration (the copy goal). If you used the latter, you could run into this same issue.
This is certainly a regression in the sense that before maven-launchpad-plugin was introduced the launchpad bundles were dependencies of launchpad.builder and we used copy-dependencies. Apologies for not having spotted this possibility at the time.
Justin
Re: Full Build Issue with Launchpad Content
Posted by Carsten Ziegeler <cz...@apache.org>.
Justin Edelson wrote
>>
> Not as far as I know. By the time the plugin executes, the project
> model (including the dependency graph) has already been generated.
>
Hmm, ok, so this would mean when e.g. using the maven dependency plugin,
the same problem arises.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Full Build Issue with Launchpad Content
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Mar 3, 2011 at 6:14 PM, Justin Edelson <ju...@justinedelson.com> wrote:
> ...How about this... get rid of the testing aggregator pom and directly
> reference the "core" testing support above launchpad.builder and the
> samples in the integration tests profile? Would that work for you?...
Yes, good idea, thanks.
Done in revision 1077863
-Bertrand
Re: Full Build Issue with Launchpad Content
Posted by Justin Edelson <ju...@justinedelson.com>.
On Thu, Mar 3, 2011 at 10:50 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Thu, Mar 3, 2011 at 3:58 PM, Justin Edelson <ju...@justinedelson.com> wrote:
>> ...The problem right now is that there's a dependency from
>> testing/samples/integration-tests to launchpad/builder...
>
> I changed the order of modules in the top-level pom.xml in revision
> 1076656, full build worked for me after rm -rf
> $HOME/.m2/repository/org/apache/sling/
Yeah, but now we'll have a problem if we ever want to include the
testing bundles into launchpad.
>
>> ...Would it be possible to move the testing samples to the samples
>> directory? Alternatively, there's probably a way to restructure the
>> testing aggregator pom, but it seems to me samples don't belong in the
>> main source tree....
>
> I'd like to keep testing/samples/integration-tests where it is if
> possible, mostly because it also tests the testing stuff (recursive
> testing in action ;-), which requires the launchpad jar, and also I
> think it's good to have the complete picture of integration testing
> tools and samples under /testing.
How about this... get rid of the testing aggregator pom and directly
reference the "core" testing support above launchpad.builder and the
samples in the integration tests profile? Would that work for you?
Justin
>
> -Bertrand
>
Re: Full Build Issue with Launchpad Content
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Mar 3, 2011 at 3:58 PM, Justin Edelson <ju...@justinedelson.com> wrote:
> ...The problem right now is that there's a dependency from
> testing/samples/integration-tests to launchpad/builder...
I changed the order of modules in the top-level pom.xml in revision
1076656, full build worked for me after rm -rf
$HOME/.m2/repository/org/apache/sling/
> ...Would it be possible to move the testing samples to the samples
> directory? Alternatively, there's probably a way to restructure the
> testing aggregator pom, but it seems to me samples don't belong in the
> main source tree....
I'd like to keep testing/samples/integration-tests where it is if
possible, mostly because it also tests the testing stuff (recursive
testing in action ;-), which requires the launchpad jar, and also I
think it's good to have the complete picture of integration testing
tools and samples under /testing.
-Bertrand
Re: Full Build Issue with Launchpad Content
Posted by Justin Edelson <ju...@justinedelson.com>.
On 3/3/11, Bertrand Delacretaz <bd...@apache.org> wrote:
> On Thu, Mar 3, 2011 at 2:34 PM, Justin Edelson <ju...@justinedelson.com>
> wrote:
>> On Mar 3, 2011, at 4:55 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>>> So this means that the bundles/modules listed in bundles/list.xml are
>>> not taken into account when Maven builds the dependency tree to
>>> calculate the build order for a multi project build, right?
> ...
>> Correct.
>
> Could this be changed at the plugin level?
> Can a Maven plugin inject additional dependencies?
>
> -Bertrand
>
Not as far as I know. By the time the plugin executes, the project
model (including the dependency graph) has already been generated.
The problem right now is that there's a dependency from
testing/samples/integration-tests to launchpad/builder:
<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.launchpad</artifactId>
<classifier>standalone</classifier>
<version>6-SNAPSHOT</version>
</dependency>
Would it be possible to move the testing samples to the samples
directory? Alternatively, there's probably a way to restructure the
testing aggregator pom, but it seems to me samples don't belong in the
main source tree.
Justin
Re: Full Build Issue with Launchpad Content
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Mar 3, 2011 at 2:34 PM, Justin Edelson <ju...@justinedelson.com> wrote:
> On Mar 3, 2011, at 4:55 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> So this means that the bundles/modules listed in bundles/list.xml are
>> not taken into account when Maven builds the dependency tree to
>> calculate the build order for a multi project build, right?
...
> Correct.
Could this be changed at the plugin level?
Can a Maven plugin inject additional dependencies?
-Bertrand
Re: Full Build Issue with Launchpad Content
Posted by Justin Edelson <ju...@justinedelson.com>.
Correct.
On Mar 3, 2011, at 4:55 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> So this means that the bundles/modules listed in bundles/list.xml are
> not taken into account when Maven builds the dependency tree to
> calculate the build order for a multi project build, right?
>
> Regards
> Carsten
>
> Justin Edelson wrote
>> There's not much we can do about this within the launchpad plugin.
>> IIUC, plugins aren't consulted when building the module sequence list.
>> What might work is to add launchpad.content as a dependency
>> (scope=provided? or test?). I'm a bit surprised you're having this
>> issue as launchpad/content is before launchpad/builder in the module
>> list in the root pom.
>>
>> I don't have time right now to look at this, but should later this
>> evening. Can you file a JIRA and assign it to me?
>>
>> Justin
>>
>> On Wed, Mar 2, 2011 at 12:29 PM, Felix Meschberger <fm...@adobe.com> wrote:
>>> Hi all,
>>>
>>> When doing a full build like this:
>>>
>>> * Remove all Sling SNAPSHOT from your local maven repo
>>> * mvn -o clean install
>>>
>>> The Launchpad Builder will fail, because the Launchpad Content will only
>>> be built after the builder ...
>>>
>>> It looks like the launchpad plugin properly fails builds for missing
>>> artifacts but it does not properly support build order for multimodule
>>> builds.
>>>
>>> This happens for me with Maven 3.0.2.
>>>
>>> Can we do something about this ?
>>>
>>> Regards
>>> Felix
>>>
>>>
>>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Full Build Issue with Launchpad Content
Posted by Carsten Ziegeler <cz...@apache.org>.
So this means that the bundles/modules listed in bundles/list.xml are
not taken into account when Maven builds the dependency tree to
calculate the build order for a multi project build, right?
Regards
Carsten
Justin Edelson wrote
> There's not much we can do about this within the launchpad plugin.
> IIUC, plugins aren't consulted when building the module sequence list.
> What might work is to add launchpad.content as a dependency
> (scope=provided? or test?). I'm a bit surprised you're having this
> issue as launchpad/content is before launchpad/builder in the module
> list in the root pom.
>
> I don't have time right now to look at this, but should later this
> evening. Can you file a JIRA and assign it to me?
>
> Justin
>
> On Wed, Mar 2, 2011 at 12:29 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> Hi all,
>>
>> When doing a full build like this:
>>
>> * Remove all Sling SNAPSHOT from your local maven repo
>> * mvn -o clean install
>>
>> The Launchpad Builder will fail, because the Launchpad Content will only
>> be built after the builder ...
>>
>> It looks like the launchpad plugin properly fails builds for missing
>> artifacts but it does not properly support build order for multimodule
>> builds.
>>
>> This happens for me with Maven 3.0.2.
>>
>> Can we do something about this ?
>>
>> Regards
>> Felix
>>
>>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Full Build Issue with Launchpad Content
Posted by Justin Edelson <ju...@justinedelson.com>.
There's not much we can do about this within the launchpad plugin.
IIUC, plugins aren't consulted when building the module sequence list.
What might work is to add launchpad.content as a dependency
(scope=provided? or test?). I'm a bit surprised you're having this
issue as launchpad/content is before launchpad/builder in the module
list in the root pom.
I don't have time right now to look at this, but should later this
evening. Can you file a JIRA and assign it to me?
Justin
On Wed, Mar 2, 2011 at 12:29 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi all,
>
> When doing a full build like this:
>
> * Remove all Sling SNAPSHOT from your local maven repo
> * mvn -o clean install
>
> The Launchpad Builder will fail, because the Launchpad Content will only
> be built after the builder ...
>
> It looks like the launchpad plugin properly fails builds for missing
> artifacts but it does not properly support build order for multimodule
> builds.
>
> This happens for me with Maven 3.0.2.
>
> Can we do something about this ?
>
> Regards
> Felix
>
>