wxcode-users

[wxCode-users] Announcing wxWPM 0.2: wxWidgets Package Manager

[Francesco M. <f18...@ya...>]

Hi all,
   I'm posting this announce here as I think that even if wxWPM is not a 
wxCode component, you'll still be interested:

I'm pleased to announce a new release of the wxWPM, the wxWidgets 
package manager project.


What is it?
-----------

The wxWidgets Packager Manager project (wxWPM in short) provides the 
tools to create and use a new format of source packages: the wxWidgets 
packages.

The wxWidgets packages are simple compressed archives containing a WXP 
(wxWidgets package descriptor file) which contains the info used by the 
Package Manager to build (i.e. compile), install or uninstall the 
package on the user's system using the build system of the packaged 
software (e.g. bakefile or cmake).

The concept is very similar to the DevC++'s devpaks, but unlike them 
wxWidgets packages are cross-platform and are completely abstracted from 
the build system used by the packaged project.
They are aimed to make the software modular and easy reusable!

Packaging your software using the wxWidgets Packager GUI is extremely 
easy; once you've filled in the fields, it will even help you to make 
new releases of your software faster (creating the .zip and .tar.gz 
archives automatically excluding unwanted files); you won't even need to 
upload/distribute a new file as you can reuse your source releases (the 
usual .zip, .tar.gz archives) as wxWidgets packages (just putting a 
package descriptor inside them)!


What does it provide?
---------------------

The wxWPM project provides three applications:

   1. a GUI Package Manager which can be used to browse remote 
repositories of packages, download the selected packages, build them 
using the user-specified configuration and finally install them.

   2. the wxWidgets GUI Packager: an intuitive tool which creates the 
wxWidgets package descriptors (WXP) and will create the wxWidgets 
compressed package.

   3. the third application is a command-line manager which provides all 
functionalities of previous apps from command-line, allowing to e.g. 
script the download and the installation of the latest version of your 
favourite packages.

This project was initially sponsorised by Google in its Summer Of Code 
2006, developed by Francesco Montorsi and mentored by Julian Smart.


Links
-----

To learn more about wxWPM:    http://wxwpm.sourceforge.net
wxWPM screenshots page:       http://wxwpm.sourceforge.net/screenshots.php
wxWPM download page:          http://wxwpm.sourceforge.net/download.php

To learn about wxWidgets:     http://www.wxwidgets.org



Feedback greatly appreciated !

Francesco Montorsi

Re: [wxCode-users] Announcing wxWPM 0.2: wxWidgets Package Manager

[<msz...@ya...>]

Every one on wxCode could try this if is no too much hassle and offer it
as a download option. In the hope of having a nice users base.  It would
be nice to have a nice packaging system for our wxWidgets applications.
I'll try to use it in the next wxARG release.

Regards, Matías.

Francesco Montorsi escribió:
> Hi all,
>    I'm posting this announce here as I think that even if wxWPM is not a 
> wxCode component, you'll still be interested:
>
> I'm pleased to announce a new release of the wxWPM, the wxWidgets 
> package manager project.
>
>
> What is it?
> -----------
>
> The wxWidgets Packager Manager project (wxWPM in short) provides the 
> tools to create and use a new format of source packages: the wxWidgets 
> packages.
>
> The wxWidgets packages are simple compressed archives containing a WXP 
> (wxWidgets package descriptor file) which contains the info used by the 
> Package Manager to build (i.e. compile), install or uninstall the 
> package on the user's system using the build system of the packaged 
> software (e.g. bakefile or cmake).
>
> The concept is very similar to the DevC++'s devpaks, but unlike them 
> wxWidgets packages are cross-platform and are completely abstracted from 
> the build system used by the packaged project.
> They are aimed to make the software modular and easy reusable!
>
> Packaging your software using the wxWidgets Packager GUI is extremely 
> easy; once you've filled in the fields, it will even help you to make 
> new releases of your software faster (creating the .zip and .tar.gz 
> archives automatically excluding unwanted files); you won't even need to 
> upload/distribute a new file as you can reuse your source releases (the 
> usual .zip, .tar.gz archives) as wxWidgets packages (just putting a 
> package descriptor inside them)!
>
>
> What does it provide?
> ---------------------
>
> The wxWPM project provides three applications:
>
>    1. a GUI Package Manager which can be used to browse remote 
> repositories of packages, download the selected packages, build them 
> using the user-specified configuration and finally install them.
>
>    2. the wxWidgets GUI Packager: an intuitive tool which creates the 
> wxWidgets package descriptors (WXP) and will create the wxWidgets 
> compressed package.
>
>    3. the third application is a command-line manager which provides all 
> functionalities of previous apps from command-line, allowing to e.g. 
> script the download and the installation of the latest version of your 
> favourite packages.
>
> This project was initially sponsorised by Google in its Summer Of Code 
> 2006, developed by Francesco Montorsi and mentored by Julian Smart.
>
>
> Links
> -----
>
> To learn more about wxWPM:    http://wxwpm.sourceforge.net
> wxWPM screenshots page:       http://wxwpm.sourceforge.net/screenshots.php
> wxWPM download page:          http://wxwpm.sourceforge.net/download.php
>
> To learn about wxWidgets:     http://www.wxwidgets.org
>
>
>
> Feedback greatly appreciated !
>
> Francesco Montorsi
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
>
>   


	

	
		
__________________________________________________ 
Preguntá. Respondé. Descubrí. 
Todo lo que querías saber, y lo que ni imaginabas, 
está en Yahoo! Respuestas (Beta). 
¡Probalo ya! 
http://www.yahoo.com.ar/respuestas 

[wxCode-users] wxCode problems and wxWPM (was Re: Announcing wxWPM 0.2: wxWidgets Package Manager)

[Francesco M. <f18...@ya...>]

Matías Szeftel ha scritto:
> Every one on wxCode could try this if is no too much hassle and offer it
> as a download option. In the hope of having a nice users base.  It would
> be nice to have a nice packaging system for our wxWidgets applications.
> I'll try to use it in the next wxARG release.
Great, thanks!

This makes it possible for me to introduce a big topic which I already wanted to 
do :)

Currently wxCode internals have some drawbacks:

  1) administration is not as easy as it should be: approving new components 
takes various time and the current internal structure of wxCode website is not 
very easy-to-update / straightforward.

  2) browsing the component list is not as fast as possible: except for the 
links at the top and at the bottom of the page (those to other categories of 
components) the content is still generated on-the-fly.
Initially I thought to cache only the links (since generating that set of links 
is a _very_ slow operation) to allow the developer which uses the

  http://wxcode.sourceforge.net/edit.php

page to immediately see his changes reflected on the component list page, 
without the need of waiting that some cron job on SF regenerates that page.

However, I now realize that the infos of the components are not updated so often 
  and that the entire contents of the complist.php page could easily be cached 
and refreshed only, say, once per day.

  3) component infos are not in CVS: before my restructuring of wxCode the (very 
few) info characterizing each components were kept in the Readme.txt file which 
any component should have placed in its root folder.
While this made impossible an automatic generation of nice web reports, it was 
more programmer-friendly than the current DB-driven solution because it allowed 
the developer to avoid to use the web interface at 
http://wxcode.sourceforge.net/edit.php to modify and/or keep updated the 
component infos. The file was kept in the source repository and thus when e.g. 
making a new release the programmer only had to modify the version number there.

I don't know how many of you use http://wxcode.sourceforge.net/edit.php but I'd 
guess (not sure however) that many components have outdated infos also because 
of the lazyness of the programmer to update the wxCode internal DB.

  4) programmers do not keep up2date their components / upload sources to CVS.

  [ 5) if you think I'm missing something else, please say your opinion... ]


If we decide to solve problem #2, i.e. cache the components HTML description, 
then the wxWPM project may help us to partially solve #1, #3 problems providing 
the following (big IMO) advantages:

  1) the component infos would be stored in the CVS in an XML-like format, i.e. 
as a wxWidgets package descriptor (WXP).
A sample WXP file for my wxXml2 component is at:

http://wxcode.svn.sourceforge.net/viewvc/wxcode/trunk/wxCode/components/wxxml2/build/wxxml2.wxp?view=markup

having it in the CVS/SVN allows the developer to easily keep it updated.


  2) the component list HTML pages could be easily created using 'wxp' command 
line program (just look at http://wxwpm.sourceforge.net/packages.php - it looks 
familiar, isn't it ;) ?), and thus also cached and regenerated anytime there's a 
change.

Also, updating the website to e.g. a new look would be extremehely easy: just 
changing the "viewformat" used by the 'wxp' utility (while to change the look of 
the component list would currently require changing lots of PHP code).


  3) it would simplify the wxCode website structure, because the DB should not 
be necessary anymore: from that WXP file (which also contains MORE INFO on the 
component rather than those currently contained ), the 'wxp' command line 
utility can generate the HTML description of the packages. Thus the wxCode PHP 
website should not query the DB anymore but rather use those cached HTML code 
snippets.


  4) the maintainer of the component could create more easily the releases of 
his component. With the info taken from the WXP the 'wxp' utility is able to 
automatically create the .zip or .tar.gz excluding e.g. the object files, the 
CVS/.svn folders from the archive, etc.
Those releases would automatically be directly usable as wxWidgets packages from 
the wxWPM Package Manager.


The drawbacks of switching to the use of WXP files rather than the current DB 
solution:

  1) administrators of wxCode should necessarily install 'wxp' utility to update 
the HTML descriptions and/or add new components

  2) all the maintainers should keep the WXP file (and update it) in the repo of 
their components.


What do you think? Are they acceptable?


Looking forward to hear your opinion,
Francesco

[wxCode-users] RFC - Re: wxCode problems and wxWPM

[Francesco M. <f18...@ya...>]

Hi all,
   what about this?

the mail is long but if you want just the "summary" you can read just 
the last lines ;)

Thanks!
Francesco



Francesco Montorsi ha scritto:
> Matías Szeftel ha scritto:
>> Every one on wxCode could try this if is no too much hassle and offer it
>> as a download option. In the hope of having a nice users base.  It would
>> be nice to have a nice packaging system for our wxWidgets applications.
>> I'll try to use it in the next wxARG release.
> Great, thanks!
> 
> This makes it possible for me to introduce a big topic which I already wanted to 
> do :)
> 
> Currently wxCode internals have some drawbacks:
> 
>   1) administration is not as easy as it should be: approving new components 
> takes various time and the current internal structure of wxCode website is not 
> very easy-to-update / straightforward.
> 
>   2) browsing the component list is not as fast as possible: except for the 
> links at the top and at the bottom of the page (those to other categories of 
> components) the content is still generated on-the-fly.
> Initially I thought to cache only the links (since generating that set of links 
> is a _very_ slow operation) to allow the developer which uses the
> 
>   http://wxcode.sourceforge.net/edit.php
> 
> page to immediately see his changes reflected on the component list page, 
> without the need of waiting that some cron job on SF regenerates that page.
> 
> However, I now realize that the infos of the components are not updated so often 
>   and that the entire contents of the complist.php page could easily be cached 
> and refreshed only, say, once per day.
> 
>   3) component infos are not in CVS: before my restructuring of wxCode the (very 
> few) info characterizing each components were kept in the Readme.txt file which 
> any component should have placed in its root folder.
> While this made impossible an automatic generation of nice web reports, it was 
> more programmer-friendly than the current DB-driven solution because it allowed 
> the developer to avoid to use the web interface at 
> http://wxcode.sourceforge.net/edit.php to modify and/or keep updated the 
> component infos. The file was kept in the source repository and thus when e.g. 
> making a new release the programmer only had to modify the version number there.
> 
> I don't know how many of you use http://wxcode.sourceforge.net/edit.php but I'd 
> guess (not sure however) that many components have outdated infos also because 
> of the lazyness of the programmer to update the wxCode internal DB.
> 
>   4) programmers do not keep up2date their components / upload sources to CVS.
> 
>   [ 5) if you think I'm missing something else, please say your opinion... ]
> 
> 
> If we decide to solve problem #2, i.e. cache the components HTML description, 
> then the wxWPM project may help us to partially solve #1, #3 problems providing 
> the following (big IMO) advantages:
> 
>   1) the component infos would be stored in the CVS in an XML-like format, i.e. 
> as a wxWidgets package descriptor (WXP).
> A sample WXP file for my wxXml2 component is at:
> 
> http://wxcode.svn.sourceforge.net/viewvc/wxcode/trunk/wxCode/components/wxxml2/build/wxxml2.wxp?view=markup
> 
> having it in the CVS/SVN allows the developer to easily keep it updated.
> 
> 
>   2) the component list HTML pages could be easily created using 'wxp' command 
> line program (just look at http://wxwpm.sourceforge.net/packages.php - it looks 
> familiar, isn't it ;) ?), and thus also cached and regenerated anytime there's a 
> change.
> 
> Also, updating the website to e.g. a new look would be extremehely easy: just 
> changing the "viewformat" used by the 'wxp' utility (while to change the look of 
> the component list would currently require changing lots of PHP code).
> 
> 
>   3) it would simplify the wxCode website structure, because the DB should not 
> be necessary anymore: from that WXP file (which also contains MORE INFO on the 
> component rather than those currently contained ), the 'wxp' command line 
> utility can generate the HTML description of the packages. Thus the wxCode PHP 
> website should not query the DB anymore but rather use those cached HTML code 
> snippets.
> 
> 
>   4) the maintainer of the component could create more easily the releases of 
> his component. With the info taken from the WXP the 'wxp' utility is able to 
> automatically create the .zip or .tar.gz excluding e.g. the object files, the 
> CVS/.svn folders from the archive, etc.
> Those releases would automatically be directly usable as wxWidgets packages from 
> the wxWPM Package Manager.
> 
> 
> The drawbacks of switching to the use of WXP files rather than the current DB 
> solution:
> 
>   1) administrators of wxCode should necessarily install 'wxp' utility to update 
> the HTML descriptions and/or add new components
> 
>   2) all the maintainers should keep the WXP file (and update it) in the repo of 
> their components.
> 
> 
> What do you think? Are they acceptable?
> 
> 
> Looking forward to hear your opinion,
> Francesco
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[wxCode-users] subversion link (was Re: wxCode problems and wxWPM)

[Francesco M. <f18...@ya...>]

cecilio ha scritto:
> Hi Francesco,
> 
> I have detected a problem in the wxCode component page for my
> component wxMIdi. Probably the bug is also in other pages but I didn't
> check. The problem is that I moved my component time ago to SVN. But
> in the component page there is still a 'Browse CVS' link pointing to
> obsolete code at CVS, 
this problem has now been fixed.

Francesco

Re: [wxCode-users] subversion link (was Re: wxCode problems and wxWPM)

[cecilio <s.c...@gm...>]

Hi Francesco,

> this problem has now been fixed.

Great! Thank you very much. I have tested the page and the link and works ok.

Thank you.
Cecilio

Re: [wxCode-users] wxCode problems and wxWPM (was Re: Announcing wxWPM 0.2: wxWidgets Package Manager)

[cecilio <s.c...@gm...>]

Hi Francesco,

I have detected a problem in the wxCode component page for my
component wxMIdi. Probably the bug is also in other pages but I didn't
check. The problem is that I moved my component time ago to SVN. But
in the component page there is still a 'Browse CVS' link pointing to
obsolete code at CVS, and there is not a 'Browse SVN' link pointing to
updated code. So please, I would appreciate if the CVS code could be
deleted and the 'browse CVS' links updated to point to SVN.

Thank you.
Regards,
Cecilio

Re: [wxCode-users] wxCode problems and wxWPM (was Re: Announcing wxWPM 0.2: wxWidgets Package Manager)

[Francesco M. <f18...@ya...>]

cecilio ha scritto:
> Hi Francesco,
> 
> I have detected a problem in the wxCode component page for my
> component wxMIdi. Probably the bug is also in other pages but I didn't
> check. The problem is that I moved my component time ago to SVN. But
> in the component page there is still a 'Browse CVS' link pointing to
> obsolete code at CVS, and there is not a 'Browse SVN' link pointing to
> updated code. So please, I would appreciate if the CVS code could be
> deleted and the 'browse CVS' links updated to point to SVN.

This is a known issue, sorry.

I'll fix it ASAP together with some changes to wxCode structure.

I'd only like to get some feedback on the "wxCode problems and wxWPM" 
thread before going on the changes...

Francesco