Re: split of mockup / plone.mockup

On Tue, 2015-03-10 at 18:48 -0500, Nathan Van Gheem wrote:
> We need to move bower.json to root and then add a bowerrc file to
> customize where it installs.  

hmm...! i'll try that out. why didn't i think of the bowerrc file? that
would be indeed much easier than the other approach.

I don't care much about the location of the Makefile or package.json,
although it would be nicer to have it in the root directory.

> 
> We could also move Makefile to root, should not matter.
> 
> That should be all that's necessary though
> 
> On Mar 10, 2015 6:44 PM, "Johannes Raggam" <[email protected]> wrote:
>         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
>

------------------------------------------------------------------------------
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/hdIACgkQW4mNMQxDgAfJVQCgw13bsSOkAnaoI4q6+XeOHE96
jZcAoMUMlbZ2IN1ZMSZ1bPiLy4bS0a2v
=wraj
-----END PGP SIGNATURE-----