Re: split of mockup / plone.mockup

Isn't this the kind of general problem we have with javascript bridges 
to plone? Isn't it also crazy that we have to create a python egg in 
order to use javascript in Plone? For each library? And keep it in sync 
with new upstream releases?

In my opinion we have here a general problem. We must solve it, even if 
I have no good idea how, nor I'am deep enough into the new bundle/js 
Plone infrastructure to really be helpful

Just from an architectural POV: I would make a general package to deal 
with JS-infrastructure and then tell it in a declarative way what to 
fetch. I was the opinion the new registry works this way. If not:

One idea is to have one package ("plone.js.bowser", "plone.js.npm" or 
just "plone.js")  which then can be used to fetch all npm or bower and 
bundle it to the new registry.

just my 0.02€

Jens

On 2015-03-09 21:06, Johannes Raggam wrote:
> Hi,
>
> good arguments! That was a quick shot from me, sorry. But I think we
> agree, that Mockup needs to be a bower installable package.
>
> So, Timo's point is, that we need for each commit on mockup a
> corresponding commit on plone.mockup to get understandable and
> reproducable Jenkins result.
>
> As far as I understood it (didn't try out yet), ``git subtree``, instead
> of ``git submodules`` might be able to solve this problem. See:
> http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
>
> I'm not sure how this works out with mr.developer. Maybe we need some
> Github Webhooks to update the subtree on every Mockup commit.
>
> Johannes
>
>
> On Mon, 2015-03-09 at 15:41 -0300, Leonardo Rochael Almeida wrote:
>> Hi,
>>
>>
>> I don't know if this is relevant, and you might already be aware of
>> it, but I'd just like to point out that, with git submodules, the
>> submodule is pinned to a specific commit (hash), not a specific branch
>> of the referenced repository.
>>
>>
>> In practice this means that, for the `plone.mockup` repository to pick
>> up a new commit/release/branch/whatever of the `mockup` submodule, a
>> new commit needs to be added to the `plone.mockup` repository picking
>> up this new commit (hash) of the submodule.
>>
>>
>> This also means that any CI that monitors a branch (or master) of the
>> `plone.mockup` repository and blindly calls `submodule update` on it
>> whenever it detects a new commit on the `plone.mockup` will
>> automatically pick up changes in the submodules without any added
>> detection complexity.
>>
>>
>> Cheers,
>>
>>
>> Leo
>>
>> On 9 March 2015 at 15:26, Timo Stollenwerk <[email protected]> wrote:
>>          Am 09.03.15 um 19:08 schrieb Timo Stollenwerk:
>>          > Hi Johannes,
>>          >
>>          > making mockup installable via bower is a worthwile goal.
>>          Thanks for
>>          > working on that!
>>          >
>>          > Though, I see a problem with using git submodules. It is
>>          already quite
>>          > hard to create a proper CI setup on top of mr.developer, and
>>          using git
>>          > submodules will make this even harder. Here is why:
>>          >
>>          > We are basically nesting our development packages into our
>>          main
>>          > repository with mr.developer. This makes it hard to
>>          impossible to
>>          > trigger one Jenkins job per commit (we tried very smart
>>          stuff with
>>          > mr.roboto and we failed miserably, you have to store every
>>          single hash
>>          > value and every version pinning for each pkg and re-run
>>          buildout with
>>          > this). We are still aiming for 1 commit = 1 build. Though,
>>          adding a
>>          > second nested level (git submodules) within our already
>>          nested setup
>>          > will make this impossible. We might be able to somehow pin
>>          our modules
>>          > if we do releases in the future. We are not going to be able
>>          to do this
>>          > in a structure that is nested twice.
>>          >
>>          > Futhermore, my personal experience with git submodules is
>>          that even when
>>          > working with in manually, it is nothing but unpredictable
>>          pain.
>>          >
>>          > In addition to the uncertainty that buildout and
>>          mr.developer already
>>          > put into our CI setup, you just introduced another one.
>>          >
>>          > I think we should try to find another way to solve this
>>          problem. I'm not
>>          > sure if we still take "mockup should be used outside Plone"
>>          seriously.
>>          > Though, in any case I think we should test and release
>>          mockup
>>          > separately. What if the mockup CI system (travis?) creates a
>>          new release
>>          > if all unit tests pass. The Plone CI could pick up the
>>          latest release
>>          > and we would just have to make sure the travis job triggers
>>          the Jenkins
>>          > CI. Plone would just install the latest mockup development
>>          version via
>>          > bower.
>>
>>
>>          Sorry, I mixed things up with the CI pipeline for my current
>>          project. :)
>>
>>          We do not want to run npm/bower on our Jenkins job. Therefore
>>          we would
>>          need a Python egg for each mockup commit that can be picked up
>>          by the
>>          Jenkins job instead of a bower release. I guess we could set
>>          up a
>>          private pypi for that if necessary.
>>
>>          Cheers,
>>          Timo
>>
>>          ------------------------------------------------------------------------------
>>          Dive into the World of Parallel Programming The Go Parallel
>>          Website, sponsored
>>          by Intel and developed in partnership with Slashdot Media, is
>>          your hub for all
>>          things parallel software development, from weekly thought
>>          leadership blogs to
>>          news, videos, case studies, tutorials and more. Take a look
>>          and join the
>>          conversation now. http://goparallel.sourceforge.net/
>>          _______________________________________________
>>          Plone-developers mailing list
>>          [email protected]
>>          https://lists.sourceforge.net/lists/listinfo/plone-developers
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________ Plone-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plone-developers
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Plone-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>


-- 
Klein & Partner KG, member of BlueDynamics Alliance


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Plone-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plone-developers