Re: split of mockup / plone.mockup

Ok, all reverted, submodules may stink. I'm waiting for Jenkins results,
but I expect it to pass.

Still, IMO we need to address Mockup's bower package problem. 1.) if
other projects than Plone core want to use Mockup (I'm thinking on the
YAFOWIL form library, for example), 2.) if someone wants to create own
bundles based on Mockup patterns. I'm facing the second use case and
therefore created this now reverted Mockup splitting.

The second use case isn't so urgent with Plone 5, since you can use the
Resource registry to reuse Mockup. But for Plone 4 or Plone-less bundle
creation you need some way to depend on Mockup from bower, if you want
to use some of it's patterns.

In concrete, I'm going to create a custom bundle which includes the
patterns from the plone.app.widgets bundle, the wildcard.foldercontents
bundle and also some 3rd party patterns (e.g. my unfinished
mockup-leaflet). I want to have just one bundle instead of separate
plone.app.widgets, wildcard.foldercontents and a custom bundle, which
duplicate the whole JavaScript dependencies for each one and increasing
the size of download resources. 

How are you guys addressing this problem?

Johannes




On Tue, 2015-03-10 at 14:45 +0000, Ramon Navarro Bosch wrote:
> May we try to revert the status to a mockup repository beeing a python
> egg and a bower component. Maybe we can create there a dist folder
> with the distributed version of mockup if that can help, so the bower
> package has a compiled version?. With a .bowerrc we can have the
> bower.json on the root and we can also have the packages.json on the
> root. We can focus on improving mockup-core wherever is the problem.
> 
> 
> I would not disconnect mockup source from plone, we need to be able to
> test how a change on mockup affects plone 5. 
> 
> 
> For me its a matter of responsability that mockup stability is on
> Plone community, so we need to connect it to our development process,
> otherwise using mockup as we are using any other js/css components (as
> we are using bootstrap with bower) needs to have its own community,
> its release process, its ci, ... and then we will need to create
> another js layer with the specific plone js/css code.
> 
> 
> Ramon
> 
> El dt., 10 març, 2015 a les 15:20, Patrick Gerken
> (<lists-Hgn/qBBDvdzwVR/[email protected]>) va escriure:
>         On 10.03 15:10, Johannes Raggam wrote:
>         > most of the critique on git submodules out there refers to
>         git
>         > submodules being used as a project dependency manager. this
>         is not the
>         > way i use it for plone.mockup.
>         > but possible CI troubles are valid arguments against having
>         submodules.
>         >
>         > mockup core makes so much assumptions about dependend
>         projects (js,
>         > patterns and build directories have to live in the level
>         where Makefile
>         > and bower lives, etc), that separating the python egg from
>         mockup seemed
>         > much cleaner.
>         > fortunately we're using git and restoring the previous
>         situation is
>         > easily possible.
>         > i will revert this evening, if i and no one else comes up
>         with a better
>         > solution. i'll try the git subtree feature before, maybe
>         this is more
>         > transparent and CI sane, i don't know...
>         
>         Be careful about git subtree. If you plug mockup into
>         plone.mockup, it
>         can be hard or impossible to remove mockup and its history
>         from the
>         plone.mockup git history. Also, as said earlier, using git
>         submodule or
>         git subtree to fix a problem with mockup-core seems weird to
>         me.
>         
>         Best regards,
>         
>                Patrick

------------------------------------------------------------------------------
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
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEABECAAYFAlT/gakACgkQW4mNMQxDgAf2/QCeL5z+QnlEvbKGVci0G728RVi1
9D4AnRui806swPrxJTmcHdCoIcHXvrPo
=jDKG
-----END PGP SIGNATURE-----