You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2014/10/06 14:26:57 UTC

Building the launchpad, snapshot bundles (was: [jira] [Created] (SLING-3987) move from Subversion to Git)

Hi,

On Fri, Oct 3, 2014 at 3:43 AM, Justin Edelson <ju...@justinedelson.com> wrote:
> Hi Radu,
> I agree. But this is an orthogonal problem to the question of what SCM
> system we use.
>
> I actually thought that we did deploy snapshots via CI. I see some
> artifacts under
> https://repository.apache.org/content/repositories/snapshots/org/apache/sling/
> but it is inconsistent.
>
> Anyone know what is going on with the snapshot deployment? And what we
> can do to re-enable it?

Not sure why, but the Jenkins jobs seem to use

  mvn clean install

I can switch the sling-trunk-1.6 job to deploy the build results, so
we are compatible with as many setups as possible. However, this will
only work if the Apache snapshots repository is declared either in
~/.m2/settings.xml or in one of our poms ( which it is not ).

For the contributor setup, what I think is simplest is building a
subset of the reactor, e.g.

    mvn -am -pl launchpad/builder/pom.xml clean package

This should build the launchpad and any dependencies that I can
resolve from the reactor. Unfortuntely that used to work with Maven
3.0.5 but does not work anymore with Maven 3.2.1 . I'm not sure why it
broke and had no time to look into it.

>
> FWIW, I don't think we should (or really could) following a
> launchpad-only-contains-releases rule. But I'm willing to be convinced
> otherwise if the snapshot thing is really impossible.

Same here, it takes too long to propagate a fix into the launchpad
with releases only and the integration tests will run against old
code, therefore we will only catch regressions after the release.

Robert

>
> Justin
>
> On Thu, Oct 2, 2014 at 3:46 PM, Radu Cotescu <ra...@apache.org> wrote:
>> Hi,
>> I know that I'm just an occasional contributor to Sling and I noticed that
>> this talk is mostly between PMC members. However, here's my big +1 for what
>> Robert proposed.
>>
>> Currently if somebody wants to contribute a new module to Sling they have
>> to build the full project to get a running launchpad, which (assuming that
>> they didn't use -DskipTests) takes a while.
>>
>> Just my €0.02.
>>
>> Cheers,
>> Radu
>>
>> On Thu, Oct 2, 2014 at 4:14 PM, Robert Munteanu <ro...@apache.org> wrote:
>>
>>> Or do we we guarantee that the
>>> Launchpad is always buildable outside the reactor by banning SNAPSHOT
>>> dependencies
>>>

Re: Building the launchpad, snapshot bundles (was: [jira] [Created] (SLING-3987) move from Subversion to Git)

Posted by Robert Munteanu <ro...@apache.org>.
On Mon, Oct 6, 2014 at 3:26 PM, Robert Munteanu <ro...@apache.org> wrote:
>
> I can switch the sling-trunk-1.6 job to deploy the build results, so
> we are compatible with as many setups as possible. However, this will
> only work if the Apache snapshots repository is declared either in
> ~/.m2/settings.xml or in one of our poms ( which it is not ).


Just did that. Not sure if it helps anyone build the launchpad without
building the bundles, but I noticed that the sling-oak-it-1.6 had no
way of picking up an updated launchpad other than from the repository.

Robert

Re: Building the launchpad, snapshot bundles (was: [jira] [Created] (SLING-3987) move from Subversion to Git)

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Oct 7, 2014 at 1:57 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I don't think we need to launchpads - with the new provisioning model, we
> can easily switch the model to use the latest snapshot for all artifacts...

Right, that's closer to what I was trying to say actually - we could
have two launchpad *test setups*, one with snapshots and one with
releases.

-Bertrand

Re: Building the launchpad, snapshot bundles (was: [jira] [Created] (SLING-3987) move from Subversion to Git)

Posted by Carsten Ziegeler <cz...@apache.org>.
I don't think we need to launchpads - with the new provisioning model, we
can easily switch the model to use the latest snapshot for all artifacts

Carsten

2014-10-07 12:16 GMT+02:00 Bertrand Delacretaz <bd...@apache.org>:

> Hi,
>
> On Mon, Oct 6, 2014 at 2:26 PM, Robert Munteanu <ro...@apache.org>
> wrote:
> > ...    mvn -am -pl launchpad/builder/pom.xml clean package
> >
> > This should build the launchpad and any dependencies that I can
> > resolve from the reactor. Unfortuntely that used to work with Maven
> > 3.0.5 but does not work anymore with Maven 3.2.1
>
> FWIW this (using folder name, not pom.xml) works with Maven 3.1.1:
>
>   mvn -am -pl launchpad/builder clean package
>
> > Justin wrote:
> >> FWIW, I don't think we should (or really could) following a
> >> launchpad-only-contains-releases rule. But I'm willing to be convinced
> >> otherwise if the snapshot thing is really impossible....
>
> I think we might need two launchpads, one with all snapshots for
> integration tests, and one with releases for releases, maybe built
> with an older (tagged) version of the integration tests.
>
> -Bertrand
>



-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: Building the launchpad, snapshot bundles (was: [jira] [Created] (SLING-3987) move from Subversion to Git)

Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,

On Mon, Oct 6, 2014 at 2:26 PM, Robert Munteanu <ro...@apache.org> wrote:
> ...    mvn -am -pl launchpad/builder/pom.xml clean package
>
> This should build the launchpad and any dependencies that I can
> resolve from the reactor. Unfortuntely that used to work with Maven
> 3.0.5 but does not work anymore with Maven 3.2.1

FWIW this (using folder name, not pom.xml) works with Maven 3.1.1:

  mvn -am -pl launchpad/builder clean package

> Justin wrote:
>> FWIW, I don't think we should (or really could) following a
>> launchpad-only-contains-releases rule. But I'm willing to be convinced
>> otherwise if the snapshot thing is really impossible....

I think we might need two launchpads, one with all snapshots for
integration tests, and one with releases for releases, maybe built
with an older (tagged) version of the integration tests.

-Bertrand